On Wed, 2013-09-18 at 23:33 +0200, Chris wrote:
> Seeing that more and more developers and companies look for or actively develop native languages, I wonder will Java go native one day? (Cf. http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
> 
> Is this Java's only chance to keep up with Go and Rust (and D)?

No. It isn't even an option in the sense you intimate. As others have said there are Java → native compilers and there is a thriving, albeit relatively small, market there. OpenJDK will remain proudly a JVM, compile to bytecode, language.

> Performance is an issue, no matter how fast your processor is, Java always lags behind*. And the JVM installation horror is bad enough for developers, but for users? Now Java apps are often shipped with a version of the JRE included, which smells of defeat. If Oracle want to save Java (after so many "unfortunate" decisions), will they finally go native? I can see a market for that. There are still a lot of Java developers out there, there are loads of Java apps, Java has GUI libraries etc.

And Windows native code applications don't ship with a version of all the Windows DLLs for every application?

Java is no longer under-performant compared to C, C++, Fortran, D, Go, Rust. Check the benchmarks.

Since when is Java hard to install. I am tracking JDK8 which has releases every 2 weeks. I reinstall an entire Java distribution on 4 machines in a matter of 15 mins, which includes download of 500MB of stuff.

Shipping a JRE is not defeat, where did you get this idea from? Or perhaps you are satirizing WORA (which is and always has been a bit of a joke ever since Java 1.2).

Re the Oracle jibe. Yes they made some bad decisions, but then the JCP EC took over and the users took a voice. SouJava and LJC (of which I am a member) rattled all the cages of the complacent JCP EC and have reinvigourated contribution from users. OpenJDK is a great success cf. AdopJDK, AdoptAJSR programs . Oracle (who still make some mistakes re Java it is true) and IBM have re-energized their contributions, as have others.

> *Java's sluggish performance was what made me look for alternatives in the first place, and I found D.

I accept this as true as it is a statement by you about your decision making, but Java 8 is not Java 1. Early desktop Java was pure interpretation, and hence slow. Modern Java, via the JIT, generally executes native code. With Java 7 and method handles and invokedynamic, the world changed even more and now computationally intensive codes can run basically as fast using Java as using C, C++, Fortran, D, Rust, Go. (After initial "warm up" of the JIT.)

There is data out there backing this up but I know how much members of this list abhor benchmarks, eh Walter ;-)

Yes this was an anti-FUD rant on behalf of the "Java as a language has a few issues, even Java 8, but the JVM is a thriving platform that has a strong future and cannot be ignored" party.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thu, 2013-09-19 at 00:53 +0100, Iain Buclaw wrote:
[…]
> Java itelf is a very basic language to allow this to be possible.  But the library implementation denies this, and I don't see native support beyond JNI.

JNA

But your core point as I infer it is valid. Running on the JVM it is best not to have to use native code libraries. I think the NAG Java adaptor to it's Fortran and C++ libraries will not gain any traction.

The new interest is getting support for the heterogeneous processors on the horizon. In threads elsewhere we started debating GPGPU support in D exactly because it will be a necessity in future processors. Java has two plays in this game already.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 18 September 2013 at 22:33:46 UTC, Chris wrote:
> On Wednesday, 18 September 2013 at 22:24:08 UTC, Paulo Pinto wrote:
>> http://www.excelsior-usa.com/jet.html
> I've heard of excelsior ($2,500+) and other implementations.

Excelsior guy here with a quick comment:

For many of our users, if not for most of them, the potential performance gain from AOT compilation is just a "nice-to-have". Their main concern these days is the ease of decompiling Java bytecode compared to reverse engineering optimized native code binaries:

http://www.excelsior-usa.com/articles/java-obfuscators.html

As far as the price tag is concerned, we have free licenses available for non-commercial use and discount programs for early stage startups and small businesses.

--
Dmitry

@Paulo

>Sorry to say this, but this was only because people had to pay for it.
>I have been part of the Java land since the beginning.
>Given that Sun made the SDK available for free, and much projects in Java land are FOSS, there is this culture of free (as in beer).

This is true, and I think this is the only reason why the byte code religion could persist. I started with Java in 2004/5 I think and although I liked the idea of "write once run everywhere" performance would always leave much to be desired.

@Russel

