On which version of Java are you running Eclipse with Spring IDE?

[Torsten Juergeleit]

For Spring IDE version 2.0 we would like to leverage the new language features of Java 5 (mostly generics, foreach loops and enums). Now we are wondering how many Spring IDE users are still running Eclipse on Java 1.4 and why.

Torsten

[mraible]

I've recently starting switching all my open source projects to Java 5.

+1 to JDK 5.

For projects requiring 1.4 compilation, there's always Retroweaver (http://retroweaver.sourceforge.net).

[Dave Syer]

I use both 1.5 and 1.4 in projects (so I voted for 1.4). Unfortunately the big container vendors are still on 1.4, so it isn't practical for people who use or might have to use (e.g.) WebSphere to switch to 1.5 yet.

I guess maybe that doesn't mean I can't use Java 5 to run Eclipse and Spring IDE? Maybe I should vote again...

[Marten Deinum]

+1 for Java 5 here also.

We are also currently in the process of switching our internal project to Java 5.

[betabagel]

Unfortunately the big container vendors are still on 1.4, so it isn't practical for people who use or might have to use (e.g.) WebSphere to switch to 1.5 yet.

Exactly the same problem here. Company politics has made upgrading Websphere servers a slow process. Actually we are now migrating from 1.3 to 1.4 :)

[salp]

I voted for 1.5, but that's because I'm in the luxurious position that the Java development here is a green field, all legacy systems are in a different language.
All new projects I start in 1.5, I'm migrating some old ones from 1.4 to 1.5

But... I know a few old clients of mine that have no choice then to run 1.4 (and even a few still have to run 1.3), no way around it.

[Andreas Senft]

Actually I'm running Eclipse with Java 5 (but in 1.4 compatibility mode) and run the application with a 1.4.2 JRE as we too have a restriction based on the app server.

But in this scenario I think I can vote for Java 5 :-)

[karldmoore]

I voted for 1.5, but that's because I'm in the luxurious position that the Java development here is a green field, all legacy systems are in a different language.
All new projects I start in 1.5, I'm migrating some old ones from 1.4 to 1.5

But... I know a few old clients of mine that have no choice then to run 1.4 (and even a few still have to run 1.3), no way around it.

We are in the same position regarding 1.5, very nice!

Some of our agent code however has to be 1.1 compatible, :(. Thats so last century :), where was I in 1997?

[ronwheeler]

My life was not complex enough so I started my first Spring project with version 1.6.
I am also running all of the tools and personal apps on 6 and have been very happy so far.
Seems to run everything a bit faster. No problems with Tomcat, Eclipse, Compendium.
I would be interested in any comments about potential problems with being 1 generation ahead of the mainstream.
Are there known features in Java 6 that could cause problems with tools and applications that are designed to run under Java 5? I was able to complete the Spring MVC tutorial under version 6 and so far all of my problems with my new development have been self-inflicted.
I am not worried about 1.4 since I am happy to wait out the tool development community's adoption of 1.5. I am guessing/hoping that I will not need any tools that are only available on 1.4.
My own impression as a user of Java applications is that 5 was so much better than 1.4 that people stuck on 1.4 should be pushing hard to get to 5.


Ron

[ronwheeler]

PetClinic also works under 6.

[memelet]

We are running jdk6 and not looking back.

[cwash5]

I am using Java5

[manifoldronin]

I voted Java 6 because I have upgraded/am upgraded whichever projects I have control over to Java 6, but one of my major clients is still running 1.4.2 for both production servers and developer workstations - we are talking about hundreds of developers. And there isn't any plan to upgrade to Java 5 as far as I know.

Speaking of which, as a matter of fact, neither hibernate 3.2.0 nor spring 2.0.2 codebase actually compiles in Java 6 yet. Both seem to be thrown off track by some new overloaded JDBC API...

[ronwheeler]

Perhaps it might be interesting to run a poll that is only open to new users (first Spring project) to see what version of Java they are starting out with.

