Discussions

News: JCP work begins to simplify EJB, JDBC, and other J2EE specs

  1. Five new JSR's have been posted on the JCP which begin the work on major upgrades of significant J2EE specifications such as EJB 3, JDBC 4, JAX-RPC 2.0, JAXB 2.0, etc. All of the new JSR's have ease of development as a major stated goal. Infact, the EJB JSR will try to eliminate deployment descriptors and make EJB's more like plain java classses.

    Here's the list of these new JSRs:
    JSR 220: Enterprise JavaBeans 3.0.
    JSR 221: JDBC 4.0 API Specification .
    JSR 222: JavaTM API for XML Data Binding (JAXB) 2.0.
    JSR 223: Scripting Pages in Java Web Applications.
    JSR 224: JavaTM API for XML-Based RPC (JAX-RPC) 2.0.

    These new JSR's will likely be part of the J2EE 1.5 specification, a JSR for which hasn't been formed yet.

    Threaded Messages (32)

  2. I looked at a few JCP and all are headed by Sun and none have IBM, or open source (ex: Doug Lea, ASF, etc.).

    I guess wait and see. (I might fill out the app. to join).
    .V
  3. Very excited[ Go to top ]

    I am VERY excited to hear this. I can't wait to see our favourite standards a LOT easier to use... and to get out of some of the unnecessary XML hell ;)

    Here's to the future!
  4. "make EJB's more like plain java classses"
    WOW! this is good news.
  5. Can anyone say JDO?

    Funny how JDO does the simplification already. Big vendors must realise that people would just use Tomcat instead of shelling out £5K/CPU if they supported JDO.

    Does anyone use the remote interfaces and method level security of EJB anyway?

    I say it's a good think to simplify it. Will it use byte code enhancers?

    But the big question is will it be faster that .NET in a for next loop benchmark, ROLF? ;-)
  6. To have Entity beans become more like JDO (or have JDO replace entity beans altogether) would be a dream come true.. unforunately I don't see this happening to do political reasons...

    Floyd
  7. To have Entity beans become more like JDO (or have JDO replace entity beans

    > altogether) would be a dream come true.. unforunately I don't see this
    > happening to do political reasons...
    >
    > Floyd

    I couldn't agree more Floyd. You know this is what I've been arguing for years and it's nice to see that Sun is FINALLY listening!!!

    For those customers who can't wait for the years this is likely to take, CocoBase already delivers a Distributed Transparent Persistence implementation that outperforms hand coded JDBC and that has been available for quite some time... Our new Service Release 3 (just out), even includes a performance benchmark test suite with nice PDF documentation and a gui front end. It also demonstrates how CocoBase after running for a short period of time actually becomes so optimized by the JIT that it outperforms the identical raw JDBC code by a typical factor of 2! This means that CocoBase without caching enabled still tends to outperform many other O/R layers with their caching enabled!

    I still remember many of the JDO vendors saying that performance slowdown is simply the price of O/R mapping - but we've proven that this is in fact the opposite. When a mature O/R mapping product such as CocoBase is used, performance will typically increase - and not decrease! But don't take my word for it, you can download and try out our performance test suite in your own environment! And since we ship the test suite as source code, you can even validate the tests yourself to ensure that we are running the identical SQL... And this is with standard java classes an reflection compared to no reflection in JDBC! So we debunk the myth that O/R mapping and reflection are slow in a single step :)

    So for customers who want this new EJB 3.0 style programming, it's already available in a mature, robust and high performance implementation - today! No waiting, it integrates with existing servers, ides and modeling tools, supports standard EJBQL out of the box, includes local and distributed scrollable cursors, explicit unload from memory APIs, fault tolerant high performance (up to 500x faster) distributed caching, and an API as simple as:

    root = (MyRootClass) cbfacade.load(keyRoot);

    So developers can choose to dream of a future spec, or use a product that delivers more today than is even promised in the specification proposals...

    Just my $.02
    Ward Mullins
    CTO
    THOUGHT Inc.
    http://www.thoughtinc.com
  8. finally ...[ Go to top ]

    EJB just has too much unwarranted complexity. The notion that we would all build components that an "application assembler" would string together has not panned out. In retrospect, it's unbelievable that java books and best practices preached using EJB's for simple website architectures. But then again, what was the alternative?

    I'm very stoked on Tapestry, JDO, and other systems that tame complexity. Looks like we are moving into the "post EJB" era, which ought to be more productive and fun!

    -geoff
  9. WM again ... against JDO[ Go to top ]

    I still remember many of the JDO vendors saying that performance slowdown is simply the price of O/R mapping


    Eric>>>Can you disclose us which JDO vendor said that ?


    Best Regards, Eric.
  10. RE: THOUGHT Inc.[ Go to top ]

    I recognise Cocobase as an excellent O/R mapping tool, Also Toplink, now owned by Oracle. But as these are propriety solutions to commit to a vendor is riskier and more costly (Training) than coding to a javax interface and swap the runtime when needed (cost, bugs, liquidations)

    As standards move forward surely Though Inc must see this as a move to final commoditisation of O/R in J2EE. Where the major container merits will be cost and reliability where open source will wipe the floor.
  11. To have Entity beans become more like JDO (or have JDO replace entity beans altogether) would be a dream come true.. unforunately I don't see this happening to do political reasons...


    I totally agree, it would be a dream come true. But at the same time, I just wish people would stop overusing EJB. My last two projects have done just fine with Tomcat/JDO and I'll be very happy if I never use EJBs again. SUN is motivated by marketing and profits (pushing EJB supports its partners BEA & IBM, which bring in licensing revenue), and if SUN doesn't start listening to use developers then Java will suffer. With Microsoft quickly catching up, SUN is risking running Java into the ground.

    Michael
  12. Make Entity Bean simple[ Go to top ]

    I am using EJB for at least 3 years now, the thing is, and I don’t have much problem with Session bean with the three classes. The thing is, with these three classes we get lots and lots of flexibility.

         I am having problem with entity beans (Reason almost all EJB implementation use Session Façade). As of now I don’t thing I have used full power of entity bean, or it is possible that the functionality I have used is the acceptable level of developing community for entity bean.

         Can there be a simple way to define just DB connection, and Entity Relationships in simple DD file. With this webserver will generate one to one mapping of bean implementation on the fly, rather than we writing all those stupid entity beans. I will go one step further and say that we should have facility to write DD E-R for Database views too. With this we will get time from BMPs also as we can define BMP equivalent views in database and later just define E-R in DD and let the app server take care of entity bean headache.
         
         Caller function will use bean name in DD to access release the real table related (may be entity bean) class.

    What say?

        Bottom line is at least simplifying entity bean stuff .. This is the thing that has fewer visits from developers and has to develop in more of mandatory need rather than software requirement.

    Regards
    Chetan
  13. Please don't silence Ward Mullins[ Go to top ]

    Hello Everyone,

    I believe JDO to be a very significant development in the area of Java object persistence and O/R mapping (even though JDO does not mandate or standardize O/R mapping yet). However it is important that criticism of JDO can be openly expressed. Without frank (but polite) discussion, it is hard for us to discern the areas that need improvement in order to make JDO more appropriate to the user base it targets (people wanting an Object view of a possibly relational data source).

    Therefore please do not stop Ward and others from constructively criticising JDO.

    Thanks, Robin.
  14. Can anyone say JDO?


    EJB != Entity

    > Does anyone use the remote interfaces and method level security of EJB anyway?

    uhh.. yes

    /T
  15. Simple EJBs and XDoclet[ Go to top ]

    This is exciting news, because (and I think I can speak for everyone) we all hate deployment descriptors. Heck, even without DDs, a typical EJB will have at least 3 files (implementation, home interface, remote/local interface) and perhaps many more. Having to write all those files just for a single component is more work than I care for and keeping them in sync can be even more maddening.

    But that's why I use XDoclet (http://xdoclet.sourceforge.net). With XDoclet, I can tag a bean implmentation class with meta-data tags (that look like JavaDoc tags) and have my DD, home/local/remote interfaces, and utility classes generated for me. I can also declare my implementation as abstract, tag it appropriately, and have XDoclet generate a concrete class that implements the (usually) empty ejbXXX() methods. And XDoclet handles keeps all of these files in sync. I only have to work with a single Java class and XDoclet does the rest. Oh...and it does similar things for other non-EJB stuff like Servlets, TLD files, and Hibernate mapping files.

    I wholeheartedly support the JCP's attempts at simplifying these specifications. But in the meantime, using XDoclet, EJBs aren't all that hard.
  16. Simple EJBs and XDoclet[ Go to top ]

    The new additions of metadata comming in 1.5 will be used specifically to just what you'r using XDoclet for.
  17. I must sound crazy to most of you.. I agree that everyday there is some new idea better than the old one... But instead of releasing so many specs in such a short time & make us all change some part or another of some code, making app servers make the change to comply, why not just wait for little more time, do 2 more revisions of the spec, make sure its scalable for atleast 2 years. <br>

         Change is a good thing, but new specs generally contain better solutions to problms in old spec. Why wasnt ejb 2 spec more thoughtful to make ejbs simple, think of overlap with jdo than etc. We could have waited for ejb2.0 for 6 more months but not have the pain to move to ejb 3.0 soon. <br>
    I know that it will be about a year from now when ejb 3.0 will be drafted finally and released and then app servers will catch up... but its going to repeat the same cycle .......
          Same happens with the xml parsers too .. its released every millisecond of the day .. some comply to old versions some just dont ... do these guys think of any organizations like banks, insurance companies who have invested so much into technology that a small change in a JCP spec means changing thousands of lines of code, unit test, a lot of QA effort .. etc etc etc etc etc ...
    .. As i said before .. i may sound crazy to most of you ..which i m not :).. but to some nerds who have just 2 servers serving 100 customers, i m a jack A**..
    Happy coding
  18. I understand the sentiment, but it's very hard to predict where things will be in two years. In 1998, could you predict the technological needs of Java in 2000? In 2001, could you predict the technological needs of Java in 2003? Market conditions change. New competitors emerge (especially .NET). New technologies emerge.

    Getting a consistent, efficient, and usable spec that everyone agrees to implement is hard enough. Getting one that stands the test of time when so much changes is insanely difficult. The C++ standard took 8 years to be standardized and took many more years before the new C++ libraries got implemented universally and completely. When it was done, C++ and it's libraries had changed so much that C++ became a different language. (C++ version 1.0 had a lot of warts but it was simple and trivial to understand. C++ version 3.0 (the final version) had a different set of libraries and several new all-embracing features like templates, exceptions, RTTI, and namespaces.)

    I personally don't want Java to take over 5 years before releasing the next spec, even if it would make my life as a programmer easier and would result in a more well thought out language.

    The main problem might actually be the opposite of what you think. Perhaps we need more specs released more often so they could react to the market better and get better public feedback and interoperability with other technologies.

    They key thing is that the changes need to be structured so that it doesn't drive it's developer audience insane. If you use Debian Linux as a model, we could organize JSRs into these classifications:
    * "bleeding edge" - JSRs that have just been released. They may not have a single implementation or they may have some unforeseen shortcomings that need updating. To the best extent possible, this JSR is production quality, but it hasn't stood up to the test of time.
    * "leading edge" - JSRs from the bleeding edge that have multiple implementations that appear to work well and appear to be eventually ready for the
    * "the average developer" - JSRs from the "leading edge" that have stood the test of time. This JSRs are either part of the current Java/J2EE spec or they are destined to be.

    We developers would need to know "the average developer" JSRs because you'll more than likely deal with these several times a year in the course of your Java/J2EE work. Some jobs may require you to learn a few "leading edge" JSRs, but the majority of your work should be with "the average developer" JSRs. Tool makers and alpha geeks would be the only ones interested in "bleeding edge" and even then, they'll more likely be interested in "leading edge" and "the average developer" JSRs.
  19. I forgot to mention that using this three stage approach, BMP EJBs might never have passed the "leading edge" JSR category to become a "the average developer" JSR because of the N+1 problem. Also EJB 3 wouldn't be part of the "the average developer" JSRs until it first goes through "bleeding edge" and "leading edge" JSR status.
  20. In the meantime that we are waiting for all this stuff to come out, which could be years, there is already an alternative. .Net/c#.
  21. Mackie: In the meantime that we are waiting for all this stuff to come out, which could be years, there is already an alternative. .Net/c#.

    Or PowerBuilder. Or assembly, while we're going backwards.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  22. Cameron: Or PowerBuilder. Or assembly, while we're going backwards

    Dying to see Assembler in enterprise computing ;)
    I'm almost forgot how to build OOP programs using Assembler ;)

    Sergey Litsenko
  23. The PowerBuilder vision[ Go to top ]

    Heck, I *WISH* Java would someday reach the simplicity and productivness of PowerBuilder.

    Compared to the technology then, PowerBuilder was the best of breed tool you could find, IMHO. It was slick, feature-rich with exactly the things you needed to write enterprise applications that were scalable and performant. Java is walking right down that aisle, but still has a long way - especially in the tools area.

    I remember back then, the main thing was writing the application, rather than choosing the right technology, because you already had the technology. Sure it was proprietry (PowerSoft, and then Sybase) but atleast things were running.

    Ofcourse, PowerBuilder's time has passed, but if anyone in the enterprise applications market should aspire to something - that's it. A platform or environment that truly puts an emphasis on productiveness and programming ease (and fun).

    Arik Kfir, IAF
    Java Tech. Team leader, Isreal.
  24. The PowerBuilder vision[ Go to top ]

    Arik,

    I was a an Advanced PB instructor (etc.) and did lots of work on PB and I agree. I could code PB as fast as the client could tell me what they want.

    You CAN be that productive in J2EE!

    PB was in touch with how it was used. (Sun is not, they are engineers who assume users love complexity in development, I guess)

    * If you use J2EE w/o EJB the thing works * and scales very sweeet. Add Struts, JSTL and iBatis DAO.
    I have a working sample of above at http://basicPortal.sf.net (open source). It does CRUD/ Master Detail, Navigation (Struts menu), etc. etc. (and I have my 2nd book coming out, my teaching it is just like PB- but Java).

    Sun will never get it, you can't teach pigs to sing, you just frustrate yourself.
    JSF, EJB, JDO are design via "thought experiments". I wish they would say:
    "we are Java programers, lets see if we can get JDO (or XYZ technology) to create a multi line invoice and CRUD and show it on a JSP page and save it to a SQL DB" and see if that works. Reference Implementation demo for JDO is working with a flat file, and does not use ANSI SQL, JDO got bashed in another thread, you can look.
    Instead this is the "Sun JCP" result in the past and in the future:
    http://www.softwarereality.com/programming/ejb/index.jsp
    (I wish the would not use Java Comunity in the name, it's not true, Just call in Sun Process).
     
    As far as JavaOne JCP "community" represenation, look at this, Netcraft is very reputable and scientific:
    http://news.netcraft.com/archives/2003/04/10/java_servlet_engines.html
    See how much share Sun and Bea have (JavaOne and JCP )?

    IBM is not a part of Java One nor a member of above JCP's, nor are other major players.
    JCP according to above is a very small part of Java Community (it has no ASF-Apche represneation on the JCP- so much for the "community" part)

    Anyway.... the point is you can be very, very productive in J2EE but you have to find your path. (and not listen to Sun. The sooners Sun goes the way of Data General and DEC, the sooner JCP things go away, and the better for Java!; the Sun stock is barely at $4, and I hope soon at $1.5, they can't sell slow sparc machines for $40K a pop, when there are faster Intell machines for $4k - look at www.tpc.org)

    Use Struts, JSTL, iBatis (DAO) and you will go far, (and look at my sample app. I don't do thought experiments, if you have a better way, SHOW ME the code).

    iPlanet for everyone, :-)

    hth,

    .V

    (I do not even use the Sun VM or JDK anymore 'casue they might drop of the radar screen and my clients would freak, instead I use J:Rockit VM, it has a better license and is better VM. Nice thing about Java is that it is X-platform )
  25. JRockit[ Go to top ]

    <quote>
    (I do not even use the Sun VM or JDK anymore 'casue they might drop of the radar screen and my clients would freak, instead I use J:Rockit VM, it has a better license and is better VM. Nice thing about Java is that it is X-platform)
    </quote>
    I'm not sure about JRockit is better. At least after I heard the talk from Emmanuel C. from Inria (JAX 2003). He also showed a comparison diagram for the performance between JDKs (Sun, IBM, JRockit) in Linux. In Linux JRockit does not scale and very complex to adopt and to optimize. IBM JDK should be the best performance JDK in Linux.

    Lofi Dewanto.
  26. JRockit[ Go to top ]

    Lofi,

    I too do not belive anyone, so I test myself!

    Here is an indpenedet test showing jRockit is MUCH faster than Sun:
    http://www.ammai.com/modules.php?op=modload&name=Reviews&file=index&req=showcontent&id=10

    We all used jikes instead of javac, else you have JSP compile leaks, even IBM VM is better.
    Plus both VMs avoid StrigBuffer leaks. (SUN VM is same quality as iPlanet, BEA ships with J:Rockit, IBM uses it's VM, Oracle uses J:Rockit, only iPlanet uses SUN JDK AFAIK. Also Kaffe.org is open source Java, but can't call itself Java 'cuase of lawyers.)

    My data on J:Rock it (I tested with dbMonster createing db records and DieslTest to generate users, it takes a hour to configre both the 1st time - links to both on baseBeans.com cheat sheet page) is that it is much faster on MY machine with MY application with MY configuration.

    I am from the "show me" state.

    .V
  27. I mean, damn....[ Go to top ]

    Ease of use? I guess no-one remembers Silverstream (which, if I remember correctly, was owned by the same company that owned Powerbuilder). Or IBM's earlier (pre J2EE spec) efforts at making developer friendly server side Java development tools. Oh, yeah.... those were evil, proprietary tools and/or server platforms (like ATG dynamo - which SUN actually ran it's Java site on). We're so much better off now with SUN's JSR process perpetually defining empty specifications to address problems that have been solved before.

    I mean, why should we "get religion" about every single spec coming from a company that can't even implement a half-assed version of ANYTHING themselves (SUN ONE, baby! woo-hoo!)? Selling Netbeans as "Forte for Java" doesn't count as developing "decent" Java software, either.

    The 'SPEC' and the JSR process seem more a way of SUN keeping competitors perpetually in-check ("hey! don't innovate! thats not in the 'SPEC' we just came up with!!!") than a serious way to build a better platform.

    I shouldn't complain - most companies are now accustomed to paying "serious J2EE programmers" top dollar to dick around with xml deployment descriptors.
  28. Cameron,

    I wouldn't really dog .NET it has some pretty good features. Most of the things in those proposed JSRs are already avaliable in .NET. I think this is just a case of copying/using the best parts of another "platform" (i use that word loosely) to complement your own. Which is fair enough because this is how all technologies evolve (i.e. through competion). ASP -> JSPs/Servlets, CORBA -> COM/COM+ -> J2EE -> .NET , etc... (im sure most people could go even further back) :-)

    On the other hand IMHO i think JSRs take too long to be finalised/approved and eventually implemented by vendors. Take a look at JavaServerFaces (JSF) and JCache. These are very important because although there are other "products" that exist already that offer the functionality of these proposed JSRs (JSF and JCache), you could even write your own, (aint choice a wonderful thing :-)) it would be nice to have a "standard way" of doing these things. (i.e. standard web app framework, caching API, etc). One of the advantages is good tool and vendor support.

    JSF and JCache have been JSRs for as long as I can remember. .NET possibly copied JSF for their "web framework" (they are VERY similar) but Microsoft managed to deliver it faster because of less bureaucracy than the JCP process could. I know some of the advantages that JSRs bring but I still think the whole process is too slow. This was ok when we (the J2EE platform guys :-)) were the only available solution. But now that we have some competition I think the whole JCP process should be speeded up. Any thoughts?

    Cheers

    Smythe
  29. JSRs[ Go to top ]

    Smythe: On the other hand IMHO i think JSRs take too long to be finalised/approved and eventually implemented by vendors. Take a look at JavaServerFaces (JSF) and JCache.

    No kidding. I am a member of the JCache expert group. I can attest to things moving much more slowly than one would like. That is the nature of the beast.

    Luckily, the industry moves much faster than the standardization process. While that has its downside, it is usually a very fortunate thing, because the standards can be based on things that actually work in the real world. For example, most of the contributions to the JCache group are now coming from caching products or people experienced with those products. The end result is that the standards are better, and reflect real world usage.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  30. JSRs[ Go to top ]

    Thanks for your reply. Very interesting I never quite saw it like that. However as a member of the JCP do you find certain vendors can intentionally slow down the whole process for their own aims? (no conspiracy theory here im just asking if this is possible/plausible :-)) or is it based on a voting majority system and strict timetables/deadlines? The reason why I ask this is that some features that certain application servers support that are omitted from or delayed in the final specifications can give vendors a certain advantage in the market.

    For example, read only entity beans, propritory extentions to EJBQL that were rather silly to ommit in the first place i.e. ORDER BY clause (I've read the reason why this was ommited in the first place but... it didn't seem to wash :-)), built in optimistic concurrency (i.e. without having to implement the version number pattern... I think its called).

    Also delaying a JSRs finalisation (if it is possible :-)) could enable a vendor to implement a feature and deliver just after the JSR is finalised. i.e. have "quicker" time to market.

    The above is all fiction but i'm just wondering why the whole JCP process is so slow? Any thoughts?

    Cheers

    Smythe
  31. JSRs[ Go to top ]

    Smythe: as a member of the JCP do you find certain vendors can intentionally slow down the whole process for their own aims?

    I have not witnessed that. While there are competing interests, most of the "vendors" represented are chomping at the bit to get something -- anything -- out and visible.

    That said, I am sure there are exceptions to the rule. I know of some potential exceptions on some of the other JSRs.

    Smythe: is it based on a voting majority system and strict timetables/deadlines?

    I think each JSR works a little differently, but there is a "lead" on the JSR that typically would have the "swing vote" (so to speak, aka the final say) on a lot of matters.

    Smythe: The reason why I ask this is that some features that certain application servers support that are omitted from or delayed in the final specifications can give vendors a certain advantage in the market.

    Theoretically. However, collusion and conspiracies are rather hard to pull off ... not impossible, but it's a lot of work and fraught with the danger of being "found out".

    Smythe: Also delaying a JSRs finalisation (if it is possible :-)) could enable a vendor to implement a feature and deliver just after the JSR is finalised. i.e. have "quicker" time to market.

    It's possible, but Sun and IBM always seem to be the "latest to implement" in certain areas, and they are definitely involved with the JCP ;-) I assume, though, from your technical issues, that you were "potentially accusing" a certain other app server company with three different initials?

    Smythe: The above is all fiction but i'm just wondering why the whole JCP process is so slow? Any thoughts?

    Yes. The participants are all busy doing other things, from my experience. On the JCache JSR, at least a half dozen of the participants are actually designing / building / maintaining / evangelizing caching software. Those are full-time jobs. Most companies can't afford to donate "full time" work to the JCP. That makes it hard to find times at which all (or even a reasonable "quorum" of) participants are available to focus on the task at hand.

    It goes both ways, though. Like I said, the end result may be better, because (hopefully) the delay means that the spec matches real world realities, instead of some ivory tower BS. I definitely have mixed feelings on the topic ....

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  32. JSRs[ Go to top ]

    I assume, though, from your technical issues, that you were "potentially accusing" a certain other app server company with three different initials?

    LOL that was not my intention at all. :-) I just happened to be reading through thier feature list and it seems that these "cool" features I mentioned that they support were not supported by the spec. (It could have been any other vendor's product I was reffering to... very well spotted though :-)).

    Cheers,

    Smythe
  33. catchup[ Go to top ]

    The open source movement began simplifying J2EE a couple of years ago.

    I think I'll rather put my faith in those with a proven track record.