Hacker News Reader

Comment by jonstewart | Hacker News Reader

Beefs with this article:

1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH.

2. clang and gcc have compatible command-line option syntax.

3. The options example he lists for gcc is a pure strawman. Maybe they are necessary to compile that particular source file, but it is not necessary to use all these options in the average case.

4. The article title says "now more than ever", but there's really nothing about recent developments here. This article could have been written ten years ago.

This really just seems like crappy linkbait.

View on HN

> 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH.

It is possible to roll a 'fat' JAR with all your dependencies baked-in, which is as close to static linking as it gets in Java-land. I prefer this for stand-alone applications as it makes deployment a cinch at the expense of the size of the build artifact.

Agreed, this is how I do my Java standalones. Eclipse makes this easy with Export | Runnable Jar providing several options for how to package the build.

The Maven assembly plugin can also do this with the 'jar-with-dependencies' descriptor.

I personally use the maven-shade-plugin for this because it has built-in support for handling special resource files like licenses, service definitions, and manifest entries.

The maven shade plugin can be dangerous if you hit the zip file limit of 65535 entries. Watch your filters.

Yeah, I've used jarjar before for this.

I wonder how such a setup would play out in regards to Open Source usage.

Say you create a big jar with all dependencies in there in several layers of "lib" folders.

Licenses like LGPL say you have to keep the LGPL archive accessible to the user and grant permission for them to alter/update them.

Would a nested hierarchy of lib folders inside your jar be viewed as hindrance? Certainly you didn't "hide" the LGPL'd components in order for the user to not alter them but I think it could be viewed as "security through obscurity". If I don't immediately see a component, how do I know its there? I guess this could be solved by a readme that lists in detail what open source components are used and where in the hierarchy they can be found.

Good point(s), especially #4. The article compares an 80s language (C++) to a 90s language (Java), not to more recent compiler toolchains. Admittedly, there aren't many options here, and e.g. Scala (which I hope will be covered in future articles) relies on the java toolchain.

Edit: C++ and Java also have different cultures. The simplest compilation with g++ is "g++ foo.cpp -o foo", which isn't much more complex than "javac Foo.java". The fine-grained options clang/g++ give you are part of the “you pay for what you use”-mentality of C++.

Except there are 70's languages (Modula-2), 80's (Ada) and 90's (Turbo Pascal/Delphi), that offered more powerful compiler toolchains.

However, given C++'s requirement to be kept compatible with UNIX toolchain model, we suffer from a 70's model in C++.

Regarding #1, Java 8 allows for static JNI linking. http://openjdk.java.net/jeps/178

Cool. Did not know that.

Moreover, their own banner ad at the bottom is ironic. "Java is cured, suffering from redeploy madness. Get your cure".

http://zeroturnaround.com/wp-content/uploads/2013/09/660x122...

Didn't you hear that all that changed since Twitter switched, and now it rocks more than ever?

Most importantly, his gcc example is taken from OSX... ugh.

As the guy says he is writing music software, Mac OSX would be a pretty important platform to cover.

That said, I'm a recent convert from Linux to OSX, and I like to tinker with Garbage Band from time to time :-)

Reply on news.ycombinator.com