"If you are currently developing your initial deployment of a Spring application, which version of Java are you using.

This might provide some insight in how to construct the documentation and sample applications.
It would probably have to run for a while to get a reasonable number of ballots.

It would also be interesting to see what application architectures are most common for
Persistence
WebServices
Transactions
Servlet Engines

This might help in restructuring the reference manual or in creation of a quickstart.

Ron

[GeneralCB]

I vote for java 6.
thanks for asking.

[kantorn]

Exactly the same problem here. Company politics has made upgrading Websphere servers a slow process. Actually we are now migrating from 1.3 to 1.4 :)

Same problem here. WebSphere and its mothership IBM is well-known for letargic processes implementing new JDK:s....
I'm one of the guys getting a bit worried about a too quick pace in adding features to Java.... I mean Java 5 has great values such as templates... but Java 6 is already here and 7 is around the corner making Java look more and more like a scripting language.... but the big vendors doesn't keep up the pace. Beginning to wonder if all the adds to the Java spec is really necessary.
One of the really big arguments for Java is its fantastic open-source products, but all the new Java versions increase the risk of incompabilities and thus decreased usability to companies etc. I'm not at all a fan of M$ and .NET (just compare Java's 25 keywords to C# which at least doubles that) but colleauges that like it says "At least the products work together" Of course they do; one vendor - one version. One of the major downsides of Java development is incompabilities between versions and tendency to "Jarmaggedon"-experiences.
Just thinking aloud....

[ronwheeler]

Same problem here. WebSphere and its mothership IBM is well-known for letargic processes implementing new JDK:s....
I'm one of the guys getting a bit worried about a too quick pace in adding features to Java.... I mean Java 5 has great values such as templates... but Java 6 is already here and 7 is around the corner making Java look more and more like a scripting language.... but the big vendors doesn't keep up the pace. Beginning to wonder if all the adds to the Java spec is really necessary.

I agree.
I have been around a long time and most major languages have some stability. Java is starting to look like an inside the beltway, script kiddies language where marginally useful features are added just to satisfy the egos and intellectual curiousity of the developers.
The grownups need to step in and put some discipline into the process.
The language should be stablized until the user community starts screaming for new features.
Five years between major versions is a decent interval for a language of the maturity of Java. This would give an incentive for major vendors and projects to upgrade. With the current speed of new versions, it is dificult to start an upgrade from 1.4.2 since as soon as you start and get partway through the process, you will have to switch target versions. I am sure that they are thinking that they might as well wait for Java to stablize.
A stable version would also give an incentive to writers and educators to document and promote a current version. This would help in getting the new features more widely used and understood.
The effort expended on new versions could be spent on performance, documentation and tools.
I would like to know what program can not be written in Java 6 that will be possible with Java 7.
I would like to see compelling examples of code that is going to be so much more efficient under Java 7.
If there are insufficient examples then put off the release of Java7 until 2011 and let the community absorb Java 6 and start to build a user-driven set of requests for new features for Java 7. I do not have any. Anyone else see defficiencies in Java 6's specification that is going to stop them from working?

[GeneralCB]

Hi, I can understand some developers are upseted by the permanent refactoring of the Java env (JDK, JVM, ...), and at the same time, they can't use the new versions because of the Big corporation's lenghty migration constrains.

But for sure, Sun is on the right process and timing concerning the JSRs, and sometimes, I considered they are a bit slow to propose new upgraddes in Java SE/EE that standardize and easy java dev. processes.

Before Java, I developped with C++ (10+ years), and the first versions of java was more like VB object programming. It was very hard for me because in object oriented approach, I have loosed from C++ to java, all the capabilities and free object expressions offered by c++ genericity, multi-heritage, and others... But in an other sense, I gained more in code quality (pointers out), code shareability (Java community), and adapt my coding on the global EE industry offer driven by Big java adopters like Sun, IBM, Bea, Oracle, and the open source community...

