Except from the article it seems that the intention is to introduce literature into the classroom that challenges evolution in the typical ID way, but without mentioning ID. In fact they already have it ready.
Additionally it's suggested that the law has been written in a way to make it a lot harder to strike down.
I had the impression that there was a lot lacking from GCJ at the moment - and not just the GUI libraries which aren't applicable for JBoss.
JBoss are currently implementing parts of the Java EE 5 spec (and have a near complete EJB 3 implementation), and these rely on some of the new language features (particularly annotations) introduced in Java 5.
It's tough for a project like GCJ to keep up with both the language features, JVM and JDK libraries. Plus when you're using the JVM for an Application Server, performance - especially when it comes to garbage collection - is critical.
In order to run JBoss on RHEL you'll typically have to install someone's JDK - Sun's or IBM's (or even BEA's JRockit). Cue long discussion regarding open sourcing Java... I wonder how they intend to handle that gap when it comes to packaging and support.
I think this is a better result for JBoss and it's users than Oracle would have been. Still, I think Red Hat will have fun coping with some of the personalities in the JBoss line-up - I wish them luck!
Hmm, doesn't look like I'll be able to get to the JBoss forums today.
Slashdot Mirror
Except from the article it seems that the intention is to introduce literature into the classroom that challenges evolution in the typical ID way, but without mentioning ID. In fact they already have it ready. Additionally it's suggested that the law has been written in a way to make it a lot harder to strike down.
I had the impression that there was a lot lacking from GCJ at the moment - and not just the GUI libraries which aren't applicable for JBoss.
JBoss are currently implementing parts of the Java EE 5 spec (and have a near complete EJB 3 implementation), and these rely on some of the new language features (particularly annotations) introduced in Java 5.
It's tough for a project like GCJ to keep up with both the language features, JVM and JDK libraries. Plus when you're using the JVM for an Application Server, performance - especially when it comes to garbage collection - is critical.
In order to run JBoss on RHEL you'll typically have to install someone's JDK - Sun's or IBM's (or even BEA's JRockit). Cue long discussion regarding open sourcing Java... I wonder how they intend to handle that gap when it comes to packaging and support.
I think this is a better result for JBoss and it's users than Oracle would have been. Still, I think Red Hat will have fun coping with some of the personalities in the JBoss line-up - I wish them luck!
Hmm, doesn't look like I'll be able to get to the JBoss forums today.