A Java EE Startup: Filtering information with zeef.com

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?

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.

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.

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.

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