Red Hat Joins Open Source Java Project

narramissic writes "Red Hat has signed on to Sun's OpenJDK project and agreed to coordinate its own Java development efforts for Linux with the project. Red Hat will align the work it has done on IcedTea (its own implementation of some parts of the Java SE JDK) with OpenJDK. As part of its participation in OpenJDK, Red Hat will eventually create a compatible OpenJDK implementation for its Enterprise Linux distribution and will also use OpenJDK to create a runtime for its JBoss Enterprise Middleware that is optimized for a Linux environment."

mono

[Miguel de Icaza (660439)]

what about mono?

Re:

[AKAImBatman (238306)]

As you may have figured out, that's not the real Miguel. This is his doppelgänger who tries to be funny. "What about mono?" is obviously a gag based on how hard Miguel tries to push Mono as being a one-true-OSS-replacement-for-Java-that-is-potentially-encumbered-but-you're-supposed-to-trust-Miguel-that-it's-not.

I dunno. I chuckled. Mods, make your own decision.

Will anything change for end users?

[visualight (468005)]

With all the "openness" going on with Java these days will things get even more complicated? I have 3 important commercial apps that run on java, all three have their own run time environments that are incompatible with each other. I have no end of trouble with jre and firefox. I can't count how many times I've had problems with classpaths trying to run java stuff.

Will the OpenJDK mean another runtime? As in Blackdown, Sun, Open?

Re:Will anything change for end users?

[bytesex (112972)]

That's not the result of the openness of the JDK or the JVM; the specs for both were always open. Sun always gave you the src.zip for the JDK, and they provided the bytecode spec and in what way to run such bytecode openly and free op charge.

Re:

[visualight (468005)]

Ok, "openness" is not a factor, but it is yet another runtime isn't it?

Re:

[M. Baranczak (726671)]

The src.zip only contained parts of the source code.

Re:

[Z00L00K (682162)]

If you run three different VM:s that are incompatible then something is amiss unless at least one of them is the Microsoft VM that is known to be incompatible.

Only a few issues makes it harder to run all on the latest SUN JRE, and none of them are considered good programming practice. I suggest that you take that back to the app vendors and tell them to get it right and working on the latest released Java (1.6).

The major problem I have recognized is actually related more to the centrally distribution of

Re:Will anything change for end users?

[hey! (33014)]

I think the biggest problem with the original write once, run everywhere promise was this: Java was almost, but not quite, an operating system. If you had a system that worked on WinXP but not Vista, you'd fix the problem; you wouldn't tell your customers to install both operating systems on the same machine because he can't. If I had A,B and C that only ran on Windows versions X,Y and Z respectively, I'd take the trouble to make A and B run on Z.

In Java I can get by with A, B and C each running only on JDK 1.2, 1.4 and 1.6 respectively, but I have to call upon the user, working with the host OS, to deal with any confusion that arises. Now, multiply that by any libraries you use that aren't part of the standard java distribution, and things start to get really interesting.

In part the problem of Java classpaths is one of an embarrassment of riches. There are so many powerful frameworks and amazingly useful little libraries that are out there, free for the taking. However, once you open that Pandora's box, it isn't simply a matter of write once, run everywhere; you have to deal wit the dependency issues that come out of that box. It can be done, and it's not really all that difficult, it's just one of those craft things that some people seem to have figured out how to do and others seem to leave as an afterthought after all the fun stuff has been finished.

The embarrassment of riches also applies to the biggest pitfall in Java development: making bad framework choices, which you can do in multiples at the same time on any project. Leaving aside the case where you have a bad framework (the early EJB stuff -- ugh), or where you have made a bad mistake in requirements analysis, there are so many frameworks that are wonderful for one set of requirements and dreadful overkill for others. Working with a set less than optimally chosen frameworks sucks the joy out of a project, as you set aside the pleasure of solving the client's problem for the tedious drudgery of gluing together mismatched bits of architecture.

Re:

[aled (228417)]

I understand that OpenJDK is the open source version of Sun JDK. I'm curious about which are the runtimes that you need to use, or are they 3 different versions of the SUN runtime?

Re:

[visualight (468005)]

A JRE is installed with the apps, and they have start scripts that setup they're own environment in the running shell, except one that adds itself to /etc/bashrc (I took that out and made a new script like the other two though). I'm not at that workstation but I think all three Sun.

Anyway, there are different versions of different runtimes and not all apps work with all of these variations, and this sometimes makes me want to throw them all out.

Re:

[petermgreen (876956)]

You can already, icedtea contains a java plugin from amd64 based on work from the gnu classpath project.

parallel universe

