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.
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 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.
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.
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.
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.
>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.
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.
> 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.
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.)
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 .
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.
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
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.
>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
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.
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).
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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!
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.
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:
@Stateless
public class Bean {
// do something
}
That's all. There are no required framework or business interfaces, no obligation to put ejb beans in a separate EJB module and there are no specific compiler tools needed. It's a total day and night difference.
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.
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.
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.
> 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.
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")
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)
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'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.
"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:
(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/.
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 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.
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.
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".
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.
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.
> 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...
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.
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
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.