Forgot your password?
typodupeerror
Programming IT Technology

Using Java 5 Features in Older JDKs 37

Posted by Hemos
from the if-you-had-to-of-course dept.
BlueVoodoo writes "Java 5 added a number of powerful language features: generics, enumerations, annotations, autoboxing, and the enhanced for loop. Even if you're stuck on JDK 1.4, you can still use generics. Use Java and theory to learn how."
This discussion has been archived. No new comments can be posted.

Using Java 5 Features in Older JDKs

Comments Filter:
  • Retroweaver (Score:2, Informative)

    by Anonymous Coward on Monday March 05, 2007 @01:01PM (#18238898)
    Can't get to TFA for some reason, but isn't this the point of Retroweaver [sf.net]?

  • by ghoti (60903) on Monday March 05, 2007 @01:04PM (#18238936) Homepage
    It's great that IBM is writing this, but these tools have been around for years. They basically came out the same time as the final release of Java 1.5 (or "5.0"), when many people realized that it would be tricky to deploy programs that were using the new features. By now, everybody should have updated to 1.5 anyway.
  • by Anonymous Coward on Monday March 05, 2007 @01:20PM (#18239142)
    *lol* People are still running production apps on 1.3.

    Moving a large infrastructure to a new JDK, while a Really Good Idea, is non-trivial and can be very expensive.
  • by Zonk (troll) (1026140) on Monday March 05, 2007 @01:42PM (#18239500)
    Java 1.5 was released 09/29/2004, so it's over two years old. 1.6 was release 12/12/2006.
  • by Anonymous Coward on Monday March 05, 2007 @01:53PM (#18239630)
    You can use the undocumented, unsupported 'jsr14' target in javac to compile 1.4-compatible bytecode from 1.5 source. No need for Retroweaver or other tools:
    javac -source 1.5 -target jsr14
  • by xlv (125699) on Monday March 05, 2007 @01:58PM (#18239678)
    I'm the current maintainer for Retroweaver and the article does not mention all the Retroweaver features:

    Annotations are supported, the concurrent backport is used for the concurrent packages, runtime classes can provide support for new features or replace classes entirely, ...

    I suppose the article is based on the 1.2.5 version and not the beta version(s). I guess I followed the Google model of having a really long beta cycle with a stable product...

    Seeing the possible confusion with the Beta tag, I just decided to release the official 2.0 version earlier today.

    Xavier
  • Re:Retroweaver (Score:2, Informative)

    by Anonymous Coward on Monday March 05, 2007 @02:10PM (#18239850)
    Uhmmmmmmmmm

    If I understand correctly, Generics are backwards compatible because of how they get compiled. As long as your development machine supports generics, you don't have to worry about them on older JVMs!

    This is about doing the development on older JVMs. This isn't a backwards compatibility issue in Generics themselves as much as a "If you already have backwards compatibility issues, but want X, here's how to do it."

    But I'm inclined to say if you have problems with JVM versions, you're either doing something wrong and funky or you're trying to develop too much on the bleeding edge.
  • Re:Retroweaver (Score:3, Informative)

    by Sciros (986030) on Monday March 05, 2007 @02:55PM (#18240510) Journal
    Class dependencies are different depending on the compiler, so there are a few situations where the JVM executing the code makes a difference. Java 5 isn't that new, so it's not even really bleeding-edge stuff.
  • by caseih (160668) on Monday March 05, 2007 @03:06PM (#18240646)
    If you'll read the article, you'll find that this is mentioned. In fact Retroweaver was around before this undocumented switch, and supports the same things plus a few additional features like the for-each loop, autoboxing, string concatenation, and enumerations. So you'll get a bit more mileage out of Retroweaver than just plain old -target jsr14.
  • by iabervon (1971) on Monday March 05, 2007 @03:24PM (#18240908) Homepage Journal
    Generics are really the important feature. Replacing "Map" with "Map<String, List<MyDetail>>" is really significant for being able to tell what the code is supposed to be doing and making it work correctly and reliably. For that matter, I had a problem with a commercial J2EE implementation back in the 1.3 days that was returning a Map<String, String> when it was supposed to return a Map<String, String[]>, which was not obvious because it was just returning a Map.

    Of course, this depends on figuring out how all your current code actually works, which can be a major undertaking.
  • cldc1.0 (Score:3, Informative)

    by pjt33 (739471) on Monday March 05, 2007 @05:08PM (#18242162)

    -target cldc1.0
    allows you to produce 1.3-compatible bytecode. It has the CLDC preverifier attributes in, but if you're worried about class file size you can strip them with an optimiser.
  • by EsbenMoseHansen (731150) on Monday March 05, 2007 @05:30PM (#18242546) Homepage

    Generics are really the important feature. Replacing "Map" with "Map<String, List<MyDetail>>" is really significant for being able to tell what the code is supposed to be doing and making it work correctly and reliably.

    Of course, this depends on figuring out how all your current code actually works, which can be a major undertaking.

    Yep, this is a step in the right direction. Then we just need the rest of the C++ template features, and we might be approaching something that approaches being a nice language. Like not throwing out half the types during runtime... how silly is that? Getting rid of that terrible Collection framework and replacing it with something STL like (improving the STL interface with a Range class) would be a nice bonus. Oh, and I can have a lambda function, too? And operator overloading. And ruby like setters/getters? Multiple inheritance, or at least mixins, too. And if it could actually make coffee..?

    Man, Java

    is just so damn LIMITING!

    Yes, I love that quote. Describes so much software I dislike :D

  • by alan_dershowitz (586542) on Monday March 05, 2007 @06:25PM (#18243324)
    Just because it's production-ready for Sun's purposes doesn't mean it's fully tested and supported by your J2EE application server (for example.) If it's not supported, you're on your own if you have a problem. That's why corporations don't switch right away. As far as code is concerned, if it ultimately ends up being targeted for the 1.4 JVM for example, your unit tests should still work, you're not running your server out of spec, and there shouldn't be any problem IMO.

"When it comes to humility, I'm the greatest." -- Bullwinkle Moose

Working...