4 ms·

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,

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.

lockje 9y ago
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 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.
- jacques_chester 9y ago
  > This is highly valueable for reuseability and not having 10 libraries completely reinventing the wheel. This was a problem in the days when the only available platforms were closed-source. Standardisation was pushed onto vendors by buyers in an attempt to weaken their lockin power. It never really worked very well. No matter how flawless the standard, no matter how miraculously identical the behaviour of the implementations, nobody is going to bet their career on a move that bets the company on a different vendor. Too expensive, too risky, too long. OSS changes that equation entirely. Say you pick Guice. Will Google behave like Oracle and extract everything up to one dollar less than your "fuck this, let's migrate" price? They can't. Say you pick Spring. Will Pivotal burst through the door demanding licensing fees, support fees, sales fees, fee-collecting fees, fees to the power of fees, also à la Oracle? They can't. So you're left with technical lockin. Which you always had anyway. The economics have changed. For libraries, for code running inside a single process, standards are now largely irrelevant, because you'll rely an OSS framework or library in which there is no risk of vendor lockin. The frontier of standardisation has moved to formats and network protocols. The most widely-used network protocols actually foreshadowed the triumph of opensource. Similarly, file formats we've all pretty much settled on a handful of open formats for the vast majority of greenfield and brownfield integrations. These protocols and formats have standards, but as a guide to cooperators, not as a shield against vendor bloodsucking. Java EE matters a lot, insofar as the majority of Java code written somewhere passes through a JEE-defined interface. But it no longer controls the destiny of Java programmers. That now lies with the OSS contributors and their sponsors. Disclosure: I work for Pivotal, we sponsor Spring.
  - watwut 9y ago
    It is not so much that you replace existing project, but more that you start using different technology for new one once you are fed up with old. It makes learning it easier since the bulk of it is the same. Same with hiring people who have experience with different vendor. Also, it gives you shared documentation. At least that is something that I perceived to be different against js world where exact technology match is often required and documentation weaker.
saiya-jin 9y ago
With web stack & EJB i agree, but JMS is still used heavily ie in finance (where I currently work). In situations where you need 100% reliable and trackable message delivery with various load balancing/failover modes, and don't care that much about perfromance (ie max tens of messages/s). Which is good enough for most system integrations these days. Direct peer-to-peer connectivity (ie SOAP or REST) has few issues, ie when taget is down due to crash/patching, you only get 400/500/timeout and client has to be smart enough to retry later or handle it in other ways. Cluster can solve few of these, but not all of them. What we face regularly - weekend patching where consumers are down for 10 hours easily due to external constraints. What I want to say - for reliable mesasging, you don't want direct connectivity, rather than central servers that can withstand any situation, and clients don't have to be too smart. Be it some ActiveMQ or Websphere MQ cluster or anything else. JMS is battle-proven, you can have TSL over it and support for it is huge.
filomeno 9y ago
Well, actually Java EE is only a "spec", with no code. There's a reference implementation, though. Sometimes this RI is popular, sometimes it isn't. Following your example: JPA (the spec) is implemented, among others, by Hibernate. And EclipseLink is the reference implementation for JPA.

lockje 9y ago

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 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.

jacques_chester 9y ago
> This is highly valueable for reuseability and not having 10 libraries completely reinventing the wheel. This was a problem in the days when the only available platforms were closed-source. Standardisation was pushed onto vendors by buyers in an attempt to weaken their lockin power. It never really worked very well. No matter how flawless the standard, no matter how miraculously identical the behaviour of the implementations, nobody is going to bet their career on a move that bets the company on a different vendor. Too expensive, too risky, too long. OSS changes that equation entirely. Say you pick Guice. Will Google behave like Oracle and extract everything up to one dollar less than your "fuck this, let's migrate" price? They can't. Say you pick Spring. Will Pivotal burst through the door demanding licensing fees, support fees, sales fees, fee-collecting fees, fees to the power of fees, also à la Oracle? They can't. So you're left with technical lockin. Which you always had anyway. The economics have changed. For libraries, for code running inside a single process, standards are now largely irrelevant, because you'll rely an OSS framework or library in which there is no risk of vendor lockin. The frontier of standardisation has moved to formats and network protocols. The most widely-used network protocols actually foreshadowed the triumph of opensource. Similarly, file formats we've all pretty much settled on a handful of open formats for the vast majority of greenfield and brownfield integrations. These protocols and formats have standards, but as a guide to cooperators, not as a shield against vendor bloodsucking. Java EE matters a lot, insofar as the majority of Java code written somewhere passes through a JEE-defined interface. But it no longer controls the destiny of Java programmers. That now lies with the OSS contributors and their sponsors. Disclosure: I work for Pivotal, we sponsor Spring.
- watwut 9y ago
  It is not so much that you replace existing project, but more that you start using different technology for new one once you are fed up with old. It makes learning it easier since the bulk of it is the same. Same with hiring people who have experience with different vendor. Also, it gives you shared documentation. At least that is something that I perceived to be different against js world where exact technology match is often required and documentation weaker.

saiya-jin 9y ago

With web stack & EJB i agree, but JMS is still used heavily ie in finance (where I currently work). In situations where you need 100% reliable and trackable message delivery with various load balancing/failover modes, and don't care that much about perfromance (ie max tens of messages/s). Which is good enough for most system integrations these days. Direct peer-to-peer connectivity (ie SOAP or REST) has few issues, ie when taget is down due to crash/patching, you only get 400/500/timeout and client has to be smart enough to retry later or handle it in other ways. Cluster can solve few of these, but not all of them. What we face regularly - weekend patching where consumers are down for 10 hours easily due to external constraints. What I want to say - for reliable mesasging, you don't want direct connectivity, rather than central servers that can withstand any situation, and clients don't have to be too smart. Be it some ActiveMQ or Websphere MQ cluster or anything else. JMS is battle-proven, you can have TSL over it and support for it is huge.

filomeno 9y ago

Well, actually Java EE is only a "spec", with no code. There's a reference implementation, though. Sometimes this RI is popular, sometimes it isn't. Following your example: JPA (the spec) is implemented, among others, by Hibernate. And EclipseLink is the reference implementation for JPA.