Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2577 posts at DZone. You can read more from them at their website. View Full User Profile

Your Chance to Shape Java EE 7

11.09.2012
| 9840 views |
  • submit to reddit

For those of you who are still in the Java EE camp, the work on JEE 7 (under JSR 342) is progressing nicely and it recently entered early draft stage. 

You can dig deep into the spec here if you like. 

It's reached the stage where the community now has an opportunity to provide feedback, so a good friend of DZone, Reza Rahman, brought this to our attention and we thought it was important to get as many Javalobby community members involved as possible. 

There are now a number of important open issues that the Java EE expert group would like to get broad community feeback on. These issues include what new JSRs to add to the Java EE Full/Web Profile as well as how to better align CDI with Java EE.   --Reza Rahman


Now's your chance to help shape the future of Java.

Java EE 7 Feedback Survey


Comments

Reza Rahman replied on Fri, 2012/11/09 - 5:03pm

Thanks so much for posting this. For folks out there, also feel free to discuss anything you feel is important for Java EE here. I'll try and pass it to the EG.

Jonathan Fisher replied on Fri, 2012/11/09 - 8:44pm in response to: Reza Rahman

Drop The following: CORBA, remote/home interfaces, RMI/RMI registries, JMS 1.0, EJB < 3.1, "Remote" and "RemoteException", older JavaMail APIs.

Redefine remote EJBs to mean "Fast, Binary, network webserices" 

Make @ApplicationException default

Drop local EJBs. Just use CDI instead.

Add JMX2.0, JMS2.0

Add standard for scaling out an EJB (aka webservices) across a bunch of clusters automatically. So as capacity becomes short, a server could expand and create more EJB servers to handle the load transparently.

Screw RMI, come up with a binary, better, faster protocol that doesn't involve damned RMI registries and complex port configuration.

The big thing is, DROP THE OLDER CRUFTY APIs! 

Reza Rahman replied on Fri, 2012/11/09 - 10:15pm in response to: Jonathan Fisher

Good points, things to know/consider/look into:

* The EJB 3.2 EG is considering dropping EJB 2.x and CORBA

* JTA now enables declarative transactions in CDI managed beans with a modernized set of annotations - more CDI alignment likely to come in Java EE 8

* Folks are encouraged to use the new simplified JMS 2 API as opposed to JMS 1.x

* WebSocket based remoting over HTTP is now possible for EJBs

Grzegorz Grzybek replied on Mon, 2012/11/12 - 2:31am

I think JavaEE should change from religious/political creature into set of modern frameworks and libraries. CDI became the key concept of JavaEE and every other specification should be made CDI extension. Of course there's much legacy in JavaEE - mainly in the areas where "the details are application server-specific" - it is most visible in the field of security.

JavaEE should put more emphasis on what is and rather should be provided by application server, i.e., what influences the programming model - CDI, EJB, JTA, Servlets. On the other side more specification should be freed from application server - JavaMail, Bean Validation, WebServices, XML processing - these are just libraries. What's the point in telling people that these (especially JavaMail, or in smaller degree BeanValidation) specification let the user choose freely from available implementations, when there is only one widely-used implementation? (JavaMail: com.sun.mail, I don't count Geronimo's mail impl which throws NPEs, BeanValidation: HibernateValidator).

And last point: all specs (API) JARs should be put into Maven Central the same second the spec becomes FR! Maybe spec leaders think that when spec is released, the work is over - no! I hate it when I have to choose from <code>javax.servlet</code>, <code>org.jboss.javax.servlet</code>, <code>org.glassfish.javax.servlet</code>, <code>org.eclipse.jetty.javax.servlet</code>, etc...

regards

Grzegorz Grzybek

Jonathan Fisher replied on Mon, 2012/11/12 - 10:51am in response to: Grzegorz Grzybek

@Grzegorz Grzybek

Now that we have CDI, I could agree more with what Grzegorz Grzybek said. _Everything_ should be based on CDI extensions. It's a brilliant plan. 

Sun never wanted to break backwards compatibility, but honestly, the community is ready for a clean slate. Do you know why JEE is complicated? Because theres about 100x ways to do something with older unsupported APIs.

So what about companies that already have existing legacy applications in J2EE/JEE? Simple: Don't friggen upgrade to 'J3EE'.

I hope Oracle gains the fortitude to wipe the slate clean... we don't need the old crufty APIs around forever, and the sooner the design starts for the new stuff, the less ground Java will continue to lose.

Reza Rahman replied on Mon, 2012/11/12 - 10:55am in response to: Grzegorz Grzybek

You describe youself as "Seniorish Java Developer and Spring enthusiast" and "SpringSource Certified Spring Professional". I think a natural question to ask is whether these are really issues with Java EE or mostly a critique from a heavily Spring centric perspective?

