Simon Brown has brought up the fact that although it is early days, there are six J2EE 1.4 implementations, compared to 21 of J2EE 1.3. Are these implementations coming? Or is the consolidation and commoditization of the platform to blame?

It's still relatively early days for J2EE 1.4 in the real world, but compare the number of J2EE 1.4 implementations (6) with the number of J2EE 1.3 implementations (21). I remember that prior to the final J2EE 1.3 release, vendors seemed to be falling over themselves to get their implementations out but this doesn't seem to be happening anymore. Most J2EE app servers have some ability to support web services (the key addition for J2EE 1.4) so I'd be surprised if the lack of implementations is due to the complexity involved. Even JSP 2.0 and Servlet 2.4 containers were fairly thin on the ground until recently. What do you think?

Read Simon in: Where are all the J2EE 1.4 implementations?

http://jonas.objectweb.org/

The site claims that it is J2EE 1.4 compliant. I haven't used it so I can't verify this.

However, just because Sun doesn't list a product as 1.4 compliant doesn't mean that it isn't. It just means that not all free software is able financially or in terms of the restrictions that Sun imposes to pass the certification.

- Erwin

However, just because Sun doesn't list a product as 1.4 compliant doesn't mean that it isn't. It just means that not all free software is able financially or in terms of the restrictions that Sun imposes to pass the certification.- Erwin

Simon only listed the J2EE 1.4 certified appservs. JOnAS is currently in the process of being certified (see: http://www.objectweb.org/phorum/read.php?f=25&i=62&t=62).

That's right, certification is something huge, especially for a not-for-profit project like JOnAS. However, JOnAS was the first application server to be awarded a scholarship by the JCP to undergo certification of compliance with J2EE 1.4 (see: http://www.objectweb.org/phorum/read.php?f=25&i=54&t=54). The JCP granted this scholarship because of the not for profit nature of the project. AFAIK, the JOnAS team is doing a great job on the certification.

When JOnAS is certified, Simon may also have to add products from other vendors (such as Red Hat or MandrakeSoft distros, and very likely other vendors too) to his list.

This is what's great with true open-source projects such as ObjectWeb's: several vendors can develop different offers (in terms of software and/or professional services) based on these projects. This is for the benefit of all: the vendors, and also the users who have more choice!

Simon only listed the J2EE 1.4 certified appservs. JOnAS is currently in the process of being certified

That was my point, you don't have to have be certified to be a good product. So my opinion is that you should count all application servers the implement J2EE 1.4, not just the ones that are certified by Sun. In most circumstances, being certified is much less relevant than being a good product.

Simon only listed the J2EE 1.4 certified appservs. JOnAS is currently in the process of being certified

That was my point, you don't have to have be certified to be a good product. So my opinion is that you should count all application servers the implement J2EE 1.4, not just the ones that are certified by Sun. In most circumstances, being certified is much less relevant than being a good product.

Well, both are important, but they are important for different "populations". For sure, being a good product doesn't hurt -- and thanks for mentioning JOnAS. Actually, we consistently get feedback from people who adopt JOnAS, often while migrating from other J2EE appservs, including open-source, and they are generally very impressed by the quality of the software (not to mention the friendliness of the team). JOnAS is in production at "Forbes 2000" enterprises and certification was not the only criterion of choice.

Nevertheless, certification is a way to ensure that the software is absolutely compliant with a standard, and this may seem very important to some enterprises: I mean, to their IT departments.

However, just because Sun doesn't list a product as 1.4 compliant doesn't mean that it isn't. It just means that not all free software is able financially or in terms of the restrictions that Sun imposes to pass the certification.- Erwin

Uh, that's the exact case for J2EE 1.3 as well, isn't it?

However, just because Sun doesn't list a product as 1.4 compliant doesn't mean that it isn't. It just means that not all free software is able financially or in terms of the restrictions that Sun imposes to pass the certification.- Erwin

Uh, that's the exact case for J2EE 1.3 as well, isn't it?

Well, with J2EE 1.4, Sun/JCP made the test of compatibility kit available to nonprofits (eg ObjectWeb -- the case of JBoss, being for profit, is different) open-source projects. The Apache folks where instrumental in this evolution (thanks to them).

This is why JOnAS is on the way to certification. AFAIK, JOnAS 3.x was never planned to undergo certification -- and cost probably was a top issue.

Well, with J2EE 1.4, Sun/JCP made the test of compatibility kit available to nonprofits (eg ObjectWeb -- the case of JBoss, being for profit, is different) open-source projects. The Apache folks where instrumental in this evolution (thanks to them).

Exellent. But if the certification is more available, one should expect more certifications?

Excellent. But if the certification is more available, one should expect more certifications?

No. It is more available, but :
- You need to provide a compatible product (which is a very big bunch of software), then pass the Sun TCK (which is a lot of work).
- "More available" means available to open-source products, and to non-profit organizations. Not many of them are able to build up a compliant J2EE server: by now, only ObjectWeb, Apache and JBoss (for-profit, but open-source) were credible candidates.

Anyway, this is a very important step for the whole OSS world: a kind of "official" recognition that OSS organizations can be just as good as the biggest software companies in such important things as infrastructure software.

>Exellent. But if the certification is more available, one should expect more certifications?

The effort to certify is tremendous. Took us 6 months with 3 fulltime people, and a few others part time to pass the some-odd 24000 tests. As an organization, for-profit or non-profit, you have to commit to it or it is just impossible to complete.

Bill

The effort to certify is tremendous. Took us 6 months with 3 fulltime people, and a few others part time to pass the some-odd 24000 tests.

Yep, right. And Bill is here only talking of the effort to actually pass the tests, ie hook up the appserv to the TCK, run the tests, fix the bugs.

And here I'd like to rebound on a remark from Erwin:

That was my point, you don't have to have be certified to be a good product.

For the contributors (who, in open-source, often times are also users), having a good product sometimes is more important than being certified.

The code of an open-source project like JOnAS relies on many components, some from ObjectWeb, some from other communities, that all may live their own life, because contributors make improvements, refactoring, bug fixes, etc to these projects.

In an open-source world, you cannot just stop the, tell everybody to take a one year break and quit contributing because you're working on certification, and go back to the open-source way once certification is completed!

So, indeed, certification of a nonprofit, open-source project is a tricky endeavour :)

