What should the JCP be doing?

Home

News: What should the JCP be doing?

  1. What should the JCP be doing? (27 messages)

    The JCP is the mechanism for defining specifications relating to Java. These specifications are called Java Specification Requests (JSR) and there can be multiple implementations, for example, JSR 315 defines the latest servlet standard and software such as Tomcat and Glassfish implements this standard.

     

    The form is being pushed out by the LJC but the results will be public and visible to all participants in the JCP. Please fill in the survey and publicise to as many people as possible.


    https://docs.google.com/forms/d/13hcWIi_powmSF_bZ6vUK6a31KyZOot5xB6GECzEUM0I/viewform

    Threaded Messages (27)

  2. Go home? Is it even marginally useful anymore?

  3. What should the JCP be doing?[ Go to top ]

    If you have specific feedback on what you think should be improved in the JCP, it's helpful to detail those. That's what this effort is all about and I applaud the LJC for it, especially for the questions pertinent to Java EE.Personally, I've worked with the JCP for many years now. My experience has largely been positive and one of the factors that heavily influenced my decision to join Oracle.

    Reza Rahman | Java EE/GlassFish Evangelist

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

  4. What should the JCP be doing?[ Go to top ]

    If you have specific feedback on what you think should be improved in the JCP, it's helpful to detail those.

    It's been said in various places before ... open TCK process so anyone can check things and contribute tests that match the spec. It still hasn't been done. When such as that is done then come back and ask again by all means, but til that happens there's no point.

  5. What should the JCP be doing?[ Go to top ]

    You are of course entitled to your opinions and you can certainly share your opinions with the JCP reform process. The way I see it, open sourcing the TCK (if that's what you are even alluding to) can pose a serious risk to compatibility. It's also a pretty political topic that has at best a minor effect on rank and file developers.
    Reza Rahman | Java EE/GlassFish Evangelist
    All views voiced are my own, not necessarily Oracle's.
  6. What should the JCP be doing?[ Go to top ]

    Neil -

    Oracle has been pushing for a revision of the JCP rules to make developer access to the tests much easier, for openness and transparency, as part of the "JCP.next" effort. However, under this proposal, the use of the TCKs for commercial purposes will typically still require licensing. (I say "typically" because the proposal also includes support for JSRs to be able to specify open source licenses for TCKs; however, it is unlikely that Oracle-led JSRs -- which include the platform JSRs -- will use open source licenses for the TCKs.)

    Furthermore, Oracle does provide the TCKs for free under "scholarship" agreements to qualified non-profits like Eclipse and Apache.

    Peace,

    Cameron Purdy | Oracle

    For sake of full disclosure, I work at Oracle. The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.

  7. What should the JCP be doing?[ Go to top ]

    Furthermore, Oracle does provide the TCKs for free under "scholarship" agreements to qualified non-profits like Eclipse and Apache.

    I think we know that this is not accurate/problematic. I remember reading a blog some time ago about a group who tried that way. Here it is

    http://datanucleus.blogspot.co.uk/2011/01/jpa-tck-request-and-jpa21.html

    They seemingly gave up and concluded incompetence or deliberate non-providing. So OPEN UP THE TCK, and quit the politics

  8. What should the JCP be doing?[ Go to top ]

    I think we know that this is not accurate/problematic. I remember reading a blog some time ago about a group who tried that way.

    Interesting. So one blog is enough to make up your mind.

    I'll query internally to see if there is more to the story than shows up on the blog. I know that I've been actively working with a number of non-profits -- including Apache and Eclipse -- to get the scholarships out there, and this is something that Oracle puts a lot of effort into, even though it doesn't do anything for revenue.

    Peace,

    Cameron Purdy | Oracle

    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.

  9. Alex -

    Go home? Is it even marginally useful anymore?

    The JCP is brilliantly useful. It provides the process by which various technologies become standards in Java, supporting a continually growing set of capabilities that are "write once, run anywhere". In this past month, we released Java EE 7, with annotation and CDI support across the entire platform, and support for new HTML 5 technologies like WebSockets. How is that not useful?

    I'm sure you had some deeper point that you wanted to get across with your 5-second post. Perhaps you could elaborate on that, instead of denigrating the work of hundreds of volunteers who are making the Java platform better for all of us.

    Peace,

    Cameron Purdy | Oracle

    For sake of full disclosure, I work at Oracle. The opinions and views  expressed in this post  are my own, and do not necessarily reflect the  opinions or views of my employer.

  10. New standards? Wow! That's so exciting!

    I think it's waaaay past the time most people care much about SunOracle stanadards, almost no widely used Java technologies are actually based on anything by Sun. Some strange and deluded people still care about portability between WebSphere and Tomcat, but most developers just don't care anymore.

    The only JCPs that matter are the core language JCPs and the core language development is handled in such a way, that it's hard to see what can be done to make it worse. Maybe form another committee?

    And then we have an elephant in the room - Android.

  11. Alex -

    I think it's waaaay past the time most people care much about SunOracle stanadards [sic], almost no widely used Java technologies are actually based on anything by Sun.

    I appreciate that you may not care, but just because you are living in a cave does not mean that the rest of the world is.

    For example, there would be no Tomcat with those "SunOracle stanadards" [sic]. There would be no Spring with those "SunOracle stanadards". There would be no JBoss or Glassfish with those "SunOracle stanadards".

    What standards do is to create a predictable environment that other things can build on top of. It isn't always "sexy" work, but it's important work.

    Peace,

    Cameron Purdy | Oracle

    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.

  12. You have a very inflated opinion of Java stanards.

    Spring started long before the CDI and evolved just fine. Tomcat (and Jetty) are really HTTP request processors and would have happened anyway. WebSockets (Comet) were first developed within Jetty, for example.

    Would Coherence have happened withint JCache JCP?

    PS: my current application doesn't use ANY non-core Java standards (not even servlets).

  13. You have a very inflated opinion of Java stanards.

    Spring started long before the CDI and evolved just fine. Tomcat (and Jetty) are really HTTP request processors and would have happened anyway. WebSockets (Comet) were first developed within Jetty, for example.

    Would Coherence have happened withint JCache JCP?

    PS: my current application doesn't use ANY non-core Java standards (not even servlets).

    +1

    Innovation comes from real projects, not from the JCP. A "standard" (could / ought to) come after, taking accepted best practice and smoothing out the API, but nothing more.

  14. What should the JCP be doing?[ Go to top ]

    <p>I am confused as to what the actual point here is. By and large, JCP standards do exactly what you are saying. What innovation does happen usually happens as an organic/inevitable outcome of assimilating competing non-standard innovations into baseline best of breed APIs.</p><p>I am not sure what the rational argument is that says competition amongst compatible products that have a common vendor-neutral baseline is not what's best for developers. Without standardization, server-side Java would have likely never reached the level of success it has today. It would have been very likely just another PHP, ColdFusion, Rails, etc. Haven't we crossed the non-standard Java application server bridge way back in the nineties?</p><p>Reza Rahman | Java EE/GlassFish Evangelist</p><p>All views voiced are my own, not necessarily Oracle's.</p>
  15. What should the JCP be doing?[ Go to top ]

    Not sure how to say this politely, but I could present a litany of pretty valid points that contradict what you are saying as to interest in Java, Java EE and the JCP. I'll present a simple one for starters - if what you say was true, evangelists like me and Arun would not consistently have full house sessions across the globe.It is equally easy to demonstrate that the entire Java EE ecosystem directly or indirectly benefits from work that happens in the JCP - either by using APIS directly or by adopting ideas that come out of the JCP.As to Andriod, I can tell you first hand how painful mobile development is because of a lack of standardization. Most companies are desprate to move onto something standard like HTML 5 to get away from the nighmare of duplicating software for each platform they need to support.

    Reza Rahman | Java EE/GlassFish Evangelist
    All views voiced are my own, not necessarily Oracle's.
  16. What should the JCP be doing?[ Go to top ]

    Not sure how to say this politely, but I could present a litany of pretty valid points that contradict what you are saying as to interest in Java, Java EE and the JCP. I'll present a simple one for starters - if what you say was true, evangelists like me and Arun would not consistently have full house sessions across the globe.

    Duh. I went to quite a few of them - not to listen to YetAnotherStory about how EJB3 is the best thing since sliced bread but to meet fellow developers, perhaps get some new connections.

    As for Android - it is THE mobile Java standard. Oracle should have worked with Google, instead of throwing excrements like a monkey.

  17. What should the JCP be doing?[ Go to top ]

    OK, this is definitely deloving to silly bickering not worth my time. While what you say may be accurate for a random local JUG talk, it is absolute nonsense for large international conferences where Java EE usually competes against others talks on separate tracks. On Andriod, Sun did negotiate and anyone would be naive to think sensible negotiation isn't ongoing. The Industry also needs a standards based solution that works across mobile devices, since the iPhone is still doing quite well (or perhaps better) than Andriod. The sensible focus now for server-side Java probably is HTML 5.Reza Rahman | Java EE/GlassFish Evangelist All views voiced are my own, not necessarily Oracle's.
  18. almost no widely used Java technologies are actually based on anything by Sun

    Uhm, JSF? CDI? Servlet? JSP? JTA? Bean Validation? JPA?

    Those are all used A LOT...

    And I'd say portability matters a lot. The risk that one vendor goes out of business (or just stops developing the product) and you have to re-code your entire code base to another API is greatly reduced.

    Sure, unfortunately portability is still not at the level that I can take a random Java EE application that has only ever been tested on say JBoss and then run it on GlassFish. But, in most cases porting the app from JBoss to GlassFish will be a matter of days, maybe weeks at most. Certainly not years for a big code base.

    I've seen another thing happen a lot in practice as well. A company where I work or am involved with is bought or buys another company. They use Java EE, but happen to deploy to another AS. Making it all run on the same AS is never more work than weeks.

    It also happens that said company is running a totally different stack, say PHP instead of Java EE. In that case you're just hosed. It rarely happens that a large code base is recoded overnight. In practice the two (three, four... etc) code bases linger around for years and years to come.

  19. Long term evolution[ Go to top ]

    The JCP standards are imho currently the best and only way to develop long term stable application. Without needing to reinvent your application every second year, and a clear migration/evolution path it is really working quite well for enterprise applications and products. Nothing is perfect of course, but in many cases we are happy to have sticked with the standard instead of jumping on the latest hype, that 6 months later turned out to be a dead end. The JCP standards are almost never a dead end. Cheers, Tomas
  20. Long term evolution[ Go to top ]

    Of course standards as a way to write stable systems is great idea. Those who went TCP/IP won over those who went with other protocols.

    But there's one problem with JavaEE IMO. First - we should talk about ~5 years periods and longer. JavaEE 6 was released on 10th December 2009 and JavaEE - last week. So the bets placed 3.5 years ago should be valid now and for at least 2 years from now (with JavaEE 6). And they are. JavaEE 7 haven't changed thath much.

    But what have to tell the people who placed their bets on EJB 2.1? There's really sometimes no way to tell them - hey rewrite your 1000+ session beans and deploy to Glassfish instead of WebSphere 6. I'm pretty sure that session beans written now will be cool even few years from now but you have to realised that some people just don't write EJBs anymore... JCP in the area of JavaEE specifications isn't really that innovative. CDI was revolutionary and was a great move. It required 3.5 years to spread it's @Inject and @Produces into other specs. CDI was really a competitor to Spring IOC but Spring IOC is not a holy grail of Spring fanboys...

    I belong to the group of pragmatics, who just realised that using Spring model (with the  BeanFactory -> BeanDefinitions -> Beans model with all the benefits of such relation) is the way to protect the future from EJB2.1/EJB3.0 revolutions. Spring's model is the way to detach deployment environment lifecycle from application lifecycle (i.e. to be able to change AppServer, e.g., WebSphere 5 to WebSphere 6 without touching the application. By the way - now I'm in the process of evaluating problems related to tag libraries working on WebSphere 6 but not working on WebSphere 8.5).

    I really hoped to "program to JavaEE APIs" back in 2002-2004 but then came Spring and "programming to Spring APIs" is better way to not to fall to "dead end".

    I use JavaEE APIs all the time - JMS, BeanValidation, Mail, Servlets, JTA... But not the most important and fundamental - CDI. This is were you have to choose between Spring and "Java EE" - there's really only Spring IOC vs CDI debate. Not Spring vs JavaEE.

    And the last thing - Security - how using "Vanilla JavaEE" is going to protect my future when I don't have decent Security technology? Spring Security is brilliant and allows me to do everything I need. "isUserInRole()" gives me nothing.

    So sticking to non-standard, Github based Spring portfolio is much more reliable than waiting for JavaEE 8. But I'll still not be able to download TCK for JAX-WS, I still won't be able to tell which one of 10000+ tags in java.net SVN repository is "the" version I should file a JIRA issue to...

    regards

    Grzegorz Grzybek

  21. Long term evolution[ Go to top ]

    I consider myself a pragmatist too but I've left Spring behind as of Java EE 5 and haven't looked back since.

    My principal issue with Spring is that it is a single-vendor/single implementation solution and I don't see why I need to use it when there are equally good or better alternatives available (more on that below). That's hardly the only problem with Spring I see though. I also see issues with jar hell and configuration hell that I really hate. Harald Wellman did a great job outlining the problems some time ago: http://hwellmann.blogspot.com/2012/05/deconstructing-spring-myths.html.

    Besides overlooking Spring's weaknesses, I think you miss a few key concepts:

    Standards are for standardizing, not innovating. That's why all standardization processes take time. Now, Java EE 7 certainly was an exception in that it look longer than anyone really wanted. Historically, the Java EE release cadence has been about 2.5 years, which is great compared to pretty much any other standard out there. To boot, Java EE 6 was a pretty good release.

    No good standard including Java EE is a walled garden. What this means is that standards aim to define a stable core for about the 80% use case. Beyond that, you are encouraged to use the ecosystem around the standard to meet needs outside the core. For J2EE/Java EE adopters, this has meant adopting solutions like Seam, Arquillian, RichFaces, PrimeFaces, Hibernate (in it's time), Castor (in it's time), XDoclet/EJB 2 (in it's time) and the other numerous complementary extensions to Java EE. As features mature and get assimilated into the standard, you have the option of porting over the non-standard parts or just leaving things alone for older applications in their maintenance cycle and adopt the standard for newer applications. Either way, you are fine due to the almost religious focus on backwards compatibility for pretty much all things Java EE.

    A few of the other things you said can use some clarification, so I'll do that below:

    * Java EE 7 haven't changed that much.

    - You are clearly off base here. Java EE 7 is easily one of the most major releases Java EE has ever had. Just take a look at my slide deck on Java EE 7: http://www.slideshare.net/reza_rahman/javaeenext-java-ee-7-8-and-beyond. Most independent industry analysts have the same view: http://www.eweek.com/developer/oracle-delivers-java-ee-7-with-html5-support/. Just the support for HTML 5 WebSocket is hugely significant. In fact, I'd say the changes are far more significant than anything the Spring framework has had in pretty much the same time period.

    * But what have to tell the people who placed their bets on EJB 2.1? There's really sometimes no way to tell them - hey rewrite your 1000+ session beans and deploy to Glassfish instead of WebSphere 6...

    - Firstly, there's no need to port anything at all because of fact that containers like WebSphere most certainly work hard to maintain backwards compatibility. Secondly, EJB 2 is now a ten year old technology. I don't think anyone can expect a modernization from a ten years old technology to be painless. Thirdly, the component model changes that have happened from Java EE 5 to Java EE 7 and onward is really about meta-data. So in order to say port from EJB 3.0 to CDI 1.1 @Transactional components you primarily are just swapping annotations, not Java code. That's pretty much exactly the same story for porting between say Spring 2 XML to Spring 3.2 Java Config so I am not sure what your complaint there really is.

    * CDI was revolutionary and was a great move. It required 3.5 years to spread it's @Inject and @Produces into other specs.

    - If you are talking about the CDI aligment work done in JSF 2.2, JTA 1.2, Bean Validation 1.1, etc the changes again are pretty easy to adjust to and most of it has been possible for a long time via Seam 3/Java EE 6. For new specs, the point is obviously moot since they did not exist when CDI 1.0 was standardized.

    * Security - how using "Vanilla JavaEE" is going to protect my future when I don't have decent Security technology?

    - You are way off base here too. There are actually several good options. The first is container security. Here's a decent article showing you the basics on GlassFish: http://blog.eisele.net/2013/01/jdbc-realm-glassfish312-primefaces342.html for authentication. Authorization is just a matter of using a few annotations like @RolesAllowed. If you really need something more elaborate/portable there's always PicketLink and Shiro. Both work well with CDI.

    * So sticking to non-standard, Github based Spring portfolio is much more reliable than waiting for JavaEE 8. But I'll still not be able to download TCK for JAX-WS, I still won't be able to tell which one of 10000+ tags in java.net SVN repository is "the" version I should file a JIRA issue to.

    - This is perhaps the clearest example of frivolous nitpicking, bias or resistance to change on your part. For most developers, getting issues solved is a simple matter of logging a JIRA issue against a GlassFish version. The engineers involved figure out the rest and they are damn good at it. The vast majority of developers go this route and could care less where source code is stored.

    Reza Rahman | Java EE/GlassFish Evangelist

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

  22. Long term evolution[ Go to top ]

    Thank for your long response!

    > I also see issues with jar hell and configuration hell that I really hate. Harald Wellman [...]

    I won't discuss Herald's blog here ad the problems he had. I personally had much greated JAR hell when trying to use newest CXF version on JBoss 6 without influencing other applications running on it than ever with Spring. I've always preferred to pack my dependencies into WEB-INF/lib - that's more portable between JBoss, WebSphere, Tomcat and e.g., Jenkins' test environment. But others might like the opposite.

    > Beyond that, you are encouraged to use the ecosystem around the standard to meet needs outside the core. For J2EE/Java EE adopters, this has meant adopting solutions like Seam, Arquillian, RichFaces, PrimeFaces, Hibernate (in it's time), Castor (in it's time), XDoclet/EJB 2 (in it's time) and the other numerous complementary extensions to Java EE

    I've used everything (except Seam) actually. XDoclet was real pain but did it's job.
    And your mentioning of Seam is were I always need to respond to your comments Reza. I was responding to the "Seam argument" back then when the king of "JavaEE advocates" was Gavin King. God bless him for Hibernate and his hard work to kill Entity Beans and to bring us JPA. But now his working on Ceylon (by the way - I've heard a little from that area recently...). IMO without the word "Seam", the JavaEE advocates would have nothing to say when talking about "JavaEE ecosystem around the standard". I know Seam gives us what standard JavaEE doesn't have (e.g., Security, Rules, etc.) but just please take a look at "Seam" and "Spring" tags at http://stackoverflow or links at DZone... Just an excersise for the curious.

    > Just the support for HTML 5 WebSocket is hugely significant. In fact, I'd say the changes are far more significant than anything the Spring framework has had in pretty much the same time period.

    For the sake of completeness, one of the biggest "thing" that happens now "around" Spring is Spring-Data project (using Eclipse's terminology - "a release train"). It covers NoSQL, Hadoop and similar technologies. Spring Integration still evolves and (just like Apache Camel) is the most pleasant to use and powerfull EIP implementation.

    > Security [...] There are actually several good options. The first is container security. [...]. There's always PicketLink and Shiro.

    I know Shiro. Even when it was called JSecurity. But I'm using Spring Security. Reza - when you mention Shiro, you'd *always* pick it instead of Spring-Security just because it is not from SpringSource? Isn't that a policital decision?

    > For most developers, getting issues solved is a simple matter of logging a JIRA issue against a GlassFish version.

    And where's JIRA for WebSphere? I know Glassfish is great, it's compliant with latest JavaEE on the very day it is released, but Glassfish is actually *not* what I'm using (although it surely is a great product). I've used the word "mess" to describe the feeling I had while looking for particular version of JaxWS or (back then) of JaxRPC. I've read tons of other people's code (you must have too). Spring products' code is clean. Spring artifacts have clear versioning schemes, clear dependencies, clear Git tags, clear changelogs. These aspects add to the total value of a product. They make the products reliable.

    But back to JCP. It *is* different now. Back then, JMS was to standardize different messaging technologies under one API. Earlier JDBC did that work. And it *was* standardization. Now, with WebSockets (one of dozen of HTML5 technologies), JSON, Batch it doesn't work that way. What *different* APIs/Protocols/formats do JavaEE speifications try to *unify*? What *real* problems JavaEE 7 tries to solve? Did JavaEE 7 respond to the *real* problems developers had? Of course the times are different. There are now much less APIs/Protocols/formats that need to be unified, but JavaEE, JCP and Oracle have to admit it. Just allowing to manipulate JSON with classes from javax.* package doesn't mean Spring is "legacy" or "dead" or "lost" just because it has no blessing from JavaEE advocates or no vote in JCP (or suspended voting rights just like Google). I liked when Google, Apacheand Doug Lea wer on the list of voters. Now we have Goldman Sachs... Why JavaEE advocates don't say "Seam is dead/lost/legacy"? Just because there are many JavaEE advocates among the authors?

    regards
    Grzegorz Grzybek

  23. Long term evolution[ Go to top ]

    <p>* Thank for your long response!</p><p> - No problem at all. The way I see it, many Java EE advocates get too preoccupied with talking about features that they forget that we also need to articulate our core value propositions in the first place instead of simply assuming they are known. I am conscious to not do the same.</p><p>* I've always preferred to pack my dependencies into WEB-INF/lib</p><p>- Frankly, I see this as mostly an obsessive need to control the runtime more than anything else. In my Java EE projects, I've never had a practical need to mess with hacking the runtime other than occasionally working with the operations folks to apply a necessary patch or update the runtime when needed. That being said, I've primarily worked with GlassFish and JBoss, not WebSphere and most application servers nowadays do help you do this if you really need it.</p><p>* without the word "Seam", the JavaEE advocates would have nothing to say when talking about "JavaEE ecosystem around the standard".</p><p>- I don't think this is right at all. The list of things that complement and extend various Java EE APIs are virtually endless. With regards to CDI alone, you have things like Arquillian, DeltaSpike, CODI, ZK, Camel, Errai, PicketLink, Shiro, Wicket, Struts 2, Forge, JBoss Tools, ModeShape, CDISource etc just to name a few.</p><p>-Please take a look at "Seam" and "Spring"</p><p>* If you are trying to insinuate that Java EE is not as widely used as Spring, just go ahead and say it. Any Java EE adopter worth their salt knows that already. That being said, I think you may be surprised as to how much traction Java EE actually does have. As some simple anecdotal evidence, take a look at this Google Trends graph: http://www.google.com/trends/explore?q=java+ee%2C+spring+fram%2Cework%2C+gwt%2C+scala#q=java%20ee%2C%20%20spring%20framework%2C%20%20spring%20data%2C%20%20spring%20mvc%2C%20%20jsf&cmpt=q that charts the terms Java EE, Spring Framework, Spring Data, Spring MVC and JSF.</p><p>* One of the biggest "thing" that happens now "around" Spring is Spring-Data project.</p><p>- If you are going to look outside the core Spring framework to say Spring still innovates, you should also be taking into account the work that's being done in the Java EE ecosystem that matches or outweighs Spring Data. I've presented on that work here, take a look: http://www.slideshare.net/reza_rahman/using-nosql-with-jpa-eclipselink-and-java-ee. At least you mentioned Camel, which basically occupies the same space in the CDI ecosystem that Spring Integration does in the Spring ecosystem.</p><p>* when you mention Shiro, you'd *always* pick it instead of Spring Security just because it is not from SpringSource? Isn't that a political decision?</p><p>- I'm not sure where the accusation of playing politics is coming from. You asked me what the security solutions in Java EE are. Spring Security is so tied to the Spring component model that it is virtually unusable outside Spring. PicketLink and Shiro on the other hand integrate easily with CDI. In fact, Shiro is so component model agnostic that it integrates with Spring too.</p><p>* And where's JIRA for WebSphere? I know Glassfish is great...</p><p>- And this is precisely where the value of standards come in. If you are unhappy with one Java EE implementation, you can switch to another. For example, if you are really that big on GitHub, JBoss/WildFly is the right choice for you. If you are unhappy with Spring on the other hand (like me) you are basically stuck with Spring.</p><p>* But back to JCP. It *is* different now...</p><p>- I am not sure what your point here is. I've already explained what the goals of any good standardization effort is - to maximize vendor neutrality, portability and compatibility. As an end result, you get a set of APIs that you can count on to avoid vendor/implementation lock-in. That means identifying very common needs that users have, figuring out the best baseline reliable way of meeting that need and standardizing that way. All Java EE 7 APIs like JMS 2, JAX-RS 2, concurrency, WebSocket and all the rest do exactly that. Now, you can claim that you personally don't care about vendor neutrality at the API/programming model level and only care about minimal standardization at the protocol or infrastructure level (BTW, WebSocket and concurrency clearly belong at this level). In fact, Java EE works hard to provide portable hooks to support that mindset too. If we didn't, you would never be able to run things like Spring across pretty much all containers.</p><p>* Spring is "legacy" or "dead" or "lost"...</p><p>- The fact is that most responsible Java EE advocates don't say this (I most certainly don't because it's a stupid thing to say). The reality is that Spring has a huge deployment base that's not going to go away overnight just because we now have CDI. There's also the reality that Java EE has to live with the consequences of the mistakes made in the J2EE era. Lastly, Spring has proven to be valuable catalyst for Java EE so it would be a shame for them to go away or be so weakened as to be irrelevant. The few people that I do see saying this sort of stuff is mostly as an emotional "payback" response to similar nonsense the Spring folks have been saying about Java EE for years. Lastly, there's the folks that make a pretty simple and reasonably valid technical point - now that DI is available as a standard, the core value proposition for Spring DI has been significantly diminished. This is the very reason Java EE advocates do indeed see the biggest part of Seam as now being "dead" (contrary to what you seem to think).</p><p>Reza Rahman | Java EE/GlassFish Evangelist</p><p>All views voiced are my own, not necessarily Oracle's.</p>
  24. Long term evolution[ Go to top ]

    Frankly, I see this as mostly an obsessive need to control the runtime more than anything else

    I agree - that's quite obsessive. But it results from my experience where Application Server used is not ideal and not my choice. My choice of WEB-INF/lib jars was better than what particular version of WebSphere has provided.

    With regards to CDI alone, you have things like Arquillian, DeltaSpike, CODI, ZK, Camel, Errai, PicketLink, Shiro, Wicket, Struts 2, Forge, JBoss Tools, ModeShape, CDISource etc just to name a few.

    Of course there are "ecosystem" products. I won't comment your list - I have my own (sometimes overlapping with yours) :)

    As some simple anecdotal evidence, take a look at this Google Trends graph

    Actually these trends are stupid - just enter these words in Google Trends: "java ee, j2ee, spring" - you won't believe how much "better" is J2EE than JavaEE (and that means just nothing).

    PicketLink and Shiro on the other hand integrate easily with CDI

    I think the biggest (and really "the single") thing that differs us two is the choice of component model of our applications - you've chosen CDI and me - Spring IOC. With all the consequences (and "ecosystem" products :)).

    If you are unhappy with one Java EE implementation, you can switch to another

    I've wrote a comment to your entry in "The JPA 2.0 EntityManager vs. the Hibernate Session: Which one to use?" - I've divided "standards" into two groups: "protocols/formats" and "APIs". Shortly - in the beginning APIs' implementations seem to be switchable, but after some time you just have to "assume" some implementation. Sometimes much later (as with JDBC - only when you start using particular driver's extensions) and sometimes much earlier (as I had to do with JPA).

    regards
    Grzegorz Grzybek

  25. Long term evolution[ Go to top ]

    Not sure much of any of this needs to be commented on. As to the trends vis-a-vis J2EE and Java EE, what is shown is that J2EE has a huge deployment that is gradually going down, while Java EE matches Spring and is trending upwards - that exactly matches up with what I've seen in the field. As to the value of vendor neutrality at the API level, I've already commented on it here and on the thread you are alluding to. That being said, I am glad you are forthright about what you value in the interest of full disclosure. Most IT decision makers that I know of value vendor neutrality at all levels that they can adopt easily to safeguard their investments.<p>Reza Rahman | Java EE/GlassFish Evangelist<p>All views voiced are my own, not necessarily Oracle's.
  26. Long term evolution[ Go to top ]

    <p>BTW, in the interest of full disclosure, I think you should clearly identify yourself as you do elsewhere - "Seniorish Java Developer and Spring enthusiast. SpringSource Certified Spring Professional". IMO this sort of stuff is important when you are not necessarily purely a dispassionate observer. It's the same reason I've always included in my signature my involvement with Java EE.</p><p>Just my 2 cents. Please don't take this the wrong way. I am not questioning your integrity.</p><p>Reza Rahman | Java EE/GlassFish Evangelist</p><p>All views voiced are my own, not necessarily Oracle's.</p>
  27. Long term evolution[ Go to top ]

    Dude, the "container security" is such a piece or crap, that everybody responsible for it should be fired (from a gun into the Sun, preferably).

    For example, in ALL of my projects I had to add per-client groups. I.e. each client needs their own set of groups and users. The container-based security immediately becomes useless.

  28. Long term evolution[ Go to top ]

    This is frankly nonsensical bickering too. Container based security is more than good enough for 80%+ of use cases (certainly has been in my pretty long career in server-side Java spanning numerous clients). The multi-tenancy case you are alluding to is a relative edge case for most applications and met via either PicketLink or Shiro (as I've already mentioned). In fact, Spring Security won't meet the edge case without significant custom code either.Reza Rahman | Java EE/GlassFish Evangelist All views voiced are my own, not necessarily Oracle's.