[squoozer (730327)]

I must have slipped into a parallel universe or something because it's starting to look like Java might finally make it's way onto the Linux platform in a useable way. Fair enough we have been deploying Java apps on Linux boxes for a while but it's been much harder than deploying a PHP, C, C++, etc etc application. That always struck me as strange because I would have thought that Java was the perfect language for open source projects. Fairly quick, simple to develop in, stacks of libraries, popular.

Re:

[Antique Geekmeister (740220)]

You mean they might pry the installer out of Sun's hands? Great!

Re:parallel universe

[morgan_greywolf (835522)]

I must have slipped into a parallel universe or something because it's starting to look like Java might finally make it's way onto the Linux platform in a useable way.

Java has been available and has worked well on the Linux platform for years. The main problem in trying to deploy Java on most Linux distros is that the more popular distros started putting GNU Java and GNU Classpath as the default Java VM and classpath on Linux. Sun's Java has been available in binary form for as long I've been using Linux (I started using Linux in 1994). I'm not sure when they started offering source, but it's been available, too, and things like Blackdown have been based on it for a long, long time.

And there are plenty of nice Java apps and environments on Linux -- Eclipse is one of the big ones, obviously. The bottom line is that gcj/gij gave Java on Linux a bad name because standard Java apps and programming examples never have worked on it right. Install Sun's JRE/JDK or Blackdown, and you'll find that Java works great on Linux.

Re:

[M. Baranczak (726671)]

The reason they used the wacky GNU Java is that Sun's licensing made it hard to include their Java on free distros. This is now changing, fortunately. In Ubuntu, you can now install the Sun JDK with apt-get, just like any other package. (I think you have to activate the Universe repo first... it's been a while.)

Re:

[heffel (83440)]

Sun's Java has been available in binary form for as long I've been using Linux (I started using Linux in 1994).

Quite an amazing feat since Java didn't come out until 1995. When I first started working with Java (1996) there was no official Sun Java under Linux, there was a port from BlackDown [blackdown.org] (their web site seems to have gone AWOL recently).

I can't remember exactly when Sun added Linux as an officially supported platform, however I know it wasn't from the get go. As a matter of fact, the number one bug in

Re:

[marcosdumay (620877)]

Assuming you are using a x86, then yes, Java is available for you on Linux. Don't try to be cute using 64 bits, if you do so you'll start to see the limitations.

Also, the Linux jre has a different set of bugs from the Windows one, and since both sets aren't small (try to do anything different from what the designers intended and you'll see them) Java tends to not be very portable.

Re:

[noldrin (635339)]

Actually Sun precompiled Java consistently causes processes to hang and I end up needed to kill -9 firefox. Now that I have the open source sun java compiled by Fedora the system is rock solid and haven't needed to kill -9 firefox once. I've had the same results with flash vs gnash. Besides being overly restricting, closed sourced software just tends to suck more.

Re:

[petermgreen (876956)]

That always struck me as strange because I would have thought that Java was the perfect language for open source projects. Fairly quick, simple to develop in, stacks of libraries, popular.
But not foss leading to poor integration with linux distros.

Hopefully it won't be too long before the remaining encumbered components are properly replaced and opensource java becomes a part of all major general purpose linux distros.

Re:parallel universe

[EricTheRed (5613)]

The main problem with unresponsive Swing apps, is that most developers do everything within the Event thread, so the app is unable to respond in a reasonable manner.

If Swing developers remember to move intensive operations off the Event thread and into a background thread, then Swing app's are really nice and responsive. It's not that difficult, but for some reason most developers are either unable to, or unwilling to do this simple task.

Believe me, I've seen the source of plenty of Swing app's that have been written with everything in the Event thread and the developer (one of whom I had employed at that time) refused to do this because they couldn't be bothered.

As for the look and feel, it's getting better but it still has a long way to go.

Re:

[EricTheRed (5613)]

> Which is the same way they do it in every other framework. Swing is slower than the others and now it is all Swing users fault?

I wasn't blaming swing users, but from past experience most don't follow the Swing event model, even when it's documented well. Virtually all are creating swing objects outside of the Event thread (EDT).

> I can understand that for very large operations but if I have to create a thread for every event driven operation, I am done for.

No is did not say for every operation, I sa

Re:

[0xABADC0DA (867955)]

Which is the same way they do it in every other framework.

Kindof. In Swing all of a GUI runs through the same event loop, so while something is processing an event all parts of the GUI are frozen. In other toolkits a lot of basic functions like redrawing are handled by the OS or by a separate thread that manages low-level gui 'controls'. In Swing you can have for instance a drop down list with tables as the entries instead of names. But since the GUI is are so flexible nothing can be done really while other events are being processed.