J2EE 1.3 was compelling because of the JMS integration and the CMP 2.0 standard.

J2EE 1.5 will be important because it will likely represent Sun's last, best, attempt to simplify the programming model.

But there's nothing really exciting about J2EE 1.4. The centerpiece of the spec is an overly complex, cumbersome Web Services integration piece. So far, I have been able to address my SOA needs (including .NET integration) using the simpler Axis product, and given a choice I will always use that instead of the bloated progeny of Web Services Developer's Pack.

BEA was one of the first to market with a J2EE 1.3 implementation, and they seem to be silent here. Maybe it's because all their employees are working at Google now, or maybe customer demand is so weak that they plan to leapfrog to J2EE 1.5.

IBM does not have a J2EE 1.4 implementation that is suitable for production use, and the JBoss product is barely a month old.

Possibly most vendors are beginning to question whether they should pay Sun six to seven figure licensing fees to support a spec that provides only incremental added value.

IBM does not have a J2EE 1.4 implementation that is suitable for production use

True at present, however WebSphere 6.0 was announced last month for planned availability before the end of this year. You can expect the WAS 6.0 Technology for Developers listing on the Sun compatibility site to be updated to WAS 6.0 about the same time.

Randy Schnier (IBM)

BEA v 9 is expected before the end of the year and will support 1.4 as will WebSphere 6 (also expected before the end of the year).

Macromedia is interesting though. The last public statement was over a year ago
http://www.macromedia.com/macromedia/proom/pr/2003/jrun_nec.html

I guess they'll do the work at some point but I wouldn't hold your breath

Of course one of the advantages of having a standard like J2EE is being able to move from one vendor to another. If 1.4 support is important to you I'd start planning to move sooner rather than later (and be sure to let Macromedia know!)

Of course one of the advantages of having a standard like J2EE is being able to move from one vendor to another.

Does anyone belive above?

I personaly can take a Tomcat 5 War and run it on Resin 3 fine but other than that I beleive it to be PITA.

.V

Admittedly its only JSP/Servlets and classes but I've deployed one app of mine on Tomcat on Windows, WebSphere on AIX and Web Logic on Solaris in the last year with only minor hastle.

IBM does not have a J2EE 1.4 implementation that is suitable for production use

True at present, however WebSphere 6.0 was announced last month for planned availability before the end of this year. You can expect the WAS 6.0 Technology for Developers listing on the Sun compatibility site to be updated to WAS 6.0 about the same time.Randy Schnier (IBM)

Please provide additional information about this. Why isn't the IBM JDK 1.4 from WAS 5.1 suitable for production use?!?

Please provide additional information about this. Why isn't the IBM JDK 1.4 from WAS 5.1 suitable for production use?!?

IBM JDK 1.4 == J2SE 1.4

IBM WebSphere 6 == J2EE 1.4 (not yet ready for production use)

IBM does not have a J2EE 1.4 implementation that is suitable for production use

True at present, however WebSphere 6.0 was announced last month for planned availability before the end of this year. You can expect the WAS 6.0 Technology for Developers listing on the Sun compatibility site to be updated to WAS 6.0 about the same time.Randy Schnier (IBM)

Please provide additional information about this. Why isn't the IBM JDK 1.4 from WAS 5.1 suitable for production use?!?

Please provide additional information about this. Why isn't the IBM JDK 1.4 from WAS 5.1 suitable for production use?!?

Ted, please scroll up and read the earlier response to your question.

No one is talking about IBM JDK 1.4.

J2EE 1.4 has nothing to do with JDK 1.4.

IBM JDK 1.4 is not at all related to this discussion.

No one said not to use IBM JDK 1.4.

No one said anything about IBM JDK 1.4.

Peace.

I agree!

It is harder for us to put for a budget to upgrade from (our significant investment in) 1.3 to 1.4. IMO, J2EE 1.4 should be good for those green field poject implementation.

However, at this stage, I would rather wait and think for compelling reasons to put forward when 1.5 is ready.

------------------------
my daily judgement - "good product" vs "benefits" vs "financial reposonsibilty".

Does anybody know if Macromedia is planning to upgrade the JRun application server?

http://www.macromedia.com/cfusion/webforums/forum/messageview.cfm?catid=69&threadid=886844

http://www.macromedia.com/cfusion/webforums/forum/messageview.cfm?catid=69&threadid=796299

J2EE 1.3 hit the tail end of the .com boom. These were the days when J2EE was the only solution to everything outside of MS, no matter what your problem was J2EE solved it.

It is now generally accepted that J2EE is definitely not the solution to everything and far from the best solution to a large number of problems. It has a major role in the app server space but the over use of J2EE has been the seed to lighter weight APIs, frameworks and architecture like Struts, Spring, JavaSpaces, Hibernate and JDO. [Yes these do overlap with J2EE I know, please read on]

If anything we will see a stronger uptake on these frameworks than J2EE 1.4. J2EE is now playing catch-up, what compelling reason do we have to use an app server at about $8k/CPU over something running on Tomcat using Spring/Struts etc. and Hibernate? JBoss and Geronimo are good options but we don't need the full stack, EJBs are not popular and even forbidden in some banks, if you're going to use JBoss without EJBs then you've not got much more than Tomcat with a few nice but complex options.

I can see a far better future with best-of-breed frameworks, Spring, Struts etc. distributed services with the likes of RIO and JavaSpaces, caching with products like Tangosol, messaging of course with JMS or perhaps this?, integration with C24 IO, finally persistence through Hibernate or JDO.

-John-

What about the active* products from codehaus (like your own activespaces)?

Totally agree, Codehaus is a major player for the future. I sort of included ActiveMQ in mentioning Geronimo, it is part of Geronimo after all and James's first and only complete project, only joking James. :-)

ActiveSpaces isn't "mine" although I was there at the conception :-)

-John-

I am not so worried they will show up eventually.

But it takes time.

J2EE grows by each version.

The vendors add more and more vendor specific stuff to
the app servers.

The code base for an app server must be exploding.

This simply means longer implementation time.

More time to make sure that the new stuff does not
break some of the old stuff.

