Slashdot Mirror

Looks like the JBoss people will be making use of the Sun test suites according to The Server Side. Maybe this will set a precedent for Kaffe.

I had to dig this up, thought I'd save you the trouble.

http://www.theserverside.com/home/thread.jsp?threa d_id=20376&noise=show#89229

It appears to be the CTO of THOUGHT accusing an open source software project of patent violations. Classic.

Thread is here

The database access in Java is really a mess. On one side we have the EJB technology, now grown up and mature, but still having many problems: you cannot use built-in database sequences, instead you have to resort yourself to the well known hack (in the Java Community a hack is called "the pattern") with session bean and entity bean. Reading from database is rather slow - you have to use DAO (write them by hand or have generated like in OptimalJ) or resort to container specific practices - like in JBoss - where you define how many rows should be read at a time.

Even more mess is due to arrival of the new technologies duplicating the functionality of the EJB - like the JDO, which (as I have read in: JBoss chooses the JDO) may be the basis of enterprise Java in tommorow meaning not only the betterment of your applications but also meaning that new sources of incopatibility will emerge.

In this case one fears that his applications will have to be rewritten, the tools will change, the practices you learn now will become obsolete.

Additionally there is still the problem of using the database effectively. The more indirection you have in accessing the DBMS, the more portability you acquire, the less specific you can be. Those questions need answer if the Java Enterprise Technology shall continue to lead.

There is alot of confusion around proper code practices. A better discussion is taking place on theserverside.com. Some people are too entrenched to change away from the rdbms centric approach(stored procedures, triggers, etc.). But for the rest of us, I recommend looking into the JCS code which when matched with an OR tool, gives the programmer ideal mapping tools. Apache is working slowly on a fine tool called OJB that will hopefully someday include full JDO support. Let them know you're interested. CMP - Container Managed Persistence BMP - Bean Managed Persistence JDO - Java Database Objects EJB - Enterprise Java Beans Here's a summary of the future for those of you who just want to observe from the gallery. I prefer open source tools personally, so most of the links are for those tools:
EJB is problematic. Most(80% I'm guestimating) of programmers don't understand it but think they do. It is not 'THE' CMP solution, but one of them. Containers give you the ability to do clustering between app servers, which is a good thing. But EJB isn't the only one, compared set against ATG's superior repository API. Scope in EJB is also confusing and most programmers get this wrong, but the mapping is thus: request scope: stateless session bean session scope: statefull session bean global scope: entity bean If you don't understand scope, that is a different issue. But it is necessary for proper app server design to know the difference and use them correctly. JDO is most likely the future. It can or may not use a container. And gets around the flaws of every other mapping tool. Here is a synopsys of their flaws: A better architecture does not alter itself to fit the tools one is using but best fits the problem to be solved. For example, most tools like hibernate and castor suffer from the need to force the bean that is persisted to use public getters and setters. If you want to make your getter and/or setter private, default or protected scope, then you're out of luck. JDO doesn't have this limitation. In many designs, not every column in a table needs to be exposed to calling classes. EJB requires that a persisted bean implement an interface or subclass a parent. This also alters the design, and JDO makes no such requirements. Staying true to the best design to fit the problem, will give you the best return. Naturally, the world is moving away from stored procedures, joins and the like. Yes, really it is, you don't have to like it, just live with it. Although most of the foot dragging is by those who's past history doesn't include multi-threading and good OO design. Perl is a prime contributer here. Although Perl can do in memory object caching, most Perl mongers aren't familiar with it. It's much easier in Java though. But in-memory caching is a must have. That is the key concept behind best java database accessing practices. Using only request scoepd objects is less efficient.
So by next year, JDO will be production ready. Until then use EJB or Cocobase, Castor, Hibernate or the like($) if you must have cluster(multiple app server) support. Otherwise, good old SQL(use a config file to load the SQL statements to avoid embedding) with a BMP design will do quite fine for a single box. Also, design from the object level, and not from the table level. This is heresey to some, but it is a (better)best practice.
Note:
With the release of JDK1.5, the use of external XML configuration files will be reduced or eliminated since source code markup will be added.

We do a lot more than clustering app servers. Our product serves as an in-memory data store in a clustered application tier. If you have experience with high-scale J2EE applications, you'll probably have experienced what I call the "single point of bottleneck": the database. For some of our customers, we've reduced their database usage by 99.9%+ and their overall infrastructure costs by over half. With the replicated cache, each application server has all the "cached" data locally, so access is instantaneous. With our concurrency features, the data integrity is maintained, whether on a single server or replicated across 100 servers. With our distributed cache, if you have 100 servers each caching a half GB of data, you have a 50GB cache!

Other features include support for grid computing, cache querys, and more. We've focused heavily on making sure that our clustering is fault tolerant and extremely reliable.

Check out how the TheServerSide created a single cluster out of multiple vendor's app servers using Coherence. You may not need it for your application, but it shows what you can accompish.

Gene Gleyzer
Tangosol, Inc

http://www.theserverside.com/resources/article.jsp ?l=JavaOneDayOne_03

Here's the URL w/o the extra space so that it works.

yes you can

anyway, ejbs really aren't very elegeant in terms of persisting data. things like o/r bridge from jakarta or cocobase offer similar functionality without the (coding and runtime) overheads of local and remote stubs.

where ejb does come into it's own is in the area of scaling... if you're using them for that then by all means take advantage of the persistence mechanisms too, but they're not worth it on their own.

also, where do you get the idea that you only write the business logic? you also have to handle controllers and views. unless i've massively understood what business logic is all this time and it's not the 'model'.

According to this article on theserverside.com, in one person's benchmarks, .NET is slower than Java. YMMV and all that.

According to this article on theserverside.com, in one person's benchmarks, .NET is slower than Java. YMMV and all that.

FUD. The specification was released only one year ago.

FUD. See JDOCentral.com and TheServerSide for real-world discussions.

There's an interesting thread over at TheServerSide which discusses JDO vs. Entity beans.

You should read the 'White' paper (in the 'Blue, White, Red' serie) by Marc Fleury. Marc Fleurey is the leader of the JBoss projet, and he is making profit from service around the JBoss EJB server. In this paper he shares how his business works around a Free Software product.

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

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.

I disagree with the poster in principal, but he does have a point in that anyone who started EJB development at EJB 1.0 was screwed. Suns "Best Practices" at the time led to horrible performance when implemented in the real world. To do a JOIN with entity beans back then meant that the database table information would be queried in a FINE GRAINED manner and passed THROUGH THE NETWORK so that it would appear that the database tables could be manipulated as objects. In essence they wanted EJBs to allow java programmers write database calls without knowing how to write database calls.

EJB 2.0 with newer design patterns has made great strides in performance AND scalability. I won't go into it here except to say that the two patterns that EJB developers should look at are

1) Session Facade - If you don't have a trained DBA on staff, or performance is not as important as maintainability.