Can you make the case of why every API should be a CDI extension? Isn't that an implementation detail not that relevant to users?

On security, the thought has been that JAAS/Java Security provides what portability can be practically possible given the divergence in vendor security implementations and the extensive need to integrate with non-standard/non-Java EE technologies. Beyond that, folks are free to use CDI portable extensions like Seam Security. Also, beyond security, can you be more specific about what other areas you want more standardization?

Of the three APIs you mentioned -- JavaMail, Bean Validation, WebServices, XML processing -- only JAX-WS does not define use outside of EE (but you can still do it using things like Apache CXF). What other specs should be usable outside EE that are currently not? Why?

The fact is that the vast majority of Java EE APIs have at least two major implementations -- JavaMail and Bean Validation are exceptions by and large. If there is a need for more/better implementations of these, there certainly is little barring that to happen.

No standard (not just Java EE) can get bound to something as implementation/technology specific as a Maven repository. Nonetheless, almost all Java EE implementations including GlassFish makes APIs available via Maven.

 


 

Reza Rahman replied on Mon, 2012/11/12 - 11:03am in response to: Jonathan Fisher

Other than RMI, CORBA and EJB 2.x as a whole (which I said might already be deprecated), can you be more specific about what other APIs/features you would like deprecated and why?

It is true Java EE pays a lot of attention to backwards compatibility (because customers often ask for it). However, a specific pruning process was adopted in Java EE 6 in order to remove old APIs in a systematic way. Things that have already been pruned following that process include EJB 2 CMP, JAXR, JAX-RPC and the like.

Jonathan Fisher replied on Mon, 2012/11/12 - 12:32pm

I come from a J2EE background, but I'm proficient with both JEE and Spring. 

Basing everything off of CDI makes a lot of sense. The creators of CDI accidentally-on-purpose created a great foundation. Instead of a JEE server, we essentially would have CDI servers. This would really bring some much needed unity to the JEE platform. We'd likely see a huge simplification  memory decrease, and performance increase form basing everything on the CDI platform.

The problem isn't deprecation btw, the problem is _removal_. See my previous list, things like RemoteException, Remote (interface), the concept of Home/Business interfaces, etc are all crufty crap that needs to be disposed of. Even the beloved JSF2.0 (also an awesome framework)  carries a lot of dead weight.

I know Oracle's paying customers (banks, investment firms, credit card processors, etc) want to keep that stuff around, but the fact is, hardly anyone in the startup world is using Java, much less JEE (Some are using the JVM, but not JEE). If Oracle wants to secure Java's future, they really need to have JEE legacy edition, and create a more trendy JEENext, based on the lessons learned over the years.

Not all the APIs are horrendous... JPA/JMS2.0 are both brilliantly thought out. JAX-RS isn't terrible, but the interceptor API should have been based on CDI.

I think a ton of community support would appear if Oracle was to kick a JEENext specification off, where they started with essentially a clean slate.

Reza Rahman replied on Mon, 2012/11/12 - 1:23pm in response to: Jonathan Fisher

The goal of the pruning process is complete removal, not merely deprecation.

As mentioned, CDI alignment is a major issue being slated for both Java EE 7 and Java EE 8. It is a leap however to say everything should be CDI. Now, there is a Java EE 8 discussion around greater modularity at the API level (CDI notwithstanding), just as GlassFish allows for incremental server/API upgrades, etc via OSGi today. Even for that discussion, it's not clear what APIs beyond what's actually already usable ourside of Java EE needs to be addressed and why. More specifics there would certainly be useful.

Henk De Boer replied on Mon, 2012/11/12 - 3:36pm

Some good points are raised. 

Letting everything -be- a CDI extension is a bit extreme for my taste, but I do think CDI could become a foundational technology that most if not all other specs can leverage. The question about @Injection in the survey hints at this direction already.

JSF 2.2 is already biting the bullet and will depend on CDI for several of its new features (e.g. flow scope) and will furthermore support CDI explicitly (CDI compatible @ViewScoped). The spec lead Ed Burns has indicated JSF's native managed beans will eventually be deprecated.

What I currently see is that some other spec leads are, how shall I put this, "afraid" of CDI. The problem for them is that they all also want their specs to be used outside Java EE, and are somehow afraid that if they leverage CDI they can't do that anymore. But doesn't CDI itself runs perfectly well outside Java EE? It only means that in order to run those specs outside Java EE users will have to add one extra jar to their projects. Is this so bad?

Btw, would a Java EE Core Profile be an idea? A very simple profile which contains all foundational technology, e.g. Servlet (but not JSP), CDI and maybe JCache?

