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."

Comments

Go get em JBoss!

[ChaoticChaos]

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? ;-)

Re:Go get em JBoss!

[ChaoticChaos]

You're just jealous your posts don't capture as many eyeballs as mine do. ;-)

Re:Go get em JBoss!

[ajs]

Hint to moderators, the parent is no more insightful than it is coherent.

"It's un-friggin ridiculous how damn much IBM..."

I'm going to have to get out the big parsing guns for this one...

"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"

And this is related... how?

Supporting evidence?

Re:Go get em JBoss!

[Anonymous Coward]

Pat yourself on the back, you squeezed out a sentence without the words "honestly" or "surprised" in it.

Re:Go get em JBoss!

[ChaoticChaos]

The connection is that IBM charges an arm and a leg for Websphere Advanced and I was making a humorous connection between that and the savings they are making with many of their jobs being shipped to India. Get it now? You can laugh at this point too. If you want to know when to breath in and exhale, just let me know that as well.

Re:Go get em JBoss!

[Vengeful weenie]

These are the problems you get when a company stradles the lines between software/hardware and copyrighted code/free code. I don't think it's a problem of a free version of J2EE, I think it's a problem of J2EE that runs on any platform [read non-SPARC, esp. WinTel].

On the other hand, the fact that JBoss might be using Sun code would be a problem for a truly free implementation.

Re:Go get em JBoss!

[Anonymous Coward]

I think the right interpretation is: Sun is playing the SCO game. They also said that after the SCO sued IBM they were reconsidering theur long term strategy with Linux. Am I crazy?!...think about it: they want to make people think Free Sw == Stolen Sw. Like IBM stole SCO's IP, so JBoss guys did.

Regards,
chrix

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 claims JBoss doesn't need Sun's testing nor does it want it.

Re:Go get em JBoss!

[dingd0ng]

It's about time Sun gave JBoss the chance to prove themselves. However, we've been using JBoss successfully for over two years, and will continue to do so regardless what happens between Sun and JBoss. But...go JBoss!!!

Re:Go get em JBoss!

[Anonymous Coward]

Maybe that is what you were trying to do. However that is not what your previous post said. The previous post did not make sense.

You may argue we should somehow understand your awful grammer or your ill-chosen phrases, but an intelligent person should be able to form a descent sentance. This leaves us to question your intelligence. I think after your other posts in this threads I've formed my own conclusion, you dumb cunt.

Re:Go get em JBoss!

[Rinikusu]

/* Where are the savings going? ;-) */

I know you were just joking here, but keep in mind that the same question arose when the US automakers began shipping US jobs wholesale to Mexico. The automakers stated that the savings to the company would be substantial. Unfortunately, just because it costs less to make does not in any way put the company in any sort of obligation to lower prices. Nike's that cost $200 at the Foot Locker generally only cost $5 at the most in materials, labor, warehousing etc using cheap labor in SE Asia. Where's the savings going? Into the company's coffers. :: sigh ::

Re:Go get em JBoss!

[ChaoticChaos]

"...you dumb cunt". Oh yeah, you're the pinnacle of pure breeding. Your true colors are showing through.

Re:Go get em JBoss!

[truthsearch]

JBoss is continually downloaded on a massive scale. It's also a very active project. It's obviously being used a lot out there. I'm guessing a lot of people get it to try out J2EE and see what the standard can do for them, then when it comes time to create a production system they go to a vendor like BEA or IBM.

Re:Go get em JBoss!

[ChaoticChaos]

LOL! I realized that when I wrote the comment. Notice the ";-)" you quoted above. I know what's happening with the savings. ;-) Still, back to the original point, it's unbelievable how much they charge for Websphere Advanced. I know of two shops with 10+ developers that went the Java route but didn't go the J2EE route because of the price of the J2EE compliant servers. They just could not afford it.

Re:Go get em JBoss!

[Anonymous Coward]

I understood it well enough. Perhaps you're stupid?

Re:Go get em JBoss!

[andrewski]

Sun is a truly misguided and confusing tamale. Spicy beef in the middle, and covered in red sauce.

Seriously, the misguided and confusing stances that they take on almost everything nowadays makes me wonder about the future of Sun. They hate Linux, they embrace it, they puss out again on it, they like Intel, now they don't!

It's really quite strance to see a business commit suicide by mass corporate confusion.

Re:Go get em JBoss!

[Anonymous Coward]

Is a descent sentance (emphasis added) opposite to an ascent sentence?

Re:Go get em JBoss!

[Anonymous Coward]

Apple's Webobjects is J2EE compatible, and sells for about $999 unlimited clients, iirc.

Re:Go get em JBoss!

[hawkestein]

Dude, welcome to the wonderful world of economics. They're only going to charge less if it means that they'll sell more units and make more money overall.

Re:Go get em JBoss!

[Anonymous Coward]