So, With java 1.2 to java 1.4, I can say that we where doing a big try in term of development. With the contribution of many smart guys/Open source projects, the limits of Java dev process have been demonstrated (the big example is the SpringFramework).

With java 5, Sun and others have put back more tools for elegant objet developement. Generics, enum, annotations, etc., are the basics patterns needed to code fast and have easy maintainable codes. I recently dropped a huge amount of codes from my packages, giving a fresh air to the code, with less lines to maintain, or check compatibility issues.

At each new version, you can see that Sun add many so called ext libraries, in the standard package, and that is a big gain in the deployment and configuration processes.

The problem here is from big corp., who as I can see, don't plan their migrations and don't want to pay for that migration until they are constrain by some external situation. That's understandable because they are driven by the amortization delay of their investments and they cannot migrate without giving financial justifications.

But for new development, there is no doubt that every one will try to use the last java version, and will stuck on old version only if they want to reuse their current business codes and can't easily port it to the new JVM. This reveal the lacks of distibuted components architecture in the whole Corporate solutions. With distributed components architecture, new projects applications could use the oldest in different JVM versions, and migrate or not the old codes.

Another point to mention, is the challenge with the .NET plateform. They have drawed their plateform using the experiences gained by using java 1. Today, Java 5/6 is a good response to .NET and is free, with a big opensource community support. If Sun stop JSRs update, Java people will begin to look at C# as alternative.

Is Java a scripting kiddies language because of annotations ? I don't think so ... But I agree that it changes a lot with the add of annotations, but this is another required level of abstraction. Remember that before annotations, many smart guys were asking for easy configuration, IOC, aspects and many solutions were proposed, with one big vapor all-in-one sulution labelled MDA(Model driven architecture). MDA is not totally died, but every body have seen that the MDA solution is not only a matter of a good tool. for MDA to succeed, the developer and designer had also the challenge to understand and express correctly the needs and requirements. That was not so easy to master for normal developer, because the MDA processes were too hard to be expressed in a generic way, for specific business solutions.

The annotation in java is a gradual step toward next MDA proposals, and before reach there, a big range of developers must have mastered a clean Java ee 5 development processes. Only a step which is starting to take his way by the numerous support (jetty6, pithfork, tomcat6, easybeans, ...).

Remember that the developement process is the key ... The code quality is bound to the production processes and tools used.

regards.

[ronwheeler]

Another point to mention, is the challenge with the .NET plateform. They have drawed their plateform using the experiences gained by using java 1. Today, Java 5/6 is a good response to .NET and is free, with a big opensource community support. If Sun stop JSRs update, Java people will begin to look at C# as alternative.

The choice of .NET or Java 6 will not be made on whether some new language construct is going to be available in Java7 or.NET 3.


Is Java a scripting kiddies language because of annotations ? I don't think so
It is the lack of stability and the addition of marginally useful features.


The annotation in java is a gradual step toward next MDA proposals, and before reach there, a big range of developers must have mastered a clean Java ee 5 development processes.

I assume you mean Java 6. Java 5 is no longer the current version.


Remember that the developement process is the key ... The code quality is bound to the production processes and tools used.

The code quality is bound to the production processes.
This means
Standards
Peer review
Management oversight
Good Design. Is it possible to do great code for a poor design but no one will notice.

The language has very little to do with it (once you get to a certain state)
It looks like 1.4.2 was sufficient. Java 5 is more than sufficient for anyone to right good code.

Good code is
1) Easy to understand. Well Structured. Appropriately commented. Follows standards consistently.
2) Easy to maintain. See above plus low dependency between modules
3) Bug free and robust.

Features that add little value and are only there because the other guy (Microsoft) has proposed them are more trouble than they are worth and slow down the adoption of the language rather than enhance it.

Can anyone name a major software initiative that is being delayed because there is some feature coming in Java 7 that absolutely must be available for this project to be successful.

