Slashdot Mirror
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."
I'm surprised that Sun put any kind of a negative spin at all on this. An Open Source J2EE compliant Container would be a Cruise Missile right into the Microsoft camp. It's un-friggin ridiculous how damn much IBM, et all, wants for a J2EE compliant server. Honestly, it's outrageous for small companies and your partners you want to deploy to. Honestly, I'm surprised IBM charges as much as they do with all the payroll savings they now have from sending jobs over to India. Where are the savings going? ;-)
... that their code won't pass the tests, and that some of the code is just copied from Sun.
Meaning, that Sun's code won't pass the tests either?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Those of us that have used the "big 2" webapps (weblogic + websphere) and jboss can tell you that jboss will pass J2EE compliance without any issue.
JBoss isn't necessarily as efficient or as fast as the "big 2", but its always first in adapting new versions of J2EE and JSP. JBoss is always on top of new java technology, and doesn't have the vendor specific code that the "big 2", unfortunately, have.
JBoss is really gaining serious popularity in the Java world. Its really a nice product and is true to the "non-vendor specific code" that other app servers claim to have, but don't.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
However, Phipps said he doubts that JBoss software will pass the compliance test. Basing his opinion on public information, he said, JBoss software does not appear to implement all of the J2EE specification.
Sun should already know if JBoss can pass the test since sun already had the test suite and JBoss is freely avaliable. My guess is they were pouring over the spec next to JBoss with a fine toothed comb to find things that weren't implemented and add the to the suite before it is released.
As x approaches total apathy I couldn't care less.
"Call their bluff"? Come on. JBoss has been waiting for almost a year for this test. Will everything pass without a hitch? Probably not, but that doesn't mean that they won't get the certification right away.
I love JBoss, I've used it for pilot projects for a few years now, but I've never been able to get it into production, and one of the reasons is that it wasn't "certified" by Sun. All hail the day when JBoss is certified!
---
I read your email...
Who is John Galt?
The problem is that J2EE servers usually implement the standard and then have non-standard extensions. So, the reworking would basically involve removing the calls to the vendor specific pieces.
Uhhh, have you heard of .Net? It's popular with many shops because of the lower cost of entrance.
The cost of a J2EE Container is a big obstacle for many shops.
Each vendor has custom deployment descriptors that tell teh app server "how" to deploy the j2ee app.
These need to be custom written (or generated with xdoclet) for each app server.
Each vendor also may more or less strictly enforce the j2ee spec or have hidden proprietary features which freshman developers may unwittingly rely upon.
"I will never ever say JBoss out loud. I can imagine what it would sound like, and it's frighteningly lame."
Unlike "stratjakt", which just rolls off the tongue.
"I predict that now that we're calling their bluff, they will make up another excuse for not doing the tests," Phipps said.
A comment like this from Sun is unnecessary and appears childish. This kind of remark is unprofessional and serves no purpose except to build animosity.
What will he say if it does pass? If it does not pass, did his comment serve any purpose except to give JBOSS a reason to believe the test was biased?
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.
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
If Sun thinks the JBoss group copied code, then why don't they prosecute them under copyright law?
Physicists do it with a big bang!
Even if it isn't 100% J2EE compliant, it still works as bean container, and is in general easier to use and way less expensive than the commercial alternatives, there are some of us who like to use java based web platforms, but don't have six figures to spend on it. And if it isn't J2EE compliant, this isn't such a big issue if the points of non-compliance are openly known. Viva the OSS MM
Isn't it ironic that this guy Phipps' job title is given as "chief technology evangelist" yet he snidely quips that he doubts JBoss, a product that has done much to advance J2EE in the small to mid-size business arena, will even pass the tests?
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.
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.
-- mg
We (IONA) certified our app server on Sun, and we failed something like 50 tests which we investigated and found the tests were acutally bad. The thing is, others had passed these same tests -- what we found is that the J2EE reference implementation had bugs which "passed" these bad tests, so obviously everyone else who was certified was using large parts of the reference implementation in their test suite. Heh.
He's right, though.
.NET, no matter how much I'd love that.
This hurts IBM and BEA a lot more than it will hurt Microsoft. Moving a Microsoft shop to J2EE is hard. They're two totally different things. It's like trying to turn a toy factory into a car factory.
Re-training and re-certifying all your developers is likely to hurt your pocketbook a lot more than the cost of a Windows license, or even a Websphere license, even if it is (and it is) ridiculously expensive. Thus, we're not going to see a mass exodus away from
Moving a Weblogic shop to JBoss is easy. You just start dealing with a different company. Most smart companies do this all the time when they see a better deal. You call a different support number, maybe spend a week or so in a class learning what's different, and save a lot of money. Of course, the fact that JBoss is widely regarded as being more developer-friendly than the big commercial servers is great, too.
I'm glad Sun is offering to do this. I'm not surprised they had to think long and hard before doing so.
Game... blouses.
Bringing up Mono supports his point.
Yes, but only in one ear.
I just spent a night at BEA eWorld speaking to a sales rep and developer at a dev2dev Open Source Software roundtable. I thought at first this would be a good thing... You know, how to use OSS tools and software, getting BEA to acknowledge that it's cool, and that, most importantly, developers WANT OSS tools and software.
But the evening turned into a whole BEA vs JBoss debate. The sales guy was kind of rude and cocky about JBoss... and everytime we tried to change the subject (to the benefits of OSS, for example), he kept going back to slamming JBoss.
I was very disappointed in the BEA sales rep, I expected a much more professional and conversational attitude. His partner, whom I think was a developer, had a much better view and kept trying to calm his friend down.
Admittedly, I can see where JBoss is a potential threat to BEA, but really, they have nothing to be afraid of (so far.) Their products are positioned for large applications and large enterprises, and JBoss would have trouble supporting that right now... (unless a large application needed to support a smallish to medium sized app...)
The plus side was there was a whole table full of people who were *for* OSS, including other tools, not just JBoss. In fact, I was later told that our table (in a room full of discussion groups) was the most active and interesting. Maybe someday those guys will be managers, directors, etc and will make decisions based on wisdom and common sense, and not sales and marketing pitches.
[Disclaimer: I love BEA's products. They're doing some great stuff -- they just need an attitude adjustment when it comes to OSS and other tools.]
And while I'm rambling... I just spent the last two days trying to get corporate approval to run the Tomcat based servlet container that comes with the Actuate 6.0 Reporting tool. There are a whole slew of valid business reasons why this is a Good Idea, but it was a no go. Instead, we have to link that product into our BEA servers, which aren't load balanced or very well protected for failover right now. Big Corporations seem to be afraid of OSS, and have extremely arbitrary rules for choosing software. This is something the OSS community needs to work hard to change. We're making headway, especially in terms of operating systems (RedHat), but we need to push even harder for other products.
So now please answer why JBoss needs to be compliant other than allowing legacy to run?
Because if JBoss is not compliant, nobody will use it. The fact that it is open source is a really poor argument for not needing standards compliance. Should GCC's cc be non-ANSI C since if you needed it to be ANSI C you could just open up the source and make it conform? The Apache HTTPD server is compliant to the HTTP spec. Tomcat is a reference implementation of a servlet container.
There's an ocean of difference between being able to access the source code and being able to effect changes to that source code. Open source should conform to standards.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)