On security, the thought has been that JAAS/Java Security provides what portability can be practically possible given the divergence in vendor security implementations 

JAAS itself is clearly not enough for Java EE. JASPIC comes really close, but it doesn't seem to get the attention it should get (see Implementing container authentication in Java EE with JASPIC).

Reza, you say on the Caucho wiki that JASPIC is bloated. This is a bit troubling to me. Normally all bloated APIs are the old pre-Java EE 5 ones, but JASPIC was a new one in Java EE 6.
Can you explain why you think JASPIC is bloated?

Henk De Boer replied on Mon, 2012/11/12 - 3:25pm in response to: Jonathan Fisher

I think a ton of community support would appear if Oracle was to kick a JEENext specification off, where they started with essentially a clean slate.


I would really like to see that as well. In fact, I've arguing for this exact same thing.
The Java EE 6 Web Profile is a bit like this, but it also has the (in this context) unfortunate requirement that it should also be a small profile.


A Java EE Next Profile (Legacy Free Profile, Cruft Free Profile, etc, etc), would be like the Java EE full profile, but with things like Corba, EJB 2 component interfaces, JAX-RPC, The now legacy JMS 1.0 methods for which there are 2.0 replacements, all things that are marked deprecated in JSF (like the old expression classes from before the unified EL, JSP support, the native managed bean facility, etc), etc.


The Web Profile has pioneered this a bit. Apart from excluding whole specs (like JMS), it also introduced the idea of selectively removing things from a single spec (EJB lite). The "problem" again with the Web Profile is that it didn't just remove the legacy stuff, but also the modern useful stuff (like @Asynchronous in EJB, and JAX-RS).


Now in Java EE 7 things do become a little confusing, since the web profile will in fact get @Asyncronous and JAX-RS. It looks like an ongoing struggle between having a small profile and a "next/legacy free" profile.

Reza Rahman replied on Mon, 2012/11/12 - 4:41pm in response to: Henk De Boer

As usual, thanks for bringing a bit more rationality into this discussion. It's in fact true that some spec leads have not been entirely supportive of CDI. As you can see from the survey though, that issue is being addressed sooner rather than later.

As to the Java EE "core profile", it was extensively discussed and tabled as a bad idea in the early Java EE 6 timeframe. The issue is that it goes too far from the Java SE/Java EE concept of a unified, deteministic platform/runtime (as opposed to just a C/C++ style collection of libraries cobbled together) and runs the danger of fragmentation/lack of compatibility.

As to JASPIC, it is not needed for things like Resin that have no need to plug in security providers into other application servers or have other providers being plugged into it (remember, JASPIC is largely a security provider SPI, not a developer centric API). Indeed, you'll find few security providers out there utilizing JASPIC. Concrete proposals for Java Security enhancents are of course welcome, as long as we understand that defining integration points for database, LDAP, OpenID, SAML...infinite/ever-evolving list of providers is not really practical for any standard. That's more suitable for something like the Resin Security Framework, WLS Security or Seam Security.

P.S.: I no longer contribute to Resin as an independent but am now an actual official Java EE/GlassFish evangelist and Oracle employee. More here: http://blog.rahmannet.net.

Reza Rahman replied on Mon, 2012/11/12 - 4:37pm in response to: Henk De Boer

From this, what I can garner is to start the pruning/deprecation process for the JMS 1.x API now (that was not under discussion this time around). I'll definitely pass on the feedback.

Do keep in mind, backwards compatibility is a big deal for any software as pervasive as Java (even the Spring folks get that). We simply cannot afford to have things break from one version to the other on upgrade without a lengthy warning period. That being said, pruning is a priority and is being actively done. What's helpful are actual specifics of what we feel should be pruned and why.

Serge Boulay replied on Mon, 2012/11/12 - 5:25pm in response to: Reza Rahman


"JTA now enables declarative transactions in CDI managed beans with a modernized set of annotations - more CDI alignment likely to come in Java EE 8"

Reza,

I really like the idea of this feature although I wonder if this means the death of EJB (which is not a bad thing) ? On a different note, is there anything in the way of an MVC controller type framework on the horizon. I know that JAX-RS 2.0 was considering it ?

Henk De Boer replied on Mon, 2012/11/12 - 5:35pm in response to: Reza Rahman

As you can see from the survey though, that issue is being addressed sooner rather than later.


Indeed. After some further digging, I noticed that Ron Monzillo from the Identity API JSR (not for Java EE 7 I think), was also looking into leveraging CDI. So that are already two specs. Things are definitely moving.


remember, JASPIC is largely a security provider SPI, not a developer centric API