2) Course Grained Session Beans - If you do have a DBA, and/or you need the best performance.

look here for a good EJB patterns benchmark

look here for a free book on EJB design patterns.

Amazon and EBay runs on J2EE? What gives you the impression? I don't think either one of them are running on J2EE. EBay has contracted IBM to redo it's web site but it's not yet moved to the new one.

Here is the article about EBay going to use WebSphere. If you read the discussion, it's not very certain how much J2EE is there for EBay version 3. Do anyone has any idea what version EBay is running now? Has it switched to version 3 yet?

Its difficult to find unbiased comparissons as I am sure you have seen from the flame wars that errupt every time the subject comes up. You can try this Web Services for a review of web services or this Smackdown for a synopsis of the recent petstore furore or check out GotDotNet for general stuff about .NET

Misguided not. It would have been possible to create an entirely client-side calculator-app that would be fast as lightning, yet this is not what Millstone is for. I'll conceed that the Calc-app is perhaps a bad example-app as it brings forth sentiments like this. It is only intended to demonstrate and tutor the usage of Millstone, and not, in this case, it's power.

One important aspect of Millstone is that the presentation of an app is separated from the underlying logic. This means that once adapters have been made for different terminals, that same Calculator app, without so much as one line of code changed, will work on your cell-phone, digi-tv and terminals that aren't even imagined yet.

As to the responsiveness of the example application, I'd like to point out that it's running on a single server sitting in the room next to me, in Finland ... so you're bound to get some netlag if your surfing in from the states. Regarding the /. :ing as an excuse, it is if we never really believed that we'd get on here. :)