Look how many people are in Java 5 even though Java 6 is available. They obviously do not see any feature that is missing in Java 5 that stops them from developing their Spring app.

Stop with the new features and spend the time fixing the existing features. Lower the memory footprint, decrease CPU usage.
I will confess that they have managed to do that pretty well between versions. Java 5 is heads and shoulders better than 1.4.2 and it seems that Java 6 is just a bit faster than Java 5.

Remember "No one likes change except a wet baby" and the Java language developers.

Ron
Ron

[GeneralCB]

ron, I understand your points and agree with it ... specially when you say

Stop with the new features and spend the time fixing the existing features. Lower the memory footprint, decrease CPU usage.
I will confess that they have managed to do that pretty well between versions. Java 5 is heads and shoulders better than 1.4.2 and it seems that Java 6 is just a bit faster than Java 5.



In fact, I have not allready look at the Java 7 proposal and I think many others Java developers are not ready to that. As you mentionned, stability, strenghness, speeds are more important ...

But Some people have to anticipate the next steps, although more time are to be ginven to the current version.

thanks.

[ronwheeler]

But Some people have to anticipate the next steps, although more time are to be given to the current version.

I am flexible about 2011 for Java 7 :) Say... a year on either side.

Perhaps we can attract some of the key Java rabblerousers to help out on Spring while they wait for 2011.

Spring with Java 6 looks like a pretty neat way to get everything that I want out of a Java app and there is lots to do on Spring to reduce the development cycle.
I think that the law of diminishing returns applies to Java language changes.

Ron

[GeneralCB]

I am flexible about 2011 for Java 7 :) Say... a year on either side.

Perhaps we can attract some of the key Java rabblerousers to help out on Spring while they wait for 2011.

Spring with Java 6 looks like a pretty neat way to get everything that I want out of a Java app and there is lots to do on Spring to reduce the development cycle.
I think that the law of diminishing returns applies to Java language changes.

Ron

I have took a look to the java 7 (dolphin) features ... and many of them are based on concrete openSource packages out there. So, I am very interrested to have those updates: uom, date & time, closures, bean validation, etc.,

It's sure that, there are many leadership conflicts to address in the way new functionnalities are proposed (via JSRs) in new Java releases. As I stated before, Sun is dumping many open source innovatives in the JSE, seemingly taking out the focus from original solution providers.

Can we mention the big case of Spring with the great work of Rod and his team, which will end in major benefits for Sun and Al ? It's depend on the reaction of the Spring guys and the community !

It is important to understant the open source community market... I am not sure I understand all, but I have my personnal opinion on that ...

First of all, as small biz company with limited resources, an open source team must not fight on the same market share nor with the same arguments. Taking the example of I21, one can ask how to benefits from their innovations in the open source market ?

By only prooving their ability to be the best source of support for their products solutions (SpringFramework) and the others solutions (SpringFramework to address Java ee 5 needs and future needs)

In result, the lambda programmers like me will choose SpringFramework to do everything and with confidence. If I know that Java 7 is out and I have a SpringFramework version for Java 7, I will take Java 7 adds via the SpringFramework.

I think that Spring team must be ready(agree) to take out many duplicated codes from his Framework in the progressing step of graduate to next Java version, unless his code is more efficient than the JSE code (not sure to see this append, as they must check that before ...)

The main final target is to centralise all common code in one place (JSE).

Tomorrow, writing applications will mostly consist of busines rules coding and code assembling... lasylly speaking.

To help developers, Spring Team challenge will switch to more smart Assembly tools ...
As they are very sharp in technical communication, they will again analyse and propose the optimal way to go from basic JSE to a full ee integrated application.

And you will see again another kind of MDA framework appearing from I21. I don't know how it will be but I suppose that they have already began to think to after the SpringFramework 2.

So, Spring Team must not worry about the JSR dumping process, as many community developers need them to take it into account. But they have to split their resources to address each Java platform 1.4 1.5 1.6 1.7 ...

Simple personal dream.
regards.