Also, some toolkits allow

Re:

[jma05 (897351)]

> Swing is actually a really freakin' awesome toolkit for creating the building blocks of a GUI and for creating new components. It's just really bad at being an application GUI since your application code is running in the same mix as all the little details of a component.

This is unfortunately true of all of Java. At one end it tried to provide a low level virtual "machine" and the framework accordingly, and at the same time pretends to be a business class, high level framework. Likewise, the language i

Re:

[by Anonymous Coward]

public class HelloWorldDemo {public static void main(String args[]){System.out.println("Hello World");}}

How many lines?

Re:

[Dragonslicer (991472)]

You're talking about Perl, right?... When any program you can possibly imagine takes more than one line of code...

Fixed that for ya.

Sun has found religion..

[downix (84795)]

Open Sourced Solaris, SPARC, now Java... Halleluiah cries the OSS choir.

But seriously, this business move by Sun has made it far more attractive to my company, enabling us to test out Solaris on our existing server before we perform a rollout. In addition, having the source code for the UltraSPARC T1 has enabled us to do research into how the chip functions on a lower level, with an eye to further optimizing our software to perform even faster on it. Sun, you might win over my heart just yet.

Re:

[publicworker (701313)]

Sun, you might win over my heart just yet.

I don't think they care about your heart. It's your wallet they are going after.

For most geeks the way to their wallet is via their heart.

FYI

[Saija (1114681)]

The official news on the red hat site:http://www.redhat.com/about/news/prarchive/2007/sun_java.html/ [redhat.com]
because i can't find references on the sun & openjdk site.

Re:

[LarsWestergren (9033)]

because i can't find references on the sun & openjdk site.

Mark Reinholt (chief engineer for the java platform) blogs [sun.com] about it. Also the experimental Mercurial repositories are open [java.net].

Slightly offtopic, so are the JavaOne 2008 Call for Papers [cplan.com].

I truly hope for the end of gcj/gij

[by Anonymous Coward]

Why? Sure, it was a novell idea to try and create an open sourced java but the whole arguments which backed it up were false. Many people seriously believed that Sun was not opening up the Java source code period, while in fact that was a mere lie. The Java source code was available but simply licensed in such a way which didn't really go well with some. And so they simply declared it "closed source" and fooled many people into thinking that the Java sourcecode wasn't available period.

Why I mention this? Because it was perfectly legal to adopt certain pieces and sniplets of code, check the way things were build an adapting those ideas. All of that might have made a difference for the gcj/gij projects. Personally I condemn those 2 projects, but having said that I will have to admit that they did make a good effort.

But the main reason I hate this stuff with a passion is because its not compatible with Java, and it is my belief that all the nonsense (gcj/gij + the bs about the closed source java) has left Java with a bad name / reputation on the Linux platform. Which I think is unfair and an utter shame. Would this have not been the case I think Java could have lifted some interoperable development movements to higher levels. Sure; it has already done this to some extend and Linux is still a big market for Sun, but when the bs was still spreading you could already easily download binary installers (self extractors) to install Java on Linux. But I have met simply way too many people who had problems to "do java on linux" and when you started disecting the problems it all boiled down to Linux distributions shipping gcj/gij thus resulting in non-working Java software. And as well all know; a good user doesn't blame his tools but the product he's trying.

I once spend 45 minutes on the Sun Java tutorial and couldn't get some examples to work. Eventually I tried on another platform, that did work, and so I knew where to look. Eventually I ended up dumping gcj/gij and replacing it, unfortunately I think many others ended up dumping Java.

Re:I truly hope for the end of gcj/gij

[basiles (626992)]

Yes, but a (maybe minor) feature of GCJ is its ability to build self-contained Java applications, i.e. to compile some Java source code into an executable which does not require any previous JVM installed, etc...

I admit that there are few Java applications (at least on Debian) which are compiled by GCJ and packaged as plain old binary executables. Of course, this means avoiding some fancy Java tricks (the dynamic class loader, some reflection abilities, etc...).

