An Open Letter to the JSR 310 Community

Sunday, May 13. 2007

An Open Letter to the JSR 310 Community

After an exciting JavaOne for all of us, and a great jsr 310 BOF session, I thought I'd type of some thoughts that I have, and things I'd like to see happen in this space from an application developer department.

The day after the BOF, I just happen to sit with the Sun JDK date/calendar group during lunch, and we got to talk about the exciting things happening in this space...

I'm sure these discussions and thoughts have already occurred.. but in the off chance that they haven't I'd like to share them....

Upgrading / Migration Path -

I will like to see transformation/adapter utilities included into the JSR, for transforming the legacy date/calendar objects into the new JSR objects.

I believe in the application developer space there will be a slow migration process to the new apis for legacy ... Most likely this migration path will be an iterative process for us vs. the traditional waterfall in our project plans. This migration path will also be dependent on third party API developers providing support.. Especially in the ORM space. So these utilities should be part of the core API, and the should at a minimum cover java.util.Date, java.util.Calendar, and java.sql.* related date time facilities.

also there will need to be some sort of "marketing" campaign to the open source developers who develop the 3rd party libraries to start to migrate their applications as soon as possible. have there been any thought into this process?

Object Model -
I'm not speaking for the existing java.util.Date/Calendar jdk team, but they expressed concerns over the object model. The complexity, and the overall getting up to speed time. I have not personally used the joda libraries so I couldn't tell them how effective this transition is. They were also concerned on how many objects will exist in the packages and how it will relate to the complexity. I share some of the same concerns of complexity. I do however really like the demoed objects and structure that I saw during the BOF session and how you express the conceptional aspects of the date & time object, as well as their operations. I believe you guys are on the right track. My main recommendation is to make sure the javadocs are rock solid, provide two aspects to them, and make sure those aspects are clearly marked up... the Quick & Dirty tips to get the answers in 30 seconds of reading, and then for more abstract concepts or power-tips provide them as well.

Legacy APIs ... I know this has been discussed extensively in the past, especially for java.util.Date. Since we have had these methods deprecated for years, can we finally just remove the deprecated methods, and use it just as a value object? I know this is outside of the scope of this JSR, but it would be nice to include it, and figure it out, so we can start cleaning up the legacy API.

I know this isn't feasible but the way I'd would like to deal with this is, have the compilers throw compile errors if these deprecated objects/methods are used (to force a refactoring), but have the JRE still allow them so it doesn't break the current deployments, and the previously generated byte code. Perhaps the gentleman that I sat with during lunch can provide some thoughts on this...

I'd just like to reiterate a final time, that I'm glad that this work is occurring in the space, and look forward to the improvements that your hard work has provided..

Posted by cfrostrun in Java at 08:57 | Comments (3) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Rather than the compiler throwing errors I would simply like an official End Of Life program for deprecated methods.

Once an established, tested and familiar alternative exists an official End Of Life should be declared - The End Of Life expresses the Java release at which that element will no longer exist in the API. This could possibly be specified as an argument to the Deprecated annotation for documentation purposes.

For example, if java.util.Date were deprecated in 1.7 and during the development of 1.8 the community process deems the adoption of the new APIs to be progressing well it could decide that java.util.Date will no longer appear in 1.9 (probably a tad over-enthusiastic).

@Deprecated(endOfLife="1.9")

Specifying an explicit End Of Life gives tool developers a healthy sense of urgency and aids in prioritising efforts to move away from deprecated API content.

Simplifying the API as the language becomes more complex to learn is crucial to maintaining up-take of java and ensuring that newly skilled developers continue to enter the marketplace.

#1 Talden (Homepage) on 2007-05-23 14:14 (Reply)

I'd love that to be true. But what about all the Java programs out there that are expected to run as normal? I'm not sure it is being realistic that we can ever get rid of that stuff...

#1.1 Kieron on 2007-06-14 00:34 (Reply)

In some JSR's like the Java EE 'Umbrella' 316, the term 'pruning' is used a lot for those kinds of SDK cleanups.

Until something like that is imaginable, I suggest some kind of Wrapper or translator was a good idea to convert between the 2 APIs.

A slightly less known implementation by rather well known people (like Eric Evans or Martin Fowler) covering some aspects of Date and Time has a similar thing in the way of 'toJDKCalendar' which once this JSR was a full part of Java, too may have to be renamed into something like 'toLegacyCalendar' or similar.

#2 Werner Keil (Homepage) on 2007-10-01 18:36 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry