10 ms·

A Java EE Startup: Filtering information with zeef.com

83 points by john-waterwood 11y ago

threeseed 11y ago
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.
- eranation 11y ago
  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)
  - threeseed 11y ago
    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.
    - eranation 11y ago
      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.
    - mikehaggard 11y ago
      >But suggested for a new project ? I'm seeing this a lot. If you browse the site the article's on you'll find some more examples. The moral of the story is that "we" all think Java EE is very enterprisey and that it's anti the popular trend (which is AngularJS, Node.js, or were those popular yesterday?), and meanwhile a couple of startups are being very productive and able to start quickly with modern Java EE because "nobody" has realy noticed that Java EE slimmed down so much and got so much more productive.
- john-waterwood 11y ago
  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)
  - hibikir 11y ago
    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.
- coldtea 11y ago
  >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.
edem 11y ago
I can imagine that they feel themselves productive with EJB but only without the contrast say Ruby, Python or LISP would give.
- speakeron 11y ago
  You may think that, but productivity is really about a smart person who knows their tools. And, of course, at least they won't have do a rewrite when it becomes apparent that they have to scale big time.
  - edem 11y ago
    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.
    - john-waterwood 11y ago
      With Java EE being clearly the better tool compared to Python and Ruby. Python is laughable. One word; GIL. Nuf said.
      - edem 11y ago
        That statement is not backed by any facts by you so it is unacceptable.
        john-waterwood 11y ago
        Google for "GIL Python" and have a laugh (or cry). I think that's enough backing for my statement to begin with. Java, and so Java EE is considerably faster than Python, each and every benchmark out there proves this. Often it's up to a hundred times faster. Java has a much richer ecosystem than Python and even more so than Ruby. Java projects are also much easier to maintain and much easier to scale. Enough backing? It's just the start of why Java EE is the better tool ;)
eranation 11y ago
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.
- mkawia 11y ago
  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 .
  - spacemanmatt 11y ago
    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.
    - eranation 11y ago
      I second that. If you really want to save time start with spring boot, or even a yeoman generator like JHipster...
    - john-waterwood 11y ago
      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
cies 11y ago
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.
- mikehaggard 11y ago
  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.
  - cies 11y ago
    > That said, it DOES mean that they have been happy with Java EE Sure. I'm also happy for them, and I acknowledge JEE's massive installed-base and performance. Just the "startup secret weapon" claim/title I thought was unfounded.
    - john-waterwood 11y ago
      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.
dschiptsov 11y ago
Please, Java EE here is an offence to our intelligence. There are infoq and other yellow paid content sites for it. Please.
- mkawia 11y ago
  What's wrong if that platform is improving . There are so many really good java libraries to play with . I for instance wanted to build a webapp with the StanfordNLP .
  - dschiptsov 11y ago
    Oh, come on, the creator of this site has a whole essay about languages (or platforms) which has been made to solve actual problems faced by its creators or to solve other people's problems (to be sold to greater fools). There is no better example of second approach than J2EE. To Google J2EE sucks is not that difficult. My favourite quote from Bell Labs folks - "whole encyclopedia could be written about what is wrong with J2EE". Rebranding doesn't matter - it is the same crappy mess of piles of unnecessary layes of ugly, redundant abstractions. Don't be hypocrites. It sucks.
    - speakeron 11y ago
      > 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...
smoyer 11y ago
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).
- 616c 11y ago
  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.
puppetmaster3 11y ago
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 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.
- blumkvist 11y ago
  I read somewhere that the best troll comments are ones where you can't tell if the poster actually means what he says or is trolling.
manishsharan 11y ago
JSF ? Oh those gullible youngsters ! 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.
- smoyer 11y ago
  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!
  - deleted 11y ago
    [deleted]
  - manishsharan 11y ago
    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.
    - henk53 11y ago
johnyzee 11y ago
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.
- smoyer 11y ago
  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.
- Ygor 11y ago
  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.
  - johnyzee 11y ago
    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.
  - stephen 11y ago
    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.