You are right there, and this is maybe a shame. Either JASPIC itself should perhaps facilitate developers, or some extra puzzle piece should be added that does.

A recurring theme in Java EE was that it doesn't gather so much for the kind of applications that need or want to take certain matters into their own hands, like data sources, security etc. Java EE started addressing those use-cases as well via the @DatasourceDefinition annotation, and Java EE 7 expands on that (e.g. via similar annotations for JMS destinations). I think security could be part of this as well.

JASPIC or any other standard wouldn't need to specify LDAP, OpenID etc modules itself, but would just need to provide a way to tell the container that authentication happened and what the resulting roles are. JASPIC in fact does do that, although in a way that's not entirely aimed at developers.

I have (a little bit of) experience with creating Tomcat and JBoss login modules, and I must say that the interfaces that need to be implemented are quite similar to what must be done for JASPIC.

If servers all started using JASPIC as their native interface to build login modules for, then I guess they could still use their own security framework to actually implement those login modules (called btw SAMs in JASPIC terminology; server authentication modules). Those login modules (e.g for LDAP, OpenID, etc) would then maybe not be directly portable, but developers would be sure that the JASPIC interfaces/SPI provided by the servers are available and stable.

JAVAEE_SPEC-9 is very much related to this discussion.

P.S.: I no longer contribute to Resin as an independent but am now an actual official Java EE/GlassFish evangelist and Oracle employee

Nice to know. I somehow missed that ;)


Reza Rahman replied on Mon, 2012/11/12 - 5:48pm in response to: Serge Boulay

Clearly, we are indeed moving away from the EJB component model to CDI. The JTA interceptors are just one step in that direction, amongst others.

The JAX-RS MVC framework was tabled for now because of timeline concerns. It can be picked back up in Java EE 8 if there is sufficient interest in the community.


 

Henk De Boer replied on Mon, 2012/11/12 - 5:51pm in response to: Serge Boulay

I really like the idea of this feature although I wonder if this means the death of EJB (which is not a bad thing) ?

In a way, but not entirely. The services offered by EJB will then live on, but will be expressed as a set of CDI annotations. The subtlety is perhaps about what you exactly call "EJB"; its services or its specific component model?

On a different note, is there anything in the way of an MVC controller type framework on the horizon. I know that JAX-RS 2.0 was considering it?

I remember this being considered, but at least during Devoxx last year it was said this was postponed to be considered later. A problem with such a framework is that Java EE already has a MVC web framework. It's called JSF.

Having two MVC web frameworks would IMHO be highly confusing. I know it's popular to bash JSF, but it's actually quite a good framework these days. I wonder if some of this bashing isn't just coming from the people behind the other frameworks (like Wicket and Spring MVC). If JSF's main problem is that it's being blackened by its competitors, why would a new web framework from Oracle/Java EE not receive the same treatment?

Instead of having two competing MVC web frameworks within Java EE, it's probably better to give JSF more "action/request"-based properties, for those use-cases that need this. In fact, this is already happening a bit. JSF 2.2's view action is an example of this direction, and the issue about a stateless mode is the most popular one now at the spec Jira. See JAVASERVERFACES_SPEC_PUBLIC-1055.

Corey Puffalt replied on Tue, 2012/11/13 - 12:19am

Reza,

I'm surprised with your stance on Security in JEE.  I suppose your attitude explains the current situation though.  I take it then that all the spec leads consider the status quo with respect to security is acceptable?

Honestly, today I find Security in JEE the weakest link.  As Henk pointed out if we had a straightforward way to register an authenticated Id and associated roles with the container in a standard way without having to muck about with any vendor-specific configuration in order to do so it would immediately make many, MANY developers very happy.  

Stop worrying about standardizing LDAP, DB, OpenID, SAML etc.  Just give developers an API that allows us to plug in our own authentication scheme and register it with the container (without having to resort to container-specific configs).  As we saw with CDI extensions -- if a proper API is developed, others will innovate on top of it. 

My 2 cents.

Corey

PS: Please deprecate the non-CDI Inject-like annotations that just cause all developers confusion.

Grzegorz Grzybek replied on Tue, 2012/11/13 - 4:38am in response to: Reza Rahman

@Reza
You describe youself as "Seniorish Java Developer and Spring enthusiast" and "SpringSource Certified Spring Professional". I think a natural question to ask is whether these are really issues with Java EE or mostly a critique from a heavily Spring centric perspective?
[...]
I no longer contribute to Resin as an independent but am now an actual official Java EE/GlassFish evangelist and Oracle employee.

So you read my profile on StackOverflow. So you should also be aware of number of questions asked under different tags (such as "spring", "java-ee", "cdi", ...). I haven't mentioned "spring" in my comment at all, so I hope we'll continue substantial discussion. You on the other hand work for Oracle, so we also should be aware of your background :)