[ronwheeler]

First of all, as small biz company with limited resources, an open source team must not fight on the same market share nor with the same arguments. Taking the example of I21, one can ask how to benefits from their innovations in the open source market ?

By only prooving their ability to be the best source of support for their products solutions (SpringFramework) and the others solutions (SpringFramework to address Java ee 5 needs and future needs)

In result, the lambda programmers like me will choose SpringFramework to do everything and with confidence. If I know that Java 7 is out and I have a SpringFramework version for Java 7, I will take Java 7 adds via the SpringFramework.

I think that Spring team must be ready(agree) to take out many duplicated codes from his Framework in the progressing step of graduate to next Java version, unless his code is more efficient than the JSE code (not sure to see this append, as they must check that before ...)

The main final target is to centralise all common code in one place (JSE).

Tomorrow, writing applications will mostly consist of busines rules coding and code assembling... lasylly speaking.

To help developers, Spring Team challenge will switch to more smart Assembly tools ...
As they are very sharp in technical communication, they will again analyse and propose the optimal way to go from basic JSE to a full ee integrated application.

And you will see again another kind of MDA framework appearing from I21. I don't know how it will be but I suppose that they have already began to think to after the SpringFramework 2.

So, Spring Team must not worry about the JSR dumping process, as many community developers need them to take it into account. But they have to split their resources to address each Java platform 1.4 1.5 1.6 1.7 ...

The constant tracking of Java versions and the need to support all of the different versions is already a burden on the Spring team (and others).
It is time to take a break in the Java progression to let the open source community get caught up.
Let 1.4.2 disappear, let Java 6 get fully supported by the open source projects with some certainty that the effort will have some permanence and not be obsolete before it is completed.
If the Java market gets too broken down into sub-markets of 1.4.2, 5 , 6 and 7, it will be impossible for a small team to produce an open source product that can attract a reasonable number of users.
Even today, if I target Java 6, it appears that the entire Webshere community will not be able to use my "product". How many versions of Java can the open source community stand?

Ron

[GeneralCB]

So, lets go for Java 6 now, as reference platform.:)

[ronwheeler]

I am in
+1

[gregturn]

Unfortunately, our mission critical production system is running on 1.4. To upgrade would require upgrades to many machines, extensive regression testing possibly with customer involvement and also scheduling of impacting downtime. Since things run okay "as is", there isn't a compelling reason to do this yet. Instead, our attention is to addressing user needs and building new features they need to use our software in accomplishing their job.

I know there are bigger and better things in Java 5 and possibly 6, but my wanting/not wanting it doesn't contribute much to the engineering cost estimate to upgrading, nor bang-for-the-buck of doing the upgrade.

[kantorn]

It is, of course, extremely important that companies can see Spring & al. as a feasible solution that greatly reduces development effort in their production environments. Please don't make Spring a "sitting-home-alone-developing-on-the-very-latest-version" gizmo! We WebSphere people have to be able to use it without JVM-conflicts (i.e 1.4.2) for years to come, I'm afraid.

[mcdoma2000]

Does the version of the JDK that the Spring IDE uses bleed over into the project?

If not, why would it matter what JDK the IDE uses, as long as you have it configured to use the appropriate version of the JDK for the project itself.

I am not an expert, so I may be missing something...

Mark McDowell

[alexmarshall]

I've voted for Java 6 myself. I've found the Annotations and Generics to be too useful to not use, and I'd like to see more projects do the same. Unlike many others though, I'm fortunate enough to have absolute control over what technology my company uses :)

[Bron]

Java 6. I have to build some of my projects against Java 5, but I run Eclipse itself in Java 6. At this point, I would dread working without generics, so I avoid Java 1.4 if at all possible.

[mittaldeepak01]

I am using Java 5 for all my projects.

-Deepak Mittal

[Bas]

Java 1.4 only, sad by true. Most of mission critical apps are still running on 1.4 and no planning to upgrade.