And if customers are more interested in bug fixes for
the 1.3 compliant version than in a new 1.4 compliant version,
then it gets even more delayed.

But they will catch up.

if you're going to use JBoss without EJBs then you've not got much more than Tomcat with a few nice but complex options.

A bit understated I must say...Please do a bit more due-diligence before posting.

Without EJBs JBoss has a lot to offer:

JBoss Cache - your Tangosol is not open source or free.
JBoss AOP
Compliant and certified Web Services
JMS Messaging
JCA - connection pooling
JTA - transaction management
J2EE Security with integration with LDAP, Oracle, and other datastores.
Mature Clustering on JGroups: HTTP SEssion replication, JMS failover and replication.

All services/components configured and tightly integrated through our Microkernel:
Services
Service dependencies
Dependency Injection
Scoped and Unscoped classloading
Hot deployment of any archive
Pluggable archive deployers: i.e. Hibernate .har files, AOP .aop files, Bean Shell .bsh files. You can extend JBoss to deploy any component archive format and gain class loader scoping and hot deployment capabilities automatically.

Finally....

EJB 3.0, which is a HUGE leap in usability and simpler Spring (which IMO, is not so simple)

So that's just the app server...

We also have mature standalone projects under the JBoss Inc. umbrella like:

Hibernate: The O/R mapper you know and love
JGroups: Reliable multicast and cluster management
jBPM: Business process management
AOP
Nukes: Portal Server, Forum software, CMS
Tomcat: We fund a large portion of Tomcat development

All the above are fully supported by JBoss Inc. through our professional services and running in production in thousands of installations.

Bill

Bill,

I sincerely appreciate the list of jboss features you have detailed in this thread. I think I've rediscovered an old girlfriend all over again:) Nice work to you and your team.

Regards, Mike

Wow, what a reply, if only I had the time to do it justice!

JBoss Cache - your Tangosol is not open source or free.

It might be free and open but Tangosol works, has excellent references and you get good support for your money. It's used in several large banks for serious tasks, I can't name one knowing using JBoss' cache however good it might be.

Most of the other things you list are part of J2EE but you don't need a damn great big app servers to use them all, there are very few that can't be used stand-alone.

Don't get me wrong, J2EE isn't dead, far from it, I just said it's past it's peak. I still use J2EE a lot and expect to do so for some time to come.

-John-

I can't name one knowing using JBoss' cache however good it might be.

Anybody using JBoss 3.2.6 or JBoss 4+ clustering features is using JBoss Cache. You'll have to ask Bela or Ben about JBoss Cache in other sites for standalone deployments.

Most of the other things you list are part of J2EE but you don't need a damn great big app servers to use them

Another misconception that JBoss is this "great big app server". Completely untrue.

jboss "all" configuration (every single component/service ever written for JBoss) takes 59seconds to boot up on my laptop. jboss "default" configuration, without all the bells/whistles takes 15 seconds.


Sure, the download might by 90 megs, but you can customize the size and number of services you want to use just by deleting files within deploy or lib.


For instance, if you just wanted Tomcat, Hibernate, connection pooling, and J2EE security, you could just deploy that. BTW, we have a Hibernate Deployer that allows you to hot deploy hibernate archives just like you would a WAR or EAR.

Bill

John, you're talking about solutions, tailored for the end-customer, who requires a certain application to perform a certain business function. Ok.

But if we talk about a platform for running a multitude of applications, then we see vendors like IBM, BEA, SAP etc. An here J2EE is not losing it's peak.

Innovation in the form of frameworks is great, but I think standards must play catch-up, you saw what we had with entity beans ;)

EJBs are not popular and even forbidden in some banks

That's just complete ignorance on the banks part. There's nothing wrong with session beans and MDB (message driven beans) work well with the JMS you mentioned. I agree with staying away from Entity Beans.

I'd *love* to know how the banks distributes a highly cpu entensive workload? RMI? Is that a better solution then an EJB?

but the over use of J2EE has been the seed to lighter weight APIs, frameworks and architecture like Struts, Spring, JavaSpaces, Hibernate and JDO.