Indeed. I use JBoss in a development environment and then, alas, have to deploy to WebSphere in prod/staging :(

Re:Go get em JBoss!

[Anonymous Coward]

The Sun code they are referring to is undoubtably the SSL implementation from tomcat (also used in Jetty.) Which is free to use, but Sun probly has a restriction that their lawyers think they've found that disallow JBoss from using it and being a certified J2EE server. They may also have confidence that sections of the JBoss code won't pass test requirements, even if it passes real-world compatibility. They may only give JBoss 1 round of free tests, and any failing conditions means they will have to retest using the 6 figure certification process that IBM and BEA had to pay for. A one shot test is meaningless since there may be test cases that don't rely on results at all, only on irrelevant details.

If this seems odd, look at some of the JSRs coming out these days. JDO is held back specifically with nonsensical implementation requirements, which are specifically designed to protect Sun's partners from competition both from open source solutions (like Hibernate and Castor) and fine commercial products like Toplink.

Sun's code

[mcrbids]

... 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?

Re:Sun's code

[ChaoticChaos]

ROFL!!!!!!! Interesting inference. Sounds like they dissed themselves on that one. LOL!!!!!

Re:Sun's code

[Anonymous Coward]

ROFL!!!!!!! Interesting inference. Sounds like they dissed themselves on that one. LOL!!!!!

Just when I was getting ready to defend you against the guy who called you a dumb cunt, you go and post this. It was just a joke. You truly think the inference is valid? You are a dumb cunt.

Re:Sun's code

[ChaoticChaos]

Did you notice the "ROFL!!!!!" part of the post????? I *realize* it was a joke. Try reading before making a fool of yourself.

Re:Sun's code

[Anonymous Coward]

Deeper and deeper you dig. I wasn't saying you didn't think it was funny. But when you say "Sounds like they dissed themselves on that one," you are also implying that you think the inference is valid. You dumb cunt.

Compliant or not?

[The Bungi]

For example, a company that writes a billing application using J2EE software and tools should be able to run that program on any J2EE-compliant software without extensive manual coding.

...

But the company asserts that its software is compatible with J2EE because applications written for commercial Java applications servers can be reworked to run on JBoss in a matter of hours or days.

So... what is compliance in this case? It seems to me that if the application has to be reworked and the J2EE standard says otherwise, then there's no issue - JBoss is not compliant? Is that what the J2EE certification actually dictates?

Re:Compliant or not?

[BrianB]

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.

Re:Compliant or not?

[Fulcrum of Evil]

Perhaps they are referring to the removal of vendor-specific code?

Re:Compliant or not?

[mightycthulhu]

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.

Re:Compliant or not?

[lewp]

There's virtually no non-trivial J2EE application you can just take from one J2EE server to another. Even if both of the servers are officially compliant, say Websphere to Weblogic, there's still enough things left up to the container vendor in the J2EE spec that you're going to need to make modifications for everything to work properly.

Anyone who tells you that you can just deploy a J2EE app on any J2EE server is either lying to you, has never used J2EE, or is deploying apps where someone already put in the necessary time ensuring it works on a bunch of different servers.

The current main idea is to isolate the needed modifications to the application deployment descriptors as much as possible, rather than having to change the actual code.

I'm fairly comfortable editing Java code, and don't have any plans to begin making money off of Java code, so it doesn't do much for me. But in a large enterprise where the developers are far removed from the administrators or for a company trying to make money selling closed-source Java, I suppose this element of J2EE could be a big win.

Additionally, J2EE is fairly young in a lot of ways, and continually evolving. The more widely-implemented vendor-specific features will almost certainly gain official support in later versions of the spec, so as time goes on the situation should continue to get better and porting between servers should only get easier.

Re:Compliant or not?

[Delirium Tremens]

You obviously don't know sh^H^H much about J2EE.
A J2EE application is a mix of 3 things:

1. Java source code
2. J2EE XML descriptors
3. Proprietary XML descriptors

(1) and (2) can be reused. But (3) must be rewritten for each target application server. And depending on the application that is being migrated, this could be done in a matter of hours or days.

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.

Re:Compliant or not?

[The Bungi]

You obviously don't know sh^H^H much about J2EE.

Forgive me for asking. Do you hang out in IRC and tell newbies to go RTFM as well?

Re:Compliant or not?

[Delirium Tremens]

Well, you do have a funny way of commenting that sounds like FUD to me. That's why I jumped at you.

The article says: the company asserts that its software is compatible with J2EE because applications [...] can be reworked to run on JBoss in a matter of hours or days.
Yet, you come in and say that if the application has to be reworked and the J2EE standard says otherwise, then [..] JBoss is not compliant.

It seems to me that you have a serious English problem with understanding causes and their effects. Or maybe I should say RTFA.
Oh wait, this is Slashdot. I nearly forgot.

Re:Compliant or not?

[truthsearch]

I find that strictly complying with the deployment descriptor standards works perfectly for JBoss. Using the deploy tool from Sun's J2EE SDK everything I've written works perfectly on JBoss. I can't speak for any other servers, but I'm guessing they may add extensions which their developer tools add to the deployment descriptors. As you say, for non-freshman who know better sticking to the standard works.

Re:Compliant or not?

[Delirium Tremens]

Dear AC,

Please note that I never post messages as a loo^H^H^H AC like you did.

Now, go wash your mouth before your grand-ma smacks you for being rude.

Re:Compliant or not?

[rodgerd]

Because it's just a spec. AIX, IRIX, Windows NT (POSIX Server) and VMS have all claimed to be fully POSIX compliant. Now try and untar, build, and run a POSIX compliant C program on all those platforms unchanged.

J2EE is just a spec. The devil's in the details...

Re:Compliant or not?

[quigonn]

The POSIX that is implemented in Windows NT is actually only the system call interface - the very first version of POSIX didn't define anything about commandline utilities or such.

Re:Compliant or not?

[The Bungi]

You said I said:
J2EE standard says otherwise, then [..] JBoss is not compliant.

That's nice - you omitted the question mark I put at the end of that sentence. If we choose not to ignore that, then this:

It seems to me that you have a serious English problem with understanding causes and their effects

Is just you trying to put words in my mouth (or just insulting me by implying that my grasp of English is somehow more deficient than yours?). I was quoting two pieces of the article that seemed at odds with each other, verbatim, and then asking a question about them.

Or maybe I should say RTFA

Indeed.

Re:Compliant or not?

[Anonymous Coward]

Dear Delirium Tremens,

Shut up. Your opinions are uninteresting and unimportant. Go back to IRC where you tell "cluebies" to "RTFM."

Sincerely,
Anonymous Coward.

Re:Compliant or not?

[Delirium Tremens]

ok ok ok. truce. let's agree to disagree.
Besides, I did answer your question. Albeit, rudely. So, see, I am not an evil elitist.

Re:Compliant or not?

[The Bungi]

OK, peace =)

Re:Compliant or not?

[Anonymous Coward]

do you eat out your dad's asshole with that mouth?

Re:Compliant or not?

[Insideo]

We get around this at my company by doing our development using Apache Tomcat, and then testing and deploying on IBM Websphere.

This allows us to catch incompatibilities quickly, before they become problems later on. If our unit tests won't pass on both Tomcat and Websphere, then the code doesn't go in.

If we ever need to port to another appserver (e.g. Weblogic), it shouldn't be a problem as we already have code that works on two different J2EE (or almost J2EE in the case of Tomcat)-compliant app servers.

Re:Compliant or not?

[Anonymous Coward]

For the love of god, get rid of that sig. Every time I read it I cringe at the stupidity of it. Please... do it for the ACs out there :(

Re:Compliant or not?

[Anonymous Coward]

"Loser" has one "o". "Looser" has two. They don't mean the same thing.

Re:Compliant or not?

[Dr. Scott]

We get around this at my company by doing our development using Apache Tomcat, and then testing and deploying on IBM Websphere.

Which reminds me of the old saying: there is no such thing as portable code, there is only code that has been ported.

It'll pass, no problem

[FortKnox]

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.

Re:It'll pass, no problem

[lewp]

I can't see a problem with having helpful vendor specific features if you're clear about the fact that they are vendor specific.

Scenario 1: You want the ability to easily move between servers. You avoid using the vendor specific features of the various servers. Everything works out fine.

Scenario 2: You don't care about moving between servers. You use handy vendor specific feature A and are able to get up and running faster as a result. Again, everything works out fine.

In 99% of cases I'd go for scenario 1, but I certainly wouldn't be pissed to have scenario 2 available to me, just in case.

Re:It'll pass, no problem

[Anonymous Coward]

Of course JBoss will pass certification.

Just look at the header of all its deployment descriptors... oh wait.. they are not compliant. Well what do you know..

- Definite Troll -

Re:It'll pass, no problem

[DickBreath]

Let's see. Sun has access to JBoss, because it is open source.

JBoss has been complaining about not having the compliance test.

Maybe Sun knows something that we're all about to find out. Maybe JBoss won't pass the test. Even some tiny failure to pass the test. So maybe this is why Sun is putting such a negative spin on what should be such a positive development.

The negative spin should also clue us in to Sun's true feelings about JBoss.

Re:It'll pass, no problem

[RodgerDodger]

First, I don't believe anybody's passed the tests on their first attempt.

With the tests not being generally available, most vendors focus on deskchecking against the spec (usually via their own test cases), plus doing what the reference implementation does. However, the reference implementation doesn't pass the official tests either.

Secondly, the test cases themselves are not perfect. They're software, and they have bugs. Just like the vendor software being tested, the test cases were written by someone interpreting the spec, and there's no assurance the interpretation was accurate.

If Sun allow more than one pass over the test cases, and give feedback on what's failed, I'm certain JBoss will be passing before long.

The main news here is that Mark Fleury won't be able to brag about how Sun won't let him show how good his software is anymore. If it makes Fleury shut up, then I only wish Sun had done this earlier... :)

Re:It'll pass, no problem

[timeOday]

I've been bitten by scenario 2, with CORBA. There was some vendor-dependent code in our stuff, but it's a good product so who cares, right? Well, one year they assigned us a new sales rep and he decided we hadn't been paying nearly enough, or maybe he just wanted a bigger comission and thought we couldn't migrate, who knows. So they tried to quadruple the price.

We ended up porting to TAO. It wasn't THAT bad, but we did end up writing some stuff twice - first vendor dependent, then vendor neutral. Not money well spent.

On another but related topic, since TAO was free, the management couldn't believe it would be any good, so we had to give the impression we were just using it for a while until we found something more expensive. Of course, TAO was more standards compliant, open source (fabulous for debugging), and the developers would respond to questions on the same day (much better service than from our very costly support contract with the "other guys.") It made a great impression on me and everybody else for open source, and I gather JBoss is just that sort of project too.