mark_l_watson 11y ago
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.
paukiatwee 11y ago
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?
- oldmanjay 11y ago
  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.
  - henk53 11y ago
    >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.
  - paukiatwee 11y ago
    it's funny to see the same defense (JEE is design-by-committee crap ) over and over :) > that lack of external perfection does not make JEE usable or worthwhile. So tell me, which framework does not lack of external perfection and make it usable or worthwhile.
devonkim 11y ago
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.
CoffeeDregs 11y ago
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?
- oblio 11y ago
  I can't really say how good they are but I found Liquibase (used by the Dropwizard framework), and FlyWay. So there are some options available.
- stephen 11y ago
  I imagine most Java web/services would consider it bad style/coupling to pick just one data back end (e.g. assume everyone uses JPA or Hibernate or what not), which would be needed to support migrations. Even after Rails, the Java ecosystem is less "everything out of the box" and more "build your own stack". There are some exceptions, e.g. Grails and Play. Although both of those have migration modules: https://www.playframework.com/modules/migrate-1.3.2/home https://www.playframework.com/modules/migrate-1.3.2/home https://grails.org/plugin/database-migration 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/ http://joist.ws/.
- needusername 11y ago
  > I never see a good DB migration/evolution story There's Flyway and Liquibase. Having that said, once you have branches, triggers, set up subpartitions and have PL/SQL blocks that mix DDL and DML things aren't easy anymore.
jincheker 11y ago
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
- john-waterwood 11y ago
  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!
bni 11y ago
From the article: "So our strategy has been to reduce the number of relations between entities to what is strictly necessary, and occasionally to use JPA DTOs when a subset of data is needed for a rather complex entity. Such DTOs are populated using the constructor selector syntax in JPQL queries and JPA is generally smart enough to generate far more optimal queries then." I have been using this "pattern" a lot lately, its great. looks something like this: SELECT NEW mypackage.Pojo( e.id, oe.name ) FROM MyEntity e JOIN e.otherEntity oe WHERE e.someProperty = :parameter1 Its also possible to place these in external files, working around Javas inability to have multi line strings after all these years.

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.

eranation 11y ago
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)
- threeseed 11y ago
  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.
  - eranation 11y ago
    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.
  - mikehaggard 11y ago
    >But suggested for a new project ? I'm seeing this a lot. If you browse the site the article's on you'll find some more examples. The moral of the story is that "we" all think Java EE is very enterprisey and that it's anti the popular trend (which is AngularJS, Node.js, or were those popular yesterday?), and meanwhile a couple of startups are being very productive and able to start quickly with modern Java EE because "nobody" has realy noticed that Java EE slimmed down so much and got so much more productive.
john-waterwood 11y ago
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)
- hibikir 11y ago
  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.
coldtea 11y ago
>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.

edem 11y ago

I can imagine that they feel themselves productive with EJB but only without the contrast say Ruby, Python or LISP would give.

speakeron 11y ago
You may think that, but productivity is really about a smart person who knows their tools. And, of course, at least they won't have do a rewrite when it becomes apparent that they have to scale big time.
- edem 11y ago
  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.
  - john-waterwood 11y ago
    With Java EE being clearly the better tool compared to Python and Ruby. Python is laughable. One word; GIL. Nuf said.
    - edem 11y ago
      That statement is not backed by any facts by you so it is unacceptable.
      - john-waterwood 11y ago
        Google for "GIL Python" and have a laugh (or cry). I think that's enough backing for my statement to begin with. Java, and so Java EE is considerably faster than Python, each and every benchmark out there proves this. Often it's up to a hundred times faster. Java has a much richer ecosystem than Python and even more so than Ruby. Java projects are also much easier to maintain and much easier to scale. Enough backing? It's just the start of why Java EE is the better tool ;)

eranation 11y ago

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.

mkawia 11y ago
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 .
- spacemanmatt 11y ago
  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.
  - eranation 11y ago
    I second that. If you really want to save time start with spring boot, or even a yeoman generator like JHipster...
  - john-waterwood 11y ago
    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

