|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 40
Messages: 40
Messages: 40
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Java EE 5 passes public review ballot
JSR 244, the umbrella spec that defines what other specs and capabilities will be included as part of Java EE 5 (formerly J2EE 1.5), has had it's public review spec approved by the JCP EC. The theme of the release is ease of development, focused on redefining the platform in light of annotations and pojo-driven development, with major additions including the Java Persistence API 1.0 (EJB 3 entities), JSF, JSTL, and more.
From the spec:The focus of J2EE 5.0 is ease of development. To simplify the development process for programmers just starting with J2EE, or developing small to medium applications, we've made extensive use of Java language annotations that were introduced by J2SE 5.0. Annotations reduce or eliminate the need to deal with J2EE deployment descriptors in many cases. Even large applications can benefit from the simplifications provided by annotations. As expected, the EC passed it unanimously, with IBM still making the usual comments about licensing they've included on all JSR votes in the last 6 months:IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model. The specific API's mandated for Java EE 5 are:
Enterprise JavaBeans (EJB) 3.0
Servlet 2.4
JavaServer Pages (JSP) 2.1
Java Message Service (JMS) 1.1
Java Transaction API (JTA) 1.0
JavaMail 1.3
JavaBeans Activation Framework 1.1
J2EE Connector Architecture 1.5
Web Services for J2EE 1.1
Java API for XML-based RPC (JAX-RPC) 1.1
Java API for XML Web Services (JAX-WS) 2.0
Java Architecture for XML Binding (JAXB) 2.0
SOAP with Attachments API for Java (SAAJ) 1.3
Java API for XML Registries (JAXR) 1.0
Java 2 Platform, Enterprise Edition Management API 1.0
Java 2 Platform, Enterprise Edition Deployment API 1.1
Java Authorization Service Provider Contract for Containers 1.0
Debugging Support for Other Languages (JSR-45)
Standard Tag Library for JavaServer Pages (JSTL) 1.1
Web Services Metadata for the Java Platform 1.0
JavaServer Faces 1.2 Requirements
Common Annotations for the Java Platform 1.0
Streaming API for XML (StAX) 1.0
Java Persistence API 1.0
The spec does not mention JSR 223 scripting integration, Service Data Objects, or the Work Manager API.
|
|
|
Message #181050
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can't wait
Awesome!! Can't wait, just finished reading EJB 3.0 spec. It definitely seems to be a much easier and elegant approach to developing enterprise apps!
|
|
|
Message #181053
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can't wait
"J2EE" Connector Architecture
Web Services for "J2EE "
"Java 2 Platform, Enterprise Edition"
"Java 2 Platform, Enterprise Edition "
So "J2EE" , "Java 2 platform" are official terms still used under Java EE . I thought theres no more "Java 2".
i think i am going to have to a tough time in near future, explaining to recruiting managers which edition / version of java i have worked on.
Regards
Surajeet
|
|
|
Message #181056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can't wait
"J2EE" Connector Architecture Web Services for "J2EE ""Java 2 Platform, Enterprise Edition" "Java 2 Platform, Enterprise Edition "So "J2EE" , "Java 2 platform" are official terms still used under Java EE . I thought theres no more "Java 2".
Not all of the component JSR's that make up Java EE have been renamed, but they probably will be after Sun people read your post. :)
|
|
|
Message #181059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java EE 5 passes public review ballot
What's "Java Persistence API 1.0"? Its the "persistence" part of the EJB3 spec (CMP).
Java Message Service (JMS) still in 1.1 ? Aren't there lots of desirable things that the current spec does not define ?
|
|
|
Message #181074
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RoR is better than JSF, Spring is better than EJB...
this is not news. Most anything is better. Has that changed?
I think groovy, ibatis and jdnc are best parts of Java.
.V
|
|
|
Message #181081
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java EE 5 passes public review ballot
What's "Java Persistence API 1.0"?
Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own.
|
|
|
Message #181098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java EE 5 passes public review ballot
Seems there is nothing in Java EE 5.0 so far to cure the monolithic server syndrom used to exist in J2EE. The Java EE 5.0 servers will even become more bloated (with new APIs such as JSF and JPA 1.0 etc becoming mandatory).
To save Java EE, server side "plug and play" needs to be intoduced into the spec so that Java EE 5.0 servers will no longer be required to implement every single API in the spec (only the core APIs). The problem with this approach is that it will generate less license fee for Sun, or no license fee at all?
|
|
|
Message #181102
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Business Integration and Rule Engine
Why Java Business Integration is not added to Java EE 5? How about JSR94 (Rule Engine)?
|
|
|
Message #181125
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java EE 5 passes public review ballot
A Persistence API that works only with RDBMS databases. Should not Java be portable? <<<Another lockin>>>
|
|
|
Message #181129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Should not Java be portable?"
No.
which project you developped had as a requirement that it should be portable?
|
|
|
Message #181131
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java EE 5 passes public review ballot
Seems there is nothing in Java EE 5.0 so far to cure the monolithic server syndrom used to exist in J2EE. The Java EE 5.0 servers will even become more bloated (with new APIs such as JSF and JPA 1.0 etc becoming mandatory). To save Java EE, server side "plug and play" needs to be intoduced into the spec so that Java EE 5.0 servers will no longer be required to implement every single API in the spec (only the core APIs). The problem with this approach is that it will generate less license fee for Sun, or no license fee at all? Removing these files will just save you a few megs of HDD space. A few megs of appserver install won't make much difference to anyone. Besides, I like the fact that any certified app server will support all the APIs I need.
|
|
|
Message #181137
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Should not Java be portable?"
No. which project you developped had as a requirement that it should be portable?
I have an example. I have been working on programs that perform mathematical analysis for various scientific data. It would be very useful to have those programs able to the persist results of their analyses to a variety of stores, depending on the requirements of the users. These could include tables in a relational database, XML files, CSV files etc.
Fortunately I can use JDO for this.
|
|
|
Message #181138
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Fortunately I can use JDO for this.
Now u can use new java persistence API for the same.
|
|
|
Message #181139
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What's "Java Persistence API 1.0"?
What's "Java Persistence API 1.0"? Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own.
So that it could work without application server, even in standalone applications.
It has its own package javax.persistence
|
|
|
Message #181142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why so many persistence mechanisms
We alredy have JDO, Entity beans, Hibernate, Coherence etc. So,what's the need for persistence api. what's that going to add?. I think it will make tougher to decide between these and you finally endup choosing DAO.
|
|
|
Message #181148
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why so many persistence mechanisms
We alredy have JDO, Entity beans, Hibernate, Coherence etc. So,what's the need for persistence api. what's that going to add?. I think it will make tougher to decide between these and you finally endup choosing DAO.
There's lots of different persistence technologies in Java because there's no such thing as the "perfect choice" for all applications.
DAOs are another matter - that is an architectural/best practice decision - DAOs can and should be used with any of the APIs (JDO, JDBC, EJB 3.0 persistence, etc).
If fact, using DAOs mean that you can switch the underlying persistence API/technology without affecting the rest of the application.
PJ Murray
CodeFutures Software
Code Generation for Java Persistence
|
|
|
Message #181155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 pojo persistence
Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own. Maybe because it is not so coupled anymore with application server. Now we can unit test entity bean outside of container, or effectively us it in desktop applications. That's nice.
|
|
|
Message #181156
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
couldn't agree more
A Persistence API that works only with RDBMS databases. Should not Java be portable? <<<Another lockin>>>
Guess they've gazed a bit too long at Hibernate instead of folllowing the broader, independent path JDO shows us. (JDO being DS indept e.g.)
No matter, as soon as even more JDO implementations start supporting Object DBs, XML (to FileSystem) etc, (aside from RDBMS) the market will understand even more its value (having one API for all this!) and decide once again, like they have this time. (already now Spring & JDO are a killer combo)
Then you'll see Sun come with new promises for EJB X.0 again "that will solve all those issues". Yeah Right. :-)
|
|
|
Message #181160
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Fortunately I can use JDO for this. Now u can use new java persistence API for the same.
I don't believe I can. JDO was designed to allow persistence to both relational and non-relational stores. EJB 3.0 is designed for relational systems only. If I am wrong about this, and JDO/EJB 3.0 convergence now means that EJB 3.0 is more general-purpose I would be very interested!
|
|
|
Message #181177
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Give me serverside anyday
POJO + Annotations = EJB (I like it)
JSP + JSF = ??? (Mangled presentation layer)
|
|
|
Message #181188
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
If I am wrong about this, and JDO/EJB 3.0 convergence now means that EJB 3.0 is more general-purpose I would be very interested!
I'm interested in knowing more about this too.
I don't know a lot about JDO, so maybe my question will seem off the wall, but here goes. Would it be possible for a JDO implementation to support EJB3 spec? I understand that a big part of what people think of JDO are the user facing API's, but if there is a JDO implementation out there that has very flexible back-end persistance options it seems that they could gain more marketshare by supporting java.persistance.* too.
I think that Patrick Linskey from SolarMetric is on the EJB3 group? It would be interesting to heard form him on this.
Patrick, are you there? Any thoughts on this?
|
|
|
Message #181211
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
I'm interested in knowing more about this too.I don't know a lot about JDO, so maybe my question will seem off the wall, but here goes. Would it be possible for a JDO implementation to support EJB3 spec?
My understanding is that almost all current JDO implementations are going to do exactly this, as the specifications are pretty close in many ways. You will be able to use JDO 2.0 and EJB 3.0 at the same time on the same objects in the same application.
My particular interest is as to whether EJB 3.0 alone can be used to persist to more than relational stores.
|
|
|
Message #181249
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 pojo persistence
Look like "EJB3 pojo persistence" has been removed from EJB 3.0 to a separate API of its own. Maybe because it is not so coupled anymore with application server. Now we can unit test entity bean outside of container, or effectively us it in desktop applications. That's nice.
That has always been the case for "EJB3 pojo persistence".
What's new here is a renaming of "EJB3 pojo persistence" to "Java Persistence API 1.0" or "JPA 1.0", is it not?
|
|
|
Message #181251
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 pojo persistence
The problem is that "EJB 3.0 pojo persistence" has been sold for long to the developer community (a comminity initially opposed the PoJo persistence spec being part of EJB 3.0),
even the Java EE 5.0 committee will have to revert the name from "Java Persistence API 1.0" (or JPA 1.0) to "EJB 3.0 PoJo 1.0". :-)
|
|
|
Message #181561
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
My particular interest is as to whether EJB 3.0 alone can be used to persist to more than relational stores. Any data access or connectivity API including JDBC or ODBC can be used as adapter or bridge (there is ODBC adapter implemented on top of EJB itself to integrate EJB with VB). I think EJB is designed for RDBMS in the same way as JDO is designed for OODBMS.
|
|
|
Message #181577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
My particular interest is as to whether EJB 3.0 alone can be used to persist to more than relational stores. Any data access or connectivity API including JDBC or ODBC can be used as adapter or bridge (there is ODBC adapter implemented on top of EJB itself to integrate EJB with VB). I think EJB is designed for RDBMS in the same way as JDO is designed for OODBMS.
JDO is not designed for OODBMS. I don't know where you picked up that piece of misinformation. JDO is store neutral. It works equally well with OODBMS, RDBMS and other forms of persistence. The main use of JDO today is with relational stores.
|
|
|
Message #181657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Both JDO and EJB are store neutral in the same way as JDBC or any data access API. I can paste link to JDBC implementations for OODBMS too, but I am sure you know it yourself. So JDBC is designed for OODBMS in the same way as JDO is designed for RDBMS.
|
|
|
Message #181785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Both JDO and EJB are store neutral in the same way as JDBC or any data access API.
No. To quote from the JCP website:
"JDBC is a Java API for executing SQL statements"
Hardly store neutral!
I can paste link to JDBC implementations for OODBMS too, but I am sure you know it yourself.
Please post such links - I would be interested. They don't mean that JDBC was designed for this - they only mean that an OODBMs may allow some small subset of SQL to work.
So JDBC is designed for OODBMS in the same way as JDO is designed for RDBMS.
No, because JDBC is basically a pass-through API for executing SQL and handling the results. This is fundamentally different from JDO, which allows a guaranteed full and rich API and query language on a range of stores, even (if the implementation provides is) CSV files and XML stores. But of course, I'm sure you already know this as we have covered this in detail in other threads.
|
|
|
Message #181817
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
SQL is store neutral, it is just a query language.
It is, of course, not neutral. From wikipedia:
"SQL is the most popular computer language used to create, modify and retrieve data from relational database management systems"
BTW this is a link to FAQhttp://www.versant.com/resources/faqs/faq_vsql.html
Sorry, but this isn't SQL. It is a language that provides an SQL-like dialect.
I do hope you aren't going to try and argue that we should all use some hypothetical 'portable SQL' as a universal way of accessing all data stores...
|
|
|
Message #181824
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Probably some vendors fail to implement SQL and probably same vendors fail to implement JDO too, but Versant claims "The version of standard it support is SQL/92" (I think SQL 92 is not so bad too) and this fact doe's not make SQL or JDO not portable.
JDOQL is based on object model. Using your analogy JDOQL is OODBMS specific, but as we all know JDOQL is store neutral. SQL is not RDBMS specific too, it is just based on relational model in the same way as JDOQL is based on object model.
|
|
|
Message #181826
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Probably some vendors fail to implement SQL and probably same vendors fail to implement JDO too,
No. If they fail to implement JDO, it's not JDO. This is not a comparable situation to SQL, where a huge range of incompatible languages call themselves 'SQL'.
We have already discussed this in detail in previous threads.
SQL is not RDBMS specific too, it is just based on relational model in the same way as JDOQL is based on object model.
JDOQL is not based on an object model. It is simply a querying language that has a Java-like syntax.
|
|
|
Message #181827
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Why it is unsuitable for less structured stores ? Just less structured stores are unsuitable for data.
|
|
|
Message #181871
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Why it is unsuitable for less structured stores ? Just less structured stores are unsuitable for data. Better tell CERN that. They use relatively unstructured OODBs to handle petabytes of data.
|
|
|
Message #182014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
Why it is unsuitable for less structured stores ? Just less structured stores are unsuitable for data. Better tell CERN that. They use relatively unstructured OODBs to handle petabytes of data.
CERN can find the best database without my help.
BTW Aree they going to use JDO to port this stuff to RDBMS ?
|
|
|
Message #182761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should not Java be portable?
It was a joke, but it looks like CERN realy has this dealema:"Faced with such a dilemma, the inescapable conclusion is that we need to build a system ourselves"http://wwwasd.web.cern.ch/wwwasd/rd45/presentations/ecoop99/ecoop-paper.htmlIt was interesting to read how CERN uses OODBMS technology, thanks.
The point of mentioning CERN was to illustrate that relational databases are not a universally appropriate way to handle data, and are not required to guarantee data integrity.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
