6 ms·

One of the strenghts of the Java platform is the separation of vendor-neutral standards (e.g. JAX-RS, and all the REST concepts, and annotations, it provides) a

One of the strenghts of the Java platform is the separation of vendor-neutral standards (e.g. JAX-RS, and all the REST concepts, and annotations, it provides) and particular implementations (e.g. Jersey). Java EE is a collection of such standards, providing enormous capability while not tying you to a particular app server - I'm busy with a rather painless JBoss -> Glassfish migration as we speak. Secondly, Java has ample platforms that allow for the developer-driven assembly of various cool libraries into a "platform" - for example, OSGi. It concerns me that this library absolutely ignores these two most valuable concepts in the Java world. If you want high-performance web services with much more powerful backing technologies (EJB, JPA, JMS...) without locking into a particular haphazard collection of libraries, just write and deploy a JAX-RS module into your free, lightweight app server of choice (Wildfly, Glassfish, etc). The Java ecosystem is much more mature than the Node.js-based "arbitrary assembly of X cool libraries" that this little project is emulating, and I would encourage people to put that same effort into understanding Java EE, which over the past 5 years has become a lean, lightweight platform indeed - but one with real horsepower for serious systems when you need it. Not denouncing the greatness of the libraries that have been combined here, I'd steer clear of this project - you're missing out on what is really possible.

cssmoo 12y ago
You're right but wrong. That's all OK in theory but not in reality having migrated various Java EE gubbins on a project. It's a rat's nest of supposed standards and interop that doesn't amount to much at the end of the day because there's still coupling to infrastructure and configuration at every level. On top of that there's edge cases that the APIs and standards don't consider as they're all pretty leaky. Dropfish is a cohesive "opinion in a box" that just works without having to do a Java EE iteration zero which is hours of eye-stabbing pain. Someone did all the hard work of swapping components out until they found something that wasn't horrible and stuck them all together. The Java EE ecosystem is mature, you're right but it's not pleasant, is inflexible despite its modularity and doesn't live up to it's promoted abilities. Saying that I've used both in production, but would rather can both of them and use something like flask and python with SQLAlchemy just for the fact I don't have to deal with massive heavyweight environments and it's possible for a human to understand it all in a lifetime. Also, 500 level deeps stacks in Java+OSGI projects make me cry. Trac has a better composition and component model!
- dawidloubser 12y ago
  I've had some terrible experiences with migrating, and maintaining, Java EE apps before. But every single one of those were caused by how the teams built the system, and not by Java EE itself. The added complexity, and choices, imposed by Java EE require a degree of understanding, maturity, and ability to abstractly design that is beyond the average programmer that just quickly wants to hack together a couple of REST services. I'm not trying to paint successful Java EE developers as some sort of elite here, but there is no doubt that people with a solid understanding can, and have, built long-lasting systems of beauty with it, whereas the average un-informed team, having managed to soundly lock themselves into awful pre-2005 app servers, have created conterted messes of Java code beyond belief. Both Java EE, and OSGi, are soundly beautiful in their own ways, but both have suffered from some awful implementations and libraries that have caused a lot of pain. For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser). In this world, I challenge any environment to put more horsepower behind your REST services, for less effort.
  - tokenizerrr 12y ago
    > For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser). Do you have any recommended reading for that? Every time I try to get started with Java EE I am plagued with outdated material and pages upon pages of boilerplate XML configuration.
    - nbw-hn 12y ago
      Check out the JavaEE tutorial from Oracle http://docs.oracle.com/javaee/7/tutorial/ http://docs.oracle.com/javaee/7/tutorial/ and the 1st Cup https://docs.oracle.com/javaee/7/firstcup/index.html https://docs.oracle.com/javaee/7/firstcup/index.html There's also an excellent GIT repo of JavaEE7 samples that is maintained by RedHat here: https://github.com/javaee-samples/javaee7-samples https://github.com/javaee-samples/javaee7-samples