Re:It'll pass, no problem

[PissingInTheWind]

What about the scenario where a poor misguided soul use vendor-specific features, not adding anything to performance and yet losing portability?

That's a problem too with vendor-specific features, they can easily be misused in many ways.

btw I mostly agree with you, just adding my 2 bits.

Hooray

[Anonymous Coward]

This is great. JBoss will finally receive a blessing that it has long needed. Even if it doesn't pass the tests at first, you can bet they will shortly thereafter. Isn't that the point of the tests? Who cares what Simon Phipps says.

Good news!

[Joe the Lesser]

Regardless of the outcome of the tests, the only way to make progress is to let things happen. Even if they can't pass the tests, they'll come out of it more experienced and have feedback.

Perhaps Sun finally felt some heat from the tech community? (pun intended)

Re:Good news!

[dnoyeb]

I don't get it. This is not school right? They can take the test 100 times a week till they pass. So just making the test available seems to be to be inviting them to pass it. its open source, those guys get happy when bugs and stuff are found after all.

Re:Good news!

[pivo]

They can take the test 100 times a week till they pass

Only if they have a supercomputer. The last time I ran them they took three days, but my machine is slow. Even on a fast machine they'd take a day.

Passing the tests is very difficult and no doubt there will lots of areas where they'll have problems, but yeah, they'll eventually pass and that'll be one fewer reason not to use JBoss. yay.

Re:Good news!

[Anonymous Coward]

There is a reason you're called "the Lesser," isn't there. Intellect, I'd imagine.

Cruise Missle into Microsoft??

[Black-Man]

No... that would be BEA and IBM. Since when does Microsoft have a Java App Server??

Re:Cruise Missle into Microsoft??

[ChaoticChaos]

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.

Re:Cruise Missle into Microsoft??

[chrisseaton]

Uhhh, have you heard of Mono?

Re:Cruise Missle into Microsoft??

[Anonymous Coward]

Mono is not anywhere a company would base a business project on, and no IT manager without a winning lottery ticket would bet his job on Microsoft technology being cross-platform.

Re:Cruise Missle into Microsoft??

[lewp]

He's right, though.

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 .NET, no matter how much I'd love that.

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.

Re:Cruise Missle into Microsoft??

[Anonymous Coward]

Uhhh, his point is that .NET is cheap while J2EE is expensive, and that Sun therefore benefits from the arrival of JBoss.

Bringing up Mono supports his point.

Re:Cruise Missle into Microsoft??

[rodgerd]

+1, Funny.

Re:Cruise Missle into Microsoft??

[Paradise Pete]

Uhhh, have you heard of Mono?

Yes, but only in one ear.

Re:Cruise Missle into Microsoft??

[Anonymous Coward]

It's like trying to turn a toy factory into a car factory.

Wouldn't "more like trying to turn a Skoda factory into a Humvee factory" be more appropriate? :)

Re:Cruise Missle into Microsoft??

[stor]

> Uhhh, have you heard of Mono?

Uhhh, have you heard of anyone *deploying* mono in a corporate production environment?

Cheers
Stor

ps. Sun don't get it... they never have. Way too arrogant to see past their own BS.

Re:Cruise Missle into Microsoft??

[chrisseaton]

No, shurely Mono is "An Open Source [ECMA] compliant Container would be a Cruise Missile right into the Microsoft camp"

Re:Cruise Missle into Microsoft??

[oznet]

Are you saying J2EE creates applications that are bloated, heavy, gus-guzzling, expensive, unreliable crap?

Not that I would argue.

(BTW I know several people who own Hummers, both real ones, and that Cheby POS. And I was reffering to all of them above)

Re:Cruise Missle into Microsoft??

[silverbolt]

I am not the grandparent poster, but ...

I have heard of Mono, but most people have not ! Shops that would think of using JBoss would be even less likely to know about Mono.

Re:Cruise Missle into Microsoft??

[stoborrobots]

The key point is that now is the time when many companies are making that decision... Now is when the barriers to entry for an application server environment must be few, and far between...

At the moment, the entry to J2EE is pretty well blocaded by the $$$,000 that IBM and BEA are charging. So companies will invest in the initially cheaper MS environment.

If there is a "portable" (and hence more preferable) solution available, and it stacks up cheaper, then it will hit MS as hard as it hits IBM/BEA...

Re:Cruise Missle into Microsoft??

[Anonymous Coward]

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.

JBoss is Open-source. It's already widely used among Java developers, and if it manage to get a J2EE certification, yes, it'll be a cuise missile in the Microsoft Camp.

Sounds like a setup to me

[bmongar]

From the article

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.

Re:Sounds like a setup to me

[mpechner]

There are some things going here.

People from the JBoss team will be present.

It will be the same test BEA and IBM has to pass.

If this wasn't the case, we'd all be paying for JRun licenses instead fo using TomCat.

Re:Sounds like a setup to me

[Tailhook]

Sun should already know if JBoss can pass the test since sun already had the test suite and JBoss is freely avaliable

Sun probably does know. If you were Phipps, would it be better to simply proclaim that JBoss is not compliant and create an Open Source "martyr" or merely suggest it isn't and let the JBoss Group prove you wrong?

Personally I doubt it is actually compliant. The test suite is very thorough and pokes around in obscure areas of the various specs, some of which are ambiguous. The big vendors spend a lot of time massaging their products to comply with the spec with the benefit of the licensed test suit at their disposal. JBoss hasn't had this luxury. They'll need to go through this process before all the light turn green. Don't be surprised if it takes the JBoss Group a year to get there.

I don't blame Sun for withholding certification from JBoss. They have managed to get powerful vendors to sign on to the J2EE platform based on the promise that there is a payoff in terms of licenses. Now that these big vendors have established a credible market for the platform, Sun can let JBoss play and provide a low cost point of entry. Had a "free", certified compliant implementation existed early the big vendors may have thought better of it. Sun now wants JBoss compliant because it makes the platform stronger to have a solid low-cost implementation.

JBoss is not threat to the big J2EE vendors. Implementing a single server side class in J2EE requires writing at least three separate bits of Java code for the home, remote and bean interfaces/classes. There may also be local variants of these to overcome marshalling overhead. XML metadata must also be maintained. This is for a single EJB. If you have many EJBs, you have a very large number of source files and bits of metadata that must be kept in sync. The big commercial vendors sell tools that make this easy. You can do it with vi, but you don't want to. If JBoss is really compliant and really as good as its hype, the vendors will just incorporate it into their own products, just like they did Apache. Their "value add" still remains, because JBoss does little or nothing to relieve the sheer development burden of distributed J2EE development (aside from good dynamic deployment.)

J2EE is now technically credible and supported by real vendors with real products. Now Sun wants to make it cost effective by allowing JBoss to compete after getting its certification ducks in a row. Wise move.

Re:Sounds like a setup to me

[ahornby]

JBoss is not threat to the big J2EE vendors. Implementing a single server side class in J2EE requires writing at least three separate bits of Java code for the home, remote and bean interfaces/classes. There may also be local variants of these to overcome marshalling overhead. XML metadata must also be maintained. This is for a single EJB.

XDoclet makes this really easy - you only have one source file and the rest are generated.

Re:Sounds like a setup to me

[Tailhook]

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.

I'm not knocking XDoclet or JBoss or anything else. I'm only pointing out that there are obvious advantages to the commercial platforms. When a project grows beyond a handful of geeks you need "high-touch" tools.

I know J2EE developers that could just barely manage to install J2SE+J2EE properly on their local machine on a good day. You can not expect these people to adopt XDoclet/Ant/CVS/ArgoUML/etc and make it all function productively. You can expect them to write perfectly good business applications from within an integrated environment.

Re:Sounds like a setup to me

[ahornby]