cies 11y ago

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.

mikehaggard 11y ago
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.
- cies 11y ago
  > That said, it DOES mean that they have been happy with Java EE Sure. I'm also happy for them, and I acknowledge JEE's massive installed-base and performance. Just the "startup secret weapon" claim/title I thought was unfounded.
  - john-waterwood 11y ago
    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.

dschiptsov 11y ago

Please, Java EE here is an offence to our intelligence. There are infoq and other yellow paid content sites for it. Please.

mkawia 11y ago
What's wrong if that platform is improving . There are so many really good java libraries to play with . I for instance wanted to build a webapp with the StanfordNLP .
- dschiptsov 11y ago
  Oh, come on, the creator of this site has a whole essay about languages (or platforms) which has been made to solve actual problems faced by its creators or to solve other people's problems (to be sold to greater fools). There is no better example of second approach than J2EE. To Google J2EE sucks is not that difficult. My favourite quote from Bell Labs folks - "whole encyclopedia could be written about what is wrong with J2EE". Rebranding doesn't matter - it is the same crappy mess of piles of unnecessary layes of ugly, redundant abstractions. Don't be hypocrites. It sucks.
  - speakeron 11y ago
    > 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...

smoyer 11y ago

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

616c 11y ago
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.

puppetmaster3 11y ago

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

blumkvist 11y ago
I read somewhere that the best troll comments are ones where you can't tell if the poster actually means what he says or is trolling.

manishsharan 11y ago

JSF ? Oh those gullible youngsters ! 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.

smoyer 11y ago
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!
- deleted 11y ago
  [deleted]
- manishsharan 11y ago
  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.
  - henk53 11y ago

johnyzee 11y ago

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.

smoyer 11y ago
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.
Ygor 11y ago
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.
- johnyzee 11y ago
  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.
- stephen 11y ago
  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.

mark_l_watson 11y ago

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.

paukiatwee 11y ago

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?

oldmanjay 11y ago
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.
- henk53 11y ago
  >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.
- paukiatwee 11y ago
  it's funny to see the same defense (JEE is design-by-committee crap ) over and over :) > that lack of external perfection does not make JEE usable or worthwhile. So tell me, which framework does not lack of external perfection and make it usable or worthwhile.

devonkim 11y ago

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.

CoffeeDregs 11y ago

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?

oblio 11y ago
I can't really say how good they are but I found Liquibase (used by the Dropwizard framework), and FlyWay. So there are some options available.
stephen 11y ago
I imagine most Java web/services would consider it bad style/coupling to pick just one data back end (e.g. assume everyone uses JPA or Hibernate or what not), which would be needed to support migrations. Even after Rails, the Java ecosystem is less "everything out of the box" and more "build your own stack". There are some exceptions, e.g. Grails and Play. Although both of those have migration modules: https://www.playframework.com/modules/migrate-1.3.2/home https://www.playframework.com/modules/migrate-1.3.2/home https://grails.org/plugin/database-migration 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/ http://joist.ws/.
needusername 11y ago
> I never see a good DB migration/evolution story There's Flyway and Liquibase. Having that said, once you have branches, triggers, set up subpartitions and have PL/SQL blocks that mix DDL and DML things aren't easy anymore.

jincheker 11y ago

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

john-waterwood 11y ago
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!

bni 11y ago

From the article: "So our strategy has been to reduce the number of relations between entities to what is strictly necessary, and occasionally to use JPA DTOs when a subset of data is needed for a rather complex entity. Such DTOs are populated using the constructor selector syntax in JPQL queries and JPA is generally smart enough to generate far more optimal queries then." I have been using this "pattern" a lot lately, its great. looks something like this: SELECT NEW mypackage.Pojo( e.id, oe.name ) FROM MyEntity e JOIN e.otherEntity oe WHERE e.someProperty = :parameter1 Its also possible to place these in external files, working around Javas inability to have multi line strings after all these years.