This is IBM finally beating Sun over control of enterprise Java - something they've been fighting for for well over a decade (and much closer to two). IBM has been trying to get the Java process away from Sun - and they even backed an IDE to compete with NetBeans.
Eclipse... of the Sun (Microsystems).
Apparently, Oracle has finally gotten tired of IBM (through Eclipse) saying "we can do it better" and trying to manage it and said "ok - you can do it."
This is awesome. CDI, JAXRS, JPA, JTA, and JMS are brilliant technologies but are held down by the weight of legacy technologies. Maybe we can finally see Java EE based solely on CDI, which would kick every platform out of the water. Scopes take dependency injection to the next level and finally fulfills the promise of modular, testable, reusable code.
> CDI, JAXRS, JPA, JTA, and JMS are brilliant technologies but are held down by the weight of legacy technologies.
JMS is not a brilliant technology. It gets stuff done but it's not brilliant. Issues I have with JMS:
- There is the old API which is closely modelled after JDBC, quite verbose, many objects that you have to close (not that bad anymore since Java 7) and checked exceptions. You almost never want to work with this API directly but use some convince layer above it. For example something like Spring JdbcTemplate, unfortunately Spring JmsTemplate hasn't received any love and therefore doesn't support generics or functional interfaces. I have a PR open for this but nobody seems to care about JMS anymore. But at least the old API works with connection pooling.
- There is the new API (JMSContext) which is much nicer to use, much less verbose and uses runtime exceptions. Unfortunately the new API does not work well with connection pooling. That's why Spring doesn't support the new API. That was supposed to be fixed in JMS 2.1 (https://github.com/javaee/jms-spec/issues/126) but then Oracle cancelled JMS 2.1.
- The old and new API from above are both part of JMS 2.0. In addition some methods you can only call when running in Java EE, some methods you can only call when running in Java SE, and some methods you can call from both Java SE and EE. We're talking about methods on the same interface here. How can you tell which ones you can call? If you're lucky it's mentioned in the method comment, that should now be the case for most of the methods since JMS 2.0, otherwise you just have to know about the inner workings of JMS and Java EE.
- JMSException#getCause() is unspecified. Only JMSException#getLinkedException() is specified. Yes, Java 1.4 Exception#getCause(). Which means if you have some generic exception handling code that uses Exception#getCause(), like let's say a logger framework that renders stack trace, then that code is only guaranteed to work if it special cases JMSException. That was also supposed to be fixed in JMS 2.1 (https://github.com/javaee/jms-spec/issues/113) but then Oracle cancelled JMS 2.1.
- The only way to receive messages without blocking is to use an MDB. Unfortunately MDBs have to be pooled. In addition there is no portable way to connect an MDB to a non-default RAR in your application server.
Sure, JMS solves problems but brilliant it is not.
JAX-RS even has it's own component and DI model different from CDI because of NHI syndrome.
You really drank the coolaid I can see. I think dependency injection frameworks are a bad idea in general, and it seems as if the current trend goes against using them. Also I won't be expecting much good to happen after Eclipse takes over, they tend to complect implementation and not really drive development IMO.
My impression is that nobody uses any of the code shipped in Java EE. People use Servlet containers (Tomcat and JBoss) but the problems you can solve with EJB, JSF, JPA, JMS, etc. are all better solved with open source libraries, e.g. Guice, Spring, and Hibernate.
Many of the open source libraries are concrete implementations of the Java EE specs. Hibernate uses JPA, GUICE standarized the CDI implementation (http://googlecode.blogspot.nl/2009/05/javaxinjectinject.html). And many of the technologies offered by Java EE are standarizations of concepts. This is highly valueable for reuseability and not having 10 libraries completely reinventing the wheel.
Sheesh, there's always someone with this take on foundations. I've heard the exact same phrase many times with "Apache" (where I used to be very active) instead of "Eclipse". :\
Large projects tend to end up under the various foundations because large projects have lots of common problems that the foundations help solve and it doesn't make sense to reinvent the wheel every time (e.g. by starting your own foundation).
Once there, lots of stakeholders are more comfortable committing lots of resources because the governance rules are predictable and well understood. So the projects tend to cater to those stakeholders, putting a higher emphasis on backwards compatibility and evolving more through extension than through revolutionary, breaking changes.
Projects which go to foundations live for a long time. And they don't stop innovating, either -- they just innovate more at the edges than at the core.
It means the whole server-side JDK API, including the servlet spec, jsp libs and JDBC SQL framework under the javax.* packages, whether actually distributed as part of the JDK or not. [0,1,2]
> Can someone explain what Java EE really means? I tried to parse the bundle and license the last time this came up, and I didn't really get anywhere.
It's no different than Web standards between browsers, it's a collection of API specifications describing how web applications should be architectured in Java. Then different libraries can follow the spec. JavaEE also has a reference implementation which used to be done by Sun/Oracle.
The problem with JavaEE is, by being too broad and generic, it is incredibly complex and often fails to solve today's developers problems. I mean who cares about JSF(java server face, a way to describe "HTML GUI widgets" in XML) when most applications use a RESTful architecture? Beans session persistance? ... JEE has a lot of technical debt, the word is definitely appropriate here.
It's basically Java SE + a standarized stack of technologies, that are usually used in server applications: Servlet, EJB, CDI, JSP, JSF, JTA, JPA...
Java EE is not the only way of doing serverside java apps - most of systems i've developed used tomcat + spring-* stack, which is not a Java EE platform.
I think reading this project page may help clarify what Java EE is:
the more esoteric corners of Java. It's like someone just offered to support windows XP forever. I highly recommenced donating to the Eclipse Foundation, they have made an impact far out of proportion to their size close to Bill Gates, but what they're doing for the good of us all might not be profitable.
Not sure if I'm mistaken but isn't the major thing about this the TCKs? As far as I'm aware they are the keys to kingdom for alternative Java implementations. Never shared by either Sun or Oracle so if and when this happens it will be a good thing™.
You're correct. In the old days that was the case. They were shared but only for money. These days Tomcat, TomEE and Payara can't claim Java EE compliance because they don't have a TCK. It is not clear to me wether this would also retroactively include the Java EE 8 TCKs. It is important to note that Oracle does not transfer the Java EE brand name. So whatever comes out of Eclipse can't be named Java EE 9. You can't make this stuff up.
It's the gentleman's way to completely unburden maintenance for software not commercially interesting at scale anymore without loosing face as enterprise supplier. Transition to just sounds better than Dumping on github, and upcoming vulnerabilities and other security issues won't make for good media appearance either.
Governance. Github would be just free hosting + tracker.
The other thing is, emerging expectation that all open source projects should be stored in one place (Github) is not a good development. Puts too much power in hands of a single company.
I heard some scuttlebutt about two years ago after Oracle got rid of some Java people that Oracle had wanted to leverage Java-as-a-Service as a cloud product, sort of like Google Compute, but just never managed to get there... The Sun acquisition, someone told me, "was a hardware acquisition". With SPARC/Solaris dead, Sun staff gone and the lawsuits against Google over Java faltering Oracle has sucked the last marrow out of the bones and is just casting them off now.
Yes, if the Payara guys manage to take over the project, do more frequent releases and pull off some major refactorings. I am not sure they have the resources.
Its' true that there's no array or map in XML, but Arrays can be serialized to XML. I too haven't reviewd JSR, So not in position to say about implementation.
, and not a second too early.
Definitely cause for celebration!
Edit: Sore toes, anyone? Too invested to see clearly? I did enough EE-consulting to have an opinion; it's over-engineered, marketing-driven bullshit; designed to make everything as complicated as possible.
Feel sad, don't like things goto Eclipse. Eclipse makes me feel less techs, maybe the bad impression from eclipse, these bad impression last for at least five years, most of time someone get into the trouble is caused by eclipse, feel more worse.
Are you confusing Eclipse-the-IDE with Eclipse-the-Foundation? The Eclipse Foundation is much like the Apache Foundation - the piece of software it was originally named for doesn't have much to do with lots of the projects hosted / owned by the foundation.
[+] [-] shagie|8 years ago|reply
Eclipse... of the Sun (Microsystems).
Apparently, Oracle has finally gotten tired of IBM (through Eclipse) saying "we can do it better" and trying to manage it and said "ok - you can do it."
[+] [-] needusername|8 years ago|reply
I also doubt IBM still cares about Java EE. Their last JSR (Batch/JSR-352) was particularly disgusting and seems to be abandoned already.
[+] [-] geodel|8 years ago|reply
[+] [-] hacking_again|8 years ago|reply
[+] [-] jrs95|8 years ago|reply
[+] [-] EtienneK|8 years ago|reply
[+] [-] exabrial|8 years ago|reply
[+] [-] needusername|8 years ago|reply
JMS is not a brilliant technology. It gets stuff done but it's not brilliant. Issues I have with JMS:
- There is the old API which is closely modelled after JDBC, quite verbose, many objects that you have to close (not that bad anymore since Java 7) and checked exceptions. You almost never want to work with this API directly but use some convince layer above it. For example something like Spring JdbcTemplate, unfortunately Spring JmsTemplate hasn't received any love and therefore doesn't support generics or functional interfaces. I have a PR open for this but nobody seems to care about JMS anymore. But at least the old API works with connection pooling.
- There is the new API (JMSContext) which is much nicer to use, much less verbose and uses runtime exceptions. Unfortunately the new API does not work well with connection pooling. That's why Spring doesn't support the new API. That was supposed to be fixed in JMS 2.1 (https://github.com/javaee/jms-spec/issues/126) but then Oracle cancelled JMS 2.1.
- The old and new API from above are both part of JMS 2.0. In addition some methods you can only call when running in Java EE, some methods you can only call when running in Java SE, and some methods you can call from both Java SE and EE. We're talking about methods on the same interface here. How can you tell which ones you can call? If you're lucky it's mentioned in the method comment, that should now be the case for most of the methods since JMS 2.0, otherwise you just have to know about the inner workings of JMS and Java EE.
- JMSException#getCause() is unspecified. Only JMSException#getLinkedException() is specified. Yes, Java 1.4 Exception#getCause(). Which means if you have some generic exception handling code that uses Exception#getCause(), like let's say a logger framework that renders stack trace, then that code is only guaranteed to work if it special cases JMSException. That was also supposed to be fixed in JMS 2.1 (https://github.com/javaee/jms-spec/issues/113) but then Oracle cancelled JMS 2.1.
- The only way to receive messages without blocking is to use an MDB. Unfortunately MDBs have to be pooled. In addition there is no portable way to connect an MDB to a non-default RAR in your application server.
Sure, JMS solves problems but brilliant it is not.
JAX-RS even has it's own component and DI model different from CDI because of NHI syndrome.
[+] [-] strictfp|8 years ago|reply
[+] [-] dfabulich|8 years ago|reply
[+] [-] lockje|8 years ago|reply
[+] [-] filomeno|8 years ago|reply
Following your example: JPA (the spec) is implemented, among others, by Hibernate. And EclipseLink is the reference implementation for JPA.
[+] [-] saiya-jin|8 years ago|reply
[deleted]
[+] [-] campuscodi|8 years ago|reply
[+] [-] moocowtruck|8 years ago|reply
[+] [-] wocram|8 years ago|reply
[+] [-] rectang|8 years ago|reply
Large projects tend to end up under the various foundations because large projects have lots of common problems that the foundations help solve and it doesn't make sense to reinvent the wheel every time (e.g. by starting your own foundation).
Once there, lots of stakeholders are more comfortable committing lots of resources because the governance rules are predictable and well understood. So the projects tend to cater to those stakeholders, putting a higher emphasis on backwards compatibility and evolving more through extension than through revolutionary, breaking changes.
Projects which go to foundations live for a long time. And they don't stop innovating, either -- they just innovate more at the edges than at the core.
[+] [-] mibollma|8 years ago|reply
[+] [-] csours|8 years ago|reply
[+] [-] qwerty_asdf|8 years ago|reply
[0] http://docs.oracle.com/javaee/6/api/javax/persistence/packag... / http://docs.oracle.com/javase/7/docs/api/javax/sql/package-s...
[1] https://docs.oracle.com/javaee/6/api/javax/servlet/package-s...
[2] http://www.oracle.com/technetwork/java/javaee/jsp/index.html
[+] [-] camus2|8 years ago|reply
It's no different than Web standards between browsers, it's a collection of API specifications describing how web applications should be architectured in Java. Then different libraries can follow the spec. JavaEE also has a reference implementation which used to be done by Sun/Oracle.
The problem with JavaEE is, by being too broad and generic, it is incredibly complex and often fails to solve today's developers problems. I mean who cares about JSF(java server face, a way to describe "HTML GUI widgets" in XML) when most applications use a RESTful architecture? Beans session persistance? ... JEE has a lot of technical debt, the word is definitely appropriate here.
[+] [-] emergie|8 years ago|reply
Java EE is not the only way of doing serverside java apps - most of systems i've developed used tomcat + spring-* stack, which is not a Java EE platform.
I think reading this project page may help clarify what Java EE is:
http://openejb.apache.org/apache-tomee.html
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] solomatov|8 years ago|reply
[+] [-] forgotpw1123|8 years ago|reply
[+] [-] damagednoob|8 years ago|reply
[+] [-] needusername|8 years ago|reply
[+] [-] vbezhenar|8 years ago|reply
[+] [-] tannhaeuser|8 years ago|reply
[+] [-] watwut|8 years ago|reply
The other thing is, emerging expectation that all open source projects should be stored in one place (Github) is not a good development. Puts too much power in hands of a single company.
[+] [-] exabrial|8 years ago|reply
[+] [-] geodel|8 years ago|reply
1. https://github.com/oracle
[+] [-] horusthecat|8 years ago|reply
[+] [-] rmrfrmrf|8 years ago|reply
[+] [-] needusername|8 years ago|reply
[+] [-] jerianasmith|8 years ago|reply
[+] [-] nomercy400|8 years ago|reply
[+] [-] annonwhatever|8 years ago|reply
[+] [-] drama-queen|8 years ago|reply
A rethink of the provider/deployment end of the equation for the world of k8 mesos etc. could resurrect it.
[+] [-] andreasgonewild|8 years ago|reply
Edit: Sore toes, anyone? Too invested to see clearly? I did enough EE-consulting to have an opinion; it's over-engineered, marketing-driven bullshit; designed to make everything as complicated as possible.
[+] [-] puppetmaster30|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] UK-AL|8 years ago|reply
[+] [-] terminado|8 years ago|reply
[+] [-] wener|8 years ago|reply
[+] [-] QuercusMax|8 years ago|reply