I know J2EE developers that could just barely manage to install J2SE+J2EE properly on their local machine on a good day. You can not expect these people to adopt XDoclet/Ant/CVS/ArgoUML/etc and make it all function productively. You can expect them to write perfectly good business applications from within an integrated environment.

True enough. The JBoss IDE effort for eclipse might be off use for those people. I think eclipse also has remote debugger support, CVS integration et al. Being more of an emacs/command line type person I haven't really looked into it that much.

Re:Sounds like a setup to me

[twisty7867]

>You can expect them to write perfectly good
>business applications from within an integrated
>environment.

Actually, you can't. As an architect/project lead, I find that no greater than 50% of developers can actually be expected to write a business application of acceptable quality without intense supervision. I do share your assessment about J2EE tools, though. As a .NET developer as well as J2EE, even the best tools are marginal, and I find Eclipse et al to be primitive at best.

Re:Sounds like a setup to me

[steve_l]

Sun dont want to let jboss near the tests, but apache forced them in to it last year, when they threatened to stop working with Sun unless open source projects got access to the test kits (not the reference impls) under various terms and conditions. Axis is the first Apache project to do this, and it has been beneficial. Except when their tests are different from the spec, which happens sometimes.

A certified JBoss (it'll happen eventually) will hurt BEA and IBM, and Sun via licensing fees. But it is good for Java.

Re:Sounds like a setup to me

[iabervon]

The test suite is very thorough and pokes around in obscure areas of the various specs, some of which are ambiguous.

This is obviously a good reason to ignore Sun's certification: the test suite relies on unspecified behaviour, and is therefore not 100% compliant itself. Of course, the J2EE specification itself is badly managed; it is impossible to write code for container-managed relations which is legal with both the second proposed final version of the latest release and the final release. Most of the incompatibilities between JBoss and other implementations that I have noticed has been that JBoss only follows the version of the specification that it says it does, while Weblogic (e.g.) lets you use features together which were never both permitted in a single version.

Of course, the certification is essentially bogus anyway; I've seen obvious non-compliant behaviour from a version of Weblogic that was certified.

Re:Sounds like a setup to me

[Anonymous Coward]

Perhaps Sun should just go back and rig the tests so that JBoss will fail like they did with MS and Java certification.

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.

Finally!

[delirium28]

"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...

Re:Finally!

[bwt]

I agree. JBoss is open source, and clearly the are pretty damn close to compliance. Even if Sun designed the test to expose every noncompliance JBoss has, the result will be good for JBoss. They'll do the tests, post the results, people will mob the incompatibilites, and then it will pass.

What I don't understand is why you need Sun to write the compatibility tests. Isn't it a fully documented standard? Why doesn't somebody just create an open source compatibility test?

Sun: "They copied us"

[stratjakt]

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. Phipps also noted that JBoss appears to be using software written by Sun

translation:

"They copied us, and we suck!"

I will never ever say JBoss out loud. I can imagine what it would sound like, and it's frighteningly lame.

Re:Sun: "They copied us"

[abigor]

"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.

Re:Sun: "They copied us"

[Anonymous Coward]

JB o s s..... hopefully you're not dyslexic...

Re:Sun: "They copied us"

[bigsteve@dstc]

The CNET article doesn't say that any more!!! Specifically, the sentence "Phipps also noted that JBoss appears to be using software written by Sun" is no longer there.

I wonder if Phipps actually said that in the interview. If he did, he'd better have some evidence!!

No shit...it's free

[Anonymous Coward]

JBoss is really gaining serious popularity in the Java world.

No shit...it's free

Sun/Phipps needs to show more class

[Kefaa]

"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?

Re:Sun/Phipps needs to show more class

[Anonymous Coward]

A year ago, I might have cared about this, but now, GAH! I am quite fed up with the state of the Java group at Sun. The VM is just terrible, even on Solaris, and the entire J2EE spec is just entirely too ponderous for a lone developer like myself to even consider using, not that I'm advocating .Net either. Personally, I'm gonna stick with tried-and-true PHP/Perl, using HTTP for message passing. Its worked well for me so far. Yeah yeah, I guess this is just flamebait, but I'm tired of Java. It's burned me three times, and it's not happening again.

Re:Sun/Phipps needs to show more class

[sprytel]

Sure it does... remember, its all about perception.

When JBoss doesn't pass (as has been pointed out before... its Sun's test and a free product... so they must already know the outcome), then Sun can say:

"See JBoss is an interesting little diversion, but if you want a REAL J2EE-COMPLIANT APP SERVER, then you need to buy a commercial product."

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.

Its a pretty smart move by Sun. It keeps them from looking like the bad guy, or "anti-open source", but at the same time serves to marginalize JBoss as a competitor to "legitimate" commercial app servers.

Re:Sun/Phipps needs to show more class

[evronm]

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.

My thoughts Exactly. For someone who's supposed to be an "Evangelist", he sure doesn't know a thing about PR..

<SimpsonsComicBookStoreGuy>"Worst evagelist ever" </SimpsonsComicBookStoreGuy>

:-)

Re:Sun/Phipps needs to show more class

[Soko]

What will he say if it does pass?

"Whadda ya know? Guess we wrote the specs in a way that even amatuers could understand them..." - or some other way to spin Sun/Sun's J2EE into looking better.

If it does not pass, did his comment serve any purpose except to give JBOSS a reason to believe the test was biased?

Biased? Having the JBoss devs play that game would be lame as well. What would be worse for Sun would be the following:

"Fuck. Welp, no sense whining about it.

Now that we know where we're not compliant, break out the code editors, people. Let's fix it all now, and then we can tell Phipps to shove it where the Sun don't shine..."

Soko

Re:Sun/Phipps needs to show more class

[Trailer Trash]

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.

Gee, childish, unprofessional remarks from a Sun employee? What's next? Lies from Redmond?

Re:Sun/Phipps needs to show more class

[Anonymous Coward]

I like loving Sun.

But we grew apart. I still send her cards sometimes on the holidays though.

Damn Ultra 10's.

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:Sun/Phipps needs to show more class

[Anonymous Coward]

"Sure it does... remember, its all about perception."

I think its all about kicking people in the balls who play the its all about perception game.

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.

Re:Config files, etc...

[The Bungi]

I figured as much. Still, it seems to me that even a simple abstraction could be better -at that level- than simply not specifying what a server should do.

As luck would have it, I've been engaged in a project to create a .NET app server (as an alternative to COM+) for the past few months and we're trying to figure out how other similar products work. My point of reference tends to be the MTS/COM+ model so I've got a ways to go.

Thanks for the explanation.

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.

to be fair

[Anonymous Coward]

There are features in websphere and weblogic that JBoss doesn't have. For example, weblogic has T3 connection pooling that allows webserver to use it's pool of connections. Websphere has tight integration with VAJ. JBoss has it's strengths too, so in terms who is better it depends on the user.

for people who have to connect to DB2, websphere and VAJ is obvious. For those who want to share a connection pool with the webservers weblogic is nice. I think Jboss will pass with minor fixes and changes. No big deal by any means.

Copied Code?!?

[bokumo]

If Sun thinks the JBoss group copied code, then why don't they prosecute them under copyright law?

Re:Copied Code?!?

[rossjudson]

If they think the JBoss guys copied code, why don't they just point out the file and line numbers. It's open source, isn't it?

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).

Shouldn't Sun

[Znonymous Coward]

be working a getting the dot back into dot com or something? .backwards is everything Russia Soviet In

Re:Shouldn't Sun

[HoneyBunchesOfGoats]

.backwards is everything Russia Soviet In

Does this mean that Yoda was a communist?

Certification means squat.

[Anonymous Coward]

Just because a java app server is certified doesn't mean it's perfectly compliant. There are definite holes in WebLogic that aren't there in JBoss. Reading the spec, the JBoss people are the ones who got certain issues right.

Hold on one second...

[jaaron]