Realistically, we're too small to make mega $ hardware investments in preparation for high demand, we just have to wait for that demand to realize itself and then respond to it.

Further discussion regarding the speed and efficiency of the ui transformation process can be found in the serverside.com thread.

Regards,
Peter Bäck

• CRI(?) The Common Runtime layer. The thing which runs the compiled code, sort of comparable to a Java runtime environment.
• Several languages: C#, VB.NET, C++.net, J#, maybe some other language I forgot. They all run on the Common Runtime layer and therefore 100% interoperable. A C# module can call a VB.NET module.
• ASP.NET: ASP as it should have been done. Brings it up to par with JSP.
• Support for XML Web services. Calling modules over a http call using XML/SOAP.
• ...

• For a Java oriented serverside programming site: The Serverside
• Several O'Reilly titles: .NET framework (more general), Programming C#, Programming ASP.NET (last two specific for the languages)
• Wrox has a good set of .NET books that are worth looking into

I have this book, and JSTL In Action and both of them are truly excellent books. The 11/10 rating is quite appropriate. I have been attempting to convince myself to buy the Manning Ant book as well - just for the documentation on all of the Ant extensions that it includes.

Additinally, Manning Press has experimented with releasing PDF versions of books (in read only if you use acroread or windows, but not otherwise) and this was how I first met their books. (The books were hosted over at The Server Side). Anyway, this was my first intro to Manning Press. I now look over their books before any other.

The think I like most about Manning books is that they are written for smart people who have clues. Many tech books feel the need to explain basic concepts of programming in every single one, Manning doesn't bother - they stick to the topic on hand, they write as if the audience has a clue, is intelligent, and has real work to get done.

TheServerSide has some good reviews on the various enterprise servers, as well as some complete stinkers. A general rule of thumb is to throw out all the comments which seem to be lacking in spelling or logical argument.

Couldn't find the 10 times faster than .Net comparison by Oracle, but:

http://www2.theserverside.com/resources/article.js p?l=PetStore

http://www.oracle.com/features/9i/index.html?9iasf ast.html

The latter gives a measurement of 538ms response time for 600 users on the Petshop. Since the Middleware Company PDF lists response time as 14ms for "J2EE AppServer A" and 10ms for .Net, at 750 users, there's obviously some difference in benchmarking practices. If anyone has a link to the "10 times faster" propaganda, please post.

J2EE Classloading

Will give you a good overview of the issue. Note that there are different MODES for Websphere that means it works differently for classloading between versions. I think that the Websphere 3.51 version is different to most servers in classloading.

You will get ClassDefNotFound errors in most situations that this problem is seen.

We support 8 J2EE servers with our product and we find that server configuration is the biggest headache when getting the same application working on all the servers.

Amazingly, I haven't seen any mention of Jakarta, an all-Java project of the Apache Software Foundation (ASF).

Here's my list...

• java.sun.com and developer.java.sun.com
• jakarta.apache.org
• www.theserverside.com

The reference for server side java is The Server Side.com
Also, JGuru has quite a lot of stuff about general java
And of course, the Sun Java site is an excellent reference to, and they recently redesigned the web site which is now much more intuitive IMHO...

Also, get a copy of Thinking in Java by Bruce Eckel (Free PDF version on the web), this is the best book on java ever written!

TheServerSide is the best site I've found for J2EE stuff.

Download the full Manning book J2EE and XML Development (pdf) here
You can also get a full copy of Bitter Java there.

Writing software is not difficult. Writing high-quality software _is_ difficult and requires experienced craftsmen (infer journalistic gender-neutrality, please).

So how then, can you get high-quality software quickly? Two ways:

1. Hire experienced experts. Experienced experts produce high-quality work quickly. They write code generators to do tedious work for them. They classify problems and hunt down and implement reusable solutions. Keep giving them raises and interesting problems. Granted, defects in the software will be of the extremely intractable variety (very subtle design flaws or bad/wrong requirements)
2. Reuse experienced expert knowledge and technique in the form of pattern-driven code generating tools. Hire journeyman developers to adapt the code the tool burps out and get on with life. Keep an expert or two around to extend or correct the patterns the tool uses for generation. You'll get applications that are far less pretty than the hand-crafted variety. On the other hand, the defects are known and predicatable. Tools (apologies for the shameles plug) for this sort of development are just now becoming available and practical. Granted, when handed a powerful implement fools often find a way to hurt themselves (thus instantiating the 8th corollary to Murphy's Law).

