11 ms·

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 lac

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
    - StevePerkins 11y ago
      Oh, I couldn't possibly disagree more. JEE has come a long way, and it's a shame that people unfairly dismiss it today due to their ancient experiences with EJB 2.x. However, JEE is a very conservative stack, which suffers greatly from "design-by-committee". Spring therefore is, was, and always will be at least a generation or two ahead. JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use. Because the JEE model is to have a slew of libraries loaded at the global app server level, you're much more likely to run into conflicts with libraries that your application loads at its WAR/EAR file level. Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards. With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file. Moreover, it doesn't even have to be a WAR. You can easly bundle a production-grade embedded Tomcat instance (or Jetty or Undertow) directly within your application, building an executable JAR file with no dependencies whatsoever apart from having a JRE installed on the target machine. Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture. These days disk storage is a lot cheaper than unnecessary system complexity. Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size. Spring's dependency injection is straightforward, and compatible with other JSR-330 implementations like Guice and Dagger. I find JEE's CDI to be a clunky mess in contrast. In the presentation tier, Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms (Microsoft has meanwhile walked away from this as outdated bad practice). Last but not least, there is community engagement to consider. If you take a Spring problem to StackOverflow, you will have an answer within minutes. Hell, you could even take it to IRC and probably get answers in real-time. By comparison, the JEE "community" is practically non-existent... and if anything consists mostly of consultants seeking to sell you their time. Again, JEE has indeed come light years from where it was a decade ago. But because of its conservative, committee-based DNA... it will always be years behind Spring, and delivering solutions much more muddy and disjointed. Spring seems to occupy an ideal common-sense spot on the spectrum. It lags several years behind the "hipster" frameworks of other platforms, stealing at a stable and production-grade pace those innovations that prove themselves. At the same time, it's well ahead of the glacial pace at which those innovations make their way (poorly) into the Oracle-blessed standards.
- eranation 11y ago
  Yes, servlets are not the best for modern web development :) (although they have their uses...) JAX-RS (jersey is the reference implementation) is like a parallel universe, well designed, batteries included, statically typed REST API framewrok that has a lot of potential (I prefer it over Spring MVC in terms of syntax or even over play framework's routing)
mikehaggard 11y ago
> I think it just lacks a new MVC module as an alternative to JSF. In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem 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.
- eranation 11y ago
  This is great news!
- deleted 11y ago
  [deleted]
- stephen 11y ago
  Personally, I think "blessing" UI frameworks as JSRs ("official!") is a bad idea. I think it leads to the UI framework (e.g. JSF in the past or this new MVC spec) "winning" and getting adopted by teams who, if they had to evaluate several competing non-blessed frameworks, would pick something better/easier/more modern, but instead go with the JSR-backed option. Although perhaps I'm just being pessimistic. JSRs can probably be a good thing; as a programmer in the JVM ecosystem, I've just never considered "it's a JSR" as a brand of quality/something that should affect my choice, and if anything it's the opposite. (My pessimism aside, if they're basing the spec on existing good ideas, like JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart approach.)

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
  - StevePerkins 11y ago
    Oh, I couldn't possibly disagree more. JEE has come a long way, and it's a shame that people unfairly dismiss it today due to their ancient experiences with EJB 2.x. However, JEE is a very conservative stack, which suffers greatly from "design-by-committee". Spring therefore is, was, and always will be at least a generation or two ahead. JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use. Because the JEE model is to have a slew of libraries loaded at the global app server level, you're much more likely to run into conflicts with libraries that your application loads at its WAR/EAR file level. Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards. With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file. Moreover, it doesn't even have to be a WAR. You can easly bundle a production-grade embedded Tomcat instance (or Jetty or Undertow) directly within your application, building an executable JAR file with no dependencies whatsoever apart from having a JRE installed on the target machine. Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture. These days disk storage is a lot cheaper than unnecessary system complexity. Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size. Spring's dependency injection is straightforward, and compatible with other JSR-330 implementations like Guice and Dagger. I find JEE's CDI to be a clunky mess in contrast. In the presentation tier, Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms (Microsoft has meanwhile walked away from this as outdated bad practice). Last but not least, there is community engagement to consider. If you take a Spring problem to StackOverflow, you will have an answer within minutes. Hell, you could even take it to IRC and probably get answers in real-time. By comparison, the JEE "community" is practically non-existent... and if anything consists mostly of consultants seeking to sell you their time. Again, JEE has indeed come light years from where it was a decade ago. But because of its conservative, committee-based DNA... it will always be years behind Spring, and delivering solutions much more muddy and disjointed. Spring seems to occupy an ideal common-sense spot on the spectrum. It lags several years behind the "hipster" frameworks of other platforms, stealing at a stable and production-grade pace those innovations that prove themselves. At the same time, it's well ahead of the glacial pace at which those innovations make their way (poorly) into the Oracle-blessed standards.
eranation 11y ago
Yes, servlets are not the best for modern web development :) (although they have their uses...) JAX-RS (jersey is the reference implementation) is like a parallel universe, well designed, batteries included, statically typed REST API framewrok that has a lot of potential (I prefer it over Spring MVC in terms of syntax or even over play framework's routing)

mikehaggard 11y ago

> I think it just lacks a new MVC module as an alternative to JSF. In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem 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.

eranation 11y ago
This is great news!
deleted 11y ago
[deleted]
stephen 11y ago
Personally, I think "blessing" UI frameworks as JSRs ("official!") is a bad idea. I think it leads to the UI framework (e.g. JSF in the past or this new MVC spec) "winning" and getting adopted by teams who, if they had to evaluate several competing non-blessed frameworks, would pick something better/easier/more modern, but instead go with the JSR-backed option. Although perhaps I'm just being pessimistic. JSRs can probably be a good thing; as a programmer in the JVM ecosystem, I've just never considered "it's a JSR" as a brand of quality/something that should affect my choice, and if anything it's the opposite. (My pessimism aside, if they're basing the spec on existing good ideas, like JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart approach.)