This may not yet be a chance for rejoicing. See the ServerSide 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.

Still useful

[mysterious_mark]

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

How does that help Sun?

[sterno]

Sun makes money by charging for the testing and certification and licensing of the J2EE standard to the likes of IBM and BEA. If I can download a free product, that's licensing fees that don't go to Sun. Sure, I'm not buying Microsoft's products, but it's not like Sun would be benefiting either.

Re:How does that help Sun?

[ChaoticChaos]

I think your point is spot-on. I've read that as well. I was talking to someone today about Sun's sad stock price and commented that it is a shame there isn't a small royality they make on Java period. Just a tiny one would help Sun tremendously.

Re:How does that help Sun?

[Anonymous Coed]

Then even fewer people would look at using Java than do now.

Re:How does that help Sun?

[Anonymous Coward]

Funny thing was that for a long time IBM WebSphere was not certified -- Did that hurt it's sales? Probably not.

Certification is a big deal for the small players (JBoss and commercial) -- the big guys like BEA etc have enough mindshare that they don't need it.

JBoss failure means $$$

[Anonymous Coward]

WIth the horrendous price of Bea's Weblogic and IBM's Websphere, the biggest surprise was the large number of IT departments who were paying up for these compliant solution. I am usually a supporter of Sun but this incident is bringing that into question. I know some of the people involved with JBoss and can attest to their tenacity to provide an opensource alternative EJB server.

Re:JBoss failure means $$$

[ChaoticChaos]

Bingo. Bingo. Bingo.

Re:JBoss failure means $$$

[Anonymous Coward]

Tell that to MS who Sun forced via judicial decree to ship a recent spec java compliant functionality layer to Windows. Sun is the sole arbitrator and it looks like they will strongarm to keep even propriatary extended features in so long as those with the cash pay them through licensing and compliance testing.

Evangelist? More irony?

[cdthompso1]

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?

Re:Still useful-A solution looking for a problem.

[Anonymous Coward]

Actually what place does JBOSS have in the sphere of java application servers? Is it (as one person said) the "atomic cannon" of solutions, while all the rest is of "flyswatter" status? What problems does it solve that the rest can not?

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.

Sun Suck

[sinnetworks]

Sun got their head stuck up their ass and their code isn't worth copy/pasting most of the time!

I don't know about J2EE, but their J2ME KVM implementation was such bad code that we had to rewrite some of it to get it pass its own test. Terrible C coding practices I've seen in this VM when we were writing our own code based on their standards to work in sillicon.

Me think they're ashamed that open source software like JBoss are quicker to adapt and evolved according to the needs of their users than Sun could ever be with all their corporate bullshit they spread like jelly.

GO JBOSS! Give them hell

Re:Sun Suck

[TheLink]

Disclaimer: I don't really do Java stuff (but hey this is Slashdot :) ).

But it would be funny if the one of the reasons they didn't want JBOSS to be tested was that JBOSS would fail many tests where passing would mean doing it wrong. That's not bad situation when it's the chummy old boys taking the tests, but imagine if it's the JBOSS bunch...

Maybe they've fixed things for 1.4 so that passing 1.4 tests would at least mean not doing things wrong... ;)

Seeing the complaints from ppl here that certified stuff is broken wrt the spec, what does being certified for J2EE 1.4 mean?

He will get fired to say otherwise!

[urbieta]

I bet Simon Phipps was sitting in the human resources office when stated that hehehe

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.

It'll pass

[truthsearch]

I only used JBoss, nothing from any commercial vendor. I have to agree with its quick adoption of new J2EE features. It's also got a great design. Coding for what you might call an extension, though, shouldn't be such a problem. The core itself is relatively small, and every "service" is plugged into it according to standards. So using those other "services" that are written by the JBoss team should be portable to other serves because those services can go along with it. JBoss's database services, for example, should be able to run on other platforms that conform to the standard. I code strictly to the J2EE standards and I've never found a problem with JBoss's compliance.

No joke.

[CatOne]

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.

Another quote ...

[Midnight Thunder]

Phipps also noted that JBoss appears to be using software written by Sun.

[sarcasm]Considering that JBoss is written in Java and uses the J2EE API, then is this a surprise? After all to use Java you need a JDK, which is written by Sun, as is the JDK.[/sarcasm]

I would certainly be interested to see what 'software' Phipps was refering to.

Where are the savings going?

[Dog and Pony]

Why, into step 5, of course! :)

Re:

[Anonymous Coward]

It's funny how people that whine about jobs going to India when no one raised a complaint when Blue collar jobs have been heading South and West for two decades. Before it was a result of globalization and the change to a service economy, but now that White collar workers are being affected, people open their mouthes and bitch.

Sun bluff?

[aled]

This seems a move from Sun to counter negative press, made for their previous negative to let Jboss pass the test.
Note that Sun is giving JBoss a chance before making comparisons with MS: Sun Microsystems has made an important compliance test available to JBoss Group.
What I don't understand is that because JBoss is open source, if Sun thinks some code is theirs they just have to point to it.

You are right!

[vchoy]

Quote: "...Phipps also noted that JBoss appears to be using software written by Sun."

./run.sh
.
JBoss Bootstrap Environment
.
JBOSS_HOME: C:\jboss-3.0.6\bin\\..
.
JAVA: c:\j2sdk1.4.1_01\bin\java
.
JAVA_OPTS: -Dprogram.name=run.bat
.
CLASSPATH: ;c:\j2sdk1.4.1_01\lib\tools.jar;C:\jboss-3.0.6\bin \\run.jar
.
------
.
09:01:01,453 INFO [Server] JBoss Release: JBoss-3.0.6 CVSTag=JBoss_3_0_6
09:01:01,468 INFO [Server] Home Dir: C:\jboss-3.0.6
09:01:01,468 INFO [Server] Home URL: file:/C:/jboss-3.0.6/
09:01:01,468 INFO [Server] Library URL: file:/C:/jboss-3.0.6/lib/
09:01:01,468 INFO [Server] Patch URL: null
09:01:01,468 INFO [Server] Server Name: default
09:01:01,468 INFO [Server] Server Home Dir: C:\jboss-3.0.6\server\default
09:01:01,468 INFO [Server] Server Home URL: file:/C:/jboss-3.0.6/server/default
/
09:01:01,4 68 INFO [Server] Server Data Dir: C:\jboss-3.0.6\server\default\db
09:01:01,468 INFO [Server] Server Temp Dir: C:\jboss-3.0.6\server\default\tmp
09:01:01,468 INFO [Server] Server Config URL: file:/C:/jboss-3.0.6/server/defau
lt/conf/
09:01 :01,484 INFO [Server] Server Library URL: file:/C:/jboss-3.0.6/server/defa
ult/lib/
09:01: 01,484 INFO [Server] Root Deployemnt Filename: jboss-service.xml
09:01:01,500 INFO [Server] Starting General Purpose Architecture (GPA)...
09:01:01,687 INFO [ServerInfo] Java version: 1.4.1_01,Sun Microsystems Inc.
09:01:01,687 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.

-------I admit as a user it's my fault in using "Sun's" Sdk. I will correct this mistake as soon as possible. -----

09:01:01,687 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
09:01:01,718 INFO [ServiceController] Controller MBean online
09:01:01,796 INFO [MainDeployer] Creating
09:01:01,812 INFO [MainDeployer] Created
09:01:01,812 INFO [MainDeployer] Starting
09:01:01,812 INFO [MainDeployer] Started
09:01:01,812 INFO [JARDeployer] Creating
09:01:01,828 INFO [JARDeployer] Created
09:01:01,828 INFO [JARDeployer] Starting
09:01:01,828 INFO [MainDeployer] Adding deployer: org.jboss.deployment.JARDeplo
yer@12d3205
09:01: 01,828 INFO [JARDeployer] Started
09:01:01,843 INFO [SARDeployer] Creating
09:01:01,843 INFO [SARDeployer] Created
09:01:01,843 INFO [SARDeployer] Starting
09:01:01,843 INFO [MainDeployer] Adding .....

