Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Red Hat Joins the OpenJDK
URL: Red Hat and Sun Collaborate to Advance Open Source Java Technology
At 12:22 PM on Nov 5, 2007, Geertjan wrote:
Fresh Jobs for Developers Post a job opportunity
Today Red Hat announced that they're joining the OpenJDK community . Attention, in the press release and elsewhere, is going to an implication of this step—the open sourcing of IcedTea as an OpenJDK project.
From the press release, one gleans the following:
Here are a few quotes around this new development:
Sacha Labourey, CTO of JBoss: "Red Hat fully supports Sun's courageous decision to open source Java technology. After more than 10 years of continuous leadership, the Java technology ecosystem will enter an era of accelerated innovation and benefit from extreme pervasiveness on a wide range of environments. Through these strategic agreements, Red Hat commits to contribute to the Java platform and distribute a compatible, open source Java software implementation." (from the press release)
Rich Green, executive vice president, Software, at Sun Microsystems: "Sun welcomes Red Hat to the OpenJDK community. It is a vote of confidence to have Red Hat, a leader in open source, engaging with the community on such a broad scale. When we open-sourced our Java software implementation, we hoped to see just this kind of collaboration between the GNU/Linux world and the Java technology ecosystem. It is gratifying to see the promise of open-source Java technology coming true with Red Hat's leadership." (from the press release)
Simon Phipps, Chief Open Source Officer, at Sun Microsystems: "Creating an environment with licensing, code and governance acceptable to groups like Red Hat was one of the primary motivations of our choices around OpenJDK, so this is fantastic news all round, and an interesting counterpoint to the approach others have taken in other projects." ( in his blog )
What do you, reading this, think about this development? And... who should be next to take the same step?
43 replies so far (
Post your own)
Re: Red Hat Joins the OpenJDK
> Red Hat commits to contribute to the Java platform and distribute a compatible, open source Java software implementation.*shiver*
Let me be the first to say..."Let the divergence begin!".
My suggestions for possible features for Red Hat Java to make it better than Sun's Java:
* A new packaging and installation system (ala RPM)
* Additional command line tools
* Additional options to existing tools like javac.
* Additional keywords (e.g. "foreach") and contructs (e.g. properties)
* Additional libraries (e.g. google collections) packaged as part of the distro.
Also, let me be the first to say...my app seems to work OK on Sun's Java, but not Red Hat's Java. Is anyone else having this problem?
Re: Red Hat Joins the OpenJDK
cmon. it is a good thing that redhat is in..Re: Red Hat Joins the OpenJDK
> *shiver*>
> Let me be the first to say..."Let the divergence
> begin!".
That makes no sense, Andy. RedHat is going to work *with* Sun on a single Free / Open Source implementation of Java, OpenJDK. Let the convergence begin...
> Also, let me be the first to say...my app seems to
> work OK on Sun's Java, but not Red Hat's Java. Is
> anyone else having this problem? ;)
What you call "Red Hat's Java" is presumably GCJ. GCJ won't run all Java programs, because it isn't 100% Java compatible (not through lack of trying). But Red Hat is committed to shipping a free (as in freedom) runtime for Java programs, and up until OpenJDK became available, GCJ/GNU Classpath was pretty much the only game in town. But now with OpenJDK Red Hat has the opportunity to ship a more compatible (and ultimately 100% compatible) Free Java runtime...and that's great news!
http://www.jfree.org
Re: Red Hat Joins the OpenJDK
> > Red Hat commits to contribute to the Java platform> and distribute a compatible, open source Java
> software implementation.
>
> *shiver*
>
> Let me be the first to say..."Let the divergence
> begin!".
>
> My suggestions for possible features for Red Hat Java
> to make it better than Sun's Java:
>
> * A new packaging and installation system (ala RPM)
Yes, and you have to find a way that people use it. As RPM is far from standard on Linux
> * Additional command line tools
Yeark !!! Who cares about command line tools.
Have AOP in the core, and also bring Groovy, so it will be scriptable, hence no more need for command line tools.
> * Additional options to existing tools like javac.
Less options would be better !
> * Additional keywords (e.g. "foreach") and contructs
> (e.g. properties)
(as said earlier have Groovy in, no need for more)
> * Additional libraries (e.g. google collections)
> packaged as part of the distro.
No, those library should be optional. That is what libraries are for.
> Also, let me be the first to say...my app seems to
> work OK on Sun's Java, but not Red Hat's Java. Is
> anyone else having this problem? ;)
This is definitely a possible problem !!! I hope it won't happen.
Re: Red Hat Joins the OpenJDK
> > *shiver*> >
> > Let me be the first to say..."Let the
> divergence
> > begin!".
>
> That makes no sense, Andy. RedHat is going to work
> *with* Sun on a single Free / Open Source
> implementation of Java, OpenJDK. Let the convergence
> begin...
>
> gt; Also, let me be the first to say...my app seems
> to
> > work OK on Sun's Java, but not Red Hat's Java.
> Is
> > anyone else having this problem? ;)
>
> What you call "Red Hat's Java" is presumably GCJ.
> GCJ won't run all Java programs, because it isn't
> 100% Java compatible (not through lack of trying).
> But Red Hat is committed to shipping a free (as in
> freedom) runtime for Java programs, and up until
> OpenJDK became available, GCJ/GNU Classpath was
> pretty much the only game in town. But now with
> OpenJDK Red Hat has the opportunity to ship a more
> compatible (and ultimately 100% compatible) Free
> Java runtime...and that's great news!
Why exactly do we need that ? Spreading ressources is far from a good thing.
Re: Red Hat Joins the OpenJDK
All the main library bindings cleaned up and accessible from JNI and/or JNA.Replace everything done in Mono, dump Mono. Beagle'd be the first one to be put out of its misery.
Make it easy to program widgets for the desktop, in Java (instead of javascript). Perhaps this is more of a Gnome / KDE thing. I don't like either. Ok, something in Beryl? But Beryl embeds inside Gnome. Arg, it's all so convoluted.
Re: Red Hat Joins the OpenJDK
Exactly why would an announcement that Red Hat has licensed the TCK (meaning they plan to be compatible) and signed the Contributor Agreement (meaning they do not plan to fork) imply anything at all negative, Andy?Re: Red Hat Joins the OpenJDK
He probably read a different articleRe: Red Hat Joins the OpenJDK
Why exactly do we need that ?Probably not a need as in "must have" but having to companies working together on a single JDK beats two companies working on two JDKs, so definitely a "nice to have".
Spreading ressources is far from a good thing.
Not sure which part of the article you are referring to, but pooling the resource of two companies into on effort looks like a good thing to me, even if it's spread over more developers thus probably requiring a bit more resource on communication.
Re: Red Hat Joins the OpenJDK
> Why exactly do we need that ? Spreading ressources is> far from a good thing.
Spreading resources? The announcement is about Sun and Red Hat pooling resources...and that's a good thing.
http://www.jfree.org
Re: Red Hat Joins the OpenJDK
Good news,But I don't remember Red Hat have nice product in java field.Java Tips -
Re: Red Hat Joins the OpenJDK
> > *shiver*> >
> > Let me be the first to say..."Let the
> divergence
> > begin!".
>
> That makes no sense, Andy. RedHat is going to work
> *with* Sun on a single Free / Open Source
> implementation of Java, OpenJDK. Let the convergence
> begin...
Could you point to the specific place where it says RedHat is going to work *with* Sun, please? I got the impression that RedHat was going to be releasing it's own JDK, not working *with* Sun on theirs.
>
> gt; Also, let me be the first to say...my app seems
> to
> > work OK on Sun's Java, but not Red Hat's Java.
> Is
> > anyone else having this problem? ;)
>
> What you call "Red Hat's Java" is presumably GCJ.
We don't yet know what Red Hat means when they say they'll be releasing a TCK-compliant Java.
> GCJ won't run all Java programs, because it isn't
> 100% Java compatible (not through lack of trying).
100% Java compatible - passing the TCK - is a necessary but not sufficient condition for running all Java programs correctly.
> But Red Hat is committed to shipping a free (as in
> freedom) runtime for Java programs, and up until
> OpenJDK became available, GCJ/GNU Classpath was
> pretty much the only game in town.
Which, IMO, was a good thing. Very few people used gcj, classpath, etc. So we essentially had just one Java.
> But now with
> OpenJDK Red Hat has the opportunity to ship a more
> compatible (and ultimately 100% compatible) Free
> Java runtime...and that's great news!
OK, go ahead, I'm listening. Tell me why it's a good thing. As we've discussed many times before, I think the situation with C and C++ is a bad one: many "100% compatible" implementations that all more or less conform to the standard, and the need to port among them.
Re: Red Hat Joins the OpenJDK
I was being facetious. I was just pointing out how there can be many differences among alternative Java implementations which will give us all headaches. All the while, none of those differences cause it to fail to TCK, so they're all "Java compatible". Similar to how all C/C++ compilers are all "compatible" because they all conform to the standard.Re: Red Hat Joins the OpenJDK
> Exactly why would an announcement that Red Hat has> licensed the TCK (meaning they plan to be compatible)
> and signed the Contributor Agreement (meaning they do
> not plan to fork) imply anything at all negative,
> Andy?
You probably have to have read Javalobby for the last few years to appreciate my post.
The negative is exactly what I point out: that if companies (such as RedHat) start releasing their own Java's, we'll be back to the bad-old-days of C/C++ ports.
Passing the TCK is similar to conforming to a standard: it's a minimum requirement to ensure some basic compatibility, but it does not go nearly far enough to ensure real compatibility.
Additional tools, additional options, different packaging, additional packages would not break the TCK. As for additional keywords and constructs, these may or may not fail the TCK, but if they do, it's easy enough to get around that. They could simply provide a preprocessor, for example.
As for Red Hat signing the Contributor Agreement, that doesn't necessarily mean they don't plan to fork. The exact wording from Red Hat is "Red Hat plans to distribute a compatible, open source Java software implementation." If they had simply intended to distribute Sun's JDK unchanged, they would have worded that differently, I think.
Whether it's a true "fork" or not can be debated, but either way, if they deliver anything other than exactly what we get from Sun, I think that's a bad thing. Again, I'm simply going by the history of C and C++. Best case is you end with something like a repeat of gcc/egcs: this:http://www.softpanorama.org/People/Stallman/history_of_gcc_development.shtml
Worst case, you end up with many compilers out there as divergent as MSVC++ and gcc.
It doesn't take a Microsoft in the picture to be a mess. Porting C/C++ among Solaris, AIX, HPUX, and Linux is a pain, too.