Thus is definitely a move in the right direction. There have always been issues with the GNU OpenJava project being well behind the current version of Java. As a result everybody installs Sun's JDK in Linux if they want to do more than run the (few) Java applications that ship with the main distros, but you can't remove OpenJava in case something breaks.

Now that LB4 encompasses Java 6 this issue will vanish and we'll reclaim a bit of disk space.

I really don't understand the comments about diccuculties with installing Java. In the RPM based distros it is a non-issue: download and install the RPM, change your class path definition to suit and its job done: no harder than slotting in Opera or adding a 3rd party jar file.

Unlike Sun's Java, OpenJDK ships a 64bit Java plugin for Linux. That's the only thing I use anyway.

Java on a webpage sucks quite hard anyhow, be it openjdk or Sun's Java. Unfortunately sometimes there's no other way.

And I agree with them.

As you say, Java is king of the server side, or at least crown prince in a succession crisis with .net. However I question the point you are making, first saying that we don't have standardisation in the java world (which I would dispute on a practical level), and secondly, apparently arguing for the tck to be open sourced and that we should embrace the subsequent forking.

Which would you like, more standardisation, or less?

I would also ask the question as to what a java developer thinks of as his deployment platform. I don't tend to think of 'linux', 'windows', 'solaris' etc I think java 5, java 6. Especially on app servers, the java platform has done a good job of insulating the coders from the operating system.

I like it, it makes me happy, I don't think of the OS that much in my day to day work, does that make my stuff non-native?

I don't think it's too hard to get a completely standardized Java running on Linux. When I installed Ubuntu, I got OpenJDK, but I'm not sure I like that very much; it seems like a weird mix of Sun's open source Java and a lot of goofy stuff from the FSF, like their Classpath project.

What I do is create a Java directory in /opt, download the REAL JDK from Sun, install it to my new /opt directory, and adjust my profile file so the bin directories of the JDK and the JRE come first in my PATH. Then I specify CLASSPATH wherever I need to, and target the official JDK in my tools, like NetBeans.

Problem solved: I'm using the canonical Sun-provided version of Java, and the weirdo OpenJDK Ubuntu likes to install gets ignored.

Sorry if this offends any of the OpenJDK folks... You lost me when you decided to replace the binary stubs in OpenJDK with GNU Classpath. You should have re-implemented the missing code from scratch, cleanly, instead of building a big, clunky Rube Goldberg contraption out of two separate systems.

You Unix beards always try to glue everything together from a million tiny programs... You even call it "The Unix Way". For scripting projects, that's fine, but for a large, complex project like a JDK??? Yuck. Rube Freakin' Goldberg.

On Ubuntu, you CAN get the Sun version of Java directly from their repository, if you choose the "Universe" setting. Here's a page that describes how to set up for Sun java instead of the Rube Goldberg mixture:

https://help.ubuntu.com/community/Java

Still... I like being able to manually set it up. My earlier instructions work on ALL Linux versions, except the ones with "alternative" versions of glibc.

:)

who cares? you can get java from java.sun.com and untar it. problem solved.

in this way since before this millennium java has been running just fine on linux.

My brain hurts, already!

Fiddlers can play with JDK configs all they like,

The rest of us get on with installing it and running it.

Am I Apple or Windoze?

Isn't that abomination dead yet?

I seem to remember that not long ago Java was to bring world peace & feed the starving - or was that Bob Geldof and Bono - I forget now.

Anyway.. 14 years later it turns out it was all just big idealistic visions & grand statements, and we end up with another poor performing butt ugly half-baked solution, that doesn't deliver & wastes time money & resources - oh no wait - perhaps that was Bob and Bono after all.

"Matt Stephens is co-author of Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to get from use cases to source code and tests, using Spring Framework,..." - so I'm not expecting any gushing praise for Glassfish from you.

Gosh, I'd better go and tell all my clients that the Java apps I've built for them over the last 8 years actually don't work, and they'd better get rid of them. That includes a Bank Teller app, online banking, an insurance claims management system and a electricity meter billing system - you know, Mickey Mouse apps that don't really do anything important.

Schmuck.

Is that Java has never managed to achieve a version numbering system that's been stable for even one major version. Whenever you've got version N and are about to upgrade to version N+1 you inevitably find it's been replaced by version "M bla bla bla" (where M!=N+1 and "bla bla bla" is some idiotic marketing gobbledygook) for some reason you don't really care about and certainly don't have time to investigate.

So you just download whatever SUN says is the latest version (from SUN) and use it. This approach seems to work. I don't know why it works, but it does and I hope it continues to work otherwise I may have to give up on Java.

See how easy it is to stuff up what was quite a good idea once?

"But a tools developer will see a huge difference, as their market has suddenly grown hugely," Phipps said.

In other words, their tools will now be easily available on Linux as well as Windows."

Most Java development tools are written in Java and thus run on any platform that has a decent JRE/JDK. That's always been the case, I don't see anything different now from the days when non-solaris *nix users had to use the Blackdown Java kit.

For me openjdk has taken the pain out of getting a working Java development environment on a Debian box. Netbeans and Glassfish are in Debian too... for me life is now good.

@Phil:

You seem to have a lot of inaccurate misconceptions about IcedTea, the variant of OpenJDK packaged in distros like Fedora, Ubuntu and Debian. It has never included the whole of GNU Classpath as you seem to imply. A number of files were initially taken from GNU Classpath to provide implementations of classes not provided by OpenJDK. With the binary plugs, OpenJDK had all the same issues as the Sun JDK. Suggesting that the code should have been reimplemented from scratch is just absurd; when existing Free Software would do the job straight away, what is the point of that? All that would have done was slow the process of getting OpenJDK into distros. As more code was Freed by Sun, these classes were removed and the code base changed from an early version of what Sun calls 1.7 to a backport aiming at compliance with 1.6. The build of IcedTea in Fedora 9 later succeeded in passing the 1.6 TCK (http://www.press.redhat.com/2008/06/24/openjdk-and-the-icedtea-project/).

If you want to go to great effort to avoid IcedTea for no sane reason, then go ahead. But you're missing out on additional features such as a 64-bit plugin, support for more architectures and a PulseAudio plugin along with the knowledge that you're actually helping to support the FOSS community.

Hey, Andrew:

Thank you for that information.

If you're right, and you probably are (you sound like you know what you're talking about), then I think it deserves another look. I'll give it a try.

Thanks,

Phil

My main dev platform lies with Linux; and with a previous job, many flavors of UNIX (Solaris, AIX, HP-UX). My preferred platform for that would be C/C++, but for most web stuff or client/server stuff, Java is the most convenient solution. Plus, the Java EE spec with EJB's is pretty easy to use (at least the J2EE one, I haven't mucked around with the Java EE5 specs.

As for Spring, well it required doing ugly hacks on our already working Weblogic appserver, so I really don't really care for it; it is after all doing the same stuff the J2EE/Java EE framework is already doing anyway!

Is that still going?