Re:Newsflash

[wizardmax]

I dont think so, its just that MS does it so often that we are now got used to walking with a nice steaming pile of shit on our heads. Kinda sad.

Cancel My Order From Sun

[mushroom couch]

JBoss is well designed and written by hard-working open source contributors. Sun can go to hell.

Who needs a J2EE container

[Anonymous Coward]

Seriously. If you develop "enterprise" applications in Java, EJB is a terrible architecture choice. This leaves 2 other parts of J2EE: servlets and JSP which are mostly OK. There are lots of OpenSource or cheap commercial high quality containers that support JSP and Servlet specs: resin, jetty, tomcat, NewAtlanta to name a few.

So why would anybody care about this whole fight between Sun and JBoss. Sun hypes stupid EJB technology and JBoss is trying to cash on this hype. I have no sympathy for either one of them.

Re:Who needs a J2EE container

[Anonymous Coward]

Anyone wanting to run servlets and jsp need a j2ee container in the form of a servlet container.

--
jonmartin.solaas@mail.link.no

Re:Who needs a J2EE container

[Anonymous Coward]

Right, but you would'nt need a EJB container. case in point - Tomcat.

Huh?

[Anonymous Coward]

I've been programming Java since it came out and hate MS business practices, but I don't remember once where MS had this kind of attitude towards developers.

Re:Huh?

[wizardmax]

Ok, you win, I cant think of anything right now... I have a fiew case where they screw the users, but not developers... Lets hope its not going to stay like this.

They'll Fail

[pjdoland]

Don't you think Sun's already tested JBoss? Why would they make statements like that and then end up with egg on their faces?

Re:They'll Fail

[chamont]

That's funny you're right. Is it premature to laugh at the JBoss dudes already?

Monty

More OSS ignorance

[irritating environme]

Ignorant (intentionally so...) from the corporate types.

OSS may not pass everything the first time, but telling it what it doesn't pass just hastens its compliance, and it will inexorably march toward it.

OSS development is like the gentle ocean and the sandcastle: it takes a while, but the sandcastle will fall, and once the tide turns, it doesn't matter how many people are rebuilding the castle.

Re:More OSS ignorance

[Anonymous Coward]

I give JBOSS about as much chance of passing a Sun test as those OSS .net guys.

Remeber both MS AND Sun have the power over their own ever shifting "standards" and "version compliance." Still it doesn't mean that their efforts will be fruitless. Both implementations may eventually keep the vendors in check and foster innovation. I am not betting on it mind you but it is possible.

uh yeah

[Anonymous Coward]

does this new report make any sense to non computer literate?

all I got was...

JBoss = give em hell
SUN = see you in hell

Bear in mind...

[Anonymous Coward]

That JBoss has been openly critical of Sun's numerous failures to produce ANYTHING of quality surrounding Java / J2EE (and justifiably so), so there is little to no motivation for Sun to play nice with JBoss, even tho they are shooting themselves in the foot by smearing the most successful open source J2EE app server implementation ever.

I may not agree with everything the JBoss team says and does (some of the discussions can be permanently damaging to small children and the elderly), but at least the thing works. Compare that to the steaming pile of crap that IBM puts out as an application server and I am damn glad there is an alternative (Weblogic is ok, but expensive).

sun speak

[kungfoobar]

sun speak: I predict that now that we're calling their bluff, they will make up another excuse for not doing the tests, Philips says.

Translation: 'We may have *modified* the tests a little so you guys can't pass. Best of luck!'

sun speak:JBoss appears to be using software written by Sun.

Translation: 'We at Sun never use other people's codebase for our products (apache regex), it's wrong that JBoss does.'

sun speak: making the compliance test available will make it clear that Sun does not want to intentionally obstruct JBoss Group's efforts to gain J2EE compliance

Translation: 'We pray every night to the same God Microsoft does that JBoss burns itself to the ground. Linux should die to.'

Re:sun speak

[aled]

But regex is licensed by apache license that allow use and Sun code may be protected by some Sun licenses that don't.
What would be interesting is what code they are talking about.

jThe jproblem jwith jthis jarticle...

[Anonymous Coward]

jIs jthat jit jdoesn't jstart jevery jword jwith j. jBecause jmakes jeverything jbetter.

jI jtraded jmy jMcJob jfor ja jjob.

Comparision matrix

[dagooncrn]

Here nice, with prices starting at $25k/cpu for *certified* containers :)

It might Fail

[Fujisawa Sensei]

There are reasons why JBOSS might fail the compliance test. However these reasons are beacuse the spec is idotic, such as unnecessary ro even crippeling of synchronization in certain functions. So failing might be a good thing in some areas.

old fashioned "hello world"-defence

[riqnevala]

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

....sorry about stealing someone's code..

How much code does it take to be identified as "stolen"?

Copying SUN's code comment

[Anonymous Coward]

I have to ask - where the heck did you come up with
this? I read the article and it never once mentions
accusing them of copying sun's code.

** SLACKWARE 9.0 IS RELEASED ***

[n0dez]

ftp://ftp.kpn.be/pub/linux/slackware/slackware-9.0 -iso/

Re:** SLACKWARE 9.0 IS RELEASED ***

[n0dez]

I just wanted to tell everyone the good news about Slackware (Slack9). Sorry, I knew that it was offtopic.

n0dez

Re:So? Microsoft Windows 2000 complies with CC EAL

[kungfoobar]

Number of Windows related viruses over the years...
Too many to count

Cost due to Windows server based attacks on a global scale...
gazillions

Number of Linux viruses released to the masses...
1 maybe 2

The cost due to a Linux virus on a global scale...
0 USD.

The price for a Linux admin's good night's rest because he/she doesn't have to worry about security attacks? Priceless...


For everything else, there's a CC EAL4 cert, symantic or norton.

Re:

[Anonymous Coward]

What country are you from (or when were you born)? There was all kinds of "bitching" when the blue collar jobs left the United States.
Difference between now and then though is that the blue collar people could at least retrain to white collar. If the white collar goes away, what exactly is left?
War industry and aerospace (almost the same thing really) will be my guess for our future.

More too it than just passing tests

[Anonymous Coward]

As has been posted, being spec compliant is only half the game. The other half is the config file madness that app servers seem to relish. It's too bad that decent doco isn't part of the spec...

Sun is afraid of JBOSS; So is BEA

[cfury]

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.

Re:Sun is afraid of JBOSS; So is BEA

[cfury]

er, that should be

(unless a large *enterprise* needed to support a smallish to medium sized app...)

heh. preview. It's kind of neat. :)

Re:Sun is afraid of JBOSS; So is BEA

[sheldon]

I'm a little bit confused by this frustration with introducing Tomcat, because it was my understanding that one of the primary motivators for using Java is it's platform independence. Since your company already uses BEA, and therefore assumably has support licenses in place for this... why would you feel the need to add Tomcat into your environment in addition?

It's far easier for a corporate IT shop to support one style of technology rather than say 3 or 4.

Although admittedly we're running into that problem here. We buy third party products and companies and thus far I know we have JBoss, Oracle and BEA running in various places. I had a similar conversation several weeks ago with a developer who is convinced he wants to bring Tomcat into our environment. I can't understand why since we already have these other options, and besides our Oracle contract is an enterprise licensing deal so it'd be no extra cost to his team.

Sometimes I really don't understand developers. Are you trying to make the best technical decision, or are you just motivated by familiarity or ideology?

Re:Sun is afraid of JBOSS; So is BEA

[Anonymous Coward]

>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.

Man, what would you do? Here is a whole company
working hard to get this product out (yes, and they really, really want to get a sallary)
- and on the other hand there is this free JBoss product.