timclark 12y ago
I'd rather use a careful selection of libraries that provide me a single executable to run than have to work with OSGI or a JEE container.
oblio 12y ago
Well, Java EE can be (is) overwhelming. This is a nicely curated list of quality libraries and feels more like one than like a framework. I think that the Java folk would do well to promote such things as well as Java EE, since they cater to different market. The Node.js guys have demonstrated that there is a market for "arbitrary assemblies" and if for whatever reason Java does not promote projects such as this it will lose those developers entirely: I doubt they will be willing to start using Java EE on day 1.
switchbak 12y ago
You're still basically using many of the libraries you're mentioning - but personally I shun (most of the) JEE in preference of lighter weight approaches. If you need more of the heavy weight libraries / environments, it's (usually) not a big deal to migrate. I don't agree with some of the choices of DropWizard, and it's not something I'd use on my own projects - but as an opinionated "here's a way to get started efficiently" approach, I think it's not bad. For some developers, getting a decent base to start on is quite a daunting experience. Then again, if someone starts saying "must have X years experience with DropWizard" I think I'll probably snap.
- switchbak 12y ago
  And forcing OSGi induced brain damage on someone is just cruel. After years working with that, there's absolutely NO way I'm ever doing that again. The number of projects that don't work (mainly classloader issues) and/or had to be customized to work on it is enough of a barrier for me to never use it again. And the benefits it conferred were so minimal that the cost/benefit ratio was astronomical and completely unjustifiable. (Maybe things are different on massive teams though)
  - dawidloubser 12y ago
    I've also suffered a lot of pain in trying to get libraries that were not design for OSGi (i.e. legacy) to work well. However, when having the luxury of implementing a clean set of services from scratch, OSGi is lovely. We run a large OSGi based system in production, and the modularity, hot-deployability, strong-typing-with-contracts, etc is just lovely. I certainly won't try to say that OSGi is simple, but for complex systems that have to evolve over a long time span, it solves problems no other environment even nearly does.
regularfry 12y ago
> If you want high-performance web services with much more powerful backing technologies (EJB, JPA, JMS...) without locking into a particular haphazard collection of libraries, just write and deploy a JAX-RS module into your free, lightweight app server of choice (Wildfly, Glassfish, etc). The cost of having a choice is having to make a choice. Look at the number of concepts someone coming to the ecosystem totally fresh has to learn here. Not only that, look at the number of choices they have to make without understanding the trade-offs they might be making, or even whether they'll ever have to care. All these things you mention are added cognitive load which, for a large number of applications, will end up being totally irrelevant. Dropwizard looks to me like a solid 80/20 solution. Think of all the apps out there which get deployed to tomcat, are the only thing which will ever be deployed to that tomcat instance, and just never have to grow past a single machine, or even a single developer. What value is tomcat (or glassfish, or whatever) actually adding in that situation? I'd argue that it's pure overhead. An in-process HTTP server running under a classic UNIX process supervisor like runit or daemontools would do just as well. Maybe there are babies being thrown out with the bathwater here, but the way forward isn't to highlight all the extra work a developer has to do to find them.
- nbw-hn 12y ago
  Glassfish or Wildfly add value when the application uses JavaEE APIs. With a Tomcat or Dropwizard approach you have to piece together a bunch of 3rd party JARs to provide these APIs. You have to maintain this etc. With the app server the libraries are already bundled in there. Sure there may be more then you end up using but come one we are talking 10s of MBs here which in this day and age is nothing for most environments. Also startup times with these App servers aren't affected because they only startup the containers which are used by your application. My Glassfish instances start up in around 2ms with an app that uses JPA, Servlet, JAX-RS, EJB. I'd rather spend my time building the app and not spend time piecing together my Tomcat environment.
