Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Java EE 6 Platform Draft Published 74

Posted by Soulskill from the rather-drafty dept.
synodinos writes "The public draft of the Java EE 6 Platform specification has been published and will remain open for public review and feedback until the 23rd of Feb, 2009. Perhaps the most notable part of this delayed draft is the Web Profile, which is first profile in the history of the Java EE platform. The draft is available for download and contains both the Java EE 6 Spec and the Web Profile Spec. There is a poll running at java.net regarding what the community thinks about the new spec. Although participation is yet rather small the results tend to show that the released draft did not cause any excitement."
This discussion has been archived. No new comments can be posted.

Java EE 6 Platform Draft Published More

Java EE 6 Platform Draft Published

Comments Filter:

  • Java.net (Score:5, Funny)

    by goombah99 ( 560566 ) on Saturday January 31, 2009 @01:34PM (#26678721)

    that's got to be sacrilege?

  • JEE 6? (Score:3, Insightful)

    by SirLurksAlot ( 1169039 ) on Saturday January 31, 2009 @01:57PM (#26678869)

    I'll settle for 5 at this point. My shop is still using 1.4.2; it feels like I should be writing code on stone tablets! I suspect this is the case in any number of Java shops and it just reinforces the idea that Java is going to become the new COBOL. There is so much "legacy" code out there right now, and because of the inconsistencies between versions I can't see it going away any time soon.

    • Just because your company stays in the stone age doesn't mean everyone else is.

      It's unfortunate but it may be best for your company if stability means more than new features an it's that way with any language.

      • Re: (Score:3, Interesting)

        by rve ( 4436 )

        My current employer has outsourced nearly all of their IT and software development to IBM.

        IBM itself estimated the cost of migrating and regression testing all server side software from Websphere 5.x to 6.0 (which will support J2EE 1.4, not Java EE 5) was deemed so prohibitively high, that they instead offered to extend support for the officially discontinued Websphere 5.x.

        Supporting multiple versions at the same time, during a long transition period would increase operating cost significantly. I will be su

        • Re: (Score:3, Interesting)

          by Ilgaz ( 86384 )

          Interestingly, IBM is also the company who provides a working Java 6 on PPC/Linux for years, years before Apple supported J2SE 6 on Intel (64bit Intel only).

          Currently, if your need to run Java 6 on PPC, your only chance is installing a PPC Linux (not sure about BSD) and run IBM Java on it. I also keep wondering how the heck Apple doesn't call their old friends at IBM and borrow some code to fix the scandal of no Java 6 on PPC OS X.

          Some wings of IBM are very old fashion but some aren't. Perhaps the enterpris

          • Currently, if your need to run Java 6 on PPC, your only chance is installing a PPC Linux (not sure about BSD) and run IBM Java on it.
            It probablly is your best bet for the moment.

            The good news is that openjdk with the patches from icedtea does run on powerpc and afaict work is progressing reasonablly well on getting a FOSS JIT written for it.

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Java is much much more than the new COBOL. COBOL will be dwarfed by Java when it comes to legacy. Think of it: COBOL was never the language used for the very first programming courses. While Java has the particularity to be both widely used in academic circles and in the Real World [TM].

      FedEx, GMail, eBay. All the biggest websites are powered by Java.

      We've seen examples of "smart" websites designed by "smart" dudes in a garage using "smart" languages that then couldn't scale and had to be re-written in

  • Not surpisingly, uninteresting (Score:5, Interesting)

    by DiegoBravo ( 324012 ) on Saturday January 31, 2009 @01:57PM (#26678877) Journal

    From TFA:

    There is a poll running at java.net regarding what the community thinks about the new spec...

    I like it 12.1%
    I think the main spec is missing important JSRs 3%
    I think the web profile spec is missing important JSRs 6%
    I don't like it for some other reason 6%
    I haven't read it, but plan to 9%
    I haven't read it, and don't plan to 63.6%

    Well, most people never read the specs (that are normally boring and with a lawyer-like style) but most Sun specs appear to being ignored because of bad timing for appearance (usually too late.) The "hot thing" are mostly the open source frameworks, from which Sun ends copying at the end.

    The same is happening, albeit radically, in the Mobile editions with Android, despite the Sun auto-acclaimed ubiquity of Jave ME.

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Well, most people never read the specs (that are normally boring and with a lawyer-like style) but most Sun specs appear to being ignored because of bad timing for appearance (usually too late.) The "hot thing" are mostly the open source frameworks, from which Sun ends copying at the end.

      Specifications are not there to innovate, but to define a common set of standards which are meant to be used by different vendors. So copying ideas from open source frameworks are not a bad idea : if you set a standard, wou

      • >> Specifications are not there to innovate, but to define a common set of standards which are meant to be used by different vendors.

        Tell it to Sun, that way they would never have a business.

    • Re: (Score:3, Interesting)

      by Serpent Mage ( 95312 )

      Or if you look at the current poll numbers and not what it was when the article was first written

      I like it 28.2% (26 Votes)
      I think the main spec is missing important JSRs 6.5% (6 Votes)
      I think the web profile spec is missing important JSRs 4.3% (4 Votes)
      I don't like it for some other reason 4.3% (4 Votes)
      I haven't read it, but plan to 14.1% (13 Votes)
      I haven't read it, and don't plan to 42.3% (39 Votes)
      Something else (please comment) (0 Votes)
      Total Votes: 92

      See some things take ti

  • Look at my face - is it bothered? (Score:5, Insightful)

    by sgodden ( 1466075 ) on Saturday January 31, 2009 @02:30PM (#26679107)

    I've been leading the development of Java applications for around 8 years. On that journey, I have used fewer and fewer features of it with each succesive project.

    Nowadays, it seems that specs are a kind of summary of what has been learned from the frameworks which were created in the trenches by people that actually needed to deliver.

    My latest project, which has been in development for around 1 year, delivers as a plain web application, and uses Hibernate, Google Guice, AspectJ and Echo3.

    It's wonderful.

    Sun don't have the capability, and I'm not sure that anyone has, to provide a full and relevant specification that will allow code to be developed that will run on any application server from any vendor.

    Instead, choose your implementations and go back to good old OO basics to design interfaces behind which to hide those implementation choices. You don't need Sun to do that for you.

    • Sun don't have the capability, and I'm not sure that anyone has, to provide a full and relevant specification that will allow code to be developed that will run on any application server from any vendor.

      And that's why end users groan when a good idea gets written in java.

      • Ignoring your grammar difficulty, the majority of useful applications out there require a non-embedded database solution...therefore, some configuration is mandatory, for pretty much any application on any platform. To all of you complainers, I work on an application which deploys successfully to Jetty, Tomcat, JBoss 4.2, and Glassfish (as just the ones I've tested). In fact, I test it on all 4 platforms on a regular basis. Sorry, but it works perfectly for me.

        Java is a great platform that gives excel

        • Look, every defense of java I see is from developers and that defense is ostensibly about developing in java. How about considering how much it sucks for end users and admins who have to manage all this stuff?

          Sure, just about every kid that graduated in the last 5 years knows java, I understand why there's so many java developers, but ffs with so many of you you'd think you'd be able to get together, pick one and say THIS is java.

          No joke, I've seen devs in the same shop that struggle all day trying to get

        • Re: (Score:1)

          by oreaq ( 817314 )

          I work on an application which deploys successfully to Jetty, Tomcat, JBoss 4.2, and Glassfish (as just the ones I've tested)

          That's nice. So it runs in the web container. By the way: Which web container do JBoss and Glassfish use? So it's only two different runtimes, isn't it. The compatibility nightmares come when you integrate your Java application in a typical enterprise setup. With SAP, CICS or IMS/DC, FileNet, ICR/OCR Servers, legacy C and C++ applications, .Net, WebSphere MQ and lots other stuff.

    • Re:Look at my face - is it bothered? (Score:5, Interesting)

      by CynicTheHedgehog ( 261139 ) on Saturday January 31, 2009 @04:08PM (#26679769) Homepage

      I've never seen a serious commercial product shipped independently of an application server. I've always though of an application server to be more of a framework. As a product author/vendor, I make choices about which application server best serves my product. Then I build around it. When I sell to end users, I either enter into some kind of licensing/support agreement with the application vendor, or I require the end user to purchase licenses and support themselves.

      The spec exists so that developers can write components that can interoperate with various application servers. For example, I can write a data connector for a proprietary mainframe application and use JCA to include that in distributed XA transactions. That resource adaptor can be used on virtually any application server, but the way it is deployed and configured will differ.

      Or I might write a custom JAAS LoginModule to support some kind of proprietary authentication requirements. Again, the ability to integrate into an application server is undisputed, thanks to the specifications, but the mechanisms by which it is integrated is left to the implementor.

      To support full drop-in interoperability, Sun would have to control all of the details of deployment and configuration, and then there goes competition. Everyone would just grab a copy Glassfish and rebrand it, because how then would you innovate?

      As a developer I'm glad that there are differences in application servers. The various classloading strategies, configuration interfaces, and monitoring tools ensure healthy competition and innovation. And if something becomes ubiquitous (or problematic enough) then it gets added to the standard. (EJB3 is largely Spring+Hibernate, standardized, and Seam+Facelets is on its way to standardization through JSF 2 and WebObjects.)

      One last thing. I've worked in shops that ran Tomcat plus a few third party libs (i.e. Struts and Hibernate), and I've worked in shops that have used the full JEE stack. In the former, we had infrequent but persistent problems with transactions (lost updates, etc.) that required implementing a lot of proprietary transaction management code. Using the full JEE stack you have things like JTA and JPA that manage locking for you, which can be painful if you don't know what you're doing. But it forces you to deal with real issues rather than pretending they don't exist, which is a must for true enterprise applications. The same can be said for resource pooling, security, managing web sessions and conversations, and many other issues.

      • I've never seen a serious commercial product shipped independently of an application server.

        It depends on definition of 'serious' of course, but I was working for a company producing software for airline operations (briefing/loading, no booking nor avionics/realtime). We had number of clients, including some really big names in Europe. Software was written in J2EE and it was used on 2 different application servers, on 2 different databases (3 combinations in total) - only because companies we were supporting were mostly standarized on Websphere, so there was no need to test it on more. There is NO

      • Can you give us more detail on the "shops that ran Tomcat .. had infrequent but persistent problems with transactions (lost updates, etc.)"?

        • The shops that ran Tomcat generally used JDBC or some in-house persistence framework. In either case, there were no facilities for dirty checking or optimistic locking. So if user A loads an object into his session and modifies it; and user B loads the same object into her session and modifies it, then the changes made by whomever commits first are lost. Small shops generally ignore this problem as it happens infrequently enough to warrant serious development time, and usually end users catch the error a

      • (...) through JSF 2 and WebObjects.

        To be a little pedantic: the name was Web Beans; WebObjects is Apple's framework. JSR-299 now has the oh so sexy name: Java Contexts and Dependency Injection [relation.to].

    • Well, I've been leading development of various applications done mostly in Java for the past 11 years, and I wouldn't use Hibernate, Google Guice, AspectJ and Echo3 in any of them, though sometimes we end up using some of it. I often end up removing these and other technologies from the messy projects that are passed to me after the original team is done f.cking around with them.

  • Kudos to the JCP (Score:5, Interesting)

    by thammoud ( 193905 ) on Saturday January 31, 2009 @03:03PM (#26679323)

    It might be slow but it has been very successful. Sure many specs never saw the light of day. That is to be expected from every committee.

    Like it or not, Java is king on the enterprise server-side. J2EE sucked at the beginning but successive versions addressed many issues required by the enterprise. Persistence (Hibernate, Toplink), transactions and messaging (JMS) and the many available and free implementations. Thank you Sun for sticking with the JCP. Standards are wonderful.

    We have an ASP platform built on J2EE 5.0 handling hundreds of millions of transactions a day all on a free stack thanks for the JCP and Linux.

    I will duck now since this is /. home of the anti-Java.

    • Re: (Score:2, Funny)

      by upuv ( 1201447 )

      I will duck now since this is /. home of the anti-Java.

      Actually it's the home of anti M$. So you should be ducking on the mention of ASP not Java.

    • Re: (Score:3, Interesting)

      by Ilgaz ( 86384 )

      Most of people doesn't get the "EE" (enterprise edition) in the article and comments on story like hitting a poor java applet/application on desktop while they have never seen/worked on enterprise environment. It happens to any Enterprise/non general thing mentioned on slashdot.

      As far as I know, J2EE is the actual thing which saved the mainframes and near all finance industry runs on it.

      I bet if some article posted regarding (true or not) .NET enterprise features, it would get comments like "but .net is 990

  • Java EE Irrelevant? (Score:2, Insightful)

    by ssfsx17 ( 1192943 )
    The only times when I've had to look up the EE APIs these days are when I need a refresher on the guts of a HTTPServletRequest/Response or a SQL Connection. Otherwise, Struts, Spring, Hibernate, derivatives of the previously mentioned items and the like are the de-facto standards.
    • concerning the web layer you're right on the spot, its too low level and should not be dealt with directly, but jpa, session beans and mdbs are pretty sound and simple and should be dealt with directly, everything else, except for specific business needs, is nih and overhead. and hibernate is in fact a jpa implementation. and with spring, well you have an alternative to application servers, but jee is NOT about just application servers anymore.

    • JDBC is part of JSE.

  • And worth exactly what you paid for it.

    I work at the MegaMegaCorporation in IT and we were "tasked" to "implement" a "departmental solution". I.E. we were told to write an app for a small bunch o' end users. The app we came up with used Java, Hibernate, Guice (for DI), Spring (for JMS) and Apache. Since we were in the Java world we had a huge range of OSS thingys we could plug into our app that did a whole bunch o' kewel things easily.

    +1 for Java - all the widely available thingys

    Then, as is usual at

Slashdot Top Deals

"The one charm of marriage is that it makes a life of deception a neccessity." - Oscar Wilde

Close