Nice article - Many of the suggestions (single-jar deployment, metrics, slf4j logging, etc) are all wrapped up for you in Dropwizard <a href="http://dropwizard.io" rel="nofollow">http://dropwizard.io</a>, which we use and love.
I'm glad someone took the time to write this, it's actually a very nice resource to get new coworkers up to speed. Shouldn't be tought as dogma of course (e.g. Gradle vs. Maven).<p>Also, thanks for mentioning Packr even though noone has used it in production yet. It's only a week old.<p>Assuming OP is the original author: are you by any chance following JGO? I see Quasar is actually using Matthias Mann's green thread lib which i don't think was advertised anywhere outside JGO.
"Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself.<p>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 like the overview given to JVM tooling, many developers are fully unaware of what JVMs (not only the official one from Oracle) offer in terms of monitoring.<p>If you want to go really low level, a few of them even show the generated assembly code by the JIT.
As a Java developer, I thought this article had some interesting information about logging and monitoring. However, the deployment section had my scratching my head a little.<p>I've never totally understood why people want to make fat jars. It seems like a process full of headaches since you can't have jars in jars. Wouldn't it be much easier to create a regular zip file with a small script to set the classpath and and run the project?<p>I'm not sure I understand the motivation for embedded instead of standalone servlet container. The article linked to some slides but they mostly seemed be demonstrating that you can function using an embedded container rather than providing clear benefits. Maybe it would have made more sense with the associated talk.<p>Can anyone provide more insight to these?
> 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.<p>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. Not sure if Gradle will be a good replacement or not but would be curious to try.
> I personally prefer Gradle’s nice DSL [...] in order to use Gradle one does not need to know Groovy, even if one wishes to do some non-standard stuff [...] I just learned a few useful Groovy expressions that I found in Gradle examples online<p>The DSL is Groovy syntax from Groovy's antiquated Antlr 2.7 grammar, so simply by using Gradle you're using Groovy along with all its warts. Underneath, Gradle isn't so much a DSL as an API shipping with a programming language. You could just as easily write the first Gradle example from the article in most other JVM languages. If it was in Clojure...<p><pre><code> (require gradle :as g)
(g/apply :plugin "java")
(g/apply :plugin "application")
(g/source-compatibility "1.8")
(g/main-class-name "jmodern.Main")
(g/repositories
(g/maven-central))
(g/configurations
g/quasar)
(g/dependencies
(g/compile "co.paralleluniverse:quasar-core:0.5.0:jdk8")
(g/compile "co.paralleluniverse:quasar-actors:0.5.0")
(g/quasar "co.paralleluniverse:quasar-core:0.5.0:jdk8")
(g/test-compile "junit:junit:4.11"))
(g/run
(g/jvm-args (str "-javaagent:" (-> (configurations.quasar.iterator) next))))</code></pre>
I'm a fan of simplifying the server side, one I'd recommend for the latter part of the slideshow he referenced:<p><a href="http://www.sparkjava.com/" rel="nofollow">http://www.sparkjava.com/</a>
As far as packaging and deployment of a native executable goes, I thought it odd to not mention Excelsior JET (<a href="http://www.excelsiorjet.com" rel="nofollow">http://www.excelsiorjet.com</a>) as I believe that's the only Java compiler that can handle all of the JDK (gcj isn't there yet).
As someone not very familiar with Java can someone expand on what he means by this: "Every library is usually packaged into its own JAR, and merging all dependencies into a single JAR, might cause collisions, especially with packaged resources (non-class files)."
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).<p>[1] <a href="https://github.com/musketyr/gradle-fatjar-plugin" rel="nofollow">https://github.com/musketyr/gradle-fatjar-plugin</a>
[2] <a href="http://www.gradle.org/docs/current/userguide/application_plugin.html" rel="nofollow">http://www.gradle.org/docs/current/userguide/application_plu...</a>
This article does not mention OSGI or Jigsaw with one word but claims to guide to modern Java development.
Seems they never run any large scale EE projects yet :)
How does profiling Java applications work with JIT. Should you wait until the code has been optimized before profiling, or these tools smart enough to realize that the performance of code changes as the application runs?