| >There's very little reason to use Spring today". That, frankly, is nonsense. We all have our own preferences. I can guess what the "very little reason means". You hear this more often in Java (EE) discussions. The thing is that in 2003/2004 Spring positioned itself as the necessary layer to make arcane Java EE APIs approachable and usable. With their FooBarTemplates Spring wraps everything that's wrappable, and at the time it made somewhat sense. Rod couldn't wrap EJB though, and as he deemed it "unfixable" he invented his own bean model to replace that. At some point though Java EE started improving, and then started to improve a lot. Getting first class APIs such as JPA, co-designed by the Hibernate lead himself (Gavin King). And what did Spring do? As a pavlov reaction they started wrapping again. But the JPA APIs were brand new, perfectly well designed, and didn't need wrapping. This was the basis of the fallout between Hibernate and Spring, and a revealing moment into how Spring operated. They weren't the benevolent dictator who out of the goodness of their hearts wanted to make life better for programmers, no, they just wanted you to depend on their APIs. Rod later cashed big time, and Springsource, later pivotal became as commercial as the "evil" corporations they tried to wrap with their APIs. Fast forward to Java EE 7, and Java EE has tons of perfectly fine APIs that don't need the Spring wrapping treatment. JMS, JPA, Bean Validation, CDI, EL, JAX-RS, ... NOTHING of that needs wrapping by Spring to make it usable. It's perfectly fine as-is. So this is where the often heard "there's little reason to use Spring today" comes from, and I guess that is what was meant. Today Spring is just another platform. Java EE programmers don't need it to make their life better. Programmers in general can choose Java EE, or Spring, or .NET, or whatever. If your preference is Spring, please, use it and be happy. It's not better than Java EE, but likely not much worse either. I've seen enough Spring code and Java EE code to say it's different, but still fairly equal. I personally think the design process of Java EE is more open than that of Spring. Both are open source projects, and both have strong commercial influences as well as community influences, but with Java EE the design process is fully out in the open and people can comment on it and contribute. This is less the case with Spring. Yes, the source is open, but so is that of the Java EE RI and many other implementations. But Spring doesn't have an open design process, where Java EE has. |
LOL, JMS. I take it you never actually used JMS. Where should I start? Ah yes, checked exceptions. JMS (of course) doesn't support Java 1.5, the API still uses raw types. Also JMS (of course) doesn't even support Java 1.4. You see JMS predates Throwable#getCause so JMSException#getCause is undefined and you have to use JMSException#getLinkedException. In addition the only way to wait on a Queue without blocking or polling is to use an MDB but there is no (!) standardized way to associate a RAR with an MDB. On top of that JMS is six APIs in one. There is the part old API that you're only allowed to use in Java EE, there is the part of the old API that you're only allowed to use in Java SE and then there a part of the old API that you're allowed to use in Java SE and Java EE. How do you know which methods fall into which category? Since Java EE 7 it's a comment in the Javadoc, otherwise you have to be familiar with the spec (yes, it is on a per-method basis, not an a per-interface basis). Then there is the new API (JMSContext) which follows the same "pattern" but uses runtime exceptions for certain parts until you're at the point where it uses checked exceptions again.
Yes, JMS, perfectly fine as-is and doesn't need wrapping to make it usable.
> But Spring doesn't have an open design process, where Java EE has.
I take it you're not actually a JCP member and tried to get a feature into a JSR? It you were you wouldn't make statements like this. Java EE is open only by name.