Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Using Java 5 Features in Older JDKs

Hemos posted more than 7 years ago | from the if-you-had-to-of-course dept.

Programming 37

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."

cancel ×

37 comments

Sorry! There are no comments related to the filter you selected.

OMG this is GREAT news!! (0, Troll)

Southphillyman (1064260) | more than 7 years ago | (#18238724)

*faints*

Retroweaver (2, Informative)

Anonymous Coward | more than 7 years ago | (#18238898)

Can't get to TFA for some reason, but isn't this the point of Retroweaver [sf.net] ?

Re:Retroweaver (3, Interesting)

Sciros (986030) | more than 7 years ago | (#18239082)

Indeed. It is mentioned at the closing of the article.

Personally I'm a bit frustrated by this being a noteworthy topic... I'm a Java dev and I really wish accomodating pre-java 5 JVMs wasn't ever needed. Reminds me too much of web development.

Re:Retroweaver (2, Informative)

Anonymous Coward | more than 7 years ago | (#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 (2, Informative)

Sciros (986030) | more than 7 years ago | (#18240510)

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.

Fun but not massively practical (5, Insightful)

dintech (998802) | more than 7 years ago | (#18238926)

I've worked in a an environment where 1.4 and lower is mandatory. This was down to management believing that 1.5 was too new and 'untested' even though Sun obviously thought it production worthy.

These kind of people would be very scared if you tried to write code using 1.5, recompile the byte code using some new-ish open source toolkits and then putting it in to production. Then again, you could do it without telling anyone. :)

Re:Fun but not massively practical (2, Interesting)

Dan Hayes (212400) | more than 7 years ago | (#18240578)

You think that sucks, I have to code to the last MS JVM, which was 1.1.8 I think. A significant proportion of our userbase still uses it sadly - people still running Win98 most likely. It's very annoying... although I did manage to find a bug in JRE 6 within a day of its release which broke a small but not-insignificant proportion of websites serving applets, well done Sun for not spotting that one when testing your new caching system.

So to add mouse-wheel support to our applet for those actually using a new JVM, I had to jump through a whole bunch of hoops involving reflection to load classes that exist just to implement the MouseWheelEventListener interface and do a callback to the code. Annoying, I had to do a similar thing to get anti-aliasing to work as well.

Re:Fun but not massively practical (1)

Nimey (114278) | more than 7 years ago | (#18253280)

Are you doing web applets? If not, call me crazy, but couldn't you distribute JRE 1.5.xx on your product's CD? I've seen a few commercial packages that do this.

Re:Fun but not massively practical (1)

Dan Hayes (212400) | more than 7 years ago | (#18260520)

Yeah, it's web applets, probably about as complex as they get - a small stub signed applet which acts as a class loader and downloads and caches class files which require updating from our site (the codebase is several megs), and then a set of applications that run on top of that. Some of the simplest applications are being ported to Flash, but I'd hate to try and do some of the more complex stuff we've got in ActionScript.

Re:Fun but not massively practical (2, Informative)

alan_dershowitz (586542) | more than 7 years ago | (#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.

Re:Fun but not massively practical (1)

tlh1005 (541240) | more than 7 years ago | (#18244732)

This was down to management believing that 1.5 was too new and 'untested' even though Sun obviously thought it production worthy.

I love Java just as much as the next guy but just because Sun releases it into production doesn't mean there won't be regressions, new bugs, security alerts released saying move up to _xx to fix the problem, and then more of the same is found in the "fixed" release.

These kind of people would be very scared if you tried to write code using 1.5, recompile the byte code using some new-ish open source toolkits and then putting it in to production. Then again, you could do it without telling anyone. :)

I wouldn't want to work in an environment where someone, or some build system WOULDN'T notice this kind of change. Don't get me wrong, I'm one of the guys who wants to upgrade; I just know it needs to be done carefully, and I have also seen what happens when hundreds of developers start implementing new language features without thoroughly thinking through the impact on the overall product(s) and requirements.

Re:Fun but not massively practical (1)

oSand (880494) | more than 7 years ago | (#18247412)

"Then again, you could do it without telling anyone"

Then you will be a convenient scapegoat for any particular calamity that occurs on the project. Performance problems, client goes out of business, server room on fire- you name it.

These have been around for years (4, Informative)

ghoti (60903) | more than 7 years ago | (#18238936)

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.

Re:These have been around for years (1, Informative)

Anonymous Coward | more than 7 years ago | (#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.

Re:These have been around for years (4, Interesting)

hansamurai (907719) | more than 7 years ago | (#18239164)

If only everybody has updated to 1.5. The middle tier of our online product where I work is running on 1.4.2 with just a rumbling of upgrading to 1.5. That upgrade probably won't occur for another year for various reasons that I'm not involved in. I think the bigger the company and the bigger the product, the slower the upgrading process is. I think some architects may even be fearful of 1.5, as I just joined a new project that is running on 1.4.2.13, and they started developing that just last November!

Anyways, Java 5 has some great features but nothing that is absolutely required from my department's point of view. Autoboxing is a nice feature that helps clean up your code, but nothing we can't do now. Same for the new for-each loop. I could go on but this has been discussed to death already. I would rather we just upgrade so we can start taking advantage of the new features and supposed speed increases.

Re:These have been around for years (2, Interesting)

RevWhite (889559) | more than 7 years ago | (#18239346)

I think the bigger the company and the bigger the product, the slower the upgrading process is.

I agree with the former, at least. I work for a fairly large organization where nothing terribly critical or large is running on Java, but they still won't standardize, so some things run JVM, some run 1.3, some 1.4, and several apps need specific patch levels of 1.3 or 1.4.

Re:These have been around for years (0)

Anonymous Coward | more than 7 years ago | (#18239478)

Write once, debug everywhere?

Re:These have been around for years (2, Informative)

iabervon (1971) | more than 7 years ago | (#18240908)

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.

Re:These have been around for years (2, Informative)

EsbenMoseHansen (731150) | more than 7 years ago | (#18242546)

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

Re:These have been around for years (0)

Anonymous Coward | more than 7 years ago | (#18243122)

Some people just cannot update, as the applications they are using will not run on the newer JREs.

Java is not platform independent, it is its own platform.

I'd rather compile from C(++) source on the platform of my choice, thanks.

Re:These have been around for years (1)

clay_buster (521703) | more than 7 years ago | (#18249582)

I've worked on Java teams at two large companies in the last year. Both companies had multiple projects some over 1M lines of Java code. None of the projects were on JDK 1.5 in production. Company 1. Too much code was already in production. Switching to JDK 1.5 involved migrations through all 4 different environments and a full regression test. It's often hard to justify that amount of work to bookkeepers and business users. Company 2. Moving from weblogic to WebSphere using IBM's JDK. Support wasn't there for the first 9 months of the project. All the environments are built out Websphere 6.0/jdk 1.4. Now we only have 3 months until production so we are going out on 1.4. Moving forward, a change to JDK 1.5 means we need twice as many Websphere instances because we need JDK 1.4 for all environments for production support and JDK 1.5 for all environments for the new development. It is a major logistical issue.

the bleeding obvious... pointed out... (5, Insightful)

bitbucketeer (892710) | more than 7 years ago | (#18239152)

Java 1.6 is out now. 1.5 is so, like, last year.

Re:the bleeding obvious... pointed out... (4, Informative)

Zonk (troll) (1026140) | more than 7 years ago | (#18239500)

Java 1.5 was released 09/29/2004, so it's over two years old. 1.6 was release 12/12/2006.

Re:the bleeding obvious... pointed out... (0)

Anonymous Coward | more than 7 years ago | (#18240088)

So what you're saying is, last year what we had was 1.5? So 1.5 is so...last year?

Re:the bleeding obvious... pointed out... (1)

Ilgaz (86384) | more than 7 years ago | (#18249810)

It doesn't work that way in Java. I am sure there are still people running 1.3.x out there. OS X still doesn't have official (final/ public release) Java 1.6 for instance.

I am sure massively popular apps like Azureus, Limewire are already using such stuff mentioned in article.

Autoboxing (3, Funny)

mccrew (62494) | more than 7 years ago | (#18239242)

Autoboxing, a bad idea - automated!

Re:Autoboxing (1)

nullchar (446050) | more than 7 years ago | (#18246868)

What? Not having to: object.toPrimitiveValue() is great! Use the object where you allow NULLs and use the primitive otherwise.

jsr14 compiler target (3, Informative)

Anonymous Coward | more than 7 years ago | (#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

Re:jsr14 compiler target (2, Informative)

caseih (160668) | more than 7 years ago | (#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.

cldc1.0 (2, Informative)

pjt33 (739471) | more than 7 years ago | (#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.

Retroweaver has more features than reported (5, Informative)

xlv (125699) | more than 7 years ago | (#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

Is it just me (1)

zappepcs (820751) | more than 7 years ago | (#18239736)

or did anyone else read the title and see "Using Java 5 Features in Older *JoKes*"

Misinformation about Retroweaver (3, Interesting)

rreyelts (470154) | more than 7 years ago | (#18239918)

Disclosure: I'm the Retroweaver author.

The article seems to miss all of the features that Retroweaver has added over the past year. I think the author may not have been paying attention to the active releases on-going with Retroweaver. For example, Retroweaver supports every feature that the author purports is specific to Retrotranslator.

I have been spending less of my personal time on Retroweaver over the past year, but Xavier Le Vourch [sourceforge.net] has been doing an excellent job improving Retroweaver over that period.

Still stuck with old URLConnection (1)

Kenja (541830) | more than 7 years ago | (#18241478)

Bah, still stuck with the old URLConnection in 1.4.2 that dosn't have a timeout. Ah well, got my hopes up there for a moment. On a sinde note, anyone know how to set the timeout of Sunlabs.brazil's HTTPConnect?

Java on Mac (1)

tomaasz (5800) | more than 7 years ago | (#18245518)

While it's true that most businesses should have upgraded to 1.5 a long time ago, that's just the server side. Most Mac computers still run Java 1.4; I develop Java games for PC and Mac and I need them to run on 1.4.

Retroweaver is a great tool that allows me to use the language features of Java 1.5. I miss the improved 1.5 standard classes, ie. the improved string manipulation (String.format() with printf formatting for instance). At least I get a warning from Retroweaver..

Re:Java on Mac (1)

xlv (125699) | more than 7 years ago | (#18247234)

Basic support for String.format was added recently in retroweaver. If you let me know what you need or submit a patch for enhanced support, we can make sure the features you need are incorporated in future versions of retroweaver.

Xavier
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>