Deprecation
warnings are very important, and we must avoid calling any deprecated
API. Sun JDK is not our only
dependency, and even Sun does eventually remove deprecated API (compare JDK
6 with JDK 1.1 and there are many APIs that have been removed). But more importantly deprecated API
are obsolete and have typically been replaced by much better and better
performing API. Several of our
concurrency and performance problems have been attributed to using
deprecated API and obsolete classes.
It is important to keep our code base current and up to data with the
evolving technologies that we are dependent
on.
It
is also important to ensure we are not using any of own deprecated API, and
have not incorrectly deprecated an API. This is especially important in
testing, where we must be testing using the same API that we intend our
clients to use, not deprecated API.
Fixing
many of these code warnings can actually be quite simple, and we should be
fixing testing as well as product code. In many cases Eclipse or other IDEs
provide automated ways to fix warnings for the entire project with a single
click. Refactoring and global
search and replace can also fix many issues very
easily.
I
don't agree that our solution to IDE warnings should be to turn off the
warnings (although some seem a little odd). Turning them off ensures that new
code developed will have the same
errors.
-----Original
Message-----
From:
eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of Mike Keith
Sent: Wednesday, October 10, 2007 2:02
AM
To: Dev mailing list for
Eclipse Persistence Services
Subject: RE: [eclipselink-dev] Eclipse
IDE Error/Warning Levels
I
agree with phase 1.
I
don't think that the deprecation warning level need ever be turned on,
though, even in phase 2. Deprecation means nothing, really, and Sun has even
said that they do not ever plan on removing deprecated API. I keep that
Eclipse warning eternally turned off in all my Eclipse
projects.
I am
not sure that in phase 3 the same level of quality needs to be in place for
the tests, but as was mentioned I think we can discuss what an acceptable
level is when we reach that bridge.
-----Original
Message-----
From:
eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of Doug Clarke
Sent: Tuesday, October 09, 2007 11:18
AM
To:
eclipselink-dev@xxxxxxxxxxx
Subject: [eclipselink-dev] Eclipse IDE
Error/Warning Levels
EclipseLink
Developers,
During our
incubation phase I would like to propose an approach to dealing with the
many warnings we get in the Eclipse IDE for our code base. Historically
these have not been a great concern to TopLink development but I feel that
the move to Eclipse should include an effort to work on overall code quality
and we should leverage the Eclipse IDE tooling to do
this.
We have
a very large number of warning across our projects that make addressing
these easily a difficult task. To make this more manageable I would like to
propose a phased approach with concrete items in the project back-log to
address them.
STEP 1: Turn down
the warning levels within the project settings to get to a manageable number
of warnings we can address.
·
In
all project source projects we will turn off warnings for deprecation,
serialVersionUID, and unchecked generic type operations
·
In
all test case projects we will turn off these warnings as well as the unused
imports, local variable is never read, an unused local or private member
warnings
This will get us
down to a more manageable warning level and we can add specific items to the
project back-log to get these addressed.
STEP 2: After the
above warnings have been addressed through code changes and we have
addressed the deprecated code removal we can increase the warning level to
include deprecation as well as any additional ones the developers feel are
useful to the source projects.
STEP 3: Increase
the warning levels on the test case projects as determined by the
developers.
Based on this
proposal I would like to proceed with modifying the existing project's
warning levels and checking them in. Please provide feedback on this
proposal by COB Thursday.
Doug
![Oracle Email Signature Logo]()
Doug
Clarke | Principal Product Manager, Oracle
TopLink
Oracle Server
Technologies
45 O'Connor, Suite 4000 |
Ottawa, ON
K1P
1A4 Canada
