An Opinionated Guide to Modern Java, Part 2
blog.paralleluniverse.co
An Opinionated Guide to Modern Java, Part 2
1–10 of 138 posts
Re: An Opinionated Guide to Modern Java, Part 2
#2This feels like a different universe.
Re: An Opinionated Guide to Modern Java, Part 2
#3This feels like a different universe.
... You mean the name of the blog?
Re: An Opinionated Guide to Modern Java, Part 2
#4cool article. I wish if someone can give a Java update like this once every year!
Re: An Opinionated Guide to Modern Java, Part 2
#5As 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)."
Re: An Opinionated Guide to Modern Java, Part 2
#6"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.
Re: An Opinionated Guide to Modern Java, Part 2
#7As 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)."
When you merge multiple libraries into a single jar, it is possible that two libraries might have two (unpackaged) resources with the same name that will collide on the JVM's classpath. Or, perhaps more annoying, you might end up with an unexpected version of a (packaged) library defined class than you expected.
Re: An Opinionated Guide to Modern Java, Part 2
#8"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'm guessing tomcat.
Re: An Opinionated Guide to Modern Java, Part 2
#9As 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)."
A common example is with logging config files (e.g., logback.xml). Some libraries ship with their own (or a library's dependency). It's not uncommon in a large project to wind up with several logback.xml files littered around from libraries that included their own. These are called "resources" because they aren't code but they are included with the compiled distributable and are placed on the classpath.
Of course, your project probably includes its own logback.xml in your resources directory.
Libraries are typically distributed as JAR files, so when you include their JAR on your classpath you're also including their logback.xml in that JAR.
Now, when you go to package up an uber-JAR for your project, whatever packaging tool you use has to merge all those files into one classpath. So now it's found collisions: there are multiple, different logback.xml files on your classpath but you can only have one. How does the tool pick?
So now you have to specify a "merge strategy" to make sure that only your logback.xml is merged in and the rest are discarded.
logback.xml is just one example. Typically Java classes themselves merge just fine because the packaging tool can dedup by fully-qualified class name which is almost never shared across projects. So even if two different dependencies have a Utils class, the FQCN is different. com.foo.bar.Utils is not the same as com.bar.baz.Utils, so there's no conflict.
Conflicts can also arise from libraries which include different versions of the same transitive dependency. Generally the fix here is to exclude a transitive dependency from one of your direct dependencies so as to only include one version of that library. A common culprit is Apache Commons since so many Java libraries rely on it.
Re: An Opinionated Guide to Modern Java, Part 2
#10As 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)."
Each JAR is just a zip file. It can be convenient to merge all those JAR files into one for deployment so you don't have to have all the JAR files lying around in the system and upgrades are just "replace this one JAR file" (among other reasons).
Since each JAR is just a zip if you have two files in seperate JARs with the same path you'll have a problem when you try to merge them.