Sun 'Calls JBoss bluff' on J2EE compliance 218
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."
Go get em JBoss! (Score:5, Insightful)
Cruise Missle into Microsoft?? (Score:3, Interesting)
Re:Cruise Missle into Microsoft?? (Score:5, Insightful)
Re:Cruise Missle into Microsoft?? (Score:5, Interesting)
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.
Re:Cruise Missle into Microsoft?? (Score:2, Insightful)
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?? (Score:2, Insightful)
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?? (Score:5, Insightful)
Bringing up Mono supports his point.
Re:Cruise Missle into Microsoft?? (Score:2)
Re:Cruise Missle into Microsoft?? (Score:2)
Re:Cruise Missle into Microsoft?? (Score:5, Funny)
Yes, but only in one ear.
Re:Go get em JBoss! (Score:2, Informative)
Re:Go get em JBoss! (Score:4, Insightful)
How does that help Sun? (Score:5, Insightful)
Re:How does that help Sun? (Score:2, Interesting)
Re:Go get em JBoss! (Score:2, Interesting)
Re:Go get em JBoss! (Score:3, Insightful)
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
Re:Go get em JBoss! (Score:5, Insightful)
Where are the savings going? (Score:2, Funny)
Human effort as commodity (Score:2, Insightful)
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 i
Sun's code (Score:5, Funny)
Meaning, that Sun's code won't pass the tests either?
No joke. (Score:5, Interesting)
Compliant or not? (Score:5, Insightful)
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? (Score:5, Interesting)
Re:Compliant or not? (Score:5, Informative)
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.
Open Source Question (Score:4, Interesting)
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 (Score:5, Insightful)
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 (Score:2, Interesting)
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 (Score:2)
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 to
Re:Open Source Question (Score:2)
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.
Re:Open Source Question (Score:2)
Re:Compliant or not? (Score:2)
Perhaps they are referring to the removal of vendor-specific code?
Re:Compliant or not? (Score:5, Interesting)
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? (Score:2)
Config files, etc... (Score:5, Informative)
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... (Score:2)
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... (Score:3, Informative)
[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 revise
Re:Compliant or not? (Score:5, Insightful)
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? (Score:2, Insightful)
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? (Score:2, Troll)
A J2EE application is a mix of 3 things:
- Java source code
- J2EE XML descriptors
- 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? (Score:3, Insightful)
J2EE is just a spec. The devil's in the details...
Re:Compliant or not? (Score:2)
It'll pass, no problem (Score:5, Insightful)
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.
No shit...it's free (Score:1, Funny)
No shit...it's free
Re:It'll pass, no problem (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:2)
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.
It'll pass (Score:2)
Re:It'll pass, no problem (Score:2)
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 (Score:2, Funny)
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 i
Good news! (Score:5, Insightful)
Perhaps Sun finally felt some heat from the tech community? (pun intended)
Re:Good news! (Score:3, Insightful)
Re:Good news! (Score:2)
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.
Sounds like a setup to me (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:4, Interesting)
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 (Score:5, Interesting)
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 (Score:2, Insightful)
>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
Finally! (Score:5, Interesting)
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! (Score:2)
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" (Score:4, Funny)
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" (Score:5, Funny)
Unlike "stratjakt", which just rolls off the tongue.
Sun/Phipps needs to show more class (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:2, Informative)
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 JBos
Re:Sun/Phipps needs to show more class (Score:3, Insightful)
"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 compl
Re:Sun/Phipps needs to show more class (Score:5, Funny)
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?
Copied Code?!? (Score:5, Insightful)
Re:Copied Code?!? (Score:5, Insightful)
old fashioned "hello world"-defence (Score:2, Insightful)
System.out.println("Hello world");
}
How much code does it take to be identified as "stolen"?
Re:Copied Code?!? (Score:4, Informative)
Shouldn't Sun (Score:4, Funny)
Re:Shouldn't Sun (Score:4, Funny)
Hold on one second... (Score:5, Informative)
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 (Score:5, Insightful)
JBoss failure means $$$ (Score:3, Interesting)
Evangelist? More irony? (Score:5, Insightful)
Re:Evangelist? More irony? (Score:4, Informative)
JBoss and others (Score:5, Informative)
Another quote ... (Score:2)
[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.
You are right! (Score:5, Funny)
.
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:
.
------
.
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,
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:0
ult/lib/
09:01
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
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
More OSS ignorance (Score:2, Insightful)
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.
sun speak (Score:4, Funny)
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.'
jThe jproblem jwith jthis jarticle... (Score:3, Funny)
jIs jthat jit jdoesn't jstart jevery jword jwith j. jBecause jmakes jeverything jbetter.
jI jtraded jmy jMcJob jfor ja jjob.
It might Fail (Score:2, Insightful)
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.
Sun is afraid of JBOSS; So is BEA (Score:5, Interesting)
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 (Score:2)
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 prob
JBoss architecture vs Sun code (Score:4, Informative)
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 (Score:5, Informative)
Re:JBoss architecture vs Sun code (Score:2)
http://www.cs.rice.edu/CS/Systems/DynaServer/perf _ scalability_ejb.pdf [rice.edu]
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 Jona
another article that discusses the issue (Score:3, Informative)
Highlights:
having used both jboss and Sun One (Score:2, Insightful)
That and Sun pushing EJB's for everything when they are designed for serious transactional applications. For non-transactional applications, 75
Tempest in a Teapot (Score:5, Insightful)
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
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
Shows SUNs sincerity to OpenSource (Score:2, Insightful)
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
Sun is two faced..... (Score:2, Insightful)
JBoss HAS to be certified!!!!! (Score:3, Insightful)
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.
JBoss would upset the apple cart (Score:4, Insightful)
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.
EJB = Enterprise Java Bullshit (Score:2, Insightful)
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
Re:They'll Fail (Score:2)
Monty
Re:Sun Suck (Score:2)
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 stuf