mbell 12y ago
JavaEE has some truly terrible specs in it, particularly JSF and CDI. I also haven't seen a great deal of cohesiveness in the platform, e.g. when EE6 was released JSF's injection system only partially supported CDI (ViewScope for example wasn't supported) and there were other major problems such as unclear serialization requirements for JSF scopes breaking session management. I could also go on a long rant about JPA/Hibernate but that is an entire topic of it's own. Generally speaking I got the impression that each standard mostly worked on it's own with interoperability with other specs being a bit of an afterthought and that there was very little going on in terms of building an overarching, integrated, vision for the platform. I ran away from JavaEE toward Dropwizard and found it a much more sane platform, and much faster without the extra baggage.
pron 12y ago
Dropwizard is basically Jersey (JAX-RS) running on top of Jetty (Servlets), with an integrated monitoring library (Metrics), which is not standardized (but neither is any other). So Dropwizard is very much in line with the standards-based approach.

cssmoo 12y ago

You're right but wrong. That's all OK in theory but not in reality having migrated various Java EE gubbins on a project. It's a rat's nest of supposed standards and interop that doesn't amount to much at the end of the day because there's still coupling to infrastructure and configuration at every level. On top of that there's edge cases that the APIs and standards don't consider as they're all pretty leaky. Dropfish is a cohesive "opinion in a box" that just works without having to do a Java EE iteration zero which is hours of eye-stabbing pain. Someone did all the hard work of swapping components out until they found something that wasn't horrible and stuck them all together. The Java EE ecosystem is mature, you're right but it's not pleasant, is inflexible despite its modularity and doesn't live up to it's promoted abilities. Saying that I've used both in production, but would rather can both of them and use something like flask and python with SQLAlchemy just for the fact I don't have to deal with massive heavyweight environments and it's possible for a human to understand it all in a lifetime. Also, 500 level deeps stacks in Java+OSGI projects make me cry. Trac has a better composition and component model!

dawidloubser 12y ago
I've had some terrible experiences with migrating, and maintaining, Java EE apps before. But every single one of those were caused by how the teams built the system, and not by Java EE itself. The added complexity, and choices, imposed by Java EE require a degree of understanding, maturity, and ability to abstractly design that is beyond the average programmer that just quickly wants to hack together a couple of REST services. I'm not trying to paint successful Java EE developers as some sort of elite here, but there is no doubt that people with a solid understanding can, and have, built long-lasting systems of beauty with it, whereas the average un-informed team, having managed to soundly lock themselves into awful pre-2005 app servers, have created conterted messes of Java code beyond belief. Both Java EE, and OSGi, are soundly beautiful in their own ways, but both have suffered from some awful implementations and libraries that have caused a lot of pain. For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser). In this world, I challenge any environment to put more horsepower behind your REST services, for less effort.
- tokenizerrr 12y ago
  > For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser). Do you have any recommended reading for that? Every time I try to get started with Java EE I am plagued with outdated material and pages upon pages of boilerplate XML configuration.
  - nbw-hn 12y ago
    Check out the JavaEE tutorial from Oracle http://docs.oracle.com/javaee/7/tutorial/ http://docs.oracle.com/javaee/7/tutorial/ and the 1st Cup https://docs.oracle.com/javaee/7/firstcup/index.html https://docs.oracle.com/javaee/7/firstcup/index.html There's also an excellent GIT repo of JavaEE7 samples that is maintained by RedHat here: https://github.com/javaee-samples/javaee7-samples https://github.com/javaee-samples/javaee7-samples

timclark 12y ago

I'd rather use a careful selection of libraries that provide me a single executable to run than have to work with OSGI or a JEE container.

oblio 12y ago

Well, Java EE can be (is) overwhelming. This is a nicely curated list of quality libraries and feels more like one than like a framework. I think that the Java folk would do well to promote such things as well as Java EE, since they cater to different market. The Node.js guys have demonstrated that there is a market for "arbitrary assemblies" and if for whatever reason Java does not promote projects such as this it will lose those developers entirely: I doubt they will be willing to start using Java EE on day 1.

switchbak 12y ago

