A Java EE Startup: Filtering information with zeef.com(adam-bien.com)
adam-bien.com
A Java EE Startup: Filtering information with zeef.com
http://www.adam-bien.com/roller/abien/entry/a_java_ee_startup_filtering
15 comments
JSF isn't the greatest, but it's improved a lot starting with version 2.0. I can indeed see a preview of what my page will look like (with templates applied) right in my IDE. The fact that you called it J2EE makes me think you're talking about the "old" Enterprise Java. I abandoned it for a while back then too - it was no fun to use!
JSF 2.0 improved a lot in comparison to JSF 1.x but is still crap compared to nearly any other Java web framework. I have worked a lot with JSF. At the end of a development cycle of a large app, we decided to start over and evaluated other frameworks. Nearly every problem we had with JSF (which manishsharan listed correctly) were non existent in the other frameworks. Not only that but they were mostly a breeze to work with. Once you start using JSF extensively you know immediately that it's a standardized platform becaue everything is a compromise. Then you hear that everything sucks less with Primefaces until you find out how inconsistent the API is and how unprofessional the code looks (this may have changed now but was definitely a problem 2 years ago).
I can sign manishsharan's approach: just use a REST server and a SPA framework. It makes frontend problems leaking in your backend much less likely to happen (another problem some developers had with JSF at my last job). You are forced to separate UI and backend which is a problem that's not exclusive to JSF. It's also easier to make features of your webapp available as an app where it makes sense.
I can sign manishsharan's approach: just use a REST server and a SPA framework. It makes frontend problems leaking in your backend much less likely to happen (another problem some developers had with JSF at my last job). You are forced to separate UI and backend which is a problem that's not exclusive to JSF. It's also easier to make features of your webapp available as an app where it makes sense.
[deleted]
I should have clarified: previewing a page in an IDE is not enough in my use case (banking): I would want to preview my page on different devices' browsers.
>I would want to preview my page on different devices' browsers.
What's stopping you?
With JSF you can write normal HTML that you can load on every device. See http://jdevelopment.nl/jsf-22/#1111 and for the older somewhat less capable version: https://en.wikipedia.org/wiki/Facelets
What's stopping you?
With JSF you can write normal HTML that you can load on every device. See http://jdevelopment.nl/jsf-22/#1111 and for the older somewhat less capable version: https://en.wikipedia.org/wiki/Facelets
The main differentiator of jsf as a display technology is server side rendering, which you allude to but didn't state explicitly. When used idiomatically, jsf removes a lot of compmexity from the stack; very little or no client side javascript, client side templating, marshalling and unmarshalling data from to json or xml representation. All these things become things the developer doesnt have to deal with.
BUT before i start to sound too much like a fan boy, where jsf fails is when you need to anything off the jsf path. Then you are looking at implementing custom components or tacking on the entire client side js ecosystem.
So, jsf may have a place for rapid implementation if your devs aren't proficient with client side ui imo, but thats about the only time its appropriate, again imo.
BUT before i start to sound too much like a fan boy, where jsf fails is when you need to anything off the jsf path. Then you are looking at implementing custom components or tacking on the entire client side js ecosystem.
So, jsf may have a place for rapid implementation if your devs aren't proficient with client side ui imo, but thats about the only time its appropriate, again imo.
They used two frameworks on top of JSF though.
I was never a fan of JSF but years ago I loved using simple servlets and JSPs. Hacking JSPs and later factoring out common code to custom tag libraries was a fast way to prototype with a path later to making code cleaner and more maintainable.
>They used two frameworks on top of JSF though.
The interview mentions OmniFaces and PrimeFaces. These are not frameworks on top of JSF.
PrimeFaces is a component library. The entire purpose of JSF was to make such libraries possible. It introduced a component model with exactly the intend that a marketplace of components would appear.
This indeed happened. There's PrimeFaces, RichFaces, IceFaces, Trinidad, and a few others. They don't "fix problems" in JSF, but are what JSF was created to provide.
OmniFaces is a little different. It's a utility library. It does fixes small inconveniences in the JSF API, but it too is not a framework and makes use of the very extension points that JSF explicitly has provided.
Compare this to Eclipse. It's weird to say that JDT is a framework on top of Eclipse, since Eclipse was specifically made to host plug-ins.
The interview mentions OmniFaces and PrimeFaces. These are not frameworks on top of JSF.
PrimeFaces is a component library. The entire purpose of JSF was to make such libraries possible. It introduced a component model with exactly the intend that a marketplace of components would appear.
This indeed happened. There's PrimeFaces, RichFaces, IceFaces, Trinidad, and a few others. They don't "fix problems" in JSF, but are what JSF was created to provide.
OmniFaces is a little different. It's a utility library. It does fixes small inconveniences in the JSF API, but it too is not a framework and makes use of the very extension points that JSF explicitly has provided.
Compare this to Eclipse. It's weird to say that JDT is a framework on top of Eclipse, since Eclipse was specifically made to host plug-ins.
Thanks for the clarification!
>starting stopping J2EE servers is time consuming.
Starting and stopping j2ee servers indeed takes a long time. But so does booting Windows 9 on an old 386.
Why do you bring up J2EE? The article is about Java EE, which is really, really fast in starting/stopping. On my 3 year old desktop (Ubuntu 14.10, 3.4Ghz i7, 16GB RAM, Samsung 830 SSD), JBoss starts in exactly 1 second. Liberty takes 1.5 orso, GlassFish takes between 2 and 3 seconds.
That's not a LONG time, IFF you need to restart.
For typical JSF you don't need to restart at all. You make a change on the page and reload the browser. That's it.
With a standard JVM you can also make changes inside Java code, as long as those changes are inside a method. The IDE will hot deploy only the changed code and the JVM will hot reload it. If you want to structurally modify classes (add/remove methods, add new base class) then you can still hot reload them, but you need to install JRebel. This has little to do with JSF, and more with Java in general.
>you can't see what you screen looks like until you serve the page from your J2EE server
Not true. JSF lets you create pages using normal HTML, which can be previewed from their source.
>Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others.
What's easier is perhaps personal, but I don't think the abstraction is unnecessary. First of all when using normal HTML to create pages there's not much abstraction in the first place, it's normal HTML. Then the advantage is that you can VERY EASILY bind input/output to the server. Client-to-server data binding is JSF's strong point.
And it's not just easy, you also get validation thrown in there for very little cost and JSF is aware of what it has rendered when processing data that's being send back. This allows it to mitigate certain attack vectors, like the mass attribute assignment vulnerability in RoR.
>you will be suprised by the amount of backend code you will have to write.
Funny, how my backing beans are always really small and simple, despite the pages being of arbitrary complexity.
>Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge.
Rarely an issue if you half know what you're doing. Client side JSF can make all the changes it wants, and when it's time to update to the server you send that data to the server. Where's the problem?
In every client-server architecture there are sync issues to be aware of. With a js client and JAX-RS the server can also be out of sync if other pages or other clients made changes. This is not unique to JSF.
Starting and stopping j2ee servers indeed takes a long time. But so does booting Windows 9 on an old 386.
Why do you bring up J2EE? The article is about Java EE, which is really, really fast in starting/stopping. On my 3 year old desktop (Ubuntu 14.10, 3.4Ghz i7, 16GB RAM, Samsung 830 SSD), JBoss starts in exactly 1 second. Liberty takes 1.5 orso, GlassFish takes between 2 and 3 seconds.
That's not a LONG time, IFF you need to restart.
For typical JSF you don't need to restart at all. You make a change on the page and reload the browser. That's it.
With a standard JVM you can also make changes inside Java code, as long as those changes are inside a method. The IDE will hot deploy only the changed code and the JVM will hot reload it. If you want to structurally modify classes (add/remove methods, add new base class) then you can still hot reload them, but you need to install JRebel. This has little to do with JSF, and more with Java in general.
>you can't see what you screen looks like until you serve the page from your J2EE server
Not true. JSF lets you create pages using normal HTML, which can be previewed from their source.
>Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others.
What's easier is perhaps personal, but I don't think the abstraction is unnecessary. First of all when using normal HTML to create pages there's not much abstraction in the first place, it's normal HTML. Then the advantage is that you can VERY EASILY bind input/output to the server. Client-to-server data binding is JSF's strong point.
And it's not just easy, you also get validation thrown in there for very little cost and JSF is aware of what it has rendered when processing data that's being send back. This allows it to mitigate certain attack vectors, like the mass attribute assignment vulnerability in RoR.
>you will be suprised by the amount of backend code you will have to write.
Funny, how my backing beans are always really small and simple, despite the pages being of arbitrary complexity.
>Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge.
Rarely an issue if you half know what you're doing. Client side JSF can make all the changes it wants, and when it's time to update to the server you send that data to the server. Where's the problem?
In every client-server architecture there are sync issues to be aware of. With a js client and JAX-RS the server can also be out of sync if other pages or other clients made changes. This is not unique to JSF.
Modern Java EE has taken a lot of influence from other web frameworks. It is now much more convention over configuration than it used to be. I think it just lacks a new MVC module as an alternative to JSF. If only jersey 2.0's mvc templates were added to the core, I would have considered it instead of other alternatives (e.g. Adding routing to a view from JAX-RS, right now it's not trivial and meant mostly for "services" e.g. API methods vs JSF for your friendly neighborhood MVC. I think JAX-RS is much more friendly and familiar to people coming from other web frameworks. JSF is not too, well, RESTful and feels a little outdated to me, although it's very powerful...)
(Dropwizard uses JAX-RS by the way if I'm not mistaken)
Now with Java 8, Java EE is quite a powerful and productive framework, and the performance is pretty predictably just awesome.
(Dropwizard uses JAX-RS by the way if I'm not mistaken)
Now with Java 8, Java EE is quite a powerful and productive framework, and the performance is pretty predictably just awesome.
> I think it just lacks a new MVC module as an alternative to JSF.
In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem
That page is from the MVC 1.0 spec lead (Manfred Riem). It's going to be strongly based on JAX-RS and mimicking how Spring MVC and Jersey MVC now works.
In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem
That page is from the MVC 1.0 spec lead (Manfred Riem). It's going to be strongly based on JAX-RS and mimicking how Spring MVC and Jersey MVC now works.
[deleted]
Personally, I think "blessing" UI frameworks as JSRs ("official!") is a bad idea.
I think it leads to the UI framework (e.g. JSF in the past or this new MVC spec) "winning" and getting adopted by teams who, if they had to evaluate several competing non-blessed frameworks, would pick something better/easier/more modern, but instead go with the JSR-backed option.
Although perhaps I'm just being pessimistic. JSRs can probably be a good thing; as a programmer in the JVM ecosystem, I've just never considered "it's a JSR" as a brand of quality/something that should affect my choice, and if anything it's the opposite.
(My pessimism aside, if they're basing the spec on existing good ideas, like JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart approach.)
I think it leads to the UI framework (e.g. JSF in the past or this new MVC spec) "winning" and getting adopted by teams who, if they had to evaluate several competing non-blessed frameworks, would pick something better/easier/more modern, but instead go with the JSR-backed option.
Although perhaps I'm just being pessimistic. JSRs can probably be a good thing; as a programmer in the JVM ecosystem, I've just never considered "it's a JSR" as a brand of quality/something that should affect my choice, and if anything it's the opposite.
(My pessimism aside, if they're basing the spec on existing good ideas, like JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart approach.)
This is great news!
Working with Java Servlet is very hard to be productive in it , Simple things that I took for granted like routing,templating,user management and processing forms with binaries ie form-data is really hard.
But the static typing is really good ,ofcourse the language too .Maybe I should I've tried Jersey .
But the static typing is really good ,ofcourse the language too .Maybe I should I've tried Jersey .
Yes, servlets are not the best for modern web development :) (although they have their uses...) JAX-RS (jersey is the reference implementation) is like a parallel universe, well designed, batteries included, statically typed REST API framewrok that has a lot of potential (I prefer it over Spring MVC in terms of syntax or even over play framework's routing)
If I had to go back to Servlet development today, I would probably go directly for Spring WebMVC or whatever is current from Spring. I also wasn't a big fan of the Servlet system.
I second that. If you really want to save time start with spring boot, or even a yeoman generator like JHipster...
There's very little need to go to Spring today. Base Java EE includes nearly everything that one needs.
Plain Servlets is what you get when using just Tomcat, but Java EE goes beyond that with really great support for bean management and DI (CDI), persistence via ORM (JPA), declarative validation (bean validation), REST (JAX-RS), MVC web franework (JSF), etc
Plain Servlets is what you get when using just Tomcat, but Java EE goes beyond that with really great support for bean management and DI (CDI), persistence via ORM (JPA), declarative validation (bean validation), REST (JAX-RS), MVC web franework (JSF), etc
Oh, I couldn't possibly disagree more.
JEE has come a long way, and it's a shame that people unfairly dismiss it today due to their ancient experiences with EJB 2.x. However, JEE is a very conservative stack, which suffers greatly from "design-by-committee". Spring therefore is, was, and always will be at least a generation or two ahead.
JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use. Because the JEE model is to have a slew of libraries loaded at the global app server level, you're much more likely to run into conflicts with libraries that your application loads at its WAR/EAR file level. Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.
With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file. Moreover, it doesn't even have to be a WAR. You can easly bundle a production-grade embedded Tomcat instance (or Jetty or Undertow) directly within your application, building an executable JAR file with no dependencies whatsoever apart from having a JRE installed on the target machine. Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture. These days disk storage is a lot cheaper than unnecessary system complexity. Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.
Spring's dependency injection is straightforward, and compatible with other JSR-330 implementations like Guice and Dagger. I find JEE's CDI to be a clunky mess in contrast. In the presentation tier, Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms (Microsoft has meanwhile walked away from this as outdated bad practice).
Last but not least, there is community engagement to consider. If you take a Spring problem to StackOverflow, you will have an answer within minutes. Hell, you could even take it to IRC and probably get answers in real-time. By comparison, the JEE "community" is practically non-existent... and if anything consists mostly of consultants seeking to sell you their time.
Again, JEE has indeed come light years from where it was a decade ago. But because of its conservative, committee-based DNA... it will always be years behind Spring, and delivering solutions much more muddy and disjointed. Spring seems to occupy an ideal common-sense spot on the spectrum. It lags several years behind the "hipster" frameworks of other platforms, stealing at a stable and production-grade pace those innovations that prove themselves. At the same time, it's well ahead of the glacial pace at which those innovations make their way (poorly) into the Oracle-blessed standards.
JEE has come a long way, and it's a shame that people unfairly dismiss it today due to their ancient experiences with EJB 2.x. However, JEE is a very conservative stack, which suffers greatly from "design-by-committee". Spring therefore is, was, and always will be at least a generation or two ahead.
JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use. Because the JEE model is to have a slew of libraries loaded at the global app server level, you're much more likely to run into conflicts with libraries that your application loads at its WAR/EAR file level. Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.
With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file. Moreover, it doesn't even have to be a WAR. You can easly bundle a production-grade embedded Tomcat instance (or Jetty or Undertow) directly within your application, building an executable JAR file with no dependencies whatsoever apart from having a JRE installed on the target machine. Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture. These days disk storage is a lot cheaper than unnecessary system complexity. Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.
Spring's dependency injection is straightforward, and compatible with other JSR-330 implementations like Guice and Dagger. I find JEE's CDI to be a clunky mess in contrast. In the presentation tier, Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms (Microsoft has meanwhile walked away from this as outdated bad practice).
Last but not least, there is community engagement to consider. If you take a Spring problem to StackOverflow, you will have an answer within minutes. Hell, you could even take it to IRC and probably get answers in real-time. By comparison, the JEE "community" is practically non-existent... and if anything consists mostly of consultants seeking to sell you their time.
Again, JEE has indeed come light years from where it was a decade ago. But because of its conservative, committee-based DNA... it will always be years behind Spring, and delivering solutions much more muddy and disjointed. Spring seems to occupy an ideal common-sense spot on the spectrum. It lags several years behind the "hipster" frameworks of other platforms, stealing at a stable and production-grade pace those innovations that prove themselves. At the same time, it's well ahead of the glacial pace at which those innovations make their way (poorly) into the Oracle-blessed standards.
>Spring therefore is, was, and always will be at least a generation or two ahead.
It should indeed be the idea that Java EE is behind. Its stated purpose is to standardize that what has been proven to work. It doesn't aim to be highly innovative. Instead, it aims to be a stable base on which other technologies can build without having to be afraid that the platform changes underneath them every few months, and without much fear that the platform suddenly changes directions radically.
Keeping that in mind it's funny that CDI is so much more innovative, modern and powerful when compared to Spring Beans. CDI (and by extension Java EE) engaged in the no-XML revolution when Spring was still trying to put MORE code into their proprietary XML format. I've seen Spring applications that were ~50k lines of Java code and ~150k of Spring XML code. Gives a whole other meaning to the term XML hell.
And let's not start about the -contextual- injections and the powerful extension mechanism that CDI pioneered well before Spring was even thinking about such things.
Here Spring is at least 2 generations behind Java EE. And before you start about it, no, CDI was not inspired by Spring. Guice and both JSF native beans and EJB were CDI's inspirations.
>JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use.
JBoss is NOT old-school and big honking (whatever that means). The download size of JBoss is about 110MB, and it starts in about a second. 10 seconds with an app that contains hundreds to thousands of beans.
Compare that to a typical Spring app, where the downloaded size of all things you need easily exceeds 200MB and the war itself is a 100MB or so. A war for Java EE is often some 1 to 2MB for a BIG application. Go figure.
A Spring app with so many beans takes up a minute to boot, at least. Granted, I last checked about 2 years ago, maybe it's better now.
TomEE has been viable to be used for quite some time, and next to TomEE there's also Resin and Liberty web profile which are about as small (some 30MB).
>Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.
You may get small breakages, but you at least have a chance to migrate!
Imagine migrating your 500k loc application from Spring to Play. Not going to happen. With Java EE I've migrated applications between all major servers. Sure, there were small things breaking, but on average it took me and the team about 2 weeks to fix. 2 weeks is NOTHING compared to a total migration to another platform which can take years.
>With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file.
This is only a fairly recent development for Spring, and Java EE vendors have solutions here as well. TomEE has been capable of doing this for years, and recently there have been solutions for GlassFish (http://www.payara.co.uk/introducing_payara_micro) and JBoss (http://wildfly.org/news/2015/05/05/WildFly-Swarm-Released/)
>Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture.
From the very article this HN post links to, that startup is doing something like that already with Java EE.
>Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.
Yeah, sure. See my comment above. TomEE is some 35 MB and contains nearly everything you need. Try adding Spring libs and all their dependencies, as well as Hibernate and a transaction manager to your war. That 35MB gets eaten away pretty quickly. And please don't think that just because you only put dependencies in the pom.xml file that the data is not really there. Take a look at the final war that's build. This is often way larger than 35MB when Spring is used.
>I find JEE's CDI to be a clunky mess in contrast
I think it's exactly the other way around...
>Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms
Thymeleaf unfortunately is not very memory efficient compared to JSF's Facelets. See http://www.jsfcentral.com/articles/understanding_jsf_perform...
And Facelets/JSF uses modern templating based on plain HTML these days.
>Microsoft has meanwhile walked away from this as outdated bad practice)
No, Microsoft walked away since they had never been able to put the effort in to create a next gen version of their platform. In JSF terms WebForms is still at JSF 1.1/1.2.
ASP.NET WebForms never had its JSF 2.0 release, and it doesn't have things like PrimeFaces and OmniFaces.
PrimeFaces DID try to make a component set for WebForms, but gave up because the underlying technology was just too outdated.
>If you take a Spring problem to StackOverflow, you will have an answer within minutes.
Uhm, you can't be serious here, are you?
Ever heard of BalusC?
The JSF community is HUGE on stackoverflow, things are answered pretty quickly and there are about twice as many questions (and answers!) there compared to Spring MVC.
>By comparison, the JEE "community" is practically non-existent...
On the contrary, it's really big. Every sub spec has a public JIRA where anyone can submit ideas and looking at the last release indeed many ideas have been implemented that were proposed by the community.
I think you have 2003/2004 in mind and never looked back. Things have changed drastically since then.
It should indeed be the idea that Java EE is behind. Its stated purpose is to standardize that what has been proven to work. It doesn't aim to be highly innovative. Instead, it aims to be a stable base on which other technologies can build without having to be afraid that the platform changes underneath them every few months, and without much fear that the platform suddenly changes directions radically.
Keeping that in mind it's funny that CDI is so much more innovative, modern and powerful when compared to Spring Beans. CDI (and by extension Java EE) engaged in the no-XML revolution when Spring was still trying to put MORE code into their proprietary XML format. I've seen Spring applications that were ~50k lines of Java code and ~150k of Spring XML code. Gives a whole other meaning to the term XML hell.
And let's not start about the -contextual- injections and the powerful extension mechanism that CDI pioneered well before Spring was even thinking about such things.
Here Spring is at least 2 generations behind Java EE. And before you start about it, no, CDI was not inspired by Spring. Guice and both JSF native beans and EJB were CDI's inspirations.
>JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use.
JBoss is NOT old-school and big honking (whatever that means). The download size of JBoss is about 110MB, and it starts in about a second. 10 seconds with an app that contains hundreds to thousands of beans.
Compare that to a typical Spring app, where the downloaded size of all things you need easily exceeds 200MB and the war itself is a 100MB or so. A war for Java EE is often some 1 to 2MB for a BIG application. Go figure.
A Spring app with so many beans takes up a minute to boot, at least. Granted, I last checked about 2 years ago, maybe it's better now.
TomEE has been viable to be used for quite some time, and next to TomEE there's also Resin and Liberty web profile which are about as small (some 30MB).
>Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.
You may get small breakages, but you at least have a chance to migrate!
Imagine migrating your 500k loc application from Spring to Play. Not going to happen. With Java EE I've migrated applications between all major servers. Sure, there were small things breaking, but on average it took me and the team about 2 weeks to fix. 2 weeks is NOTHING compared to a total migration to another platform which can take years.
>With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file.
This is only a fairly recent development for Spring, and Java EE vendors have solutions here as well. TomEE has been capable of doing this for years, and recently there have been solutions for GlassFish (http://www.payara.co.uk/introducing_payara_micro) and JBoss (http://wildfly.org/news/2015/05/05/WildFly-Swarm-Released/)
>Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture.
From the very article this HN post links to, that startup is doing something like that already with Java EE.
>Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.
Yeah, sure. See my comment above. TomEE is some 35 MB and contains nearly everything you need. Try adding Spring libs and all their dependencies, as well as Hibernate and a transaction manager to your war. That 35MB gets eaten away pretty quickly. And please don't think that just because you only put dependencies in the pom.xml file that the data is not really there. Take a look at the final war that's build. This is often way larger than 35MB when Spring is used.
>I find JEE's CDI to be a clunky mess in contrast
I think it's exactly the other way around...
>Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms
Thymeleaf unfortunately is not very memory efficient compared to JSF's Facelets. See http://www.jsfcentral.com/articles/understanding_jsf_perform...
And Facelets/JSF uses modern templating based on plain HTML these days.
>Microsoft has meanwhile walked away from this as outdated bad practice)
No, Microsoft walked away since they had never been able to put the effort in to create a next gen version of their platform. In JSF terms WebForms is still at JSF 1.1/1.2.
ASP.NET WebForms never had its JSF 2.0 release, and it doesn't have things like PrimeFaces and OmniFaces.
PrimeFaces DID try to make a component set for WebForms, but gave up because the underlying technology was just too outdated.
>If you take a Spring problem to StackOverflow, you will have an answer within minutes.
Uhm, you can't be serious here, are you?
Ever heard of BalusC?
The JSF community is HUGE on stackoverflow, things are answered pretty quickly and there are about twice as many questions (and answers!) there compared to Spring MVC.
>By comparison, the JEE "community" is practically non-existent...
On the contrary, it's really big. Every sub spec has a public JIRA where anyone can submit ideas and looking at the last release indeed many ideas have been implemented that were proposed by the community.
I think you have 2003/2004 in mind and never looked back. Things have changed drastically since then.
> JBoss is NOT old-school and big honking (whatever that
> means). The download size of JBoss is about 110MB, and it
> starts in about a second. 10 seconds with an app that
> contains hundreds to thousands of beans.
>
> Compare that to a typical Spring app, where the downloaded
> size of all things you need easily exceeds 200MB and the war
> itself is a 100MB or so. A war for Java EE is often some 1 to
> 2MB for a BIG application. Go figure.
I tried to steer clear of precise numbers, because they tend to change every couple of years... and you can easily date your knowledge by citing them.
However, spin up a new Spring application today (there's an online project generator wizard at http://start.spring.io). Make it a web app, with Hibernate/JPA and the PostgreSQL database driver, and Spring Actuator for automated metrics. Build this generated app. The resulting executable JAR with all dependencies will weigh 24 megs, and that includes its app server.
Ditch the Hibernate/JPA, and use PostgreSQL with Spring JDBC instead (which is often superior to an ORM anyway). Your total deliverable size drops to 13 megs.
Look, it's all Java at the end of the day. Spring plays nice with JEE components, and in practice it's not necessarily such an either/or matter. The Java community has a sliding spectrum of bleeding-edge early adopters (e.g. Scala, Akka, Play)... conservative late-adopters (e.g. JEE)... and pragmatic moderates in between (e.g. Spring). If your comfort zone is on a different spot in the spectrum, or if you disagree with how someone else defines the spectrum, then by all means do your own thing. But the comment to which I replied said that, "There's very little reason to use Spring today". That, frankly, is nonsense.
> means). The download size of JBoss is about 110MB, and it
> starts in about a second. 10 seconds with an app that
> contains hundreds to thousands of beans.
>
> Compare that to a typical Spring app, where the downloaded
> size of all things you need easily exceeds 200MB and the war
> itself is a 100MB or so. A war for Java EE is often some 1 to
> 2MB for a BIG application. Go figure.
I tried to steer clear of precise numbers, because they tend to change every couple of years... and you can easily date your knowledge by citing them.
However, spin up a new Spring application today (there's an online project generator wizard at http://start.spring.io). Make it a web app, with Hibernate/JPA and the PostgreSQL database driver, and Spring Actuator for automated metrics. Build this generated app. The resulting executable JAR with all dependencies will weigh 24 megs, and that includes its app server.
Ditch the Hibernate/JPA, and use PostgreSQL with Spring JDBC instead (which is often superior to an ORM anyway). Your total deliverable size drops to 13 megs.
Look, it's all Java at the end of the day. Spring plays nice with JEE components, and in practice it's not necessarily such an either/or matter. The Java community has a sliding spectrum of bleeding-edge early adopters (e.g. Scala, Akka, Play)... conservative late-adopters (e.g. JEE)... and pragmatic moderates in between (e.g. Spring). If your comfort zone is on a different spot in the spectrum, or if you disagree with how someone else defines the spectrum, then by all means do your own thing. But the comment to which I replied said that, "There's very little reason to use Spring today". That, frankly, is nonsense.
>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.
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.
> 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.
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.
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.
>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.
Strange that several types in the JMS API use annotations (Java 5) http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionF...
Or generics (also Java 5): http://docs.oracle.com/javaee/7/api/javax/jms/Message.html#g...
Or AutoCloseable (Java 7): http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.htm...
Very weird that an API that supposedly doesn't even support Java 1.4 has annotations, generics and AutoCloseable among others (which implies try-with-resources). I didn't know these were all in Java 1.3? :X
>Yes, JMS, perfectly fine as-is and doesn't need wrapping to make it usable.
The latest API is perfectly fine indeed and doesn't need wrapping by Spring. If the Spring guys have suggestions to improve the API even further, why don't they just file an issue on the JMS spec tracker?
>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.
You only have to look at the JIRA of the several specs to see how much things that the community suggested went into Java EE. Go ahead, browse through it. You'd be surprised.
Strange that several types in the JMS API use annotations (Java 5) http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionF...
Or generics (also Java 5): http://docs.oracle.com/javaee/7/api/javax/jms/Message.html#g...
Or AutoCloseable (Java 7): http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.htm...
Very weird that an API that supposedly doesn't even support Java 1.4 has annotations, generics and AutoCloseable among others (which implies try-with-resources). I didn't know these were all in Java 1.3? :X
>Yes, JMS, perfectly fine as-is and doesn't need wrapping to make it usable.
The latest API is perfectly fine indeed and doesn't need wrapping by Spring. If the Spring guys have suggestions to improve the API even further, why don't they just file an issue on the JMS spec tracker?
>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.
You only have to look at the JIRA of the several specs to see how much things that the community suggested went into Java EE. Go ahead, browse through it. You'd be surprised.
> generics
Please
http://docs.oracle.com/javaee/7/api/javax/jms/ConnectionMeta... http://docs.oracle.com/javaee/7/api/javax/jms/MapMessage.htm...
ever heard of enums?
http://docs.oracle.com/javaee/7/api/javax/jms/DeliveryMode.h... http://docs.oracle.com/javaee/7/api/javax/jms/Session.html#A...
Did you read the the JMS Spec or the Javadoc of JMSException http://docs.oracle.com/javaee/7/api/javax/jms/JMSException.h...? Where does it mentions the relationship between #getLinkedException and #getCause?
> The latest API is perfectly fine indeed and doesn't need wrapping by Spring.
Did you ever actually use JMS in production? If so did you listen on a queue? If so did you use MDBs? If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker? If you used a stand alone message broker how did you associate the RAR with the MDB and what did activation specs look like?
> If the Spring guys have suggestions to improve the API even further, why don't they just file an issue on the JMS spec tracker?
Are you aware of the politics behind the JCP? Are you aware of the JSRs that were shot down by WebLogic before they were even created?
> You only have to look at the JIRA of the several specs to see how much things that the community suggested went into Java EE. Go ahead, browse through it. You'd be surprised.
As I said, I take it you never actually tried to do that yourself. I did it for the issues listed above and more and absolutely nothing happened. It doesn't help that you can't create pull requests for Java EE but you can create pull requests for Spring.
Please
http://docs.oracle.com/javaee/7/api/javax/jms/ConnectionMeta... http://docs.oracle.com/javaee/7/api/javax/jms/MapMessage.htm...
ever heard of enums?
http://docs.oracle.com/javaee/7/api/javax/jms/DeliveryMode.h... http://docs.oracle.com/javaee/7/api/javax/jms/Session.html#A...
Did you read the the JMS Spec or the Javadoc of JMSException http://docs.oracle.com/javaee/7/api/javax/jms/JMSException.h...? Where does it mentions the relationship between #getLinkedException and #getCause?
> The latest API is perfectly fine indeed and doesn't need wrapping by Spring.
Did you ever actually use JMS in production? If so did you listen on a queue? If so did you use MDBs? If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker? If you used a stand alone message broker how did you associate the RAR with the MDB and what did activation specs look like?
> If the Spring guys have suggestions to improve the API even further, why don't they just file an issue on the JMS spec tracker?
Are you aware of the politics behind the JCP? Are you aware of the JSRs that were shot down by WebLogic before they were even created?
> You only have to look at the JIRA of the several specs to see how much things that the community suggested went into Java EE. Go ahead, browse through it. You'd be surprised.
As I said, I take it you never actually tried to do that yourself. I did it for the issues listed above and more and absolutely nothing happened. It doesn't help that you can't create pull requests for Java EE but you can create pull requests for Spring.
>Please
Please? You're stating that JMS is not even at Java SE 1.4, then I give you simple prove that it's at Java SE 7, and your response is "please"?
>Did you ever actually use JMS in production?
Yes, rather intensively.
>If so did you use MDBs?
Yes
>If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker?
The default implementation, with a JMS bridge. This is a rather powerful setup. The application posts and listens to what are local queues using the default provider. The bridge then transports these to the remote destination.
>how did you associate the RAR with the MDB and what did activation specs look like
Since I didn't use a standalone provider, I didn't go that route. But I DO know that you've changed specs here and are barking against the wrong tree. A RAR is JCA and MDB is EJB, we were talking about JMS here.
While I don't have much experience with JCA, I also do know that things have been simplified a while ago. Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs...
Or read some of David Blevins posts about this topic.
JCA and particular the activation config annotation is rather ugly, I'll agree to that. It's a direct translation of the old XML version and there's room for simplification here. Hey, if you have some ideas why not file a JIRA issue?
>As I said, I take it you never actually tried to do that yourself. I did it for the issues listed above and more and absolutely nothing happened.
Do you have a link to the issues you filed? I'm rather curious now.
When I look at the JIRAs of the Java EE specs I see a lot of issues that were filed by community users and were indeed implemented.
JSF is most well known here. Take a look at: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
Check what has been implemented in JSF 2 and check that with the issues that were filed. This one makes that rather easy: http://jdevelopment.nl/jsf-22 Now see who filed a lot of those issues. See?
If we look at JMS and I grab this issue, then it's a community member and the issue got included in Java EE: https://java.net/jira/browse/JMS_SPEC-63
Now just grab whatever other spec, say JPA, and look at another feature that was introduced a while back: https://java.net/jira/browse/JPA_SPEC-26
What do you know, AGAIN a community member. You can go on and on. MANY issues that actually ended up in Java EE were proposed by community members.
> It doesn't help that you can't create pull requests for Java EE
Oh? So what is this: https://github.com/spericas/ozark/pulls?q=is%3Apr+is%3Aclose...
And not every implementation is on Github, but many RI implementations take the equivalent of pull requests; patches attached to issues. Boils down to the exact same thing.
Yes, I too would like that every implementation and specifically the RI ones were all on Github, but there are many great other open source projects that aren't on Github either and this doesn't make them any less open source or free. In fact, I just called my old friend RMS (we go way back) and according to him there's nothing in OSI that requires projects to be on Github.
Please? You're stating that JMS is not even at Java SE 1.4, then I give you simple prove that it's at Java SE 7, and your response is "please"?
>Did you ever actually use JMS in production?
Yes, rather intensively.
>If so did you use MDBs?
Yes
>If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker?
The default implementation, with a JMS bridge. This is a rather powerful setup. The application posts and listens to what are local queues using the default provider. The bridge then transports these to the remote destination.
>how did you associate the RAR with the MDB and what did activation specs look like
Since I didn't use a standalone provider, I didn't go that route. But I DO know that you've changed specs here and are barking against the wrong tree. A RAR is JCA and MDB is EJB, we were talking about JMS here.
While I don't have much experience with JCA, I also do know that things have been simplified a while ago. Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs...
Or read some of David Blevins posts about this topic.
JCA and particular the activation config annotation is rather ugly, I'll agree to that. It's a direct translation of the old XML version and there's room for simplification here. Hey, if you have some ideas why not file a JIRA issue?
>As I said, I take it you never actually tried to do that yourself. I did it for the issues listed above and more and absolutely nothing happened.
Do you have a link to the issues you filed? I'm rather curious now.
When I look at the JIRAs of the Java EE specs I see a lot of issues that were filed by community users and were indeed implemented.
JSF is most well known here. Take a look at: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
Check what has been implemented in JSF 2 and check that with the issues that were filed. This one makes that rather easy: http://jdevelopment.nl/jsf-22 Now see who filed a lot of those issues. See?
If we look at JMS and I grab this issue, then it's a community member and the issue got included in Java EE: https://java.net/jira/browse/JMS_SPEC-63
Now just grab whatever other spec, say JPA, and look at another feature that was introduced a while back: https://java.net/jira/browse/JPA_SPEC-26
What do you know, AGAIN a community member. You can go on and on. MANY issues that actually ended up in Java EE were proposed by community members.
> It doesn't help that you can't create pull requests for Java EE
Oh? So what is this: https://github.com/spericas/ozark/pulls?q=is%3Apr+is%3Aclose...
And not every implementation is on Github, but many RI implementations take the equivalent of pull requests; patches attached to issues. Boils down to the exact same thing.
Yes, I too would like that every implementation and specifically the RI ones were all on Github, but there are many great other open source projects that aren't on Github either and this doesn't make them any less open source or free. In fact, I just called my old friend RMS (we go way back) and according to him there's nothing in OSI that requires projects to be on Github.
Sheet, are you really seriuous? I totally disagree with your comments. Spring is always miles ahead of java ee. Java ee copies spring inventions. For me it has been a long road to migrate away from "java ee hell". The less java ee the better and more productive to code. Nobody uses xml nowadays, its called java configuration. And who cares about the final jar/war size ?
>Spring is always miles ahead of java ee.
So home come Java EE started with no-XML and annotations way before Spring?
>Java ee copies spring inventions.
So why did Spring years later also went the no-XML route and started with annotations?
>Nobody uses xml nowadays,
Because Java EE adopted the move away from XML early. When all major frameworks where moving away from XML, Rod was still trying to let you write MORE XML.
>And who cares about the final jar/war size ?
The Spring guys cared about the size of the combined total when Java EE was still bigger. I can't count the times that Rod ridiculed Java EE about this.
Now Java EE is slimmer and now it suddenly doesn't matter? Funny...
So home come Java EE started with no-XML and annotations way before Spring?
>Java ee copies spring inventions.
So why did Spring years later also went the no-XML route and started with annotations?
>Nobody uses xml nowadays,
Because Java EE adopted the move away from XML early. When all major frameworks where moving away from XML, Rod was still trying to let you write MORE XML.
>And who cares about the final jar/war size ?
The Spring guys cared about the size of the combined total when Java EE was still bigger. I can't count the times that Rod ridiculed Java EE about this.
Now Java EE is slimmer and now it suddenly doesn't matter? Funny...
We're (re)developing almost all our infrastructure in modern Java EE (as layers of microservices). We're seeing less than 2mS response time for most services and can afford to stack quite a few to build our customer facing applications.
Ignoring the business logic, a RESTful API can be built to run on a Java EE application server in about 10 lines of code. And it will run on any Java EE 6-7 compliant server implementation (as a single JAX-RS application ... you'll need Java EE 7 for multiple JAX-RS applications per context).
EDIT:
I also should have pointed out that the "XML Hell" that was required to configure applications and almost every managed object in J2EE <= 4 has been eliminated. When the default behavior isn't quite what you want, meta-programming can be accomplished with an annotation in the code. The few remaining XML files can often be left empty - they're simply markers that activate features of the server (CDI bean scanning, Java Server Faces, etc).
Ignoring the business logic, a RESTful API can be built to run on a Java EE application server in about 10 lines of code. And it will run on any Java EE 6-7 compliant server implementation (as a single JAX-RS application ... you'll need Java EE 7 for multiple JAX-RS applications per context).
EDIT:
I also should have pointed out that the "XML Hell" that was required to configure applications and almost every managed object in J2EE <= 4 has been eliminated. When the default behavior isn't quite what you want, meta-programming can be accomplished with an annotation in the code. The few remaining XML files can often be left empty - they're simply markers that activate features of the server (CDI bean scanning, Java Server Faces, etc).
Excellent timing. So I have played most of the time since college in Python, bash, Perl, and very little Ruby (in that order). I am going back to school to Java as part of my "torture yourself with the basics you blew off" undergrad career that was not CS, and now had a change of heart.
I have seen in /r/java and Reddit and elsewhere people eschew even for newbies the use of Spring Boot, Ninja, Dropwizard in company. Some like you say Java EE is very friendly and I can write a full-featured REST service in like a dozen or so lines of Java. Seeing as I wrote small pieces of homework "employee ID insertion into memory" classes in like 100-200 lines, can you show me said examples? Hyperbole or not, I would love to see good articles about building REST services and other stuff in pure Java EE and/or JAX-RS style explaining how a Java newbie can do this stuff.
I think other novates would greatly appreciate. The expanse of Java web libraries is so vast even showing the minimalist modern style I am jealous of in your post would be a huge benefit to me.
UPDATE: Oh Jesus Christ! Now I remember why the name Zeef seemed familiar. You make that one of the few tutorial sites I found. Now, I will go crawl under the HN couch while onlookers stare and surpress chuckles. Always read the articles, dammit! Or meet me under the couch, rather.
I have seen in /r/java and Reddit and elsewhere people eschew even for newbies the use of Spring Boot, Ninja, Dropwizard in company. Some like you say Java EE is very friendly and I can write a full-featured REST service in like a dozen or so lines of Java. Seeing as I wrote small pieces of homework "employee ID insertion into memory" classes in like 100-200 lines, can you show me said examples? Hyperbole or not, I would love to see good articles about building REST services and other stuff in pure Java EE and/or JAX-RS style explaining how a Java newbie can do this stuff.
I think other novates would greatly appreciate. The expanse of Java web libraries is so vast even showing the minimalist modern style I am jealous of in your post would be a huge benefit to me.
UPDATE: Oh Jesus Christ! Now I remember why the name Zeef seemed familiar. You make that one of the few tutorial sites I found. Now, I will go crawl under the HN couch while onlookers stare and surpress chuckles. Always read the articles, dammit! Or meet me under the couch, rather.
Is this article telling the story of someone who's been on the JEE for 12 years, loves it, and would certainly choose it again.
While I'm happy for him, I dont think it makes a good case JEE as a "startup's secret weapon" (SSW).
By hypothetical comparison, if someone used 6 major tool chains for the last $DOUBLE_DIGIT_NUMBER years, and by comparison says one particular tool chain is an SSW, then I'm much more inclined to value the recommendation.
While I'm happy for him, I dont think it makes a good case JEE as a "startup's secret weapon" (SSW).
By hypothetical comparison, if someone used 6 major tool chains for the last $DOUBLE_DIGIT_NUMBER years, and by comparison says one particular tool chain is an SSW, then I'm much more inclined to value the recommendation.
I agree with what you say. Certainly would have had a bit more value if the article had elaborated on whether they used anything else. I feel the interviewer should have asked about that. Even a "no, we didn't" would have been valuable. Now we know nothing.
That said, it DOES mean that they have been happy with Java EE and have been so happy that they choose it again for their latest startup.
Contrast this with a typical startup where engineers always seem to hate whatever they used before and are like children in a candy shop for having the opportunity to use whatever we think is cool here.
That said, it DOES mean that they have been happy with Java EE and have been so happy that they choose it again for their latest startup.
Contrast this with a typical startup where engineers always seem to hate whatever they used before and are like children in a candy shop for having the opportunity to use whatever we think is cool here.
> That said, it DOES mean that they have been happy with Java EE
Sure. I'm also happy for them, and I acknowledge JEE's massive installed-base and performance.
Just the "startup secret weapon" claim/title I thought was unfounded.
Sure. I'm also happy for them, and I acknowledge JEE's massive installed-base and performance.
Just the "startup secret weapon" claim/title I thought was unfounded.
I hear you. I personally stand by the title choice because IMHO there are two facets to Java EE. I'm not saying that it's a fact (I simply don't have the data to back it up), but those 2 facets I see are:
* huge installed enterprise base
* modernisation of the platform aiming it a both small and big users
I've been active in Java/Java EE for some time, and I know that these facets can be at odds with each other.
For instance Java EE people wanting to support enterprises exclusively still think in needs of enterprises, which means there's always a dedicated ops team, an installed server that nobody but ops can touch and developers that communicate with ops via tickets.
This warrants having data sources and security modules configured outside the application and maintained by ops.
For small users this is silly overhead. When you're the only one developing an app the security module can be right inside the app.
Some Java EE people have introduced mechanisms to do so, but the enterprise people who are still there hate it, saying a server should always be maintained by an ops team. The very idea that a small shop doesn't have an ops team just doesn't occur to them.
Long story, but the simplifications that are making Java EE incresingly suitable for small shops and startups, while maintaining access to the power of the full platform to me doesn't seem well known yet.
* huge installed enterprise base
* modernisation of the platform aiming it a both small and big users
I've been active in Java/Java EE for some time, and I know that these facets can be at odds with each other.
For instance Java EE people wanting to support enterprises exclusively still think in needs of enterprises, which means there's always a dedicated ops team, an installed server that nobody but ops can touch and developers that communicate with ops via tickets.
This warrants having data sources and security modules configured outside the application and maintained by ops.
For small users this is silly overhead. When you're the only one developing an app the security module can be right inside the app.
Some Java EE people have introduced mechanisms to do so, but the enterprise people who are still there hate it, saying a server should always be maintained by an ops team. The very idea that a small shop doesn't have an ops team just doesn't occur to them.
Long story, but the simplifications that are making Java EE incresingly suitable for small shops and startups, while maintaining access to the power of the full platform to me doesn't seem well known yet.
I respect your views totally. But I still disagree on the title.
> huge installed enterprise base
This is more a reason for a consulting shop to pick JEE.
All in all I think the article more describes why one cannot get around JEE for enterprise work. And how JEE is not as terrible as it was.
That last point assumes levels of "terribleness" are well understood by by many.
When it comes to "startup secret weapons" (except maybe for startups that have to tie in with enterprise systems), I think JEE is the last thing that comes to my mind. Even after reading the article.
> huge installed enterprise base
This is more a reason for a consulting shop to pick JEE.
All in all I think the article more describes why one cannot get around JEE for enterprise work. And how JEE is not as terrible as it was.
That last point assumes levels of "terribleness" are well understood by by many.
When it comes to "startup secret weapons" (except maybe for startups that have to tie in with enterprise systems), I think JEE is the last thing that comes to my mind. Even after reading the article.
We're all free to have our opinions ;)
About the reason for the consulting shop to pick EE because of the installed base, that was indeed my point regarding the first facet.
The first facet (huge base) is what appeals to enterprises. The second facet (modernisation & aimed at small users) is what appeals to startups.
That EE had a huge installed base is pretty well known I think. But that EE now also aims at small shops? Perhaps not so much ;)
About the reason for the consulting shop to pick EE because of the installed base, that was indeed my point regarding the first facet.
The first facet (huge base) is what appeals to enterprises. The second facet (modernisation & aimed at small users) is what appeals to startups.
That EE had a huge installed base is pretty well known I think. But that EE now also aims at small shops? Perhaps not so much ;)
That was a good interview. A few years ago, I took almost a year out to help a friend (from since we were little kids) and his company and they were a J2EE shop for the server side. One of the first things I did was to buy one of Adam Bien's J2EE books because I had not touched J2EE for years. My friend is a true Java Ninja and his architecture and code were elegant. That said, for my own stuff I like the simplicity of Clojure and Compojure :-)
I looked at zeef.com and it is an interesting idea, but I tried searching for a few broad topics that I am an expert in and found the results so-so. zeef.com needs a larger number of human experts contributing.
I looked at zeef.com and it is an interesting idea, but I tried searching for a few broad topics that I am an expert in and found the results so-so. zeef.com needs a larger number of human experts contributing.
When HN comment mention how bad is "J2EE", I start to know the it refer to old J2EE (J2EE 1.4 (November 11, 2003)). Now is JEE 7, no more J2EE!
Yes, JEE/Java is bad but please, there is no perfect framework/language. Ruby/Python/NodeJS whatever is awesome, but it does not mean that it is perfect langauge either.
Now JEE 7 is awesome enough that you should stop mention J2EE.
Also, Java maintenance best backward comparability that I ever know. Anyone want to discuss Python 2 vs Python 3 and Ruby 1.8 vs Ruby 2?
Yes, JEE/Java is bad but please, there is no perfect framework/language. Ruby/Python/NodeJS whatever is awesome, but it does not mean that it is perfect langauge either.
Now JEE 7 is awesome enough that you should stop mention J2EE.
Also, Java maintenance best backward comparability that I ever know. Anyone want to discuss Python 2 vs Python 3 and Ruby 1.8 vs Ruby 2?
it's funny to see the same defense over and over. no one said any other framework is perfect, but JEE is design-by-committee crap mainly designed to sell consulting hours. that lack of external perfection does not make JEE usable or worthwhile.
>JEE is design-by-committee crap mainly designed to sell consulting hours.
To whom does Geronimo sell consulting hours?
The design-by-committee hasn't been the case for at least 10 years. J2EE 1.4 was the last version largely developed that way. The last released version (EE 7) and the current one (EE 8) sees a lot of community contributions.
People from the community create JIRA issues, send contributions, even implement entire features (see the work for JSF 2.3 and MVC 1.0).
If that's design-by-committee then everything is design-by-committee.
To whom does Geronimo sell consulting hours?
The design-by-committee hasn't been the case for at least 10 years. J2EE 1.4 was the last version largely developed that way. The last released version (EE 7) and the current one (EE 8) sees a lot of community contributions.
People from the community create JIRA issues, send contributions, even implement entire features (see the work for JSF 2.3 and MVC 1.0).
If that's design-by-committee then everything is design-by-committee.
it's funny to see the same defense (JEE is design-by-committee crap ) over and over :)
> that lack of external perfection does not make JEE usable or worthwhile.
So tell me, which framework does not lack of external perfection and make it usable or worthwhile.
> that lack of external perfection does not make JEE usable or worthwhile.
So tell me, which framework does not lack of external perfection and make it usable or worthwhile.
For rich web applications, GWT is a great option. It is a blessing to write the frontend with the same language and toolchain as the backend, re-using domain classes and constants across the projects.
Our current project uses Spring MVC for the backend, exposing REST services, and GWT for the frontend, with Resty for marshalling data structures back and forth. It works really well.
Our current project uses Spring MVC for the backend, exposing REST services, and GWT for the frontend, with Resty for marshalling data structures back and forth. It works really well.
And there's Errai to extend server side CDI (injection, events and context) to the GWT client side application. Substitute REST (using JAX-RS) for the server-side calls and you can provide the same API for external programs and your GWT client.
How do you feel about improvements in GWT development speed? In terms of development mode, compilation times and the whole process of making a java code change and seeing the result in a browser? Is there a lot of work on making this better?
GWT is nice, but I remember a lot of frustration came from buggy dev modes and compilation times.
GWT is nice, but I remember a lot of frustration came from buggy dev modes and compilation times.
We've been using GWT master with both incremental compilation + Java 8 lambdas (!) and it's pretty fun.
Granted, the non-JVM debugging experience is not nearly as magical as it was before, but I believe there is some work afoot to merge SDBG (source map-based debugging in Eclipse) + the GWT plugin. Still WIP.
Granted, the non-JVM debugging experience is not nearly as magical as it was before, but I believe there is some work afoot to merge SDBG (source map-based debugging in Eclipse) + the GWT plugin. Still WIP.
It has improved a lot just within the last year, with the new development mode landing, and it will be really good once incremental compilation arrives, which is scheduled for this year. Just compile, refresh browser, done.
I kind of enjoyed debugging in the IDE with the old dev mode, but I agree it was kind of quirky and slow.
I kind of enjoyed debugging in the IDE with the old dev mode, but I agree it was kind of quirky and slow.
Seems like people are upset that they didn't compare JEE to common frameworks and platforms that startups are known to use often like node.js w/ Express, Ruby on Rails, and Django rather than trying to explain more of what's interesting about modern JEE.
Try other frameworks like Play, Spring,before you are confident to speak out the word "productive", try other frameworks from other languages like Rails before you are confident about start up speed
I tried rails once. Startup was fast, but after 3 months we got stuck and things weren't so fast anymore.
Modern Java EE let's you start about as fast as rails, especially when starting from a good Maven archetype. The code is immensely simplified. I got a backend service with JAX-RS and CDI running in literally no time!
Modern Java EE let's you start about as fast as rails, especially when starting from a good Maven archetype. The code is immensely simplified. I got a backend service with JAX-RS and CDI running in literally no time!
There is no doubt this combination would be extremely high performant e.g. Wildfly was always in the top handful on Techempower benchmarks. But using JSF and EJB is a pretty extraordinary combination to be using these days. You would honestly be laughed out of every Java development team for even considering it.
Would definitely like to see why something like Dropwizard, Vert.x or even Play 1 wasn't considered.
Would definitely like to see why something like Dropwizard, Vert.x or even Play 1 wasn't considered.
JSF and EJB are the reason why Java EE is lately considered the "secret weapon".
The fact is that both invoke memories of old times where they were very heavyweight and problematic technologies.
EJB was a total disaster, where you needed to implement 3 interfaces and inherit from a framework provided base class, compile your code with a special "enhancing" tool and run yet another tool to generate something called stubs and skeletons, just to do hello world.
Modern EJB on the other hand is a POJO with a single annotation:
In modern Java EE there's no reason whatsoever to avoid EJB.
There's a similar story with JSF. The first versions (1.x) were mostly POST focused, had heavy session space requirements, and components were hard to create.
In modern JSF 2.x, there's first class support for using GET, and the PRG pattern is at the heart of interactions that are logically POST. Session requiremebts are largely minimized by use of a partial state saving (only changes to state are saved) and a stateless mode (nothing is saved). You can use plain html to author pages with a single extra namespaced attribute to mark it as a component to JSF.
Again a night and day difference and no need to avoid it anymore.
Then JSF has a number of very cool extensions available such as PrimeFaces (beautiful visual components) and OmniFaces (Swiss army knife like Guave is for plain Java)
The fact is that both invoke memories of old times where they were very heavyweight and problematic technologies.
EJB was a total disaster, where you needed to implement 3 interfaces and inherit from a framework provided base class, compile your code with a special "enhancing" tool and run yet another tool to generate something called stubs and skeletons, just to do hello world.
Modern EJB on the other hand is a POJO with a single annotation:
@Stateless
public class Bean {
// do something
}
In modern Java EE there's no reason whatsoever to avoid EJB.
There's a similar story with JSF. The first versions (1.x) were mostly POST focused, had heavy session space requirements, and components were hard to create.
In modern JSF 2.x, there's first class support for using GET, and the PRG pattern is at the heart of interactions that are logically POST. Session requiremebts are largely minimized by use of a partial state saving (only changes to state are saved) and a stateless mode (nothing is saved). You can use plain html to author pages with a single extra namespaced attribute to mark it as a component to JSF.
Again a night and day difference and no need to avoid it anymore.
Then JSF has a number of very cool extensions available such as PrimeFaces (beautiful visual components) and OmniFaces (Swiss army knife like Guave is for plain Java)
The fact that people that have used Java do not realize that EJB3 is pretty good, when it's pretty old! I switched to EJB3 in 2006, and I really couldn't see why people would choose Spring anything instead. The switch to Soap, and then to Rest, was changing a couple of annotations. Not bad for a 9 year old framework.
Now, my biggest problem with the stack, and the reason I do not use it anymore, is Java itself. A switch to Scala makes a lot of the Java boilerplate go away, and even Java 8 doesn't get close. Now, I find all the major Scala web libraries to be lacking, in one form or another. Play's second compilation feels clumsy. Spray's freedom of routing leads to very ugly code: Just look at their own large examples. So what I am currently doing is using a homebrew routing on top of Spray, which also gives me some documentation for free: Pretty useful when you have hundreds of services in hundreds of servers.
It's a pity that Java itself moves so slowly, and is so reluctant from adding key features, like pattern matching, because the rest of the tooling is pretty good.
Now, my biggest problem with the stack, and the reason I do not use it anymore, is Java itself. A switch to Scala makes a lot of the Java boilerplate go away, and even Java 8 doesn't get close. Now, I find all the major Scala web libraries to be lacking, in one form or another. Play's second compilation feels clumsy. Spray's freedom of routing leads to very ugly code: Just look at their own large examples. So what I am currently doing is using a homebrew routing on top of Spray, which also gives me some documentation for free: Pretty useful when you have hundreds of services in hundreds of servers.
It's a pity that Java itself moves so slowly, and is so reluctant from adding key features, like pattern matching, because the rest of the tooling is pretty good.
Yeah, EJB 3 is itself really not that new, but it took some time for implementations to come out. JBoss AS 5 took ages and EAP even longer. Then people had to upgrade from their older versions and then had to discover how much the new APIs had improved.
I don't have hard numbers, but judging from popular comments online I'm carefully guessing that it wasn't until ~2011 until people really started to see how simple EJB had become.
The old stigma still clings to it, much undeserved.
I don't have hard numbers, but judging from popular comments online I'm carefully guessing that it wasn't until ~2011 until people really started to see how simple EJB had become.
The old stigma still clings to it, much undeserved.
> I really couldn't see why people would choose Spring anything instead
Testing. Updates and fixes not tied to server releases (which can take years).
Testing. Updates and fixes not tied to server releases (which can take years).
Fixes don't take years with Java EE!!!
We're using JBoss and there's an updated version mostly every few weeks, months at most. Absolutely not years, that's totally ridiculous and tells me you've never really used Java EE.
We're using JBoss and there's an updated version mostly every few weeks, months at most. Absolutely not years, that's totally ridiculous and tells me you've never really used Java EE.
JBoss still doesn't have a supported Java EE 7 server. JBoss releases still much less frequently than Spring. If you want to look at how quickly things are fixed in JBoss have a look at this:
https://issues.jboss.org/browse/SECURITY-746
If you need a feature in Java EE you have to wait several years for the next Java EE release and several years more for the next server release that implements this, see JBoss.
If you need a feature in Java EE you have to wait several years for the next Java EE release and several years more for the next server release that implements this, see JBoss.
You're mixing up things.
JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/
You're quoting an individual bug that has been open for some time. Did you also looked at the many bugs that were fixed after a few hours after being reported? Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?
Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want). That's the time between 2 spec releases. It's about the same time as between major supported JBoss releases, so between EAP 5, 6 and 7. There's 3 to 4 years between major Spring releases (Spring 2 2006, Spring 3 2009, Spring 4 2013).
And Java SE doesn't release a major new version montly, let alone yearly either. A spec should move fast enough to stay relevant, but slow enough to provide the stability needed so lots of other technology can build on it.
JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/
You're quoting an individual bug that has been open for some time. Did you also looked at the many bugs that were fixed after a few hours after being reported? Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?
Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want). That's the time between 2 spec releases. It's about the same time as between major supported JBoss releases, so between EAP 5, 6 and 7. There's 3 to 4 years between major Spring releases (Spring 2 2006, Spring 3 2009, Spring 4 2013).
And Java SE doesn't release a major new version montly, let alone yearly either. A spec should move fast enough to stay relevant, but slow enough to provide the stability needed so lots of other technology can build on it.
> JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/
http://jbossas.jboss.org/downloads
EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months
> Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?
In about 50% of the times I have reported bugs or submitted pull requests against Spring they were closed within 6 hours. Spring releases about a month apart. The other 50% lay dormant for years. Still way better than any contribution I tried to make so far to Java EE. 0% success in about 6 tries.
> Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want).
https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edit...
Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3 years
http://jbossas.jboss.org/downloads
EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months
> Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?
In about 50% of the times I have reported bugs or submitted pull requests against Spring they were closed within 6 hours. Spring releases about a month apart. The other 50% lay dormant for years. Still way better than any contribution I tried to make so far to Java EE. 0% success in about 6 tries.
> Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want).
https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edit...
Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3 years
>EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months
That's skipping a lot of updates. EAP 6.2.2: 1 month EAP 6.2.3: 2 months EAP 6.2.4 1 month EAP EAP 6.3.0: 1.5 months Etc
>The other 50% lay dormant for years
So this exactly the same as with a Java EE implementation or any other open source project for that matter. Many get fixed in hours, others weeks or months and some years or simply never. Spring is not inherently better here as their track record proves. That your personal reports were of no success maybe says more about yourself than of any Java EE implementation. I got many bugs fixed and have seen others reporting bugs that have been fixed in no time.
>Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3 years
I was more referring to this one: http://arjan-tijms.omnifaces.org/2014/10/java-ee-process-cyc...
The actual time spend on the spec is less (see table). Whatever number you look at, it's not that different from the major Spring releases, and Spring is a product even, not a spec.
That's skipping a lot of updates. EAP 6.2.2: 1 month EAP 6.2.3: 2 months EAP 6.2.4 1 month EAP EAP 6.3.0: 1.5 months Etc
>The other 50% lay dormant for years
So this exactly the same as with a Java EE implementation or any other open source project for that matter. Many get fixed in hours, others weeks or months and some years or simply never. Spring is not inherently better here as their track record proves. That your personal reports were of no success maybe says more about yourself than of any Java EE implementation. I got many bugs fixed and have seen others reporting bugs that have been fixed in no time.
>Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3 years
I was more referring to this one: http://arjan-tijms.omnifaces.org/2014/10/java-ee-process-cyc...
The actual time spend on the spec is less (see table). Whatever number you look at, it's not that different from the major Spring releases, and Spring is a product even, not a spec.
> Whatever number you look at, it's not that different from the major Spring releases, and Spring is a product even, not a spec.
Spring releases are every month. When there is a bug in a Java EE spec (like the WebSocket/CDI integration or the CDI annotation scanning in EE 7) you have to wait for the next major spec version to fix it. The spec has to be "perfect" for 3 to 4 years because there is no way to fix it.
Spring releases are every month. When there is a bug in a Java EE spec (like the WebSocket/CDI integration or the CDI annotation scanning in EE 7) you have to wait for the next major spec version to fix it. The spec has to be "perfect" for 3 to 4 years because there is no way to fix it.
>The spec has to be "perfect" for 3 to 4 years because there is no way to fix it.
This is absolutely not true.
There's the MR (Maintenance Release) for that. See for example JSF 2.1 and CDI 1.2. They were intermediate quick releases between major Java EE versions.
Even the platform spec itself can have a MR. Currently there's an MR for Java EE 7 in the works. See https://java.net/downloads/javaee-spec/JavaEE_7_Platform_MR_...
Because it's a spec, naturally more consideration has to go into it. Many implementations depend on it to be stable. In case of Spring there's only one Spring. Take it or leave it. Not having a spec behind you can be an advantage (change things whenever you want), but is a disadvantage as well (the implicit specification of how things work is in the code, but Java is not declarative and it's always a guess if specific behavior is just an implementation side-effect or an intended one).
Even changing things whenever you want can be a disadvantage. A spec naturally favors stability, which means I can run my old code with minimal or no changes at modern Java EE. Try that for regular open source libraries (be it from within the Java EE universe, Spring universe, or whatever). Chances are that the APIs and config files have changed 10 tens in the meantime.
This is absolutely not true.
There's the MR (Maintenance Release) for that. See for example JSF 2.1 and CDI 1.2. They were intermediate quick releases between major Java EE versions.
Even the platform spec itself can have a MR. Currently there's an MR for Java EE 7 in the works. See https://java.net/downloads/javaee-spec/JavaEE_7_Platform_MR_...
Because it's a spec, naturally more consideration has to go into it. Many implementations depend on it to be stable. In case of Spring there's only one Spring. Take it or leave it. Not having a spec behind you can be an advantage (change things whenever you want), but is a disadvantage as well (the implicit specification of how things work is in the code, but Java is not declarative and it's always a guess if specific behavior is just an implementation side-effect or an intended one).
Even changing things whenever you want can be a disadvantage. A spec naturally favors stability, which means I can run my old code with minimal or no changes at modern Java EE. Try that for regular open source libraries (be it from within the Java EE universe, Spring universe, or whatever). Chances are that the APIs and config files have changed 10 tens in the meantime.
[deleted]
> In modern Java EE there's no reason whatsoever to avoid EJB.
I don't see much reason to use it, either. The only exception is for distributed transactions, where session beans serve as nice abstractions as entry points and managers for the transactions.
I don't see much reason to use it, either. The only exception is for distributed transactions, where session beans serve as nice abstractions as entry points and managers for the transactions.
>I don't see much reason to use it, either.
For regular transactions (local, one transactional resource involved) they're still pretty handy as well. EJBs also have things like @Asynchronous, @RolesAllowed and the timer service. The @Stateless concept itself can be just the right abstraction as well.
Eventually though the EJB model will be decomposed and its services made available via CDI.
This is NOT because the EJB model is bad or unworkable, but because it makes sense to align everything on a single component model.
For regular transactions (local, one transactional resource involved) they're still pretty handy as well. EJBs also have things like @Asynchronous, @RolesAllowed and the timer service. The @Stateless concept itself can be just the right abstraction as well.
Eventually though the EJB model will be decomposed and its services made available via CDI.
This is NOT because the EJB model is bad or unworkable, but because it makes sense to align everything on a single component model.
I don't understand how "sucking less" makes JSF a secret weapon. What advantages does it provide over other, simpler ways of managing templates and views?
Let's turn it around, what do these "other" ways have as advantage?
It's not sucking less, it's completely not sucking at all. JSF is very powerful and easy these days. I've dabbled in various other technologies, and I think they pretty much all sucked and where much more complicated.
I do like AngularJS 1 somewhat, but it's a client side technology which has its own set of disadvantages (remember why Twitter went back to serverside generation of "ready-to-render-html")
It's not sucking less, it's completely not sucking at all. JSF is very powerful and easy these days. I've dabbled in various other technologies, and I think they pretty much all sucked and where much more complicated.
I do like AngularJS 1 somewhat, but it's a client side technology which has its own set of disadvantages (remember why Twitter went back to serverside generation of "ready-to-render-html")
Not extraordinary if you're an enterprise shop. What's not cool and old school for startups is probably the widest used web / services framework in the enterprise world, vying only with Spring and ASP.net
There are probably more java EE jobs out there than ruby ones. (It doesn't say anything really, except the fact that some places don't laugh at you if you suggest Java EE, some places would laugh at you if you suggest anything else)
There are probably more java EE jobs out there than ruby ones. (It doesn't say anything really, except the fact that some places don't laugh at you if you suggest Java EE, some places would laugh at you if you suggest anything else)
Sure it's not extraordinary to still see them used. But suggested for a new project ?
I've spent at least 15 years in enterprise companies and most new projects I've seen have been Scala/Clojure/Java 8 style in microservices form. Less so the monolithic WAR style apps.
Not dismissing the choice at all. Would just like to hear more about why they are bucking the popular trend.
I've spent at least 15 years in enterprise companies and most new projects I've seen have been Scala/Clojure/Java 8 style in microservices form. Less so the monolithic WAR style apps.
Not dismissing the choice at all. Would just like to hear more about why they are bucking the popular trend.
>But suggested for a new project ?
I'm seeing this a lot. If you browse the site the article's on you'll find some more examples.
The moral of the story is that "we" all think Java EE is very enterprisey and that it's anti the popular trend (which is AngularJS, Node.js, or were those popular yesterday?), and meanwhile a couple of startups are being very productive and able to start quickly with modern Java EE because "nobody" has realy noticed that Java EE slimmed down so much and got so much more productive.
I'm seeing this a lot. If you browse the site the article's on you'll find some more examples.
The moral of the story is that "we" all think Java EE is very enterprisey and that it's anti the popular trend (which is AngularJS, Node.js, or were those popular yesterday?), and meanwhile a couple of startups are being very productive and able to start quickly with modern Java EE because "nobody" has realy noticed that Java EE slimmed down so much and got so much more productive.
I guess it depends on the "hard core" ness of the enterprise. Walmart and such? Yes, scala / dropwizard / Vert.X and even Node.JS can be popular. Bank of X? X insurance? You will be suggesting even to upgrade to the latest Java EE and look like a crazy revolutionist.
>But using JSF and EJB is a pretty extraordinary combination to be using these days. You would honestly be laughed out of every Java development team for even considering it.
You'd be surprised.
I don't even know where you got that idea. BOTH are widely deployed and used in enterprise.
You'd be surprised.
I don't even know where you got that idea. BOTH are widely deployed and used in enterprise.
From the article:
"So our strategy has been to reduce the number of relations between entities to what is strictly necessary, and occasionally to use JPA DTOs when a subset of data is needed for a rather complex entity. Such DTOs are populated using the constructor selector syntax in JPQL queries and JPA is generally smart enough to generate far more optimal queries then."
I have been using this "pattern" a lot lately, its great. looks something like this:
SELECT NEW mypackage.Pojo( e.id, oe.name ) FROM MyEntity e JOIN e.otherEntity oe WHERE e.someProperty = :parameter1
Its also possible to place these in external files, working around Javas inability to have multi line strings after all these years.
"So our strategy has been to reduce the number of relations between entities to what is strictly necessary, and occasionally to use JPA DTOs when a subset of data is needed for a rather complex entity. Such DTOs are populated using the constructor selector syntax in JPQL queries and JPA is generally smart enough to generate far more optimal queries then."
I have been using this "pattern" a lot lately, its great. looks something like this:
SELECT NEW mypackage.Pojo( e.id, oe.name ) FROM MyEntity e JOIN e.otherEntity oe WHERE e.someProperty = :parameter1
Its also possible to place these in external files, working around Javas inability to have multi line strings after all these years.
Perhaps OT: I often swing by Java web/services frameworks every year or so and I never see a good DB migration/evolution story. I'm fairly certain that it's because I don't know where to look or that I'm thinking about it incorrectly, but I've yet to see a Java web/services framework that supports the easy database migration/evolution schemes of Django/South or of Rails. Are these migration schemes not supported for a reason? Or am I missing the docs?
I imagine most Java web/services would consider it bad style/coupling to pick just one data back end (e.g. assume everyone uses JPA or Hibernate or what not), which would be needed to support migrations.
Even after Rails, the Java ecosystem is less "everything out of the box" and more "build your own stack". There are some exceptions, e.g. Grails and Play. Although both of those have migration modules:
https://www.playframework.com/modules/migrate-1.3.2/home
https://grails.org/plugin/database-migration
(First hits from Google, so apologies if those aren't the latest/best results.)
And, even then, I think both Grails/Play also try to be backend-agnostic, e.g. the migrations being plugins instead of first-class/backed in, like Rails which assumes "yeah, you'll basically always use a relational db".
Also, re migrations, a shameless plug for my ORM that relies on migrations+the database schema to codegen the rest of the boilerplate: http://joist.ws/.
Even after Rails, the Java ecosystem is less "everything out of the box" and more "build your own stack". There are some exceptions, e.g. Grails and Play. Although both of those have migration modules:
https://www.playframework.com/modules/migrate-1.3.2/home
https://grails.org/plugin/database-migration
(First hits from Google, so apologies if those aren't the latest/best results.)
And, even then, I think both Grails/Play also try to be backend-agnostic, e.g. the migrations being plugins instead of first-class/backed in, like Rails which assumes "yeah, you'll basically always use a relational db".
Also, re migrations, a shameless plug for my ORM that relies on migrations+the database schema to codegen the rest of the boilerplate: http://joist.ws/.
> I never see a good DB migration/evolution story
There's Flyway and Liquibase. Having that said, once you have branches, triggers, set up subpartitions and have PL/SQL blocks that mix DDL and DML things aren't easy anymore.
There's Flyway and Liquibase. Having that said, once you have branches, triggers, set up subpartitions and have PL/SQL blocks that mix DDL and DML things aren't easy anymore.
I can't really say how good they are but I found Liquibase (used by the Dropwizard framework), and FlyWay.
So there are some options available.
So there are some options available.
I hate to tell you all since none will thank me, but the horse has left the barn - we now have 'thick client' where the app is client side in .js.
Also consider APIs/Baas: Backendless.com, Kinvery, App42, etc. http://baas.apievangelist.com. DIY REST is purely optional, for companies w/ poor CTO/CFO. PHP, JSP, ASP, Rails, Django is in same boat, server side rendering of UI is past prime, we now need stunning UI, ex: datatables.net, Admin LTE, etc.
Framework today is UI Kit, BootStrap, Foundation, etc. That is a framework. Alternative to that is PhoneGap, Swift - and for Java, there is hope, in Android.
Also consider APIs/Baas: Backendless.com, Kinvery, App42, etc. http://baas.apievangelist.com. DIY REST is purely optional, for companies w/ poor CTO/CFO. PHP, JSP, ASP, Rails, Django is in same boat, server side rendering of UI is past prime, we now need stunning UI, ex: datatables.net, Admin LTE, etc.
Framework today is UI Kit, BootStrap, Foundation, etc. That is a framework. Alternative to that is PhoneGap, Swift - and for Java, there is hope, in Android.
I read somewhere that the best troll comments are ones where you can't tell if the poster actually means what he says or is trolling.
I can imagine that they feel themselves productive with EJB but only without the contrast say Ruby, Python or LISP would give.
Choosing Java over Ruby/Python for your web-app really depends on what you want to sacrifice.
I counted LISP out because unless you're using Clojure, I know for sure you're not going to be able to beat anything else for web-app development. LISP for web-app probably works in the 90's for PG but we're in 2015 where libraries, frameworks, and tools for these other languages are just far too advanced and more productive than writing macros... sorry mate.
Anyway, back to Java over Ruby/Python.
Take a few examples:
At the Microservice area, Java seems to shine over other languages/platforms. JAX-RS feels more complete than Sinatra or whatever Django plugins that the Python community use. See a quick example of JAX-RS vs Sinatra somewhere in this blog post: (http://www.appneta.com/blog/microservice-service-oriented-ar...)
Maven can be huge and underwhelming (and ugly once in a while) but it's definitely more powerful than gems+bundler+rake and whatever Python adopts these days. Maven has been around for a while so most Java DEVs don't have to pick up tools as Python DEVs have to do quite often. But again, there are trade-offs: Maven XML is definitely uglier than Bundler or requirements.txt or package.json.
Let me ask one thing: in platform other than Java, do you use declarative transaction? My guess is "No". Which means you have to know when to open and close a transaction (and potentially join an existing one if the library isn't smart enough). Java Spring/EJB provides annotation based transaction.
I'm not suggesting that Java is better than other languages, but there are advantages of choosing Java.
I counted LISP out because unless you're using Clojure, I know for sure you're not going to be able to beat anything else for web-app development. LISP for web-app probably works in the 90's for PG but we're in 2015 where libraries, frameworks, and tools for these other languages are just far too advanced and more productive than writing macros... sorry mate.
Anyway, back to Java over Ruby/Python.
Take a few examples:
At the Microservice area, Java seems to shine over other languages/platforms. JAX-RS feels more complete than Sinatra or whatever Django plugins that the Python community use. See a quick example of JAX-RS vs Sinatra somewhere in this blog post: (http://www.appneta.com/blog/microservice-service-oriented-ar...)
Maven can be huge and underwhelming (and ugly once in a while) but it's definitely more powerful than gems+bundler+rake and whatever Python adopts these days. Maven has been around for a while so most Java DEVs don't have to pick up tools as Python DEVs have to do quite often. But again, there are trade-offs: Maven XML is definitely uglier than Bundler or requirements.txt or package.json.
Let me ask one thing: in platform other than Java, do you use declarative transaction? My guess is "No". Which means you have to know when to open and close a transaction (and potentially join an existing one if the library isn't smart enough). Java Spring/EJB provides annotation based transaction.
I'm not suggesting that Java is better than other languages, but there are advantages of choosing Java.
Clojure is a LISP and from my experience I'm way faster with Clojure than with Java. Plus Clojure can use any java library. And by the way it seems that you have never used any lisp for web development. When you bump into the first problem with the bloatware made of 30.000 files and you have to debug it because there were no answers on stackoverflow...then you will find all out about the dark sides of "advanced frameworks".
You may think that, but productivity is really about a smart person who knows their tools.
And, of course, at least they won't have do a rewrite when it becomes apparent that they have to scale big time.
And, of course, at least they won't have do a rewrite when it becomes apparent that they have to scale big time.
This statement is false. If all else being equal the better tool you use the more productive you become. Take assembly for insance. You can know assembly arbitrarily well (and any assembly tools) you won't be faster with assembly than you are with java.
With Java EE being clearly the better tool compared to Python and Ruby.
Python is laughable. One word; GIL. Nuf said.
Python is laughable. One word; GIL. Nuf said.
That statement is not backed by any facts by you so it is unacceptable.
Google for "GIL Python" and have a laugh (or cry). I think that's enough backing for my statement to begin with.
Java, and so Java EE is considerably faster than Python, each and every benchmark out there proves this. Often it's up to a hundred times faster.
Java has a much richer ecosystem than Python and even more so than Ruby. Java projects are also much easier to maintain and much easier to scale.
Enough backing? It's just the start of why Java EE is the better tool ;)
Java, and so Java EE is considerably faster than Python, each and every benchmark out there proves this. Often it's up to a hundred times faster.
Java has a much richer ecosystem than Python and even more so than Ruby. Java projects are also much easier to maintain and much easier to scale.
Enough backing? It's just the start of why Java EE is the better tool ;)
Please, Java EE here is an offence to our intelligence. There are infoq and other yellow paid content sites for it. Please.
What's wrong if that platform is improving . There are so many really good java libraries to play with .
I for instance wanted to build a webapp with the StanfordNLP .
I for instance wanted to build a webapp with the StanfordNLP .
[deleted]
Oh, come on, the creator of this site has a whole essay about languages (or platforms) which has been made to solve actual problems faced by its creators or to solve other people's problems (to be sold to greater fools). There is no better example of second approach than J2EE.
To Google J2EE sucks is not that difficult. My favourite quote from Bell Labs folks - "whole encyclopedia could be written about what is wrong with J2EE". Rebranding doesn't matter - it is the same crappy mess of piles of unnecessary layes of ugly, redundant abstractions.
Don't be hypocrites. It sucks.
To Google J2EE sucks is not that difficult. My favourite quote from Bell Labs folks - "whole encyclopedia could be written about what is wrong with J2EE". Rebranding doesn't matter - it is the same crappy mess of piles of unnecessary layes of ugly, redundant abstractions.
Don't be hypocrites. It sucks.
> it is the same crappy mess of piles of unnecessary layes of ugly, redundant abstractions.
This is straw-man stuff based on an old view of who uses Java and when.
I've programmed in a lot of languages - C++, Java, Objective-C (with a NeXT, of course) and the trendier functional, meta-programming languages.
One of the cliches (and truisms) of C++ is that you only use a subset. This is what people are doing with Java these days. You can bring up high-performance web services using only a thin layer of J2EE and throw away all that cruft you mention. In my company we do it all with a third-party web layer and just SE (is it just J2EE you're agin - are you fine with SE?).
What Java brings to the table is a well-sorted high performance JVM, copious free and high-quality third-party libraries and a clear and easy to use syntax. Yea, it's quite verbose, but, as you know, you spend more time reading code than writing it...
This is straw-man stuff based on an old view of who uses Java and when.
I've programmed in a lot of languages - C++, Java, Objective-C (with a NeXT, of course) and the trendier functional, meta-programming languages.
One of the cliches (and truisms) of C++ is that you only use a subset. This is what people are doing with Java these days. You can bring up high-performance web services using only a thin layer of J2EE and throw away all that cruft you mention. In my company we do it all with a third-party web layer and just SE (is it just J2EE you're agin - are you fine with SE?).
What Java brings to the table is a well-sorted high performance JVM, copious free and high-quality third-party libraries and a clear and easy to use syntax. Yea, it's quite verbose, but, as you know, you spend more time reading code than writing it...
OK. This your choice and your conditionig.
I, if you allow me, would still hold an opinion that web services could be made without "everything is an object" meme or "static typing which catches errors". There are Arc and Erlang and even Common Lisp based solutions.
Also I would argue that Golang is a much better alternative, which has been creayed, in part, because J2EE sucks.
Straw man or whatever you would call it.
I, if you allow me, would still hold an opinion that web services could be made without "everything is an object" meme or "static typing which catches errors". There are Arc and Erlang and even Common Lisp based solutions.
Also I would argue that Golang is a much better alternative, which has been creayed, in part, because J2EE sucks.
Straw man or whatever you would call it.
> because J2EE sucks
It does, but Java EE is great! :)
It does, but Java EE is great! :)
Like the creators of sitcoms or junk food or package tours, Java’s designers were consciously designing a product for people not as smart as them. – Paul Graham
http://harmful.cat-v.org/software/java
http://harmful.cat-v.org/software/java
JSF is the slowest way to do web development for rich client UI: starting stopping J2EE servers is time consuming. HTML templating is difficult; you can't see what you screen looks like until you serve the page from your J2EE server .Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others. You are much better off using REST servlets or REST Spring MVC with your javascript. JSF impedes the growth of features or functionality on a page: as you add more widgets to you page like JQuery plugins , you will be suprised by the amount of backend code you will have to write. Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge. Sadly you wont discover this mess until you are waist deep in this pile of muck.
JPA is pretty awesome ; however I have learnt over the years that you need to fine tune your queries using explainplan rather that relying on generated queries; define the views on the db itself and load them with JPA; this way the others frameworks or related application ,like a ASP application or a python web application or reportng application, can also leverage the same data and view.