| RE: [eclipselink-dev] Eclipse IDE Error/Warning Levels |
|
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----- 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----- 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
|