Hacker News Reader

Comment by lkesteloot | Hacker News Reader

It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.

View on HN

While I do think Java is great I think that's an exaggeration, I'm sure there are quite a few deal-breakers for particular uses. Personally I've opted not to use Java before because it cannot compile to a self contained native binary.

You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach.

You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach.

gcj has been abandoned. It was last updated over 5 years ago. It's not clear to me why you would even mention it.

I'm a software developer that primarily uses and likes Java, and the lack of a good and free ahead-of-time compiler for Java that produces native binaries is what I miss most in the Java ecosystem.

There's Avian. It can produce standalone, compact ELF files that have no dependencies. It's not an AOT compiler though. The problem with AOT in the Java ecosystem is quite a lot of modern frameworks and the like have ended up relying on the ability to synthesise code at runtime. Android has put a check on that kind of behaviour but it's still there.

There's also Excelsior, which is an AOT JVM, but it's for Windows only.

I agree that a really good AOT JVM would be very nice. It doesn't necessarily imply better performance however. I remember when GCJ compiled Eclipse for the first time, lots of people were surprised that it didn't magically fix every performance problems. GCJ engineers view was "HotSpot is an excellent compiler and it will take a lot of effort to beat it". When Sun Java became open source therefore, a lot of the incentive to develop GCJ disappeared. It was always primarily a licensing project not a performance project.

There's also Excelsior, which is an AOT JVM, but it's for Windows only.

Unfortunately, it's also extremely expensive. That's not to say it isn't worth every penny in some situations, but I've gotten kind of spoiled by free development tools for personal projects. I'm glad the days of spending hundreds of dollars for things like C compilers are long behind me.

I agree that a really good AOT JVM would be very nice. It doesn't necessarily imply better performance however.

For some application domains, I would be happy to trade speed -- and even features -- for the ability to create a native binary with no dependencies.

This is one area where I find the Go programming language interesting. I prefer Java, but the lack of a good and free ahead-of-time compiler for Java that creates native binaries with no additional dependencies is a killer feature for some situations.

Looks like it is Windows, Linux and Mac. No 32bit on Mac, though.

http://www.excelsiorjet.com/

Then you might be happy to know that AOT is planned for the reference implementation for Java 9, eventually Java 10.

Also that Oracle Labs have SubstrateVM, which is an AOT compiler based on Graal.

Then there is also JikesRVM and RoboVM.

Java projects can be compiled to a self contained native binary using http://www.excelsiorjet.com/ (though this is a proprietary tool, with a gratis license option for non-commercial projects).

Curious: why is this a requirement for you?

IMO, being tethered to the JVM is both its greatest strength and its greatest weakness. The JVM really is a masterful piece of engineering, but it is optimized so heavily for the server that any use case that deviates requires huge hacks to get what you want. For example, running a JIT on Android was so sluggish that Android had to design an entirely new runtime(ART).

Well, Dalvik is a JIT and ART can also do JITC and is designed for newer devices. So not sure that's a great example. The main reason Android doesn't use the HotSpot JVM is memory usage and licensing, I guess. The JVM class/jar format is very inefficient in many ways. On the other hand Dalvik is a very weak JITC. ART is stronger because it has more time to work and is, frankly, better engineered. Dalvik had a lot of problems even quite late in its lifecycle with things like lock inversions and strange method count limits, etc.

The JVM runs very well on the desktop as well as the server. I have to point out: Android runs Dalvik, not the JVM. But here's the point: Java isn't tethered to the JVM. Use the JVM for server, desktop, Use ART or Dalvik for Android. Use Jikes, Excelsior Jet, RoboVM or other VMs, compilers for other targets. The limitation you raise doesn't really exist.

Java's start up time makes it pretty crappy for command line utilities.

When did you last try it? Startup time was optimised heavily some time ago and nowadays I don't notice any real difference unless I wrote some toy app and used "time". The JVM starts fast enough that you can write command line utilities just fine.

It is certainly substantially better than it used to be, but it is still pretty far away from an AOT compiled native executable. And forget it entirely if you are running Clojure or Groovy code.

The class of tasks for which Java's startup time is an issue is very very small. I wouldn't use it for a device driver because of resource issues but there aren't many command line commands where 0.08s is an issue.

LuaJ is an order of magnitude slower to startup than Lua, IIRC. Could be LuaJ's fault, not Java's, of course.

Java's start-up time is on the order of tens of milliseconds:

http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-start...

The 'Hello' program there takes a little over 100 ms for me. I guess my computer is even less of a powerhouse than the author's.

FWIW, the Python equivalent takes about 30 ms on my machine. So, you pay maybe 70 ms to use Java. I don't think many users will notice an extra 70 ms on their command line.

Java's notoriously slow startup is really about the slow startup of software written in Java. Application servers are probably the worse offenders - how can it take a minute and a half to start a fancy webserver? What's it doing in there? They've got a lot better, though; the current generation of app servers start in one or two seconds. Not that anyone cool uses app servers any more anyway. Big bloated GUI apps also deserve some shame here (although i will forgive Eclipse, because i like my IDEs with some meat on them). Language platforms like Clojure and Groovy also manage to take their time, but then they're doing some pretty amazing stuff, i suppose.

Startup time on my Win7 box: 0.08 sec.

Reply on news.ycombinator.com