Sun 'Calls JBoss bluff' on J2EE compliance

joshmccormack writes "According to c|net's news.com Sun has finally responded to JBoss Group's request for J2EE compliance testing. Simon Phipps, Sun's chief technology evangelist stated in the article he thinks JBoss Group is bluffing, that their code won't pass the tests, and that some of the code is just copied from Sun."

Config files, etc...

[lordpixel]

The J2EE standard doesn't cover everything you'd ever need to do to get an application off the ground.

eg, most enterprise applications allow you to connect to a database. J2EE defines a way of naming the database connection ("DataSource") with a logical name. Say "MyBigDB". This is a name bound into a JNDI tree - basically a directory. Give the directory "MyBigDB" and you get back an instance of DataSource that can connect to your database.

At some point these convenient names "MyBigDB" must be mapped to actual parameters (hostname, username, password, port number) of the database.

J2EE doesn't really specify this. Each vendor has their own config file syntax for doing this mapping.

So this is the sort of thing they mean when they say it takes "hours" to port. You find out where JBoss keeps its config files, what the syntax is, and how to map MyBigDB to the hostname etc.

Hopefully none of your code changes, its just a matter of defining mappings in config files. The more complex your application, the more points of contact with "the real world" or "the bare metal" it probably has. J2EE hides a lot, but it can't hide everything.

Hold on one second...

[jaaron]

This may not yet be a chance for rejoicing. See the ServerSide [theserverside.com] article on this same issue:


Phipps' remarks are bizarre since it is obvious that no vendor can pass the J2EE 1.4 test suite, since J2EE 1.4 itself is not in final release yet.

There's something not quite right about all this, so it may be a setup by Sun to put JBoss in a difficult position.

Re:Go get em JBoss!

[Mike TV]

Bluff, shmuf.. Sun is scared of JBoss and what it might mean if vendors don't want to play ball with their J2EE 1.4 spec. This article [internet.com] claims JBoss doesn't need Sun's testing nor does it want it.

Re:Compliant or not?

[dancornell]

Even beyond discussing non-standard extensions, there are facets of application development/deployment that are not covered by the J2EE spec. Therefore, in order to provide the environment the application expects, there is application-server specific configuration that must go on.

Specifically, this is often the case in setting up the JNDI tree for the application and for the individual components (java:/comp/env/) as well as configuring features like EJB 2.0 CMP where you must map database fields to Entity EJB fields, and configuring the specific JMS queues and topics that you want to connect your Message Driven Beans to.

JBoss uses a jboss.xml config file, BEA WebLogic uses a different configuration file, and other application servers use their own file formats and tools. JBoss offers a tool that helps migrate WebLogic configuration files to their XML format. This doesn't cover non-standard extensions, but it does cover converting many of the application-server configuration options.

JBoss and others

[dagooncrn]

I used all 3 most popular containers (JBoss, WebLogic, Websphere) and seems that JBoss is the best choice. Websphere was always late with standards and Weblogis was always ahead (Websphere was EJB1.0 + some 1.1 compliant when Weblogic had almost all EJB2.0 features), but Weblogic had many errors in it's bleeding edge versions. JBoss was developed fast and with latest specs in mind but I didn't encountered any real problems.

Re:Evangelist? More irony?

[bnenning]

No kidding. If he's not reflecting Sun's official position, he needs to be smacked down. If he is, that doesn't speak well for Sun at all.

JBoss architecture vs Sun code

[Roullian]

Jboss is based on a revolutionary architecture, using extensively AOP [slashdot.org]. This is completly different from Sun's own application servers (the J2EE reference implementation and Sun ONE).
I *really* wonder which code could have been copied from Sun???
As JBoss is open source, I guess Sun could point out which specific parts where copied?

Concerning Jboss's J2EE compliance, it is widely known that Marc Fleury hates Web Services (and RMI too..). So obviously there are chances that JBoss will not be compliant in that field. But that will only matter to the very tiny part of the population that uses SOAP... I mean, as long as my EJBs are running ok, I don't really care if some obscure part of the spec is not respected...

Re:Copied Code?!?

[jrumney]

Because the code that was copied was released under the Apache License as part of the jakarta project. Note that he is not alledging that the JBoss team had copied anything that they did not have rights to copy, only that they had copied software written by Sun (as significant parts of some jakarta projects are).

Re:Sun/Phipps needs to show more class

[MeauxToo]

Undoubtedly, JBoss will fix the areas where they are not compliant. But by the time they do, a new J2EE spec will probably be out, and they won't be able to pass again. Keep in mind that all the major app server vendors define the specs via JCP... so JBoss is necessarily going to always be playing catch up.

