RE: [eclipselink-dev] Eclipse IDE Error/Warning Levels

["Mike Keith" <michael.keith@xxxxxxxxxx>]

Actually I am not aware of a single API call that Sun has actually removed since Java 1.2, and have heard people like Bill Shannon from Sun state numerous times that they have no plans to remove deprecated API. The compatibility problems with doing so are too encumbering.

 

If we were able to remove all of the deprecated code from the product then I would not have a problem with the default set to issue deprecation warnings. The problem is that in practice there is probably going to be some amount of code that uses some deprecated API somewhere. That is just the way it typically goes and I don't want our default settings to produce "expected" warnings.

 

Depending upon the tool and the problem, a tool may or may not be suitable, but we would need to look at that on a case-by-case basis.

 

I do agree that having the option disabled would not discourage people from using deprecated API, however, I would think that the code review process should check for those kinds of things.

-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of James Sutherland
Sent: Wednesday, October 10, 2007 9:16 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: 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-----
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

 

 

 

Doug Clarke | Principal Product Manager, Oracle TopLink 
Oracle Server Technologies
45 O'Connor, Suite 4000 | Ottawa, ON  K1P 1A4 Canada