Fair enough, but if developers / users had to wait until Java 8 (since 1995!) for acceptable performance, you actually prove my point. I've seen loads of benchmarks but reality would always tell a different story, sorry. Maybe if you benchmark one specific function you can get a C++ like performance, but if you use it in real life, Java doesn't (or didn't) quite get there. Mind you, I'm saying this as someone who liked Java, it always galled me that I had to say "no" to Java because of performance issues _and_ because it would not be easy to deploy Java apps, because of the JVM.

Example needed? Ok. We wanted to deliver a desktop GUI app that could interact with our server. It was meant for visually impaired students (pupils). Their assistant teachers and mothers had no clue about JVM/JREs and didn't know if they were on 32 or 64 bit machines. Loads of emails and phone calls. Then the screen reading software would make a complete bullocks of the GUI (although Java Access Bridge was included and supposed to be working!). What users ask for is "can't I just download your app / plug in?" Well, with D, yes. And please don't tell me about "Java web based installation" etc etc. One application, one executable, one click (or double-click ;-). Full stop.

Then of course there is the whole mess with Swing and JavaFX, Matisse (discontinued) blah blah blah. It reads like a manual "Who to put developers off". It galled me that I had to bin the whole Java thing, but there you go. I am not a Java hater, far from it, and a AOT compiler would make me consider it an option again, at least as far as performance and deployability (if that's a word) are concerned.

On Thursday, 19 September 2013 at 09:30:21 UTC, Dmitry Leskov wrote:
> On Wednesday, 18 September 2013 at 22:33:46 UTC, Chris wrote:
>> On Wednesday, 18 September 2013 at 22:24:08 UTC, Paulo Pinto wrote:
>>> http://www.excelsior-usa.com/jet.html
>> I've heard of excelsior ($2,500+) and other implementations.
>
> Excelsior guy here with a quick comment:
>
> For many of our users, if not for most of them, the potential performance gain from AOT compilation is just a "nice-to-have". Their main concern these days is the ease of decompiling Java bytecode compared to reverse engineering optimized native code binaries:
>
> http://www.excelsior-usa.com/articles/java-obfuscators.html
>
> As far as the price tag is concerned, we have free licenses available for non-commercial use and discount programs for early stage startups and small businesses.
>
> --
> Dmitry

Yes, the whole issue of decompilation was also an issue. Funnily enough, a few years ago I wrote an email to Excelsior asking if you guys offer a discount for academia. Our project would have qualified as "non-commercial use". But I never got an answer. So I started looking for alternatives, and here I am now :-)

On Thursday, 19 September 2013 at 08:26:03 UTC, Russel Winder wrote:
> Java is no longer under-performant compared to C, C++, Fortran, D, Go, Rust. Check the benchmarks.
Interesting.  Java people have been saying this for years and it's never been quite true, so I just looked up the benchmark shootout to see if you're right.  It shows Java 7 doing pretty well against C++ these days, roughly equivalent speed or at worst half as fast:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&data=u64q

I'd still never use it as I hate how verbose Java is, but it's intriguing to see that they've tightened it up.  Of course, all the usual caveats apply, as these benchmarks are not necessarily representative, might have been gamed, blah, blah, blah...

On Wednesday, 18 September 2013 at 21:33:50 UTC, Chris wrote:
> Seeing that more and more developers and companies look for or actively develop native languages, I wonder will Java go native one day? (Cf. http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
>

Java as some design decision that will make it perform worse natively than in a VM.

Dynamic code loading + virtual by default is one example.

> Is this Java's only chance to keep up with Go and Rust (and D)?

It certainly isn't unless the language is modified and a large amount of code is thrown away.

On Thursday, 19 September 2013 at 09:52:40 UTC, deadalnix wrote:
> On Wednesday, 18 September 2013 at 21:33:50 UTC, Chris wrote:
>> Seeing that more and more developers and companies look for or actively develop native languages, I wonder will Java go native one day? (Cf. http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
>>
>
> Java as some design decision that will make it perform worse natively than in a VM.

Are there any benchmarks?

> Dynamic code loading + virtual by default is one example.
>
>> Is this Java's only chance to keep up with Go and Rust (and D)?
>
> It certainly isn't unless the language is modified and a large amount of code is thrown away.

Do you mean it isn't going to keep up with other languages or it isn't it's only chance?

On Thursday, 19 September 2013 at 08:26:03 UTC, Russel Winder wrote:
> And Windows native code applications don't ship with a version of all
> the Windows DLLs for every application?
>
> Java is no longer under-performant compared to C, C++, Fortran, D, Go,
> Rust. Check the benchmarks.
>

Benchmarks in Java are often misleading. The language promote a style with a lot of indirections, in the code and in datas. Once your application reach a certain size, cache effect makes it slowdown dramatically. But most benchmark applications aren't big enough to exhibit that behavior.

That being said, if you code in D like in java, you'll have the same trouble (in fact, it is likely to be worse in D). Compile time polymorphism and value types are here a major benefit of C/C++/C#/D (pick whatever you like).

Obviously, you'll find some pathologic cases where java is faster (usually mono-threaded memory allocation intensive benchmark exhibit that, as the JVM is able to add concurrency to the equation via the GC). But that doesn't represent the typical way most a program works (and when they do, you want to fix that as this is a performance killer, in every language, even if java suffers less from it).

The main problem of java isn't the VM, it is its addiction to indirections.

>> *Java's sluggish performance was what made me look for alternatives in the first place, and I found D.
>
> I accept this as true as it is a statement by you about your decision
> making, but Java 8 is not Java 1. Early desktop Java was pure
> interpretation, and hence slow. Modern Java, via the JIT, generally
> executes native code. With Java 7 and method handles and invokedynamic,
> the world changed even more and now computationally intensive codes can
> run basically as fast using Java as using C, C++, Fortran, D, Rust, Go.
> (After initial "warm up" of the JIT.)
>

Yes, the warm up is usually a severe drawback for user applications. Server app do not suffer from it that much. I guess that is why java is so much used server side, but not that much to create GUI apps.

On Thursday, 19 September 2013 at 08:31:28 UTC, Russel Winder wrote:
> On Thu, 2013-09-19 at 00:53 +0100, Iain Buclaw wrote:
> […]
>> Java itelf is a very basic language to allow this to be possible.  But
>> the library implementation denies this, and I don't see native support
>> beyond JNI.
>
> JNA
>
> But your core point as I infer it is valid. Running on the JVM it is
> best not to have to use native code libraries. I think the NAG Java
> adaptor to it's Fortran and C++ libraries will not gain any traction.
>
> The new interest is getting support for the heterogeneous processors on
> the horizon. In threads elsewhere we started debating GPGPU support in D
> exactly because it will be a necessity in future processors. Java has
> two plays in this game already.

Did you ever get around to making a wiki page etc. as discussed in the last thread about D GPGPU? I've been working on a fork of cl4d that's shaping up ok (I'm thinking of publishing to code.dlang.org once I've written a test-suite), but i'm relatively inexperienced with openCL.