Skip to main content

Have you switched your development to J2SE 5.0 yet?

Completely
25% (361 votes)
Partially
23% (325 votes)
Not at all
45% (639 votes)
Don't intend to
7% (93 votes)
Total votes: 1418

Comments

moving to sun jdk 1.5

Hi There, For those folks looking to switch to Java 1.5/Tiger, be aware of those things that could break your code. Our 1.4 code used java.util.regex package. Many of the regexes simply broke when we moved to sun's JDK 1.5. This was very surprising. So, be careful -- you have been warned. All the same, our code works faster in 1.5. Would be interesting to know how other JVMs fare -- I know that JRockit has a 1.5 release but I am not sure if they have any updates to that. BR, ~A

Java 1.5

Hi There, For those folks looking to switch to Java 1.5/Tiger, be aware of those things that could break your code. Our 1.4 code used java.util.regex package. Many of the regexes simply broke when we moved to sun's JDK 1.5. This was very surprising. So, be careful -- you have been warned. All the same, our code works faster in 1.5. Would be interesting to know how other JVMs fare -- I know that JRockit has a 1.5 release but I am not sure if they have any updates to that. BR, ~A

Java 1.5

Hi There, For those folks looking to switch to Java 1.5/Tiger, be aware of those things that could break your code. Our 1.4 code used java.util.regex package. Many of the regexes simply broke when we moved to sun's JDK 1.5. This was very surprising. So, be careful -- you have been warned. All the same, our code works faster in 1.5. Would be interesting to know how other JVMs fare -- I know that JRockit has a 1.5 release but I am not sure if they have any updates to that. BR, ~A

We've moved

We are fortunate enough to ship a shrink-wrapped product which means we can include whichever JRE we want with the server installation.

Our app makes heavy use of annotations, which in my mind is the best new feature in 1.5. We've also adopted our code base for generics, although that is a feature which is much less useful than annotations.

The only 1.5 feature which is expressively banned in our project is static import. The recommendation is also that autoboxing is to be avoided.

not for commercial work

I'm now using 1.5 for private projects. Our customers (and our company servers) run operating systems for which there's no 1.5 VM available so for them I still use 1.4 and probably will for the foreseeable future.

Client Only

Most of the major servers aren't even 1.4 level yet so this will take a long,long time.

Changing is a process

Many dev organizations change environments only on the beginning stages of a major release. This can take 6 months to a year once the new technology is percieved to be "ready".

We'll be moving to 1.5 on a new product, but I don't know how many of the new cool features we'll use since we still need backwards compatibility. So many we'll complie for 1.4 compliance but run on 1.5. Our main reason to move to 1.5 is performance issues.

On existing products we've only just moved to 1.4.

Not everyone can use 1.5

I was disappointed recently with the game garden thing which required 1.5... and being on a Mac I didn't have the ability to run those web start-lets. I don't know if 1.5 is going to be in the next version of OS X (to confuse things even further which is also called tiger, or 10.4). I admit to being a bit surprised... I'd thought that most of the 1.5 new features were just syntactic sugar for the developer, and wouldn't actually have much (or any) impact on the bytecode. Is there a way to have the cake and eat it too? Ie that the people that like the new features can write code using them, but that the bytecode produced is also compatible with 1.4 jvms?

I would like to, but there is just too much legacy!

The widespread adoption of Java may be a blessing, or a curse; I still haven't decided myself. However, with so many people using it, the cost of changing the foundation has already become prohibitively high. Sun may have to consider creating a whole new language; one that cleanly extends, and is fully backward compatible with, the provious one. Perhaps they might call it: Objective Java ;-)