Struts is dead. It's being replaced by J2EE JSF. I'm a Struts developer and I look forward to having a nice JSF RAD tool to knock screens out. That's what JSF is all about. Hibernate and JDO are being rolled into EJB 3.0 (J2EE). JavaSpaces is Sun and could be includes in J2EE 1.5 if Sun wished. As for Spring I hear it's great and will run inside a J2EE framework which gets you all a J2EE server has to offer, transaction support, pooling, etc.

All in all I think J2EE 1.5 is going to be as important as J2SE 1.5 was.

"I agree with staying away from Entity Beans."

I disagree, perhaps its time to grow out of relational databases. Programmers probably need a generation or two to evolve from RDBMS.

Remember, entity beans are not evil, DBAs are :)

Cheers to all that reap the rewards of domain objects!

Yeah, right, I guess we should completely disregard a system that has:
- mathematical provability
- longer life span than the internet and most computer languages
- state of the art implementations
- extensive expertise available
- after all these years is still an academic research subject
and instead put on our "objects rule" caps, "java is king" t-shirts and piss on the obvious while merrily chanting away "death to the DBAs", "ejb, ejb, where is you be ?", "rm -Rf /usr/u0?".
Barf.

It is largely the Entity Bean in its various flvours that is the problem and usual reason for the ban. As you correctly point out, there is little problem with Sessions. MDBs are pretty damn useless unless of course you're stuck with an app server and have no other options but they are are nasty restriction on the JMS API.

Most banks have distributed grid centers, anything from 200 to 2000 CPUs, a lot are in fact C and C++ but of those that use Java all of them use RMI or a customised version of RMI, non of them use EJB in such configuration because it's just not the right thing to do for HPC. The 2000 CPU HP computing grid where I work at the moment is currently C/C++, they are also working with JavaSpaces, EJBs would not be concidered, it's got too many levels of indirection for the requirements of HPC.

I agree with you on the JSF, it's a good replacement for Struts, I think we'll see struts peak very soon for this reason too.

I am very much looking forward to J2EE 5.0, it's also my live-blood.

-John-

Most banks have distributed grid centers, anything from 200 to 2000 CPUs, a lot are in fact C and C++ but of those that use Java all of them use RMI or a customised version of RMI, non of them use EJB in such configuration because it's just not the right thing to do for HPC. The 2000 CPU HP computing grid where I work at the moment is currently C/C++, they are also working with JavaSpaces, EJBs would not be concidered, it's got too many levels of indirection for the requirements of HPC.

Well Goldman Sachs isn't a bank and they use EJB's heavily as does a lot of Wall St. I'm currently working at a bank in downtown NYC and again EJB's (session beans) are used to distribute CPU entensive jobs, especially one's that can run in parallel. Of course each problem is different and in your HPC environment you seemed to have bought into the whole grid computing on Linux with C/C++. Which is just an outgrowth of C/C++ threaded applications on large SMP Sun Sparc boxes.

If they could actually step back and design from scratch in Java things might have been different, but you have what you have.

I too as a Java/J2EE Consultant make my livelihood on this technology, but coming from a C and then C++ HPC world and can see why grid computing is attractive for things like Monty Carlo simulation. Of course the downside of Grid computing is well known and sites like Google can use it because if they lose some data it's not really that important. For Banks it's an entirely different matter.

Cheers! -Bryan

Of course the downside of Grid computing is well known and sites like Google can use it because if they lose some data it's not really that important. For Banks it's an entirely different matter.

That's why it's best to use Coherence partitioned caching to provide the data side of the compute grid .. lose servers, don't lose data :-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Of course the downside of Grid computing is well known and sites like Google can use it because if they lose some data it's not really that important. For Banks it's an entirely different matter.

That's why it's best to use Coherence partitioned caching to provide the data side of the compute grid .. lose servers, don't lose data :-)Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters

Does your company also sell software that can make round pegged business computing problems solveable by square holed Grid computing? :)

We tried running WebLogic and WebSphere on a 200 CPU set up a while ago, one of them didn't scale at all, in fact we couldn't even finish the tests, the other displayed reasonable scalability but the HTTP server failed before the EJBs did interestingly. Before this post creates an IBM vs. BEA war this was a number of years ago, things have changed a lot since.