Either method has drawbacks. #1 produces the best software, #2 produces the cheapest software. #1 makes the "Agile" crowd happy while #2 is the sermon of "Software Engineers."

Why single-out developers for defective code? Because developers write defective code. No, all developers aren't clods with text editors. Developers who do write buggy code may even care about their craft (Pragmatic Programmer tip #1). But developers themselves are to blame for the defects in their work, even though outside factors contribute to problems. We must take responsibilty for our bugs, move on and fix them. Then find new ways of working that make it more difficult for software defects to make it into production evironments.

We cannot fix imperfect programmers. We can only mitigate the effects of their imperfection through mentoring, certification, education, and proper management. In other words, treat software development as a craft, a talent to be polished and perfected.

Writing software well means communicating well with a computer. Artful written communication is very difficult to reduce to an engineering discipline, yet the skill can be taught and practiced.

Skip the WebSphere download and start with JBoss. Still compliant, but simple to manage and open. Even if you're just getting started, stepping through container source in a debugger can be an enlightening experience.

After you read the hype about the mystical and versatile powers of EJBs, brush up on its real-world shortcomings and some useful patterns for overcoming them at The Server Side.

How about Mastering Enterprise Java Beans and EJB Design Patterns both made available by their respective authors.

How about Mastering Enterprise Java Beans and EJB Design Patterns both made available by their respective authors.

In the Java "community", design patters are very popular as building blocks to build functional programs. There are many books available the the subject. One good one is EJB Design Patterns: Advanced Patterns,..., written by one of the guys who runs The ServerSide.com which also has a less formal discussion forum centering around design patterns.

While many design patterns are specific to good J2EE design, and may not be relevant for all types of application, many are general enough to be used in any object oriented language. May be part of what you are looking for.