Two things. First, JBoss is part of the JCP defining a variety of specs including those that form J2EE. You too can become a member for free so long as you sign an NDA or two. The folks at the JBoss Group are writing the next version of the JMX spec for the JCP as an example.

Second, Sun is only talking about allowing them a to purchase a license for the J2EE 1.4 compatibity tests, not the current version, 1.3. Therefore, JBoss will be unable to certify itself on the current standard, and since most of the specs composing 1.4 are still in spec, they would probably fail any available tests.

One last point of note around Sun offering up the opporunity to buy the 1.4 tests is that Marc Fleury and many of the other JBoss developers have openly stated their displeasure with the Web Services angle of J2EE 1.4. They have stated that they may not implement all of 1.4 due to the little value they see in it, and their overall displike of "Web Smervices". So, Sun might be granting this opportunity knowing full well that JBoss has little or no intention of being fully compliant with J2EE 1.4

Re:JBoss architecture vs Sun code

[catch23]

Ya know, they really haven't done anything with AOP yet. I mean, they do use the whole dynamic-proxies thing, but that isn't really AOP. They are about to "try" doing some AOP stuff but they're encountering lots of speed bumps because they're discovering that they can't create a custom class loader that the Sun class loader will actually load. (chicken-egg problem, see JBoss-AOP forums for more details). Basically they're trying to rewrite the Java system classes but are finding that they either have to hijack the Sun class loader, or they have to statically modify the classes beforehand. They're trying to use concepts of AOP so that they can (in the future) convert every single basic java object into an EJB and implement transparent caching features without the programmer explicitly specifying it in code. They are not actually using Aspects, AOP is just one of those buzzwords for anything dealing with reflective programming languages or MOP related. They're trying to make use of Chiba's Javassist [titech.ac.jp] package to do bytecode rewriting as their own form of AOP, but what they don't realize is that Javassist is just not capable of doing the things they want, yet they are too stubborn to try and use something like BCEL [sourceforge.net] which may be harder to use, but can offer a lot more.

another article that discusses the issue

[marhar]

There's another informative article here [internet.com]

Highlights:

• Sun is miffed because JBoss supports J2EE 1.3, but doesn't seem anxious to move to 1.4.
  
• JBoss isn't happy with Sun taking this public.
  
• Sun wants "well under $1 million" for the licensing.
  
• Sun wants to be the "seal of approval" for J2EE servers
  
• JBoss believes anyone can claim J2EE compatibility even if they are not certified.
  

Re:Sounds like a setup to me

[Anonymous Coward]

XDoclet is a code generator. It uses metadata in JavaDoc tags to generate source files that make a complete EJB. This is merely one function of an integrated environment. XDoclet does not provide integrated version control, integrated UML design, server side debugging or any other of a large number of features you get with a typical J2EE development tool such as JDeveloper 9i.

...except JDeveloper is a terrible, non-intuitive, slow memory hog (much like its cousin Websphere Studio/Eclipse). I'm doing Oracle 9iAS development with IDEA, Ant and Enterprise Architect (UML tool). I paid for the IDEA and Enterprise Architect licenses myself because they are significantly better tools than those offered by the big vendors, they're not that expensive and they make me more productive. I paid for the license myself so that my employer is less inclined to disagree with my insistence that I use my own tools (and so I don't spend my days banging my head against the wall, frustrated with JDeveloper).

So, I agree with your argument that paid software can be worth the cost if you're more productive than when using free software, but the offerings I see from IBM and Oracle (and Borland) are not very good - from my estimate you'd need about 1GB of RAM to run OC4J and JDeveloper so that they respond quickly; I'm runnning OC4J, IDEA, Enterprise Architect, Windows Media Player, browser windows, text editors, etc all on a laptop with 512 MB RAM quite happily. In fact I only requested an upgrade from 256 MB to 512 MB so that I could load JDeveloper occasionally.

Re:Config files, etc...

[lordpixel]

Well, interestingly enough, the config files are often bi-level... so you have:

[Code] - using logical names
[J2EE Config file] - maps logical name to "physical name"
[Vendor Config file] = maps "physical name" to parameters like hostname/port

So often even your J2EE config file can be used unaltered. What tends to happen is the J2EE config files started out with relatively few features, and the vendors added all of their stuff in the Vendor Condig File (value-added or proprietary features).

As J2EE is revised, the most commonly supported or desired features tend to move up into the J2EE Config File level. So when you upgrade to a new version you might find that things you previously had to configure on a vendor level may now be configured in an abstract portable way.

This is natural evolution. It has a cost though: the extra layer of indirection makes the initial setup more complex. Once you get it down though, its pretty easy to maintain, as a rule.