A Java EE Startup: Filtering information with zeef.com
adam-bien.com
adam-bien.com
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.
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
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.
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.
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.
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.
(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.
But the static typing is really good ,ofcourse the language too .Maybe I should I've tried Jersey .
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.
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.
> 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.
We all have our own preferences. I can guess what the "very little reason means". You hear this more often in Java (EE) discussions.
The thing is that in 2003/2004 Spring positioned itself as the necessary layer to make arcane Java EE APIs approachable and usable. With their FooBarTemplates Spring wraps everything that's wrappable, and at the time it made somewhat sense. Rod couldn't wrap EJB though, and as he deemed it "unfixable" he invented his own bean model to replace that.
At some point though Java EE started improving, and then started to improve a lot. Getting first class APIs such as JPA, co-designed by the Hibernate lead himself (Gavin King).
And what did Spring do? As a pavlov reaction they started wrapping again. But the JPA APIs were brand new, perfectly well designed, and didn't need wrapping. This was the basis of the fallout between Hibernate and Spring, and a revealing moment into how Spring operated. They weren't the benevolent dictator who out of the goodness of their hearts wanted to make life better for programmers, no, they just wanted you to depend on their APIs.
Rod later cashed big time, and Springsource, later pivotal became as commercial as the "evil" corporations they tried to wrap with their APIs.
Fast forward to Java EE 7, and Java EE has tons of perfectly fine APIs that don't need the Spring wrapping treatment. JMS, JPA, Bean Validation, CDI, EL, JAX-RS, ... NOTHING of that needs wrapping by Spring to make it usable. It's perfectly fine as-is.
So this is where the often heard "there's little reason to use Spring today" comes from, and I guess that is what was meant. Today Spring is just another platform. Java EE programmers don't need it to make their life better. Programmers in general can choose Java EE, or Spring, or .NET, or whatever.
If your preference is Spring, please, use it and be happy. It's not better than Java EE, but likely not much worse either. I've seen enough Spring code and Java EE code to say it's different, but still fairly equal.
I personally think the design process of Java EE is more open than that of Spring. Both are open source projects, and both have strong commercial influences as well as community influences, but with Java EE the design process is fully out in the open and people can comment on it and contribute. This is less the case with Spring. Yes, the source is open, but so is that of the Java EE RI and many other implementations. But Spring doesn't have an open design process, where Java EE has.
LOL, JMS. I take it you never actually used JMS. Where should I start? Ah yes, checked exceptions. JMS (of course) doesn't support Java 1.5, the API still uses raw types. Also JMS (of course) doesn't even support Java 1.4. You see JMS predates Throwable#getCause so JMSException#getCause is undefined and you have to use JMSException#getLinkedException. In addition the only way to wait on a Queue without blocking or polling is to use an MDB but there is no (!) standardized way to associate a RAR with an MDB. On top of that JMS is six APIs in one. There is the part old API that you're only allowed to use in Java EE, there is the part of the old API that you're only allowed to use in Java SE and then there a part of the old API that you're allowed to use in Java SE and Java EE. How do you know which methods fall into which category? Since Java EE 7 it's a comment in the Javadoc, otherwise you have to be familiar with the spec (yes, it is on a per-method basis, not an a per-interface basis). Then there is the new API (JMSContext) which follows the same "pattern" but uses runtime exceptions for certain parts until you're at the point where it uses checked exceptions again.
Yes, JMS, perfectly fine as-is and doesn't need wrapping to make it usable.
> But Spring doesn't have an open design process, where Java EE has.
I take it you're not actually a JCP member and tried to get a feature into a JSR? It you were you wouldn't make statements like this. Java EE is open only by name.
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.
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? 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.
Yes, and the only way of listening to a queue without polling or blocking in Java EE that JMS supports in through an MDB. The way you plug a custom JMS provider into Java EE is through a RAR. The way you connect the RAR to the MDB is undefined because "expert group" can't be bothered.
> Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs....
A very good explanation of what's wrong with JMS. The class to be notified and the configuration is the same file. If this was a host you would have the hostname and port of the message broker in the listener class file.
> Hey, if you have some ideas why not file a JIRA issue?
I personally spoke to the spec lead at JavaOne and he couldn't be bothered.
> Do you have a link to the issues you filed? I'm rather curious now.
Did you or did you not personally file a single issue?
And which expert group might that be? Java EE, JCA, JMS, EJB? There's no JCA EG at the moment, just a (former) spec lead who's available for maintenance. There's also no EJB EG at the moment.
As with any open source project, it's a matter of pushing if you really want to get some train getting forward. Linux is no different. Try persuading those guys to accept your patch. No easy feat.
Some things are just controversial in any project. I remember the endless debates in the Pidgin project about the stupid size of the text input.
In Java EE there are debates about having resources inside the war. Many are against, I argued for a long time that they should also be inside, and maybe my emails and posts helped since in Java EE 7 almost every resource can be defined in the war.
But if you first asked it, and asked the wrong person (e.g. this Jesper guy from JBoss) you'll get a NO, GO AWAY! If you are immediately turned down by that, nothing ever changes.
There's this other guy in Java EE who keeps bringing up the topic of standardizing logging, who doesn't seem to get very far. Some things are just not accepted, other things are a matter of talking to the right people, finding like minded souls and keep pushing. Again, no different from any other (big) open source project.
In this case, I'm simply not an expert on JCA, so I can't say if you're right or wrong. You did also say that JMS was not even at Java 1.4, which was clearly wrong, so I do take what you say with a grain of salt if you don't mind (no offense, really).
If this is indeed as badly defined as you claim, please, make your voice heard. Create a JIRA issue, tweet about it (cc @Java_ee or @dblevins). I know David has been fighting to improve JCA and make it simpler.
No product is perfect. If Java EE was utterly perfect than we would not have needed Java EE 8. But guess what, Spring is far from perfect either and by the same token if it was there would not have been a need for Spring 4 last year and there would not have been a need for the next version.
>A very good explanation of what's wrong with JMS.
The article is about JCA and EJB, I don't see JMS itself there.
>I personally spoke to the spec lead at JavaOne and he couldn't be bothered.
Which spec lead are you talking about? Nigel from JMS, or someone else?
>Did you or did you not personally file a single issue?
I love it how you conveniently evade the "prove" I provided that clearly shows that many features that ended up in Java EE originated from community proposed issues. Likewise, if you switch over to the implementation trackers you'll find that patches originate from the community. Be it for Mojarra (JSF), Hibernate (JPA), or whatever.
Whether I personally filed issues is almost irrelevant in the face of the examples I provided to you. But if you really want to know; yes, I filed a ton of issues. In fact, I filed a bunch from the very nick (henk53) I'm using here, as well as many in name of the customers I've been working for.
Quite a lot were resolved. Some in a short time, others took ridiculously long, but were eventually resolved. And some were never resolved. Geronimo is the one and only where I just could not get through to. Funny thing is that in theory they are the most open of all parties.
Have you ever attended a JCP meeting? The number one topic that pops up again and again for years has been open source (OSI) licensed TCK. The only party blocking that for years has been Oracle.
Instead of just acknowledging that in whatever way you're just evading the issue (again) and switching to another topic.
But to reply this new topic, TCK has been a thorn in the JCP process indeed. Not every spec has a closed TCK. CDI and Bean Validation have open ones, based on Arquillian, with an open source (OSI) license, and an associated issue tracker where everyone can open issues against it.
Now funny thing here is that CDI is rapidly becoming the underpinning of everything in Java EE. It's the core of Java EE's core.
For some other specs like JSF the TCK is unfortunately closed, but the RI (Mojarra) has such an extensive set of effective TCK tests that I wonder if there's anything at all in the TCK that's not covered by the RI tests.
Still, opening up the TCKs is another battle worth fighting.
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...
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.
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.)
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).
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.
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.
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.
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.
* 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
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.
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 ;)
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.
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?
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.
> 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.
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.
GWT is nice, but I remember a lot of frustration came from buggy dev modes and compilation times.
I kind of enjoyed debugging in the IDE with the old dev mode, but I agree it was kind of quirky and slow.
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.
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!
Would definitely like to see why something like Dropwizard, Vert.x or even Play 1 wasn't considered.
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)
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.
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)
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.
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.
Testing. Updates and fixes not tied to server releases (which can take years).
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.
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.
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.
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
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.
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.
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.
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.
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")
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.
So there are some options available.
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/.
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.
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.
And, of course, at least they won't have do a rewrite when it becomes apparent that they have to scale big time.
Python is laughable. One word; GIL. Nuf said.
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 ;)
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 for instance wanted to build a webapp with the StanfordNLP .
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.
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.
Straw man or whatever you would call it.
It does, but Java EE is great! :)