Live data from Hacker News

An Opinionated Guide to Modern Java, Part 2

blog.paralleluniverse.co

21–30 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#21
post #19

Earlier quoted context omitted.

I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.

Why is the Java community so enamored with creating Java-only solutions when general-purpose solutions work just as well (and often better)? There's no need to bundle everything up into an executable jar or war. It's much easier to write a Chef recipe to copy all the right files to the right places. And it's even easier to create a Docker container with the exploded war in its correct place. Both of those solutions d…

Java - "run anywhere" (supposedly)

Docker - "The Linux Container Engine"

Think you've got your answer there.

Re: An Opinionated Guide to Modern Java, Part 2

#22
post #19

Earlier quoted context omitted.

I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.

Why is the Java community so enamored with creating Java-only solutions when general-purpose solutions work just as well (and often better)? There's no need to bundle everything up into an executable jar or war. It's much easier to write a Chef recipe to copy all the right files to the right places. And it's even easier to create a Docker container with the exploded war in its correct place. Both of those solutions d…

Interesting, a lot of people that are really into CI point to the Java ecosystem as the best example of how to do it. People make the artifact of other language build pipelines a .deb or something similar to have basically the same artifact as a .jar/.war

Re: An Opinionated Guide to Modern Java, Part 2

#23

"Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself. Like I mentioned last time I appreciate an overview of modern Java practices but boy howdy I can't discern if this is clever trolling or a cheap way to make me read Part 3.

> "Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself.

The alternative are servlet containers, like Jetty or Tomcat. Jetty for example is very popular and really good and can be easily embedded inside an app for single JAR deployments, which is an awesome way to deploy an app btw.

Re: An Opinionated Guide to Modern Java, Part 2

#24
post #16

> While I personally prefer Gradle’s nice DSL and the ability to use imperative code for non-common build operations, I can understand the preference for the fully declarative Maven, even if it requires lots of plugins. The modern Java developer, then, might prefer Maven to Gradle. I find Maven's abstractions surprisingly hard to understand. It is a major part of my annoyance with Java as a dev setup. I miss Make/Ant…

I really enjoy Gradle. I have done significant work with Ant, Maven, and a host of tool chains in the C/C++ world. Gradle seems to have the cleanest DSL. Not every single thing under the sun is supported (Maven seems to be the most comprehensive tool I have used), but Gradle is nice to work with.

Re: An Opinionated Guide to Modern Java, Part 2

#25
Very nice article. Capsule looks promising in regards to packaging. I'm going to have give 'er a try. One could also use the fatjar[1] or application[2] plugins (within the context of gradle).

[1] https://github.com/musketyr/gradle-fatjar-plugin [2] http://www.gradle.org/docs/current/userguide/application_plu...

Re: An Opinionated Guide to Modern Java, Part 2

#27

"Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself. Like I mentioned last time I appreciate an overview of modern Java practices but boy howdy I can't discern if this is clever trolling or a cheap way to make me read Part 3.

I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.

play framework as well ( with no jsp dependency)

Re: An Opinionated Guide to Modern Java, Part 2

#28
post #15

Nice article - Many of the suggestions (single-jar deployment, metrics, slf4j logging, etc) are all wrapped up for you in Dropwizard http://dropwizard.io , which we use and love.

Do you just use it for producing a REST API or do you use it to render HTML, handle session management etc.?

Re: An Opinionated Guide to Modern Java, Part 2

#29
post #19

Earlier quoted context omitted.

Why is the Java community so enamored with creating Java-only solutions when general-purpose solutions work just as well (and often better)? There's no need to bundle everything up into an executable jar or war. It's much easier to write a Chef recipe to copy all the right files to the right places. And it's even easier to create a Docker container with the exploded war in its correct place. Both of those solutions d…

Java - "run anywhere" (supposedly) Docker - "The Linux Container Engine" Think you've got your answer there.

Docker is an option if you're deploying on Linux, which is what the majority of server deployments use these days. Chef works on the rest of the Unixes, including OS X. If you're deploying Java on a Windows server, you're doing it wrong.

And the days of needing to use different development and production OSs are over...if you develop in Windows and deploy on some Unix variant, you should be using a VM.

I'm still not buying ClassLoader contortions as being in any way justified to support the single deployable artifact requirement. It's just not necessary and can lead to many subtle and hard-to-track-down issues as well as introducing unnecessary performance overhead.

Re: An Opinionated Guide to Modern Java, Part 2

#30
post #15

Nice article - Many of the suggestions (single-jar deployment, metrics, slf4j logging, etc) are all wrapped up for you in Dropwizard http://dropwizard.io , which we use and love.

Sharing a lot of the Dropwizard philosophy, there is Spring Boot (http://projects.spring.io/spring-boot/), which we use and love as well.
Post reply on HN