Still, I believe GCJ does have at least such a niche market (for those few applications which don't want to depend on a JVM being installed).

Besides, GCJ is GCC based, and GCC is still a nice project (even if it is old).

Re:

[Ed Avis (5917)]

Well, quite. If Java doesn't have a good-quality, free implementation then I'll dump Java and use something else instead. gcj and gij are heroic efforts but they were always trying to catch up to a semi-proprietary standard.

'closed source' is an inane term. I don't think anyone from gcj or gij was describing Sun's Java as 'closed source'. It's non-free, which is what matters. Merely being able to look at the source code doesn't mean you have freedom to use, share and change the software.

Re:

[dan the person (93490)]

I truly hope for the end of gcj/gij

I think there is still a place for gcj as a native java compiler. What's stopping them now compiling against the OpenJDK class libraries instead of classpath? Should be a huge improvement for compatibility.

Re:I truly hope for the end of gcj/gij

[civilizedINTENSITY (45686)]

Actually, instead of the end, this is just the official beginning: From the intro at [gnu.org]http://gcc.gnu.org/java/ [gnu.org]

Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications. It has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5 additions.

From TFA:

Red Hat has signed Sun's OpenJDK contributor agreement and will now align the work its done on its IcedTea project, which was its own implementation of some parts of the Java SE JDK, with OpenSDK, said Shaun Connolly, vice president of product management for JBoss. IcedTea brought together the Fedora project with key Java technologies in a Linux environment, and currently provides open-source alternatives for the few remaining proprietary sections in the OpenJDK project, he said.

Yet looking into the IcedTea project [javalobby.org]:

Red Hat has launched the IcedTea project, with the goal of creating a hybrid fully free Java implementation based on OpenJDK and GNU Classpath. The project replaces binary plugs that are still non-free with code from GNU Classpath "We have been working within Red Hat to replace these binary plugs with free software based on GNU Classpath and to remove the need for bootstrapping with unfree software. This is important for a number of reasons, the most pressing being that only free software may be used to build operating systems like Fedora", said Andrew Haily on an OpenJDK newsgroup.

Also, Wikipedia [wikipedia.org] references "Wielaard, Mark [klomp.org] (2007-06-07). IcedTea [wildebeest.org]. Retrieved on 2007-06-09":

IcedTea replaces the binary plugins with the equivalent GNU Classpath code, compiles it all using GCJ and optionally bootstraps itself using the HotSpot Java Virtual Machine and the javac Java compiler it just built.

So again, this is not the end of end of GCJ but part of its validation.

Re:

[petermgreen (876956)]

IcedTea replaces the binary plugins with the equivalent GNU Classpath code, compiles it all using GCJ and optionally bootstraps itself using the HotSpot Java Virtual Machine and the javac Java compiler it just built.
That wikipedia quote is neither entirely accurate or entirely up to date

Initially icedtea was built with ecj as the compiler running on gij (a close relative of gcj and often packaged with it which may be where the idea that it was built with gcj came from).

Right now icedtea only builds with old

Other Linux Java Options?

[tji (74570)]

My problem with the Sun JRE is that it is HUGE. Why do I need 100MB+ to run a simple Java application?

Are there other good JRE options for Linux? Maybe something geared towards embedded environments?

Re:

[Saija (1114681)]

Thats the reason because sun is working in what they call "the consumer jre", please check this pages: http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html/ [java.net]
and this https://jdk6.dev.java.net/6uNea.html/ [java.net]

Re:

[petermgreen (876956)]

From that page

"The fix, then, is for us to take advantage of the disk cache to make sure that the memory pages on disk that we must read at startup have already been loaded before we need them. How do we do this? We cannot magically pre-load the pages just prioir to launching; unfortunately, the VM currently lacks the ability to see into the future to detect when the user will be launching Java (we would love to have this feature in the future, but it is not yet present). But we can pre-load at some earlie

Re:

[drig (5119)]

There's Kaffe at http://www.kaffe.org./ [www.kaffe.org] It's an optimized version for embedded uses (either embedded in devices or embedded in a larger program). It's not 100% compatible, but I believe it's more than usable for many purposes.

Re:

[drig (5119)]

Of course, I forgot J2ME. That's the "mobile" edition, designed for space/cpu constrained mobile devices.

Re:Other Linux Java Options?

[quintesse (654840)]

That number is a bit exaggerated, my install of the latest Java 6 JRE is about 80MB (and the download is only 14MB).

One of the reasons it's so big is because it has a LOT of functionality. But you're right of course when you say that you don't need all of that to run a simple Java application. So Sun decided to do something about that: in the upcoming Java 6 Update N (what was previously called the "Consumer JRE") only a relatively small "kernel" will be installed which has only the most essential components. The rest will be downloaded "when needed".

That's how flash won the web

[porkThreeWays (895269)]

It's probably too late for java to overtake flash in that market segment, but if Sun had originally done this, they would have probably won the web war. The two biggest complaints about java are, the JRE is too big to download, and the programs take too long to start. This is 99% of people's impression of java. They don't care that it's perhaps one of the best general purpose languages out there right now. They care it takes 10 seconds longer than flash to run a simple program. Sun should have never half-as

Re:Other Linux Java Options?

[deander2 (26173)]

My problem with the Sun JRE is that it is HUGE. Why do I need 100MB+ to run a simple Java application?

you don't. a simple stroll over to java.sun.com will show you that the JRE [sun.com] is 14M for windows and 18M for linux.

the "100M+" is if you're also downloading all their development tools and documentation (and possibly netbeans, depending on the link). not atypical in the least.

Re:Other Linux Java Options?

[ttfkam (37064)]

What does the uncompressed local copy have to do with download times? 14MB compressed takes just as long as 14MB uncompressed. If you think that your CPU can't handle fast decompression, just think of all of the web sites that gzip their content for network efficiency.

As for the complaint about docs, are you serious? Are you seriously complaining that there is too much documentation available in HTML format? And optional documentation at that? Think about what you're saying for a second: that you consider it a drawback that every class, method, and member of the JRE is consistently documented in detail.

GUI: AWT versus Swing are native widget peers versus internally rendered widgets.

RPC: RMI, CORBA, and XML-RPC/SOAP are for the following in order: RPC in a 100% Java environment, cross-platform binary RPC, and XML text-based RPC. There is a place for each of those.

XML parsers: are you referring to the SAX, DOM, and StAX parser APIs -- which would make three? Or do you mean two parsers like Crimson and Xerces. I think the former is self-evidently a good thing. The latter is due to compatibility and consistency through multiple releases as the older parser behavior may be necessary for an older app even if it's a little slower or more memory inefficient.

I can see your argument against including a scripting language, but Sun wanted to include a reference implementation of their pluggable scripting interface.

I/O: Blocking vs. non-blocking. What's the problem? Both have their uses.

What you call bloat, some would call completeness. Let's compare against some other popular languages.

Common Lisp: 10MB
Latest Python download for OS X: 17.9MB
Latest Perl download for OS X: 33.5MB (Linux version is between 18.9 and 24.8MB)
Latest Ruby (without Rails) download for OS X: 13.71MB

But don't take my word for it. Download for yourself. The only reason these other languages seem smaller to you is because they are bundled seamlessly with your Linux distribution.

Want database access, RPC, non-blocking I/O, XML parsing, etc. from those languages? Too bad, that's another download. Sure there are resources like CPAN, but why are their cores so bloated? Somehow Java is able to provide all of those "bloated" APIs at about the same download size as those languages that lack them.

And don't get me started on C and C++. They don't even have a standard database layer, XML library, or the like for you to download separately. Learned one non-blocking I/O library? Too bad, your new company uses a different one. Do you think ODBC is a good solution? Obviously you've never programmed for it.

I'm sure I could go on, but you get the picture.

Re:

[civilizedINTENSITY (45686)]

"Download the final release of the .NET Framework 3.0 Runtime Components" results in a 50.3 MB executable being downloaded. Surely this is compressed. Does anyone know if JRE is as large as the .NET "RE"?

Re:

[civilizedINTENSITY (45686)]

From MSDN:
Deployment in Visual Studio
Deploying Prerequisites (Visual Studio)
In order to successfully deploy an application, you must also deploy all components referenced by the application. For example, most applications created with Visual Studio 2005 have a dependency on the .NET Framework; a required version of the common language runtime must be present on the target computer before the application is installed. The deployment tools in Visual Studio 2005 enable you to install the .NET Framework

Re:

[bberens (965711)]

If you need Real Time efficiency use specialized hardware, OS, and not Java. If you're making a little app that you want to be able to run on virtually any cell phone on the planet... use Java. Use the right tool for the job. How difficult is that?

Re:

[nuzak (959558)]

There isn't just "talk of real-time gc", it's already out there.

Pardon moi if I would rather not deal with someone forgetting to free mallocs because they decided to shave a few microseconds off something already running within 50 milliseconds of deadline. Especially when the controller is buried under 10 tons of concrete.

Anyway, the research that's all the rage these days is static garbage collection. It works just like manually freeing memory, but you never have to actually do it yourself. It just inse

Getting harder to choose: Java or Python?

[pembo13 (770295)]

How do you folks intelligently and objectively choose between Python and Java? Or at this point is it a subjective decision?

Re:Getting harder to choose: Java or Python?

[jpfed (1095443)]

They each have their advantages and disadvantages. According to the great computer language shootout [dada.perl.it], Java is faster by an order of magnitude, but is more verbose and usually consumes about twice as much memory. The ultimate decision depends (at least) on your application's needs and the capabilities of the environments you're targeting.