There is a word for it, its called dumping.
Dumping is often regarded as anti competitive behavior - you want to destroy the competition ? - destroy it by selling a competing product for a lower price.

Can OSS be used as a way of legal Dumping?

Conspiracy theory: maybe JBOSS is IBM's revenge against BEA; I mean JBOSS isn't a threat to WEBSPHERE (because of W is adding advanced enterprise features, compare AIX and LINUX), but JBOSS can be used to dump BEA.

JBoss architecture vs Sun code

[Roullian]

Jboss is based on a revolutionary architecture, using extensively AOP. 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: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 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 which may be harder to use, but can offer a lot more.

Re:JBoss architecture vs Sun code

[Roullian]

Oh, I completly agree with you catch23. Their use of dynamic-proxy is not real AOP (like with AspectJ), in the sense they don't really use Aspects.
Anyway, my point was that their design was completely different from Sun's : I was wondering what they could have copied from Sun, as JBoss was accused of copy/pasting code from Sun. I mean, even if they don't do bona fide AOP, they still do things completly differently from Sun.

You raise some really interesting points. I don't agree concerning the performance problems : my JBoss servers are running blazingly fast (BTW, I use BEA's JRockit JVM, on Linux). In practice, I always had excellent performance with JBoss. Besides, it's extremely easy to make a cluster/farm of JBoss servers, and I rely on that in case of scalability issues.
I've heard of BCEL yet, but not of Javassist - thanx for the link, I'll have a look at it.

Julien Dubois.

Re:JBoss architecture vs Sun code

[catch23]

You may even want to consider another completely opensource J2EE app server called Jonas. Unlike JBoss, they don't use dynamic proxies, instead they do some pre-compilation techniques so they don't have to do dynamic proxies. Take a glance at the JBoss/Jonas comparison here:

http://www.cs.rice.edu/CS/Systems/DynaServer/perf_ scalability_ejb.pdf

It shows Jonas-Jeremie getting a significant improvement over JBoss-RMI even under jdk 1.4! In the past there have been major flamewars over the JBoss and Jonas crowds, but they all have their own good reasons. So if you really wanted flaming speed, check out Jonas. They've even completely re-written their own JMS/RMI implementation called Jonathan.

Re:JBoss architecture vs Sun code

[Roullian]

Yes I know about Jonas - I'm French, and I've been to several ObjectWeb events.

I was not a big fan of Jonas until version 3.0 :

• It lacked EJB 2.0 support
• It is sponsored by Bull and France Telecom, two companies I greatly dislike.
• I was to one of their conferences once, at Sup Telecom Paris, and I really thought the speaker was lame

However, I've heard some very good things about Jonas' latest version, and I will probably give it a try. I saw a demo at LinuxWorld Paris, and they seem to have good clustering/farming support, just like JBoss, and this is today my #1 priority.

Julien Dubois.

Open Source Question

[SerpentMage]

Here is why JBoss is neat, but a bit misguided (hence why I like Apache Jakarat more).

Ok lets consider the argument. You have compliance testing so that you can write an app to the spec and have it work on different containers. Ok, sounds good. Why do you want to use different containers? because different containers have different implementations and strenghts. Ok, sounds fair...

BUT, with Open Source you have the sources and you can do what you want with them. This is why there are X number of attachments to Apache HTTPD server and Jakarta Tomcat. In other words api compliance is not the issue in Open Source since you do not need to be compliant to other implementations (hence the success of the Apache projects)

So now please answer why JBoss needs to be compliant other than allowing legacy to run?

Re:Open Source Question

[Wavicle]

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.

Re:Open Source Question

[hconnellan]

The problem is that many people allready use JBOSS. Probably more than use WebSphere and BEA combined.

I agree that you should try to conform to standards but if the stardards authority deliberatly tries to shut you out then there isn't much you can do.

The same thing happened between UNIX/Linux and X/XFree. Linux and XFree are now becomming the defacto standards. Sun is scared that the same thing will happen with JBOSS.

Re:Open Source Question

[#!/bin/allen]

The greatest reason is that it is far simpler to code to the specification than to code to your own idea of what the specification should be and then go back and code the specification too.

<preaching>
Do you remember 10 statement ForTran? They found the largest set of ForTran statements that would compile with any compiler. Or Basic, where there were long instructions in most general Basic books that outlined the translations you would have to go through to run its programs on various different interpreters. There was always a section that said "and for the XXX and YYY systems, the code in this book should be used as guidelines more than as a direct example." You were on your own getting the programs to run.

We do have some of these problems today, but it is recognized that they create artificial inefficiencies. You need to have a GOOD reason to do this.
</preaching>

Re:Open Source Question

[makapuf]

exactly, see my l33t Outlook SNMP server replacement :

#include <stdio.h>

Here it is. Since you have the code, you can make it compliant with SNMP, SMTP, HTTP and mpeg-4 ? thanks

Re:Open Source Question

[SerpentMage]

Wait, there are standards and then there are standards. The standards I am referring to are API's not protocols. The fact that the Apache HTTPD is compliant to the HTTP spec is because that is the primary function of the HTTP server.

HOWEVER, beyond that it does not need to compliant to the spec and does what it wants to.

Now about Tomcat being a reference implementation of a servlet container, that is not entirely true. YES it is compliant to the servlet spec, but a developer can use many interesting tomcat features to get more out of their servlet. Many people would say oh, but do not do that since you will make your servlet work only with Tomcat. My answer is, SO WHAT! Tomcat is open source and it works who cares if I use Tomcat specifics....

Re:Open Source Question

[SerpentMage]

Well I am not saying write bad code. What I am saying is that why should JBoss adhere that tightly to the J2EE spec. Use the parts of J2EE that make sense and then do what you think is right.

Re:Open Source Question

[SerpentMage]

One more thing I forgot. About your gcc example. You know that this happens all the time in Open Source.

Think of the following: Python, Perl, Ruby, Velocity, Cocoon, Apache Jakarta projects etc. All of these languages / projects do as they please and implement what they think is necessary. They do not attempt to find a standard since it is NOT necessary. They code and adapt as they need to.

another article that discusses the issue

[marhar]

There's another informative article here

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.
  

having used both jboss and Sun One

[f00zbll]

JBoss beats Sun One hands down every day of the week and twice on Sundays. Anyone that has done serious java development for transactional applications know the value of an EJB container. It's just too bad many stupid CTO's think they need transactional when they really don't. The end result is EJB's get a bad rap for bad technical decisions by non-technical idiots.

That and Sun pushing EJB's for everything when they are designed for serious transactional applications. For non-transactional applications, 75% of the time you're better off cooking your own simple caching/pooling mechanism.

Tempest in a Teapot

[JohnnyCannuk]

Read this and try forming opinions other than "Sun sucks" or "Go JBoss, you rock".

I love JBoss. I use it daily. I even contributed some patches to it back in the 2.4.4 days. I like
Sun stuff. I use it daily. The company I work for is a Sun iForce Partner (we're also and MS partner, in case you think I'm realy biased). I look at this issue, and read the above article (which I was pointed to on the JBoss forums, ironically) and I see two sets of people acting incredibly childish. I won't say the two companies or organizations, because I know there are people on both sides of this issue that don't share these opinions. So Sun won't certify JBoss? Big woop. I'll still use it. So will most of the developers I work with. And we'll still use it for dev and then port to BEA or OC4J because it's easy to do (Websphere bites and is incredibly hard to port to...yet certified!). If JBoss "goes beyoind J2EE" and doesn't support the standard anymore (J2EE 1.4 in the future, it complies to 1.3 as far as I can see), I will stop using it.

Period. End of story. I'll use OC4J...not open source but free for development and certified. It's also easy to use.

I don't give a rat's ass about AOP, or even JMX or micro-kernel crap. I care about writing EJB's (Session not entity...we've discovered Apache OJB),JSP's and servlets to the J2EE standard that are easily moved from one app server to another. I care about using the latest features of the spec. As soon as I can't do that, I'll stop using that server. If JBoss goes to far beyond J2EE they will lose. If they don't like the current spec, maybe they should get involved with the JCP to affect some change, like Apache.

