JarSplice is an application that builds a fat jar, with the main difference being that JarSplice will build invocation scripts and include native resources.
The main weaknesses of JarSplice seems to be its lack of build tool integration, its (apparently) unmaintained status, and its lack of source code availability (even though it’s described as being under the BSD license).
A “fat jar” (or a “shaded jar”) is a jar file that has been bundled with a project’s full set of required resources.
To explain, imagine that we have a Java project called “foo“, that depends on an external project, called “bar.”
For foo to run properly, then, our runtime classpath must contain foo.jar:bar.jar (in some order, although the order can be significant); both files must be present for the classloader to read in order for the project to run.
A “fat jar,” however, includes all of the resources from the classpath in a single jar. The build would extract every class from both foo.jar and bar.jar and built a new jar – named, for example, foo-all.jar – and therefore only this file would be required in order to run the project, since it has every resource that the prior classpath held.
However, this only works for Java resources; it doesn’t include native resources, like LWJGL‘s or SQLite‘s binary components. If foo uses SQLite, then the computer that foo is running on has to have SQLite deployed as a system library in order for foo to run.
This is what JarSplice addresses; it does bundle SQLite or LWJGL resources into the fat jar.
Again, the main weakness of JarSplice is that it’s not integrated into a build tool, so invoking it is an external mechanism for deployment. Development seems to have stopped (the home page says the code is BSD-licensed but no reference to the code exists.) Luis Quesada Torres built a command-line tool, JarSplicePlus; there are forks of that project that seem like there’s some promise for the future.
Feel free to participate and comment.
Category: channel news
Interesting Links – 2017/Jun/12
- picocli, a command-line parser. Apache-licensed; seems similar to JCommander with fewer dependencies.
- 9 Logging Sins in your Java Applications details, well, nine possible logging problems. It’s stuff worth thinking about.
- Five Things You Didn’t Know About… Java Database Connectivity, from IBM developerworks, walks through some things about JDBC that you might not have known. I learned about at least two things that were added since the last time I took a good look at JDBC. (I’m offering no hints about which things they were.)
Interesting Links – 2017/Jun/5
- iciql is a type-safe, model-based wrapper for JDBC… another entry in a fairly large set of libraries designed for that purpose.
- “Cassandra vs. MongoDB” walks through the two datastores, comparing and contrasting.
- DZone published “What Archive Format Should You Use, WAR or JAR?“, suggesting that Docker makes .war files more relevant again.
- Need to extract an HTML page’s main content? Consider Snacktory.
Interesting Links – 2017/May/25
- How Fonts are Fueling the Culture Wars is an article talking about, well, font usage and what specific fonts mean, which has only a tangential relation to Java — but think about it in terms of user experience, too. Do you think the user experience of Java communicates a specific mode of thought? If so, what would it be? (And no, “Duhhhh” is not a valid answer!)
- From DZone: The Soon-to-Be-Hated Object Locator presents a pattern for a type of God Object, except possibly restricted in scope enough to not earn the full derision that a God Object deserves… maybe.
- Also from DZone: The Genius of the Law of Demeter, an article with far less controversy than a God Object would create. The short form of the Law of Demeter says that you call methods on objects that your class owns directly:
this.getFoo().bar()is okay, butthis.getFoo().getBar().baz()is not (and, as usual, there’s more to it than this.) - Stack Overflow: Helping One Million Developers Exit Vim documents the usage patterns for questions that … help developers exit
vim.Vimisn’t especially common for Java developers (although it happens) – but still! What a great editor! How user-friendly does an editor have to be that one in 20000 visits to Stack Overflow is specifically about how to exit the editor? (And now I wonder how many visits are about exiting Emacs, too…) - Java 9 expert group minutes: http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18 – it’s good to keep up on the current status, because the implications of every choice made are pretty serious. The second set of minutes are also available.
- vJUG24 is back! (… I didn’t know what this was until someone sent it to me.)
Interesting Links – 22/May/2017
Interesting Links – 8/May/2017
- Excellent advice for developers who design APIs, no matter who is consuming those APIs: “Building for Builders: Stripe’s 8 Tips for Designing APIs and Supporting Developers“
- Artificial intelligence is everywhere these days. Here’s “Every single Machine Learning course on the internet, ranked by your reviews“
- A cool discrete mathematics library, written in Kotlin: KotlinDiscreteMathToolkit.
- From DZone: Understanding When to Use RabbitMQ or Apache Kafka. Short form: RabbitMQ is for lazy developers; AMQP message queues does most of the work for you at the cost of throughput (which is still high for most projects!), and Kafka does almost none of the work for you but can support much higher throughput. Your humble editor’s advice, earned by experience: if you’ve got the right developers and the time to put into it, Kafka can handle much more throughput than RabbitMQ can, but .. be prepared to make sure you have the right developers and the time to put into it. Otherwise, RabbitMQ (or equivalents) will do fine.
- Druid is a high-performance, column-oriented, distributed data store. Haven’t tried it, it just looked interesting.
- Not Java, but relevant: MP3 licensing has changed! The MP3 format is now available for use by pure open source applications. Woo! Now if we could get JPEG unencumbered in the same way…
Interesting Links – 2017/May/1
- Crafting perfect Java Docker build flow, which addresses the “bare minimum you need to build, test and run my Java application in Docker container.”
- Also relevant: manorrock/maven, a docker container that delivers a specific version of Maven / OpenJDK for Continuous Integration purposes.
- From DZone: Using Java 8? Please Avoid Functional Vomit
- “The Complete Beginners’ Guide to Artificial Intelligence” is a very high-level view of AI. It won’t teach you much about AI if you know much, but it’s a good starting point in case you’re wondering where what you think of AI fits in.
- Another from DZone, appropriate after “LinkedList vs. ArrayList“: Learning Big O Notation With O(n) Complexity
- Not Java-related, but development-related: Teamwork and mental illness in the workplace. Important note: one in four people suffer from mental illness. If you’re in a team of eight, that means that statistically at least two of your coworkers suffer from something that can’t be seen.
If you have a teammate who suffers from mental illness, I’d encourage you to champion (heart and balance) within your team. Be an ally. Help create a safe and inclusive space. Not only because it’s the right thing to do, but because being around people different from you broadens your horizons and builds empathy. And empathy for others makes you better at just about every job.
Interesting Links – 2017/Apr/26
Yes, it’s been a while, I’ve been busy and I’m the only curator of this content:
- Courtesy of The Introduction of Java Memory Leaks, Javosize, the “free next generation java profiler” — and a commercial product, Plumbr (with a free trial available.)
- On
Optional.isEmpty()… – a fascinating email from Dalibor Topic. Great and funny reading. - Courtesy of selckin, Stephen Colebourne has a series on the Java Platform Module System.
- More on Java 9, not much of it complimentary yet: Critical Deficiencies in Jigsaw.
- Our friends at ZeroTurnaround (builders of JRebel) offered a Maven cheatsheet — oddly enough, it uses a really verbose way to set the Maven build version to 1.8, but it’s good.
… and just because I have a weird sense of humor:
randomUser> This code would run really well if it didn't keep waiting for the PRNG to determine the sign of a random number.
Interesting Links, 2017-Feb-23
- Maven Polyglot: replacing pom.xml with Clojure, Scala, or Groovy Script shows how you can, well, replace the XML configuration for a Maven project with a configuration in another language. This also provides some imperative-ish features to Maven projects, plus no XML except for a short description of the scripting language.
- How does a relational database work provides a (very) high level description of how a relational database does its work – and if you read carefully you can see some of the motivations behind some of the less- or non-relational database decisions out there, too.
- From user DerDingens: An Examination of Ineffective Certificate Pinning Implementations, which points out common mistakes while using certificates in Java.
- Maldivia pointed out a Java Enhancement Process draft, for Epsilon GC: The Arbitrarily Low Overhead Garbage (Non-)Collector – basically a garbage collector for Java that does absolutely nothing, for the purposes of tuning, testing, and in some cases, performance enhancements (if you know your job is short-lived, why bother running a GC if you don’t need to?) Fascinating stuff.
- From cheeser: Google, IBM back new open source graph database project, JanusGraph. JanusGraph is a fork of Titan, but its list of backers make it worth watching. Have you used a graph database before? How? What did you think of it?
- Two from DZone on git:
- Lesser Known Git Commands has some handy shortcuts for git users (and chances are good that if you’re reading this, you’re a git user.)
- Git Submodules: Core Concept, Workflows, And Tips. From the article: “Including submodules as part of your Git development allows you to include other projects in your codebase, keeping their history separate but synchronized with yours.” Great stuff.
Interesting Links – 14-Feb-2017
- From DZone: Distributed Systems Done Right: Embracing the Actor Model is a reference to a webinar (ugh, “webinar”) from Lightbend on, well, the Actor Model, a way of representing distributed services. Powerful model, even if you don’t use Actors as described.
- TwelveMonkeys is a set of additional plug-ins and extensions for Java’s ImageIO. It includes BMP, TIFF, JPEG, PNM, and a few others.
- From user u1dzer0: Awesome Asciidoctor: Include Partial Parts from Code Samples describes how AsciiDoctor can extract, well, partial code samples from a block of code. Given Java’s verbosity (not a bad thing, but a still thing that many people don’t like), having a way to ignore code can help focus on relevance. (Also see: Dexy.)
- JSON is the new Data Transfer Object is a short reference to JSON – Javascript Object Notation – in Java EE. JSON is becoming one of the more popular serialization formats (and I use “becoming” sarcastically – it’s very popular already). For better or for worse, it’s time. This isn’t a long article, nor is it very deep – but it touches on something that’s become more and more important over time.
- The Deadly Diamond Of Death In Java 9’s Module System discusses a problem Java 9 has with automatic modules, when a dependency has two names but one resolution path. (Confused? Read the article – it describes it better than I do, but at much more length.)
An Aside About Scala
A mailing list that was pretty popular back in the day recently had some activity asking about Java 8. The discussion itself was a little bit interesting, including a reference here and there to other languages… like Scala. Kirk Pepperdine wrote a post that absolutely riveted Your Humble Author, and may have actually convinced him to stop bothering with Scala except where absolutely necessary. I’d like to quote it here, since Yahoo!’s web page formats things poorly sometimes:
I personally don’t feel that Scala offers any advantages over Java. If you take away the opinions on style, I’d argue that moving to Scala actually leaves you at a slight disadvantage. First, point, the JVM support for languages other than Java was quite poor until Nashorn. Nashorn was actually 2 separate projects. One to get JS running in the JVM and the second was to refactor the JVM to isolate the APIs needed to support alternate languages. Scala hasn’t been able to take advantage of those changes as of yet and I’m not sure they are interested in doing so. Next is tool support. The Java tooling chain is and remains quite broken in 8. I fear that this situation will get slightly better in 9 but then changes there will batter the tooling china quite badly. Unless the Scala people step up to the plate (and there is no evidence of them doing so to date), the dismal state of the tooling chain in Scala will continue to get worse. I currently see very little motivation for companies to invest in the work needed to improve the tooling in Scala. Though I see that this might change, every time I’ve previously thought it might get better, something in the market changes and Scala takes a hit and things don’t get better so my track record on predicting this is admittedly very poor. But then I’m predicting improvements in this area and they’ve simply not happened.
What makes me more hopeful is that I know of a couple of very big projects running in stealth that are based on Scala. These projects are big enough that they’ve really been hurt by the weak tooling story in Scala and I imagine or can only hope that they will start to look at fixing the problems they are facing. Many of these problems are baked into the JVM so to fix them, we need to further fix the JVM’s support for alternate languages. The feeling I get coming from some JVM developers is that it’s the JVM that is past EOL. Maybe Graal will be the thing that replaced HotSpot… not sure… all I know is that the JVM is past due for a huge refactoring and simply don’t see anyone.. certainly not Oracle funding that effort.I’ve “played”with the new features and to be honest find the Scala implementations cleaner and easier to write and understand.
To say that Scala is less verbose than Java maybe true in the small but I’ve found it not to be so true in the large. Reachability in a language is very important and deserved or not, Scala as the reputation of not being so reachable and hence not so readable. IME, almost everyone one I know struggles with the readability of Scala even those that have been using it for quite some time. This is not to say that Scala code can’t be read, it’s simply that Scala code not naturally easily readable and hence people struggle with it.
I think we had the same types of problems with Smalltalk. People resisted Smalltalk for some of the same reasons and in cases where C/C++ wasn’t so desirable we saw teams jumping to Java. In this era I think the current alternative to Java is Go. The buzz around Go is more marketing and hubris than reality but it has a buzz and level of activity that feels familiar to the buzz that we say with Java in it’s early days. Just like people kicked the tires and sniff around Smalltalk and then moved on, I get the same sense here with Scala.Java is starting to give under its own weight of patched-on features, IMHO.
On the contrary, I think that Brian has done a wonderful job integrating Streams and Lambda’s into Java. The only thing I can complain about that makes things a wee bit difficult is this aversion to mutable state. Fine if you don’t like mutable state but that streams make the mutable/immutable decision is an overreach on Brian’s part. It disallows a valid model that we need to work in. It’s different than how everything else works in the language. Streams are inherently single threaded and thus concurrent modification of state is a concern that lies outside the internals of a Lambda expression. IOW, Java != Scala in that Scala had immutability baked into (just about) everything right from the beginning. Brian did consider these points when he designed Lambdas and he opted for his bias towards immutability.. so be it.. All I know if that Lambda’s do not feel like they are patched on to me. They feel like a natural part of the language… much better than the earlier proposals that were tabled. The work on ValueTypes and type inference is also focusing on making sure that the added features do not feel like bolted on bits and that they fit naturally into the current language. Brian’s idea was to create small changes in the language that have a huge impact on your code. While I don’t agree with all of his choices I do think he’s done a brilliant job.
Regards, Kirk