I don't work in the grid project, I know the guys who do very well and we're pretty much agreed that Java would now be the better option if it were re-designed today. It was however designed a few years ago and I believe they made a good choice at the time, given the constraints they had then.

I'm flying out to NYC on Sunday so we should meet up for a beer if you're interested. Drop me a line, John at C24 dot biz.

-John-

[...] you seemed to have bought into the whole grid computing on Linux with C/C++. Which is just an outgrowth of C/C++ threaded applications on large SMP Sun Sparc boxes.If they could actually step back and design from scratch in Java things might have been different, but you have what you have.I too as a Java/J2EE Consultant make my livelihood on this technology, but coming from a C and then C++ HPC world and can see why grid computing is attractive for things like Monty Carlo simulation. Of course the downside of Grid computing is well known and sites like Google can use it because if they lose some data it's not really that important. For Banks it's an entirely different matter.Cheers! -Bryan

Bryan,
Grid computing has come a long way since you last looked. Grids have become very reliable and highly-available. In fact there are Java-based middleware Grids (and I happen to represent one) that offers the scale, performance and reliability you are speaking of. This is obviously just my completely biased opinion, but at GigaSpaces we have been developing an Enterprise Application Grid for the past 4 years that offers a truly highly-available and high-performance distributed platform, with a "Messaging Grid" (with a full-fledged JMS implementation), "Data Grid", clustering, high-performance caching, etc. - at the center of which lies a distributed shared memory kernel based on Jini.

This is not your father's Grid... - In fact, the Enterprise Application Grid integrated very well with all existing J2EE application servers to provide this massive distribution of processing power.

You can read more about it at: https://www.theserverside.com/news/thread.tss?thread_id=30444

Cheers,
Gad Barnea
GigaSpaces Technologies

.... [Yes these do overlap with J2EE I know, please read on]

They do not overlap, they rely on. What is Struts without a servlet container (J2EE)? What is hibernate without JDBC (J2EE, yup it is, even though it runs under plain JRE)?

If anything we will see a stronger uptake on these frameworks than J2EE 1.4. J2EE is now playing catch-up, what compelling reason do we have to use an app server at about $8k/CPU over something running on Tomcat using Spring/Struts etc. and Hibernate? JBoss and Geronimo are good options but we don't need the full stack, EJBs are not popular and even forbidden in some banks, if you're going to use JBoss without EJBs then you've not got much more than Tomcat with a few nice but complex options.I can see a far better future with best-of-breed frameworks, Spring, Struts etc. distributed services with the likes of RIO and JavaSpaces, caching with products like Tangosol, messaging of course with JMS or perhaps this?, integration with C24 IO, finally persistence through Hibernate or JDO.-John-

You are confused. Most applications doesn't require the usage of every single technology embraced by the J2EE standard. You seem to believe this is a requirement for a J2EE application. But running jdbc-calls straight from jsp-pages are just as much J2EE, and so are most of the "lightweight" approaches you mention. EJB certainly isn't a required part of a J2EE application.

They do not overlap, they rely on. What is Struts without a servlet container (J2EE)? What is hibernate without JDBC (J2EE, yup it is, even though it runs under plain JRE)?

Hibernate relies on JDBC yes but not J2EE, JDBC was around long before J2EE as were Servlets. J2EE was a collection of technology put together to provide an all encompassing stack. The only technology that didn't exist in its own right was EJBs, they were invented to fill the gap in J2EE. The technologies are great in their own right, don't get me wrong, even Entity Beans have an important role to play (all be it small these days) but all I'm saying is that the stack known as "J2EE" has past its peak, the component parts of J2EE will stand the test of time on their own basis and the majority will survive. For J2EE 5.0+ we need to re-think the stack, just using EJB 3.0 is not the answer especially if it retains the legacy version.

-John-

When Hibernate relies on JDBC, and JDBC is part of the J2EE standard, Hibernate relies on JDBC. Same goes for Struts and servlets. That's pretty obivous.

I disagree. J2EE 1.4 brings in two major improvements for those who (like me) use app servers as an integration platform for proprietary asynchronous systems, namely JCA 1.5 (inbound requests and lifecycle management) and EJB 2.1 (timeout management).