As for Sun folks thumbing their nose at JBoss, perhaps they should remember that without JBoss, there would be hundreds of thousands less J2EE developers out there and likely .Not would be much more prevelant. They should also thank JBoss for technical innovations like drag and drop deploy of .ear's and hot deploy (is anyone at IBM reading this?), which has been picked up BEA and Oracle to varying degrees because of the competition.

Given that, and the exchange in the above article, maybe I'll switch to Jonas or OpenEJB (or another Open Source server if it exists).

This whole thing is ridiculous. Stop whining and start working to beat out .Net

Re:Tempest in a Teapot

[Dodger_]

Hey Johnny, would you be willing to answer a few questions about Java development? Send me an email at dodger@thewretched.org if you are.

Shows SUNs sincerity to OpenSource

[Anonymous Coward]

All they want is an 'under control' J2EE that is Tomcat, and everyone else making money. Doesnt matter Jboss outperforms Websphere. They dont realize Jboss's success as J2EE will proliferate Java as a language as well as an alternative to .NET. There are MANY small companies looking for open source material to run everything, their use of J2EE technology will help J2EE much more than its use by Fortune 100 companies.

Sun is two faced.....

[Anonymous Coward]

Towards open source. When it helps them against MS they love it, when it can hurt them a la JBoss they seem to be evil. Sun wants to be a software company and sell their POS Sun ONE app server, which is why they are trying to FUD JBoss. Remember, they speak of J2EE 1.4 which is not even final, so there is not test to pass. I am not aware of too many tests that can be passed before they are written.....

Arguments such this one...

[ubiquitin]

...just give me more reasons to like PHP.

Re:They'll Fail but that's OK

[Anonymous Coward]

It is normal that something will fail.

However what they'll find will probably be minor flaws that can be corrected quickly.

Does this not sound like SCO?

[ishmalius]

The Open Source community could not possibly be smart enough to do this on their own. They MUST have stolen the knowledge from US !

sdfsdf

[Anonymous Coward]

sdfsdf

Re:Evangelist? More irony?

[Anonymous Coward]

If he's not reflecting Sun's official position, he needs to be smacked down.

Go read the Cluetrain Manifesto.

Human effort as commodity

[lenski]

I am surprised it took so long. Eventually, the worldwide marketplace for intelligent human effort such as engineering, must take effect, just as it has for manufacturing.

We have *always* been a commodity. It's only recently that USians and other participants in Western-style societies have been faced with the reality of competing with the real world.

As it was with the whole crypto discussion some years ago, so it is with being intelligent: Ths US and other industrialized societies have no monopoly on intelligence. Lots of people are smart, and they are beginning to compete in the world marketplace for such services.

JBoss HAS to be certified!!!!!

[wrfink]

To understand this, you need to understand who makes the decisions to use JBoss.

Is it the Java expert? No.

Is it the Database Expert. No

Is it the Security expert? No.

Is it the Netowrk expert? No.

Is it the monkey-ass MBA? Damn strait!

If a F500/1000 company is going to use JBoss and hire the JBoss consultants, it will be at the recomendation of some MBA. It will be hard enought to get it in there since JBoss is not out taking them to Hockey games or buying rounds of golf. It has NOTHING, NOTHING, to do with the technical merrits of the software. This, my fellow techies, is why Open Source is having a difficult time.

Well, three reasons...

No marketing

No "Tech support"

nobody to sue if things go wrong.

Re:JBoss HAS to be certified!!!!!

[Anonymous Coward]

This guy is 100% correct.

Re:JBoss HAS to be certified!!!!!

[Anonymous Coward]

yes he is, but everyone has known that for a long time.

JBoss would upset the apple cart

[rkischuk]

I can't speak for Sun's true motivation here - that would be speculation. What I am fairly certain of is that the high per-CPU licensing cost of most J2EE application servers, the pricing model encourages companies to buy the biggest iron they can to avoid buying more licenses as well. Coincidentally, Sun happens to sell big iron servers.

So what happens if JBoss gains credibility through licensing? Well, the cost model gets turned on its head. If the incremental software cost is now $0 instead of $10k for each additional CPU/Server, you can now consider multi-CPU Wintel boxes, or even clusters of low-end commodity server hardware.

Suppose you go "cheap" with a Sun 280R, list price $13k, with BEA Weblogic, ~$10k = $23k for the solution.

Now, suppose it takes only 2 $3k Dell servers to attain equivalent performance - total cost is $26k by the time you add 2 CPU licenses. It's both cheaper and simpler to go with one server.

Turn it around now, for the JBoss case:

Sun Fire 280R = $13k total cost

And suppose that it now takes *4* of those $3k Dell servers to attain equivalent performance. Your total cost, $12k, is still $1k cheaper. For what you were paying before, you could have 7 of these servers, and spare change to boot.

It seems to me that Java isn't a huge money makes (nor a huge money loser) for Sun, it is merely a means to the end of driving Sun hardware sales. Change the J2EE cost model, and the plan is toast.

"high touch" or "soft touch"?

[Anonymous Coward]

If you learn J2EE by developing and testing on JBoss, then deployment won't be any harder. Its the code monkeys who need the point and click deployment. An experienced sysadmin will be sshing into the servers and using vi to tweak config xmls, and eventually have a bunch of perl script mangling the xml with regexps.

So if that were the case WebLogic would need to be positioned at the front lines more than in the server room. But really, it's all about selling, and every manager is a soft touch when it comes to high prices and shiny brochures.

EJB = Enterprise Java Bullshit

[Anonymous Coward]

There is no reason to use EJB, unless your server talks to other EJB servers. Most applications talk to a database, a mail server, etc and there is no place for EJBs for that.

JDO/Castor are much better solutions for most databse applications. EJB proponents tell you that the EJB servers take care of resource, pooling/managemnet, big deal... making resource pool/resource management is what 3rd graders do for computer science. Why these EJB "architects" thinks such simple stuff is so hard to do is beyond me.

Now the EJB proponenent's savior tool is EJBDoclet and XDoclet these days... Use of XDoclet type of tools for writing code is just plain stupid. In trying to keep Java language "pure" you are now forced to write code in comments, what stupidity? I for one, am glad about the stock market crash, because at least now engineers will make the decisions and not the "architects" who have done nothing but bull shitted their way to the top and failed companies.

Be gone EJBs for ever.

Re:EJB = Enterprise Java Bullshit

[Anonymous Coward]

This is the best Slashdot comment I've read in a long time. I have deployed many high volume servers over the years and have never understood why anyone in their right mind would use the ridiculously overly-complicated EJB model to do anything. Funny, I don't remember EJBs being taught as part of computer theory in university. Why do people use EJBs? Because they don't know any better.

Go Open Source

[Anonymous Coward]

and lay off the engineers. Good job Open Source. What have you gained, except cutting your own grave?

Re:Tempest in a Teapot - summary

[Anonymous Coward]

First you squack "If JBoss goes to far beyond J2EE they will lose" and then you backtrack with "They should also thank JBoss for technical innovations like drag and drop deploy of .ear's and hot deploy".
So which is it? Innovate, but not too much.
You have no point at all.

compliance tester

[umeboshi]

It might be more worthwhile to start a compliance testing project. This would help ensure that the testing apparatus actually performed accurate compliance testing. Given enough time and developement, Sun's cert may become virtually meaningless

Re:Slackware 9 is released!!!

[n0dez]

Sorry about my post. I sent an article about it to Slashdot (among others like LinuxToday) and none of them published it. :(

n0dez