The future of java | Hacker News Reader

The future of java

blog.headius.com

37 pointsjakep3614 comments

What Charles says without actually saying, and what I find most interesting, is that the new age of platform war will be waged on VMs. In that case, I don't think Charlie has anything to worry about. The JVM may not be all peaches and cream, but it's at least as good or better than the CLR, and Parrot hasn't reached critical mass yet.

LLVM is interesting, but aims a bit below all of these. What I'd really like to see is some of the other language specific VMs try branching out. Lua, Io, Erlang, heck -- even Smalltalk, could all be viable candidates.

In some ways it has happened a little with smalltalk: Gemstones MagLev for ruby work demonstrates that it is possible.

Whilst for many things I like the VM "platform" idea, I still think of lower level compile-to-the-metal languages are more real to me, and always necessary for some things, but perhaps thats my age and experience, and in time VMs will be the norm and native compilation will be like asm code... who knows..

If you need this for jvm based languages you can always use excelsior jet. It's awesome.

years ago I used it (back 2002-ish?) and it worked pretty well back then. Have also used GCJ for some things - but it always seems like its just creating a little JVM hidden in the native code - still not quite the same "feeling" as macro assembler (which is how I saw C back when I did it) - still many layers above.

I know, its probably all in my head, but still, in my head the real stuff happens on the metal, not in abstractions (I am an elec engineer at heart, trained as one and will always be one).

How is it better than the CLR?

!troll, I'm genuinely curious.

I don't have any data with which to back this up, but as far as I can tell it's a little faster and it has better multithreading guarantees and performance. Oh, and it's open source (mostly. sigh.) and has some pretty cutting-edge languages, e.g. Clojure and Scala.

Mono is one to watch, though.

The supposed weakness of Scala as being "too complicated" or "too rich" can be countered by developing coding standards, creating more robust editors and tools, and by better educating polyglots on how best to use Scala.

This will never work. It never worked with C++. You need sharp C++ programmers to produce C++ code; you can't use mediocre programmers using a subset of the language. Even if you enforce simplicity internally, debugging and external library dependencies force all C++ programmers to cope with the full complexity of the language.

Java is an excellent language for exploiting the abilities of average programmers. Average programmers can be self-sufficient in Java. Outstanding programmers, exploiting the full power of Java, produce code and APIs that average programmers can understand and use. Scala cannot fill that role.

The superficial similarity is deceptive.

C++, the elegance of a subset is replaced with a grab-bag of features when you zoom out.

Scala, the grab bag of features are replaced with an elegant unified language when you zoom out.

Scala gives average programmers an upgrade path and rewards them for following it. C++ gives average programmers a headache. In Java the average programmer thinks he knows the language, but that won't do him any good if all the important patterns are above the language at library level or higher.

Part 1 says that the future of Java is really porting other languages (JRuby, Jython, Scala, etc.) to the JVM and enhancing the JVM to support them. Very little is said about Java itself. Perhaps that will be discussed in part 2. I, for one, would like to see a new Java that is less verbose and has better idioms for my tired fingers.

If that's what you want, why not use one of the many fine languages available that target the JVM? May I recommend a lovely Clojure -- dynamic but type hintable, with ridiculously easy Java interop?

You are right, of course. Right now I am in the early stages of a gig where I have sole responsibility for 400K lines of an orphaned enterprise package written with all correct fads (sorry frameworks). To make matters even more fun, it is about 25% of the way through a transition from struts to flex. Turning this thing around is like doing high speed maneuvers in a super tanker. Anyway apologies for my muttering, but your suggestion is welcome.

It might not go over well in a paid gig. Corporate tech managers do tend to freak out about Lisps and low-market-share languages in general.

One strategy that might help is to be brutally honest about how long it might take in Java, and how much cheaper it would be in a JVM-hosted dynamic language. But obviously if you don't already have enough experience with an alternative language to make a confident estimate, it would be a crazy gamble.

Consulting gigs are funny. Some dont let you pee without an escort (literally), others, like this one, turn over the keys to the crown jewels. If I say it will be 2x cheaper there will be no problem. The only stumbling block is that the owner really likes the part implemented in flex and I am a little reluctant to continue with a proprietary system. Any views either way?

Scala isn't really a port; it's practically a Java native. Its primary creator had a lot to do with the development of Java, and despite being originally targeted toward both the JVM and the CLR, the Scala project has focused primarily on the JVM. As mentioned in the article, Scala can be used as a "better Java" and is much easier on the fingers (notably because it has type inference, but also because it supports functional programming better than Java.)

Reply on news.ycombinator.com