A new article on SDTimes provides an overview of major issues that have affected us in 2001. The article discusses the importance of the additions to J2EE, an apparent decline in participation in the Java Community Process, appserver consolidation and Web Services troubles.
Read Up-and-Down Year for Java With Updates to J2EE, EJB
Perhaps more interesting is the commentary about proprietary J2EE extensions conflicting with the "promise of Java".
Thanx for directing me to this important article; I found it troubling as well. I feel that there is good reason for J2EE vendors to extend their standard J2EE app servers with custom, proprietary tools. For example, BEA's CAJUN framework is supposed to only work with BEA's WebLogic J2EE server according to this article. However, I certainly think that it's premature to sound the death knell for Java/SUN's standardizing objectives.
The whole purpose of the J2EE standard is to build a common, open, and flexible foundation that will streamline certain aspects of engineering or developing. The fact that the status quo is unacceptable in that code modules, designs, architectures, etc, are not 100% portable across different J2EE vendors only provides *more* urgency to the notion of following a common standard; it certainly doesn't call for the implementing vendors to "give up" on the movement and start developing proprietary frameworks. I found this comment from the BEA executive in your linked article extremely short-sighted in that this was his reason for BEA not approving the J2EE standard and its objectives:
“Anyone that is doing enterprise Java development is learning that you don’t pick up an application from one application server and drop it on to another without any pain,” said Zachmann.
So what this BEA executive is saying is that since Java users find it difficult to move applications from other J2EE servers to a WebLogic server, then that suffices enough to cast disdain on the whole reason for a standard altogether. Although he didn't say it, his next comment was most likely "If everybody just used a BEA WebLogic J2EE server, their problems would be solved."
These attitudes and rationale are harmful to the more important objectives that are trying to finish the course begun in 1995. It's too bad that a great company like BEA, which obviously has some of the best talent in the world, forgot its roots.
The quote in my message above was by (quote) Will Zachmann, vice president of Meta Group Inc.’s Open Computing and Server Strategies practice. The comment from the BEA exec meant to be included was this:
"... the Cajun framework, according to Sebastian, makes it possible for developers to build on top of the WebLogic platform without having to understand the details of object-oriented programming or the J2EE APIs..."
The Cajun framework is obviously a powerful piece of software, and although BEA does not suggest it so, the fact that a company can abstract away the fundamentals of Object-Oriented programming still does not give a reason to move away from the standard which supports it, as the article seems to be implying by its title/theme.
Well, that article certainly seems to vindicate Microsoft. However, I'm sure the anti-Microsoft whiners will try to rationalize the non-standard approaches different vendors take anyway.
Anti-Microsoft whiners? The only whiners I see in here are disgruntled microsoft programmers that don't understand J2EE.
With the outspoken and proactive java community, I seriously doubt J2EE vendors will dare break standards. Their bottom line will loose it's buttocks in a heartbeat.
Just because moving enterprise applications (which are, by definition, complex) from one app server to another is not a 'drag&drop' procedure, that does not vindicate the MS-Wintel total vendor lockin approach.
I have a big problem with any article that starts 'No one has ever really believed in the “write once, run anywhere” credo.'. That kind of statement usually indicates a strong anti-Java agenda by the article writer.
The article also uses the word 'Java' in a very ambiguous way. Is the author referring to Java language, API, J2EE or EJB?
Also, in the 'Java Year' article, it states that 'Version 1.4 of Java 2 Standard Edition, the free version of J2EE'.
Huh? You have to pay for J2EE do you? Oh dear, where do I start with that one? Explain very patiently the difference between a standard and the implementation of the standard? No, best tell the JBoss people and watch them laugh...
The MS FUD agents are out in force for the New Year. Think they've had too much festive cheer, though, as their thinking seems even more muddled than usual.
Although I wish it weren't true because it would be easier to explain the ridiculous insinuations that her article makes, Christina Purpi has not shown any anti-Java tendencies in her history( search for her articles at the SDTimes and see for yourself ). Although she is obviously less technically educated than would be appropriate for someone in a position with arguable influence, she seems to have given great coverage on Java products in the past.
Maybe it's just me, but I finished the article with the impression that BEA had given itself the authority to declare the J2EE standard as a lost cause, and therefore it's OK for them to go ahead and veer off this course. I agree that following a standard may not be the easiest or most efficient way of doing business depending on how you look at it, but in the long term it is the wisest choice. Also, if you consider the alternatives, it is the ONLY choice.
"christina is starting her career as a journalist here at SD Times and handles day-to-day reporting while TRYING DESPERATELY TO UNDERSTAND the ins and outs of the computer software industry. she received her bachelorâ€™s degree from Hofstra University in print journalism where she was the managing editor of their student-run newspaper, the chronicle. She is also an avid photographer and sports junkie." - bzteam/SDTIMES
Christina is planning to write a ".net" article and in the process receives sage advise.
Thank you "n n" for this research; it just goes to show that the tone of her articles all depends on who she gets her information from. Maybe this latest article she wrote was all based on information from a person who did not like BEA for whatever reason. That's too bad -- these kinds of articles need to have more sophisticated and intelligent research performed on them. If a product or standard has flaws and an article wants to expose them, that's great and I encourage such activity. However, wrapping misinformation around cleverly worded sentences that leave veiled impressions of negativity is not fair, whether its targeted at J2EE-based or .NET-based products. Can anyone suggest a journalist besides Dave Winer with any credibility whatsoever, or is he the only decent choice out there?
Yes. I would agree that the tone of the article must have been dictated by those who provided her with the information. Interestingly, there are some classic MS touches to the article:
- Pushing the 'Java isn't really portable' line.
- Stating that because people extend the standard with their own libraries, then the standard is broken. (By that logic, the existence of, say, Log4J means that the J2SE API is fundamentally broken and means the end of Java!)
- Stating problems with one area of a technology as if they apply to all of that technology. Specifically, most of the issues and problems that are variously associated with Java and J2EE in that article actually lie with EJB.
At the end of the day, Enterprise Java consists of suite of libraries, if there are parts that are weak and aren't working, then they should be replaced by ones that do work.
Anyway thanks to Tyler for his clarification. Building scalable server-side solutions is a non-trivial task(!) and all standards-based efforts to ease that path should be welcomed. Certainly, I look forward to reading about their proposed solution.
'Maybe this latest article she wrote was all based on information from a person who did not like BEA for whatever reason.'
Exactly the opposite! I have heard on a number of occasions from BEA and IBM that Portability and inter-operability are not achievable with enterprise Java. This article nicely (from BEA's perspective) articulated their position.
This is the article that an intelligent person, without deep understanding of the issues would have written after speaking with IBM, BEA and Oracle. The issue is with the sources interviewed not the journalist.
<rant on> Standards are about portability and inter-operability. You can not say we support standards but do not support portability and inter-operability, which is what BEA and (to a lesser extent) IBM say. At best this is incoherent, at worst duplicitous. <rant off>
Jim: "<rant on> Standards are about portability and inter-operability. You can not say we support standards but do not support portability and inter-operability, which is what BEA and (to a lesser extent) IBM say. At best this is incoherent, at worst duplicitous. <rant off>"
When we first started using Weblogic for J2EE, there was Weblogic and there was the reference implementation. Our app worked on both.
Since then, several apps we've worked on would run on Weblogic and Orion and more recently I've seen multiple projects that would also run on JBoss.
You can choose to be locked into a platform such as Weblogic ... it's rather easy actually considering the number of services that it provides that are not standardized. You can also choose to stick to the standards as much as possible and your app will be portable (particularly if you encapsulate any deviances). Like I said, we've done it and it is a rather common approach.
OTOH I have not seen the same "ease" of portability with WebSphere. You can implement J2EE interfaces if you want to on WebSphere, but you have to use IBM classes (by their IBM class names) to do anything at all. I could just be smoking something and maybe I just missed it in their documentation where it said "oh, if you want to just use the standards, here is the trick to getting it to work", but so far I've never seen any advanced apps that could run on WebSphere and anything else too without surgery. And I've never heard of one. And the J2EE app vendors that I've worked with that support WebLogic and WebSphere have "choice words" reserved for the latter on this particular product. There is a new WebSphere 5 build that IBM released Dec 21 with J2EE 1.3 support ("the first with 1.3 support" according to IBM) and maybe it is different, but I'm not holding my breath.
Sounds to me like the old C scenario. If you knew what you were doing, it was fairly easy to write K&R (and subsequently ANSI) C that would run on different compilers / platforms. However, as soon as you started needing to do something specific, then you needed libraries that tied that part of the code to a compiler/platform. So you ended up with portable bits of your projects and less-portable bits. The same then also subsequently applied for class libraries for C++ projects and now the same game is being played with Java.
Nothing wrong with this, as long as eyes are open about which parts of the project are portable and which are not (i.e. easily to quantify which parts need work if the container is ever changed, hence cost to business can be estimated).
She's a disgrace.
What can you do?
Since there is such an active discussion about Cajun, here is BEA's current position on Cajun, which I'm heavily involved with. This is our public statement at this time:
First, Cajun has not been announced to the public, so any articles done on it are leaked information and not entirely reliable. Cajun will be announced at our eWorld event on 2/24.
Second, Cajun is not a break away from J2EE or a proprietary extension. BEA is firmly in support of J2EE and the standards process. The Cajun framework falls inline with this directly and leverages every aspect of J2EE.
Third, Cajun is an implementation of a set of standards, which will be pushed into a worldwide standards body. We cannot go into details of this at this time.
Fourth, Cajun is the first implementation of these standards and is based upon WebLogic Server. It is feasible and possible for the Cajun framework to be supported on other systems.
Director, Technical Evangelism
BEA Systems, Inc.
'Second, Cajun is not a break away from J2EE or a proprietary extension. BEA is firmly in support of J2EE and the standards process. The Cajun framework falls inline with this directly and leverages every aspect of J2EE.'
Is Cajun J2EE compliant and hence portable (in principle) across app severs?
Is the code produced by Cajun J2EE compliant and portable across app servers?
'Third, Cajun is an implementation of a set of standards, which will be pushed into a worldwide standards body. We cannot go into details of this at this time.'
I decode this to mean Cajun is proprietary but we hope to get it thru a standards body.
'Fourth, Cajun is the first implementation of these standards and is based upon WebLogic Server. It is feasible and possible for the Cajun framework to be supported on other systems.'
Ã? will be uncharitable and point out that Microsoft has made similar statements about .NET. And 'is based upon Weblogic Server' implies Weblogic specific dependancies.
Tyler, all you have to say is that Cajun and Cajun generated code (however it works)is fully J2EE compliant and is in principle deployable to any compliant implementation. If for business reasons you choose not to, thats fine.
The original article strongly sugested that BEA is out to break the standard. Frankly, your reply did not reassure me that you are not!
Any economist will tell you a product that is standardized becomes commoditized. Hence to maintain prices J2EE vendors must differentiate and add value (or become commodity suppliers). Differentiating on top of the standard (and hence maintaining portability and interoperability) is welcome and should be applauded. Differentiating in ways that break portability and interoperability should be condemed, and I firmly believe the market will do this.
Sebastian's comments are telling. Putting 2 and 2 together, Cajun is likely standards compliant and hence portable. However, BEA's business model does not support portability. BEA clearly wants to be the next integrated software stack vendor, along side Oracle, IBM and Microsoft. Portability and intra-operability are not consistent with that objective. Purchasers of J2EE technology should vote with their pocketbooks if they value standards compliant implementations with portability and intra-operability.
I would also like to debunk some of the dis-information in the article.
'The actual ability to take a complex application from one J2EE application server vendor’s product to another is just not happening.'
This is simply untrue! Smart developers who value portability write to the standard and ensure their code is portable. All the code we develop is automatically built and unit tested on three different application servers (Weblogic, Borland and JBoss) within minutes of it being checked in. The only real issue is application server specific deployment descriptors and improvements in IDEs such as JBuilder should resolve this problem.
The article claims that proprietary solutions running ahead of the standard will eventually break it, when the proprietary solutions are not selected as the standard. This is FUD. If a vendor chooses not to support the standard then it is their decision, as it is mine not to purchase their product.
'However, according to BEA, Cajun is an entire framework, not just a set of tools.'
The implication here is that a framework ncessarily breaks the standard. A framework is essentially a higher level abstraction (and J2EE needs these higher level abstractions because of the difficulties of n-tier, distributed, transactional environments). A framework breaks the standard, ONLY when it does not conform to the standard. Framework's are being developed that fully conform to the J2EE standard (and other relevant standards such as SOAP). For example, we have one - http://www.enba.com.sg
. We fully expect part or all of our framework to fall within the scope of a future standard, and will at that point conform to the future standard(s).
'these same Java vendors are now claiming their customers want one-stop shopping'
Of course they will say this, its their (IBM, BEA, Oracle) business model!
A much more interesting article would have focused on how standards, portability and inter-operability will impact the integrated stack vendors. Clearly IBM and Microsoft are the most secure and BEA the most vulnerable. Although making Cajun portable would send a clear message to the market that BEA is serious about standards.
Proprietary extensions? Well, until someone documents startup classes in the spec, then everyone does proprietary extensions.
The spec is incomplete. Some of the things missing are key. Is this an assault on the promise of Java if you gotta build the feature as an extension? No. You're simply delivering a product. Anything else requires maliciousness (as in, "it's standardized, but I don't like how it's done, so let's do it in some proprietary way")
The Sun/Microsoft litigation and decision is one of the most disappointing Java stories. It would have been very nice to have Microsoft in the Java game. Having Microsoft build an application server for IIS and having JDK 1.3 distributed in Windows would have been very big for Java developers.
I am certainly no Microsoft champion, but it is very clear that their JVM implementation was superior on Windows. Not having to distribute JDKs for Windows is significant. Having Microsoft bundle Java containers with their server-side software is significant. Because Sun and Microsoft could not get along we Java developers loose all of this leverage, and now have to put up with Java versus .NET.
Java is the biggest thing in software development right now. Microsoft would have finally come to their senses and seen the potential licensing revenue to be had and played the game wisely.
It is very unfortunate that the Sun/Microsoft case ended with the decision that it did.
Pocket PCs ship with a JVM. Microsoft's decision to not ship a JVM with WinXP etc. has little to do with the Sun lawsuit and everything to do with Microsoft doing every thing it perceives to be the interest of its desktop monopoly.
As my mother used to say 'You makes your choices and you pays your money!'
Tom: "I am certainly no Microsoft champion, but it is very clear that their JVM implementation was superior on Windows."
Their AWT implementation, for reasons documented elsewhere (something about double buffering?), performed with superior speed. Generally speaking, their JVM was ahead of its time in terms of performance but was soon overtaken by everyone else judging by the benchmarks that I was reading.
Tom: "Not having to distribute JDKs for Windows is significant."
Yes, I agree that is a great disappointment. (BTW - The states' case against Microsoft would require them to ship Java. Write your congresspersons.)
Tom: "Because Sun and Microsoft could not get along we Java developers loose all of this leverage, and now have to put up with Java versus .NET."
It was not a question about "getting along", it was a question of who controlled the standard. Microsoft, as well-documented in the recent anti-trust trial by Judge Jackson, was intent on destroying any standards that could threaten its Windows monopoly. As long as they had a shot at directing the standard (read: embrace and extend), they were willing to play. As soon as Sun reminded them of their contractual obligations, Microsoft took their marbles and went home.
It's a real shame that one of the largest and most successful companies in the world acts like a spoiled four year old. That behavior is relegating them to the dustheap of history.
Tom: "Microsoft would have finally come to their senses and seen the potential licensing revenue to be had and played the game wisely."
I don't think so. Once you are a monopoly, there is only one way to go (down), so you maintain the monopoly as long as you can (and in Microsoft's case, illegally). Licensing "standard" software means competing and having to innovate, two things that Microsoft's business model can't tolerate.
It's just like IBM in the 70s, not that I'm old enough to remember ;-) ... there's an old quote that typifies the defeatism from that era when IBM repeatedly broke anti-trust law to destroy competitors: "There is no standard so standard that IBM can't change it."
Luckily, we're over the Microsoft hump and the rest of the market has gained the critical mass that it needed to wean itself slightly of its complete dependence on Microsoft. Microsoft will continue for some time to dominate the desktop (notice that about 1/3 of the $$$ for a new PC goes straight to Microsoft), but fortunately they failed in their bid to leverage that base (illegally) into new monopolistic positions.
"It was not a question about "getting along", it was a question of who controlled the standard. Microsoft, as well-documented in the recent anti-trust trial by Judge Jackson, was intent on destroying any standards that could threaten its Windows monopoly. As long as they had a shot at directing the standard (read: embrace and extend), they were willing to play. As soon as Sun reminded them of their contractual obligations, Microsoft took their marbles and went home."
This is a very contradictory statement.
Java is not a standardized language. Sun owns it. How could MS "direct" a standard. How could anyone direct a standard? Case in point: C++ IS a standardized language. MS has the best C++ environment for Windows. But MS does not direct the C++ language.
I believe if Java were standardized then MS would take the ball and run with it and would build a top notch IDE (for Windows only) and maybe even parts of J2EE; like an EJB container. But since Sun owns Java MS isn't going to touch it. I agreee it's bad for the development community but MS is, after all, a business whose goal is to make money.
What's keeping Sun from setting Java free?
FUD. If the they couldn't find a crisis, Java would not have even been mentioned on the site. If you want real crisis, you might check some of the recent bugs found in XP or in SQL Server.
Java is doing just fine. Thanks for checking, though.
<quote>Version 1.4 of Java 2 Standard Edition, the free version of J2EE, was released in May </quote>
Wow, look how many errors they manage to introduce in those few words ;-)
christina is starting her career as a journalist here at SD Times and handles day-to-day reporting while TRYING DESPERATELY TO UNDERSTAND the ins and outs of the computer software industry. she received her bachelorâ€™s degree from Hofstra University in print journalism where she was the managing editor of their student-run newspaper, the chronicle. She is also an avid photographer and sports junkie." - bzteam/SDTIMES
They changed her description since we last shead light on here background. Take a look at her NEW description.