Can you make the case of why every API should be a CDI extension? Isn't that an implementation detail not that relevant to users?
[...]
Clearly, we are indeed moving away from the EJB component model to CDI

You're right - it is an implementation detail, but a very important one.

I've mentioned CDI, because I thing it's very well designed API and model containing DI, Event Dispatching and Interceptors with great SPI.

My hint for JavaEE is (that's the point of this post - I have a chance to shape the future, so I'm trying :)) - move the emphasis from application servers to the programming models. CDI is great programming model and application servers are just a platforms for running your applications. More facts? OK, here they are:

  • When J2EE was created, it was designed to: 1) give users crappy API, 2) allow application server vendors to make big money on areas not covered by specs.
  • Users were given EJB as a programming model with "free" API and a vision of implementation independence. Behind a free sample there were real bucks paid for such things as clustering, HA, object pooling (!), monitoring, security, etc.
  • Users had (and with security still have) primitive "isUserInRole()" and have to click out every security detail on e.g. WebSphere's /ibm/console (usually also they had to hunt for strange env entries or write JAAS modules and put them into WebSphere's ext directory)
  • Of course the times of J2EE are long gone
  • Really? I, for example, still have to work with J2EE 1.4 on WebSphere 6. It's running Spring 3.1.3 by the way...

I'm opting for CDI as a key point of JavaEE and for CDI extensions - we have to realize that programming model, ease of deployment, testing and ease of maintenance are the most important things for developers! Here is comment from @Jonathan Fisher:

The creators of CDI accidentally-on-purpose created a great foundation. Instead of a JEE server, we essentially would have CDI servers. This would really bring some much needed unity to the JEE platform. We'd likely see a huge simplification memory decrease, and performance increase form basing everything on the CDI platform.

and @Henk De Boer:

What I currently see is that some other spec leads are, how shall I put this, "afraid" of CDI. The problem for them is that they all also want their specs to be used outside Java EE, and are somehow afraid that if they leverage CDI they can't do that anymore.

I fully agree with these. I'm allergic to all recent and earlier posts about how Glassfish is great so JavaEE is great - when I hear "application server" I automatically think "WebSphere". WebSphere has great features for managing cell of nodes, clusters and servers, but this administration aspect has nothing to do with JavaEE! I think CDI is both great for developers and bad for Oracle

If Oracle (and IBM) confirms that all developers need is CDI server and that all these features the users paid big buck 10 years ago (such as clustering) may be realized with array of Tomcats + Terracota cluster below and load balancer above, then what's the point of expensive application servers?

I think we have a conflict of interests. CDI promises unification and simplicity and it's not a secret that the best things in life are free. So what's the point of application servers?

I'm not using JSF, JAX-RS, EJB in my day-to-day work. I use Spring, because it gives me what I need - a unified programming model when everything is Spring Bean (pojo). There are no different web beans, transactional beans and pojo beans. There are just beans, proxies and interceptors (aspects)...

I think that Oracle/IBM is afraid that when JavaEE will equal to CDI + extensions, the money stream will dry...

@Reza - about security

[...] given the divergence in vendor security implementations and the extensive need to integrate with non-standard/non-Java EE technologies [...]

Hmm, what do you mean by "extensive need to integrate"? Put a common-denominator kind of API above? Really? Spring has a tradition of creating templates (it has deprecated HibernateTemplate few years ago) but it's not an art for art's sake. Spring has spring-ldap, spring-social (OAuth), spring-security-kerberos - they're just another libraries

Of the three APIs you mentioned -- JavaMail, Bean Validation, WebServices, XML processing -- only JAX-WS does not define use outside of EE (but you can still do it using things like Apache CXF). What other specs should be usable outside EE that are currently not? Why?

You know what? It really doesn't matter. I treat app servers as containers which have such features as: deployment of WAR/EAR packages, monitoring, definition JVM-wide datasources (rarely other resources, such as JMS objects) and listening for HTTP traffic and dispatching requests to servlets. I've used almost everything JavaEE contains except JASPIC and JSR77/88, I always need a container - at least for servlets.

and finally @Reza - about Maven:
No standard (not just Java EE) can get bound to something as implementation/technology specific as a Maven repository. Nonetheless, almost all Java EE implementations including GlassFish makes APIs available via Maven.

Of course - JavaEE PDFs shouldn't mention Maven repos, Gradle builds or Ivy dependencies, but when finally API JARs are created, they should be put somewhere - not in messy CVS repositories of java.net.

So what JavaEE 7 needs?