-Pete
(yes, the book link has my amazon id in it...click and buy the book. It's worth having.)

The reviews for the book and comments on Amazon, TheServerSide.com, JavaRanch are very encouraging. Thank you all. And, thanks to SlashDot for reviewing the book on this forum...

I'd like to thank some other folks.

This book would not be possible without the great set of tools written for building and testing J2EE. I'd like to publicly thank James Duncan Davidson et al, Mike Clark, Vincent Massol et al, Kent Beck and Erich Gamma.

James Duncan Davidson et al created Ant. The de facto build tool for Java. This is the glue for building applications and making continuos integration doable with Java.

JUnit is the regression-testing framework written by Erich Gamma and Kent Beck. After looking at this code base you can see this framework screams with design patterns and solid OOP, and is central to Extreme Programming development with Java. It is as if these guys wrote *the definitive books* on Design Patterns and Extreme Programming--oh yeah they did!

Russell Gold wrote HttpUnit, which makes functional web applications easy and fun. (It can also be combined with Cactus.)

Mike Clark extended JUnit to provide JUnitPerf, which does load testing and performance testing. This code is an excellent example of how to extend JUnit. Mike Clark is also a really nice guy.

Vincent Massol et al for creating the Cactus (was J2EEUnit). I use this tool every day at work to unit test JSP Tags and EJBs. This is a truly novel tool. (BTW Nicholas Lesiecki, the co-author of the book, is an active committer on this project.)

Vincent Massol of Cactus contributed to the creation of the book. He reviewed the chapter on Cactus. His acknowledgement was accidentally omitted from the book during publication.

I am not implying that anyone mentioned above endorses the book or name dropping. I just wanted to thank them for contributing their time and effort to create these tools and then just give them away! Without them this book would not exist.

The book has been a bestseller under software development on Amazon most of this year. Thank you. We are blown away with the success of the book.

Check out these threads about the book if you get a chance....

Thread TheServerSide.com

Nick and I answered a lot of questions about the book at the JavaRanch as well...

Thread at JavaRanch
I've posted some more background information about the book here...

Book Web Site

I'll check back and try to answer any questions about the book. Thanks again.

The web site will soon have a sample chapter on it. Later, when we write the second edition, the book web site will have early drafts for review.

--Rick Hightower Co-Author of Java Tools for Extreme Programming

At first I agreed with this sentiment, however, after reading though Bruce Eckels "Thinking in Java 2nd ed." online link to bookI was hooked.

Ed Roman's "Mastering Enterprise Java Beans" is also a free book available at theserverside.com

BTW: After going through them online, I went ahead and purchased the tree versions as well. From the looks of the amazon.com sales rankings, so did a lot of other people. Perhaps this model is not *that* bad for book publication.

The Java Pet Store, Sun's J2EE best practices blueprint application, was rewritten in C#. It took 1/4 the code and performs anywhere from 15 to 28 times faster than J2EE. Check it out here. Debate on how it was done can be found here.

IBM's Software Donation: Move To Eclipse NetBeans?
NetBeans IDE 3.3 released
IBM to open source WebSphere tools
threads on Eclipse
threads on NetBeans
threads on IDEA

Eclipse is a product of Object Technology International Inc., which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned, "...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...". I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?
NetBeans IDE 3.3 released
IBM to open source WebSphere tools
threads on Eclipse
threads on NetBeans
threads on IDEA

Eclipse is a product of Object Technology International Inc., which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned, "...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...". I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?
NetBeans IDE 3.3 released
IBM to open source WebSphere tools
threads on Eclipse
threads on NetBeans
threads on IDEA

Eclipse is a product of Object Technology International Inc., which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned, "...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...". I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?
NetBeans IDE 3.3 released
IBM to open source WebSphere tools
threads on Eclipse
threads on NetBeans
threads on IDEA

Eclipse is a product of Object Technology International Inc., which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned, "...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...". I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?
NetBeans IDE 3.3 released
IBM to open source WebSphere tools
threads on Eclipse
threads on NetBeans
threads on IDEA

Eclipse is a product of Object Technology International Inc., which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned, "...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...". I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?
NetBeans IDE 3.3 released
IBM to open source WebSphere tools
threads on Eclipse
threads on NetBeans
threads on IDEA

Eclipse is a product of Object Technology International Inc., which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned, "...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...". I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?
NetBeans IDE 3.3 released
IBM to open source WebSphere tools
threads on Eclipse
threads on NetBeans
threads on IDEA

Eclipse is a product of Object Technology International Inc., which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned, "...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...". I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?



NetBeans IDE 3.3 released



IBM to open source WebSphere tools



threads on Eclipse



threads on NetBeans



threads on IDEA

Eclipse is a product of
Object Technology International Inc.,
which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned,
"...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...".
I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?



NetBeans IDE 3.3 released



IBM to open source WebSphere tools



threads on Eclipse



threads on NetBeans



threads on IDEA

Eclipse is a product of
Object Technology International Inc.,
which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned,
"...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...".
I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?



NetBeans IDE 3.3 released



IBM to open source WebSphere tools



threads on Eclipse



threads on NetBeans



threads on IDEA

Eclipse is a product of
Object Technology International Inc.,
which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned,
"...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...".
I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?



NetBeans IDE 3.3 released



IBM to open source WebSphere tools



threads on Eclipse



threads on NetBeans



threads on IDEA

Eclipse is a product of
Object Technology International Inc.,
which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned,
"...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...".
I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?



NetBeans IDE 3.3 released



IBM to open source WebSphere tools



threads on Eclipse



threads on NetBeans



threads on IDEA

Eclipse is a product of
Object Technology International Inc.,
which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned,
"...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...".
I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?



NetBeans IDE 3.3 released



IBM to open source WebSphere tools



threads on Eclipse



threads on NetBeans



threads on IDEA

Eclipse is a product of
Object Technology International Inc.,
which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned,
"...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...".
I think that Eclipse will be a high quality software.

IBM's Software Donation: Move To Eclipse NetBeans?



NetBeans IDE 3.3 released



IBM to open source WebSphere tools



threads on Eclipse



threads on NetBeans



threads on IDEA

Eclipse is a product of
Object Technology International Inc.,
which also produced VisualAge for Java.

And as the article "Refactoring with Eclipse" mentioned,
"...Erich Gamma is the team lead for Java tools for Eclipse. Gamma was one of the Gang of Four known for creating the book Design Patterns...".
I think that Eclipse will be a high quality software.