You're still basically using many of the libraries you're mentioning - but personally I shun (most of the) JEE in preference of lighter weight approaches. If you need more of the heavy weight libraries / environments, it's (usually) not a big deal to migrate. I don't agree with some of the choices of DropWizard, and it's not something I'd use on my own projects - but as an opinionated "here's a way to get started efficiently" approach, I think it's not bad. For some developers, getting a decent base to start on is quite a daunting experience. Then again, if someone starts saying "must have X years experience with DropWizard" I think I'll probably snap.

switchbak 12y ago
And forcing OSGi induced brain damage on someone is just cruel. After years working with that, there's absolutely NO way I'm ever doing that again. The number of projects that don't work (mainly classloader issues) and/or had to be customized to work on it is enough of a barrier for me to never use it again. And the benefits it conferred were so minimal that the cost/benefit ratio was astronomical and completely unjustifiable. (Maybe things are different on massive teams though)
- dawidloubser 12y ago
  I've also suffered a lot of pain in trying to get libraries that were not design for OSGi (i.e. legacy) to work well. However, when having the luxury of implementing a clean set of services from scratch, OSGi is lovely. We run a large OSGi based system in production, and the modularity, hot-deployability, strong-typing-with-contracts, etc is just lovely. I certainly won't try to say that OSGi is simple, but for complex systems that have to evolve over a long time span, it solves problems no other environment even nearly does.

regularfry 12y ago

> If you want high-performance web services with much more powerful backing technologies (EJB, JPA, JMS...) without locking into a particular haphazard collection of libraries, just write and deploy a JAX-RS module into your free, lightweight app server of choice (Wildfly, Glassfish, etc). The cost of having a choice is having to make a choice. Look at the number of concepts someone coming to the ecosystem totally fresh has to learn here. Not only that, look at the number of choices they have to make without understanding the trade-offs they might be making, or even whether they'll ever have to care. All these things you mention are added cognitive load which, for a large number of applications, will end up being totally irrelevant. Dropwizard looks to me like a solid 80/20 solution. Think of all the apps out there which get deployed to tomcat, are the only thing which will ever be deployed to that tomcat instance, and just never have to grow past a single machine, or even a single developer. What value is tomcat (or glassfish, or whatever) actually adding in that situation? I'd argue that it's pure overhead. An in-process HTTP server running under a classic UNIX process supervisor like runit or daemontools would do just as well. Maybe there are babies being thrown out with the bathwater here, but the way forward isn't to highlight all the extra work a developer has to do to find them.

nbw-hn 12y ago
Glassfish or Wildfly add value when the application uses JavaEE APIs. With a Tomcat or Dropwizard approach you have to piece together a bunch of 3rd party JARs to provide these APIs. You have to maintain this etc. With the app server the libraries are already bundled in there. Sure there may be more then you end up using but come one we are talking 10s of MBs here which in this day and age is nothing for most environments. Also startup times with these App servers aren't affected because they only startup the containers which are used by your application. My Glassfish instances start up in around 2ms with an app that uses JPA, Servlet, JAX-RS, EJB. I'd rather spend my time building the app and not spend time piecing together my Tomcat environment.

mbell 12y ago

JavaEE has some truly terrible specs in it, particularly JSF and CDI. I also haven't seen a great deal of cohesiveness in the platform, e.g. when EE6 was released JSF's injection system only partially supported CDI (ViewScope for example wasn't supported) and there were other major problems such as unclear serialization requirements for JSF scopes breaking session management. I could also go on a long rant about JPA/Hibernate but that is an entire topic of it's own. Generally speaking I got the impression that each standard mostly worked on it's own with interoperability with other specs being a bit of an afterthought and that there was very little going on in terms of building an overarching, integrated, vision for the platform. I ran away from JavaEE toward Dropwizard and found it a much more sane platform, and much faster without the extra baggage.

pron 12y ago

Dropwizard is basically Jersey (JAX-RS) running on top of Jetty (Servlets), with an integrated monitoring library (Metrics), which is not standardized (but neither is any other). So Dropwizard is very much in line with the standards-based approach.