I think it's not JSON or Batch processing, or even web sockets - these are provided successfully by existing technologies/servers. JavaEE needs mental shift from Ivory Tower defending the garden of application server vendors to open community working on making simple but powerful programming models.

What areas I'd like to be improved?

  • Packaging - JARs, WARs, EARs, xARs. The weakest point is ... META-INF/Manifest.MF - how long there will be Manifest-Version: 1.0 ? Even external (to JavaEE) body as OSGi uses this file for the most important part - expressing dependencies between bundles. Please use the format that's both readable, processable and versionable - XML!
  • "bean" concept - I know it's better and better, but there are still differences between JSF beans, EJBs and CDI POJOs
  • Modularization - work with JavaSE team in this area - it covers packaging I've mentioned
  • Move to Github!

What's unimportant (but listed onhttp://java.net/projects/javaee-spec/pages/Home)? (read: available now elsewhere):

  • JSON - there's Codehaus' Jackson
  • WebSockets - Tomcat and Jetty supports it
  • Concurrency Utilites (they're in JavaSE, and what's the point of making TaskExecutor managed?
  • JCache - you won't unify everything though Oracle will try... We don't need common denominator approach in this area
  • Bean Validation - that's just a library, I'm using it successfully with SpringMVC
  • Batch
regards Grzegorz Grzybek

John Waterwood replied on Tue, 2012/11/13 - 8:11am in response to: Corey Puffalt

the way forward is to simplify Jaspic, add it to the web profile and mandate that it can be used without any server specific setup.

Reza Rahman replied on Tue, 2012/11/13 - 2:32pm in response to: Grzegorz Grzybek

We of course have heard these viewpoints from folks like SpringSource for many years. They continue to not resonate with the core Java EE community (myself included as a long time Java EE adopter). The goal of Java EE is not just to enable Tomcat and act as low-level infrastructure, but to provide developers a standards based runtime that frees them from vendor-lock-in/configuration headaches wherever possible. That's not going to change any time soon.

Now, as to you the more relevant items on your wish list:

* Modularity in Java EE will be addressed after it is addresed in Java SE (and the community largely voted for deferring modularity in Java SE).

* Managed bean alignment work started in Java EE 6. It continues today and will continue going forward.

If your tirade is really about a grossly outdated version of WebSphere, you should have the gumption of taking up your complaints where they really belong -- your technology managers and IBM. Oracle, GlassFish or Java EE 7 (the actual subject of the article) have little or nothing to do with it, so posting flame bait/conspiracy theories here is pointless and is best ignored.

The fact is that the Spring-centric sabre rattling/FUD just doesn't work anymore thanks to Java EE adopter driven efforts like this one.

Serge Boulay replied on Tue, 2012/11/13 - 10:44am in response to: Henk De Boer

"Having two MVC web frameworks would IMHO be highly confusing"

In theory yes, but in practice no. Think Springsource (Spring MVC, Grails, Roo), think Microsoft (Asp.net WebForms, Asp.net MVC, Asp.net WebPages). The idea here would be to enable a different programming model. JSF offers a component based approach but I still think that we could benefit from an action based controller type framework that can integrate with the latest client side technologies. It does not have to be JAX-RS, maybe we could do something with Servlet 3.X ?

Reza Rahman replied on Tue, 2012/11/13 - 10:45am in response to: John Waterwood

The truth is that this is much easier said than done. I've tried to come up a concrete proposal myself using Resin Security  as a basis. I couldn't go much further beyond what we already have before getting into way too much implementation specific muck. If you think you can do better, good for you and good for the community -- I'll even help you get it standardized if it's an even halfway thought out proposal.

I've already said why JASPIC is neither here nor there in the Web Profile.

Reza Rahman replied on Tue, 2012/11/13 - 10:58am in response to: Serge Boulay

This is exactly the thought process behind the JAX-RS proposal (that may indeed be better elsewhere). Not the "what .NET/Spring are doing" part but providing a more client-side technology friendly framework with a different progamming model.

The concerns Henk mentions are taken very seriously however (part of the reason the proposal was tabled for now).

John Waterwood replied on Tue, 2012/11/13 - 2:32pm in response to: Reza Rahman

Sorry for asking, but can you summarize again why you think Jaspic is not there yet in the web profile? If my simple app does authentication by loading a user with an entity manager from the DB, then I only need a way to tell the container about this. Jaspic is this way, but as the linked article from Arjan Tijms points out, it's a little complicated if you only want to registrate a single Sam from within an app. Plus you still need sun-web.xml. But these look like small problems, or am I missing something? . o.

Reza Rahman replied on Tue, 2012/11/13 - 3:57pm in response to: John Waterwood

It's certainly a good question.

The issue here is that for very lightweight implementations (like Resin for example) full-blown JASPIC is a bit overkill. Take a look at the Resin Security Framework for example. It already provides some pluggability via JAAS with which you could reasonably accomplish what you would be trying to do (not to mention the built-in database authenticator). To add yet another spec just adds to the implementation burdain and actually does not add much value to most Resin (for example) users. I happen to be a fan of the Resin Security framework. It's simple and powerful. In fact, even many people that run Spring on Resin opt for it instead of Spring (Acegi) Security...

Now, for a full scale application server like GlassFish, it's of course no big deal and it does indeed support JASPIC.

Grzegorz Grzybek replied on Wed, 2012/11/14 - 12:45am in response to: Reza Rahman

@Reza
The goal of Java EE is not just to enable Tomcat and act as low-level infrastructure, but to provide developers a standards based runtime that frees them from vendor-lock-in/configuration headaches wherever possible. That's not going to change any time soon.

It sounds great, but in practice you're repeating similar slogans as "spring fanboys" with J2EE... I also want to be freed from vendors, but both Spring gives me it (sorry, but Spring libraries, available from Maven and Github are just community driven libraries, not vendor products) and Vanila JavaEE. JavaEE APIs are the same creatures as Spring libs - they're rather available, but the difference is - you don't quite know what will change in the future. Deprecating JAX-RPC is maybe attractive, but imagine that there are many (many, many) existing services created in the dark ages of RPC/Encoded Web Services. There's still need to invoke and use them...

* Modularity in Java EE will be addressed after it is addresed in Java SE (and the community largely voted for deferring modularity in Java SE).

I know it's not the fault of JavaEE. Modularity is too important to release it broken. By the way - I think it goes to the right direction in JavaSE. I'm not very familiar with the current state of Jigsaw, but I think JBoss modules may be a good pattern. My private wish is to get rid of "endorsed" and "ext" classloaders. I just want to say "I'm using xerces 2.11.0" + Xalan in this WAR and Saxon in the other WAR on my JBoss 8"...

If your tirade is really about a grossly outdated version of WebSphere, you should have the gumption of taking up your complaints where they really belong -- your technology managers and IBM. Oracle, GlassFish or Java EE 7 (the actual subject of the article) have little or nothing to do with it, so posting flame bait/conspiracy theories here is pointless and is best ignored.

Like it or not, WebSphere 6 is part of JavaEE heritage (I'm explicitly not using the word legacy). Government and public institutions are still using it. Spring Framework (not 3.2, because it required Servlets 3.0 when I last tried) still works on this dinosaur.

The fact is that the Spring-centric sabre rattling/FUD just doesn't work anymore thanks to Java EE adopter driven efforts like this one.

Oh yeah? I thought (I've read it when these "efforts" were published, but I've checked twice) that these were just tutorials on Netbeans+JPA+JSF with embarrassing table counting lines in XML files (applicationContext-jpa.xml 111 lines? Common - that's ridiculous). Oh and there's this manifesto called "Java EE wins over Spring by Bill Burke" - this what you're thanking for?

regards Grzegorz Grzybek

Reza Rahman replied on Wed, 2012/11/14 - 10:19pm in response to: Grzegorz Grzybek

Spring is not an open standard, period. There is only one implementation of Spring that is heavily controlled By SpringSource -- a commercial, profit-driven software company. If you really think that does not equal vendor lock-in, you are fooling yourself. Let's say you come across a serious bug or performance issue that SpringSource won't fix (or SpringSource gets aquired again and stops developing Sping or Spring is no longer free, etc, etc). What's your options?

Java EE is almost too concentrated on backwards compatibility, so that's clearly not an issue. As you can see even on this thread, there are many folks who indeed wish us to be less backwards compatible than we are today.

As to modularity, I think you've answered yourself. If you need it today, most modern application servers already provide workable solutions. The broader community made it clear that it does not want it in either Java SE or Java EE (in fact, most of that discussion was around enterprise applications). SpringSource's own failures on it's OSGi efforts vividly demonstate that reality.

You're missing the point about WebSphere 6 vs. Java EE 7. If you have complaints on WebSphere, take it up where it belongs instead of trolling here. The Java EE 7 API (the topic of this discussion) has nothing to do with it how IBM chooses to write it's present or past implementations. Those are decisions determined solely by IBM and it's customers. It's a bit like saying Barack Obama must be responsible for every traffic violation since he is the President. It's just not a rational chain of thought. If you have an issue with WebSphere, you have the option to switch to something else. That's the point of standardization.

As to your remarks on the resources I pointed out, you're a bit too quick to readily dismiss opinions that don't stand well with you methinks :-). After all, if you're a sworn Republican, I'm sure things like universal healthcare doesn't sound good no matter what :-). Things like bloat, boilerplate and increased complexity have always been a big deal in computing...

The fact is that these are well thought out opinions largely from independents like Bert Ertman, Paul Backer, Adam Bien and yes, myself. The numerous custmers asking me to join their Java EE projects that I could barely keep up with as an independent, the full-house audiences that I speak to and GlassFish/JBoss adopters, many of whom post stories here: https://blogs.oracle.com/stories/, would disagree with you...

At any rate, if you wish to have that particular discussion, I suggest opening up a top level article instead of wasting time on this thread that no one is reading any more. Please do invite me to it. I'll be happy to point out what you are missing. It'll be good publicity for Java EE and it's always good to know what you Spring guys think your arguments are these days. You can even critique my own analysis: http://www.rahmannet.net/downloads/spring_javaee_comparison.pdf.

Grzegorz Grzybek replied on Thu, 2012/11/15 - 1:48am in response to: Reza Rahman

Spring is not an open standard, period. [...] Let's say you come across a serious bug or performance issue that SpringSource won't fix (or SpringSource gets aquired again and stops developing Sping or Spring is no longer free, etc, etc). What's your options?

I (community) will do the same, what happened to OpenOffice-LibreOffice, Hudson-Jenkins and MySQL-MariaDB (taking Oracle as an example) - fork it. When you look at https://github.com/SpringSource/spring-framework there are already 507 forks (I know - only 1% of it has any changes, but that's how github works).

At any rate, if you wish to have that particular discussion, I suggest opening up a top level article instead of wasting time on this thread that no one is reading any more. Please do invite me to it. I'll be happy to point out what you are missing. It'll be good publicity for Java EE and it's always good to know what you Spring guys think your arguments are these days.

If only I had time... That would be great. In the meantime I was caught by the title. I don't thing this thread is dead, because the future of JavaEE 7 hasn't been shaped yet :-)

So one more suggestion - release early, release often. Now JavaEE version is regarded as completed when there are "certified app servers" being released in GA version. And it's not about TMax Jeus or Glassfish RI. You must admit it - JavaEE 7 will be "ready for the enterprise" when WebSphere 9 will be released. Sadly I've recently seen broader adoption of WebSphere 7 (JavaEE 5)...

Have you (Oracle) considered relieving JavaEE from app server releases/certification? I don't think so. So don't be surprised that there are many trolls (me included) and rants about how JavaEE is "vendor driven"...

regards Grzegorz Grzybek

Reza Rahman replied on Mon, 2012/11/19 - 3:07pm in response to: Grzegorz Grzybek

From your own examples, it's obvious that forking is much easier said that done and that most forking efforts do not succeed: http://en.wikipedia.org/wiki/Fork_(software_development). In fact, forking is likely to be sucessful only when original developers are involved in it and even then it's a rocky road. That's precisely why standards are that much better for ensuring vendor neutrality from any practical standpoint.

Any mindset that suggests a division between open source and standardization is driven by deep cynicism. They strengthen each other, not the other way around.

Any guarantee of compatibility is meaningless without a certification and verification process (although I'm sure some people would love it so that they start calling themselves Java EE compatible even if they are not). Also, certification has little to do with the overall factors involved in the timelines for WebSphere or any other app server (and I can say that because I've run the TCK against Resin myself). Think about that rationally for a second -- does it take longer to execute unit tests on a module than it takes to develop it?

GlassFish is not "merely an RI" (that's the point of the resources I just posted on GlassFish stories) and WebSphere is maybe about 25% of the Java EE market at best and shrinking (so it's hardly the defining application server for Java EE as you seem to be suggesting). In fact, having a standard acts as a counterweight against having a "defining" application server.

As to your suggestion of frequent releases, that certainly applies well to implementations, extensions and plugins (the GlassFish ecosystem does indeed follow the principal). It is ill applied when it comes to standardization where ideas must incubate/mature before they are baked in to a long lasting standard, broad consensus is needed and essential artifacts like the specification, the compatibility test kit and the reference implementation must be produced. Now, it's true that Java EE 7 took a lot longer to develop than anyone likes (for a variety of reasons that we can certainly discuss). The broad consensus for both Java SE and Java EE appears to be a two-year hearbeat.

Your (rather out of the blue) claim of Java EE/JCP being vendor driven is grossly out of touch with reality and more in-line with the on-going effort to malign a mechanism critical to the long term future of the Java community. The JCP looks very much like a community driven effort with both vendors and individual developers fully engaged for many years now. You need look no further than this survey for proof of that.

It's also why I'm here to try my very best and gather what useful feedback I possibly can.

All views are my own, not necessarily Oracle's.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.