www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Will Java go native?

reply "Chris" <wendlec tcd.ie> writes:
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)? 
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.

*Java's sluggish performance was what made me look for 
alternatives in the first place, and I found D.
Sep 18 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 18.09.2013 23:33, schrieb Chris:
 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)?
 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.

 *Java's sluggish performance was what made me look for alternatives in
 the first place, and I found D.
Java is already native, don't confuse languages with implementations. Just because the reference implementation happens to be VM only, it does not mean all Java vendors offer plain VMs. Here are some native compilers for Java and JVMs that do AOT compilation as option: http://www.excelsior-usa.com/jet.html http://www.atego.com/products/aonix-perc/ http://www-03.ibm.com/software/products/us/en/real-time/ http://www.robovm.org/ http://jikesrvm.org/ http://www.aicas.com/sites/jamaica.html http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.60%2Fdiag%2Fappendixes%2Fcmdline%2Fcommands_jit.html -- Paulo
Sep 18 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 18 September 2013 at 22:24:08 UTC, Paulo Pinto 
wrote:
 Am 18.09.2013 23:33, schrieb Chris:
 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)?
 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.

 *Java's sluggish performance was what made me look for 
 alternatives in
 the first place, and I found D.
Java is already native, don't confuse languages with implementations. Just because the reference implementation happens to be VM only, it does not mean all Java vendors offer plain VMs. Here are some native compilers for Java and JVMs that do AOT compilation as option: http://www.excelsior-usa.com/jet.html http://www.atego.com/products/aonix-perc/ http://www-03.ibm.com/software/products/us/en/real-time/ http://www.robovm.org/ http://jikesrvm.org/ http://www.aicas.com/sites/jamaica.html http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.60%2Fdiag%2Fappendixes%2Fcmdline%2Fcommands_jit.html -- Paulo
I've heard of excelsior ($2,500+) and other implementations. Sorry, I meant that it will be native as part of the Java SE package, just as D ships with dmd.
Sep 18 2013
next sibling parent "Chris" <wendlec tcd.ie> writes:
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:
 Am 18.09.2013 23:33, schrieb Chris:
 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)?
 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.

 *Java's sluggish performance was what made me look for 
 alternatives in
 the first place, and I found D.
Java is already native, don't confuse languages with implementations. Just because the reference implementation happens to be VM only, it does not mean all Java vendors offer plain VMs. Here are some native compilers for Java and JVMs that do AOT compilation as option: http://www.excelsior-usa.com/jet.html http://www.atego.com/products/aonix-perc/ http://www-03.ibm.com/software/products/us/en/real-time/ http://www.robovm.org/ http://jikesrvm.org/ http://www.aicas.com/sites/jamaica.html http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.60%2Fdiag%2Fappendixes%2Fcmdline%2Fcommands_jit.html -- Paulo
I've heard of excelsior ($2,500+) and other implementations. Sorry, I meant that it will be native as part of the Java SE package, just as D ships with dmd.
Thanks for the links, btw. This all shows that there is a serious demand for Java as native code (cf. "The RoboVM compiler translates Java bytecode into native ARM or x86 code. Apps run directly on the CPU. No interpreter or virtual machine involved.")
Sep 18 2013
prev sibling parent reply "Dmitry Leskov" <dleskov excelsior-usa.com> writes:
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
Sep 19 2013
parent reply "Chris" <wendlec tcd.ie> writes:
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 :-)
Sep 19 2013
parent reply "Dmitry Leskov" <dleskov excelsior-usa.com> writes:
On Thursday, 19 September 2013 at 09:44:30 UTC, Chris wrote:
 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 :-)
We respond to all requests that look legit. Sending from a university email address certainly helps, not least because our responses to free email users, especially Gmail, often end up in the Junk Mail folder, probably because they talk about "free", "download", and such... -- Dmitry
Sep 19 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 20 September 2013 at 05:23:15 UTC, Dmitry Leskov wrote:
 On Thursday, 19 September 2013 at 09:44:30 UTC, Chris wrote:
 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 :-)
We respond to all requests that look legit. Sending from a university email address certainly helps, not least because our responses to free email users, especially Gmail, often end up in the Junk Mail folder, probably because they talk about "free", "download", and such... -- Dmitry
I sent the email from my university email address and the spam filter is clever enough to know that it shouldn't filter answers from email addresses I have sent an email to, even if the words "free" etc appear. If in doubt, at least it asks me. Anyway, I switched to D and don't regret it. Also how do you define "legit"? If I send an email with a simple question "do you offer a discount for university projects?" or the like, why am I not entitled to an answer? Why is it not "legit"? Because I didn't include an elaborate description of the project? Why should I, if I don't even know that you offer a discount? Would be a waste of time, if the answer is a plain "No!". This said, I don't rule it out that you answered the email and that it got lost on the way. This happens sometimes.
Sep 24 2013
parent reply "Dmitry Leskov" <dleskov excelsior-usa.com> writes:
On Tuesday, 24 September 2013 at 09:17:47 UTC, Chris wrote:
 On Friday, 20 September 2013 at 05:23:15 UTC, Dmitry Leskov 
 wrote:
 On Thursday, 19 September 2013 at 09:44:30 UTC, Chris wrote:
 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 :-)
We respond to all requests that look legit. Sending from a university email address certainly helps, not least because our responses to free email users, especially Gmail, often end up in the Junk Mail folder, probably because they talk about "free", "download", and such... -- Dmitry
I sent the email from my university email address and the spam filter is clever enough to know that it shouldn't filter answers from email addresses I have sent an email to, even if the words "free" etc appear. If in doubt, at least it asks me. Anyway, I switched to D and don't regret it. Also how do you define "legit"? If I send an email with a simple question "do you offer a discount for university projects?" or the like, why am I not entitled to an answer? Why is it not "legit"? Because I didn't include an elaborate description of the project? Why should I, if I don't even know that you offer a discount? Would be a waste of time, if the answer is a plain "No!". This said, I don't rule it out that you answered the email and that it got lost on the way. This happens sometimes.
If you asked a question like that, we most definitely responded. If you still have that email you sent us back in the day, would you please forward it to me? My email address is on the Contact page of our Web site.
Sep 27 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 27 September 2013 at 11:05:17 UTC, Dmitry Leskov wrote:
 On Tuesday, 24 September 2013 at 09:17:47 UTC, Chris wrote:
 On Friday, 20 September 2013 at 05:23:15 UTC, Dmitry Leskov 
 wrote:
 On Thursday, 19 September 2013 at 09:44:30 UTC, Chris wrote:
 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 :-)
We respond to all requests that look legit. Sending from a university email address certainly helps, not least because our responses to free email users, especially Gmail, often end up in the Junk Mail folder, probably because they talk about "free", "download", and such... -- Dmitry
I sent the email from my university email address and the spam filter is clever enough to know that it shouldn't filter answers from email addresses I have sent an email to, even if the words "free" etc appear. If in doubt, at least it asks me. Anyway, I switched to D and don't regret it. Also how do you define "legit"? If I send an email with a simple question "do you offer a discount for university projects?" or the like, why am I not entitled to an answer? Why is it not "legit"? Because I didn't include an elaborate description of the project? Why should I, if I don't even know that you offer a discount? Would be a waste of time, if the answer is a plain "No!". This said, I don't rule it out that you answered the email and that it got lost on the way. This happens sometimes.
If you asked a question like that, we most definitely responded. If you still have that email you sent us back in the day, would you please forward it to me? My email address is on the Contact page of our Web site.
Fair enough, I've forwarded the email. But the code has been rewritten in D and works on all platforms natively (including Windows, if you want to call that a platform).
Sep 27 2013
parent "Dmitry Leskov" <dleskov excelsior-usa.com> writes:
On Friday, 27 September 2013 at 13:35:53 UTC, Chris wrote:

 If you still have that email you sent us back in the day, 
 would you please forward it to me?

 My email address is on the Contact page of our Web site.
Fair enough, I've forwarded the email. But the code has been rewritten in D and works on all platforms natively (including Windows, if you want to call that a platform).
Thanks for the forward. That was back on Oct 12, 2010, and we did respond on the same day. I have replied to your Friday email a minute ago, posting here just in case it does not reach you again (sorry moderators.)
Oct 01 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 September 2013 22:33, Chris <wendlec tcd.ie> 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)? 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.

 *Java's sluggish performance was what made me look for alternatives in the
 first place, and I found D.
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. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 18 2013
next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Wednesday, 18 September 2013 at 23:53:35 UTC, Iain Buclaw 
wrote:
 On 18 September 2013 22:33, Chris <wendlec tcd.ie> 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)? 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.

 *Java's sluggish performance was what made me look for 
 alternatives in the
 first place, and I found D.
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.
Why, given the fact that I can buy native compilers? -- Paulo
Sep 18 2013
prev sibling parent reply "Olivier Pisano" <olivier.pisano laposte.net> writes:
On Wednesday, 18 September 2013 at 23:53:35 UTC, 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.
Native Java won't be a problem for D if they keep JNI for talking to the system. I wish I never had to work with JNI in multithreaded environment. All the type information goes away and their global reference system is impossible to use with RAII correctly. D's ability of using a C function just by declaring it and linking with C code is a bless.
Sep 19 2013
next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 19 September 2013 at 13:55:34 UTC, Olivier Pisano 
wrote:
 On Wednesday, 18 September 2013 at 23:53:35 UTC, 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.
Native Java won't be a problem for D if they keep JNI for talking to the system. I wish I never had to work with JNI in multithreaded environment. All the type information goes away and their global reference system is impossible to use with RAII correctly. D's ability of using a C function just by declaring it and linking with C code is a bless.
That I fully agree.
Sep 19 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 19 September 2013 at 13:55:34 UTC, Olivier Pisano 
wrote:
 D's ability of using a C function just by declaring it and 
 linking with C code is a bless.
Amen!
Sep 19 2013
parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 19 September 2013 at 14:52:03 UTC, Chris wrote:
 On Thursday, 19 September 2013 at 13:55:34 UTC, Olivier Pisano 
 wrote:
 D's ability of using a C function just by declaring it and 
 linking with C code is a bless.
Amen!
This was one of the design decisions that the Go guys did wrong, by requiring a C compiler to work with CGO. -- Paulo
Sep 19 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2013 2:33 PM, 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)
I wrote a native Java compiler in the 90's that was released by Symantec. There wasn't much interest in it.
Sep 18 2013
next sibling parent reply Jos van Uden <usenet fwend.com> writes:
On 19-9-2013 2:25, Walter Bright wrote:
 On 9/18/2013 2:33 PM, 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)
I wrote a native Java compiler in the 90's that was released by Symantec. There wasn't much interest in it.
I remember that. It was part of Visual Cafe. I did use it to create a command line app for a client. It was very convenient to be able to ship a regular executable that needed no further instructions.
Sep 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2013 6:01 PM, Jos van Uden wrote:
 On 19-9-2013 2:25, Walter Bright wrote:
 On 9/18/2013 2:33 PM, 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)
I wrote a native Java compiler in the 90's that was released by Symantec. There wasn't much interest in it.
I remember that. It was part of Visual Cafe. I did use it to create a command line app for a client. It was very convenient to be able to ship a regular executable that needed no further instructions.
I'm glad you liked it!
Sep 18 2013
parent reply "Colin Grogan" <grogan.colin gmail.com> writes:
On Thursday, 19 September 2013 at 02:37:26 UTC, Walter Bright 
wrote:
 On 9/18/2013 6:01 PM, Jos van Uden wrote:
 On 19-9-2013 2:25, Walter Bright wrote:
 On 9/18/2013 2:33 PM, 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)
I wrote a native Java compiler in the 90's that was released by Symantec. There wasn't much interest in it.
I remember that. It was part of Visual Cafe. I did use it to create a command line app for a client. It was very convenient to be able to ship a regular executable that needed no further instructions.
I'm glad you liked it!
Just how many compilers have you written?! :)
Sep 19 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2013 5:50 AM, Colin Grogan wrote:
 Just how many compilers have you written?! :)
http://www.walterbright.com
Sep 19 2013
prev sibling next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 19 September 2013 at 00:25:57 UTC, Walter Bright 
wrote:
 On 9/18/2013 2:33 PM, 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)
I wrote a native Java compiler in the 90's that was released by Symantec. There wasn't much interest in it.
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). Java Shops only pay for commercial Java tooling when: - There is no free JVM available. Common scenario in embedded systems; - The project requirements state a certain piece of software is to be used, like specific J2EE and CMS servers - The paid alternatives offer features worth their price (InteliJ) If the reference SDK provided by Sun, now Oracle, had a native code compiler as part of their toolset, you would see much more interest on them. From my list on the previous post, most compilers are commercial and as such, are only bought if the project requirements say so. For example, Sun/Oracle don't have any offering for the market Aonix and Aicas cover. -- Paulo
Sep 18 2013
prev sibling parent "Jason King" <jhking airmail.net> writes:
On Thursday, 19 September 2013 at 00:25:57 UTC, Walter Bright 
wrote:
 I wrote a native Java compiler in the 90's that was released by 
 Symantec. There wasn't much interest in it.
Visual Cafe always fascinated me. Is that something you have rights to and could re-release or is it locked in Symantec's vaults?
Sep 19 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-09-18 at 23:33 +0200, Chris wrote:
 Seeing that more and more developers and companies look for or=20
 actively develop native languages, I wonder will Java go native=20
 one day? (Cf.=20
 http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
=20
 Is this Java's only chance to keep up with Go and Rust (and D)?=20
No. It isn't even an option in the sense you intimate. As others have said there are Java =E2=86=92 native compilers and there is a thriving, alb= eit 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,=20
 Java always lags behind*. And the JVM installation horror is bad=20
 enough for developers, but for users? Now Java apps are often=20
 shipped with a version of the JRE included, which smells of=20
 defeat. If Oracle want to save Java (after so many "unfortunate"=20
 decisions), will they finally go native? I can see a market for=20
 that. There are still a lot of Java developers out there, there=20
 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=20
 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Sep 19 2013
next sibling parent "Chris" <wendlec tcd.ie> writes:
 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.
Sep 19 2013
prev sibling next sibling parent reply "Joakim" <joakim airpost.net> writes:
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...
Sep 19 2013
parent reply "Paul Jurczak" <pauljurczak yahoo.com> writes:
On Thursday, 19 September 2013 at 09:48:15 UTC, Joakim wrote:
 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 [...]
It doesn't do that well when single core is selected (always slower, 4x worst case): http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=java&lang2=gpp&data=u64 It means that Java VM/libraries can explore multiple cores better that C++.
Sep 21 2013
parent "PauloPinto" <pjmlp progtools.org> writes:
On Sunday, 22 September 2013 at 02:04:11 UTC, Paul Jurczak wrote:
 On Thursday, 19 September 2013 at 09:48:15 UTC, Joakim wrote:
 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 [...]
It doesn't do that well when single core is selected (always slower, 4x worst case): http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=java&lang2=gpp&data=u64 It means that Java VM/libraries can explore multiple cores better that C++.
Which in a day and age that you can hardly buy single core machines, is a big advantage. -- Paulo
Sep 22 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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 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.
Sep 19 2013
next sibling parent reply "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 19 September 2013 at 10:06:54 UTC, deadalnix wrote:
 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 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.
Java might eventually gain value types. The IBM J9 VM already has them. http://duimovich.blogspot.ca/2012/11/packed-objects-in-java.html http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 -- Paulo
Sep 19 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 19 September 2013 at 11:05:27 UTC, PauloPinto wrote:
 Java might eventually gain value types. The IBM J9 VM already 
 has them.

 http://duimovich.blogspot.ca/2012/11/packed-objects-in-java.html

 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
That is a very good news for java ! However, a lot of code will have to be rewritten to take advantage of this. This will allow to improve on a whole class of performance related problems.
Sep 19 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/19/13 4:05 AM, PauloPinto wrote:
 Java might eventually gain value types. The IBM J9 VM already has them.

 http://duimovich.blogspot.ca/2012/11/packed-objects-in-java.html

 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
I think I've heard of at least one more similar endeavor. The funny part is, this is acquiescence of the fact they're needed, which invalidates the former claim that Java was as fast as C before it had them... Andrei
Sep 19 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 19/09/2013 11:06, deadalnix wrote:
 *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.
Yeah, tell me about it. :/ When I was writing the new parser for DDT I explored and tested a few optimizations that the JVM does to ellide object allocations (essentially escape analysis to see when an object can be treated as value object, and deallocated automatically at the end of some scope). I wanted to use a certain pervasive code idiom in the parser that would make the code more elegant, but less performant if this optimization was not made. ( http://www.meetup.com/Londonjavacommunity/messages/52187462/ ) Fortunately the JVM is its later incarnations is quite smart in its escape analysis, but unfortunately this is all done at runtime, whereas a lot of it could be performed compile-time. :( But it seems the Java folks (at least for OpenJDK) have a big aversion to performing any kind of compile-time optimizations, even though a lot could be done here. -- Bruno Medeiros - Software Engineer
Sep 19 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 19.09.2013 19:44, schrieb Bruno Medeiros:
 On 19/09/2013 11:06, deadalnix wrote:
 *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.
Yeah, tell me about it. :/ When I was writing the new parser for DDT I explored and tested a few optimizations that the JVM does to ellide object allocations (essentially escape analysis to see when an object can be treated as value object, and deallocated automatically at the end of some scope). I wanted to use a certain pervasive code idiom in the parser that would make the code more elegant, but less performant if this optimization was not made. ( http://www.meetup.com/Londonjavacommunity/messages/52187462/ ) Fortunately the JVM is its later incarnations is quite smart in its escape analysis, but unfortunately this is all done at runtime, whereas a lot of it could be performed compile-time. :( But it seems the Java folks (at least for OpenJDK) have a big aversion to performing any kind of compile-time optimizations, even though a lot could be done here.
I once read in a blog, an entry from an ex-JVM engineer from Sun, describing that anything that disputed Hotspot JIT capabilities was tabu and ideas about native compilation were frowned upon. Sadly I don't remember any longer where I read it. -- Paulo
Sep 19 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 19/09/2013 19:44, Paulo Pinto wrote:
 Am 19.09.2013 19:44, schrieb Bruno Medeiros:
 On 19/09/2013 11:06, deadalnix wrote:
 *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.
Yeah, tell me about it. :/ When I was writing the new parser for DDT I explored and tested a few optimizations that the JVM does to ellide object allocations (essentially escape analysis to see when an object can be treated as value object, and deallocated automatically at the end of some scope). I wanted to use a certain pervasive code idiom in the parser that would make the code more elegant, but less performant if this optimization was not made. ( http://www.meetup.com/Londonjavacommunity/messages/52187462/ ) Fortunately the JVM is its later incarnations is quite smart in its escape analysis, but unfortunately this is all done at runtime, whereas a lot of it could be performed compile-time. :( But it seems the Java folks (at least for OpenJDK) have a big aversion to performing any kind of compile-time optimizations, even though a lot could be done here.
I once read in a blog, an entry from an ex-JVM engineer from Sun, describing that anything that disputed Hotspot JIT capabilities was tabu and ideas about native compilation were frowned upon. Sadly I don't remember any longer where I read it. -- Paulo
Even without seeing that article, I can well believe it. It seems they shun away completely from compile-time optimizations, and not much reasoning is given to that. It seems almost a purely political/marketing move: like if they want to push the mantra that JITing is the be all and end all of compiler optimization, and doing any kind of compile-time optimization would be admitting that compile-time is also important (and somehow making Java more prone to direct performance comparisons to other languages/platforms?) -- Bruno Medeiros - Software Engineer
Sep 20 2013
parent "Thiez" <thiezz gmail.com> writes:
On Friday, 20 September 2013 at 10:41:39 UTC, Bruno Medeiros 
wrote:
 Even without seeing that article, I can well believe it. It 
 seems they shun away completely from compile-time 
 optimizations, and not much reasoning is given to that. It 
 seems almost a purely political/marketing move: like if they 
 want to push the mantra that JITing is the be all and end all 
 of compiler optimization, and doing any kind of compile-time 
 optimization would be admitting that compile-time is also 
 important (and somehow making Java more prone to direct 
 performance comparisons to other languages/platforms?)
Perhaps you're being a little paranoid. I think they don't want to do optimization in the compiler because this would remove the incentive/pressure to implement those optimizations in the JVM, which is bad for all other languages/compilers that target the JVM. For the JVM-ecosystem it is best if as many optimizations possible are implemented in the JVM. If you look at existing benchmarks Java is comparable to many other languages/platforms with regard to performance.
Sep 20 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/19/13 1:25 AM, Russel Winder wrote:
 Java is no longer under-performant compared to C, C++, Fortran, D, Go,
 Rust. Check the benchmarks.
Hmmm, this is not established wisdom and the glib "check the benchmarks" doesn't quite help. Java has gotten on par with C and C++ for raw performance of "straight" code (numerics, I/O etc). I've seen such. Java seems to have issues involving layout control, which is an important influencer of performance in computing nowadays. Clearly the Java community has amassed a nice bag of tricks regarding performance optimization (parallel arrays, hoisting allocations, etc) but systems compilers and techniques have also made solid progress. When it comes to getting "all" performance, the C model is where it's at. Andrei
Sep 19 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 19/09/2013 17:58, Andrei Alexandrescu wrote:
 On 9/19/13 1:25 AM, Russel Winder wrote:
 Java is no longer under-performant compared to C, C++, Fortran, D, Go,
 Rust. Check the benchmarks.
Hmmm, this is not established wisdom and the glib "check the benchmarks" doesn't quite help. Java has gotten on par with C and C++ for raw performance of "straight" code (numerics, I/O etc). I've seen such. Java seems to have issues involving layout control, which is an important influencer of performance in computing nowadays. Clearly the Java community has amassed a nice bag of tricks regarding performance optimization (parallel arrays, hoisting allocations, etc) but systems compilers and techniques have also made solid progress. When it comes to getting "all" performance, the C model is where it's at. Andrei
I was about to say something similar. Java is no longer under-performant to C/C++, etc., for a *certain* class of applications only. Applications that mainly do data manipulation, I/O, etc., because the JIT will (eventually) compile the Java bytecode to native code. So Java really is not behind because of being VM-based instead of fully native-based. Generally though, I would still say Java is under-performant compared to C/C++, etc., although I would say it's mainly due to lack of optional manual memory management. Or lack of value-types (which in a way, are a form of memory management). I didn't think layout control would be a major issue, except for a very specific type of applications, no? That seems like a very low level optimization. -- Bruno Medeiros - Software Engineer
Sep 19 2013
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 19 September 2013 at 17:34:21 UTC, Bruno Medeiros 
wrote:
 I didn't think layout control would be a major issue, except 
 for a very specific type of applications, no? That seems like a 
 very low level optimization.
You can easily get large performance improvements from good memory layout (well over 2x).
Sep 19 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-09-19 at 18:34 +0100, Bruno Medeiros wrote:
[=E2=80=A6]
 I was about to say something similar. Java is no longer under-performant=
=20
 to C/C++, etc., for a *certain* class of applications only. Applications=
=20
 that mainly do data manipulation, I/O, etc., because the JIT will=20
 (eventually) compile the Java bytecode to native code.
 So Java really is not behind because of being VM-based instead of fully=
=20
 native-based.
=20
 Generally though, I would still say Java is under-performant compared to=
=20
 C/C++, etc., although I would say it's mainly due to lack of optional=20
 manual memory management. Or lack of value-types (which in a way, are a=
=20
 form of memory management).
 I didn't think layout control would be a major issue, except for a very=
=20
 specific type of applications, no? That seems like a very low level=20
 optimization.
I am not going to be drawn into a low-level blow-by-blow debate on this, definitely not on this list since it is inherently biased!, but mainly because Andrei will accuse me of being David Bryant again ;-) There are native code shops and JVM shops (as well as PVM shops, and Ruby shops, etc.) There is a quasi-religious fervour involved in each of these. To be honest I do not care, I am happy working native (D, Go, Rust, C++, but not C) or JVM (Groovy, Scala, Java, Ceylon, Kotlin, Clojure, JRuby, Jython), or PVM (Python), or Ruby. For me there is no absolute best, just a relative best for the client involved. Skills of the team involved at the time, and the overall dependencies of the organizations, matter as much as any absolute notion of best wrt a processor. I do note though that The Disruptor (by LMAX) is a seriously cool lock free ring buffer based system written entirely in Java. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Sep 19 2013
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 19 September 2013 at 23:37:05 UTC, Russel Winder 
wrote:
 I do note though that The Disruptor (by LMAX) is a seriously 
 cool lock
 free ring buffer based system written entirely in Java.
The Apache Cassandra distributed database is using it in its latest incarnation, among other things.
Sep 21 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-09-19 at 00:53 +0100, Iain Buclaw wrote:
[=E2=80=A6]
 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Sep 19 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Sep 19 2013
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-09-19 at 12:11 +0200, John Colvin wrote:
[=E2=80=A6]
 Did you ever get around to making a wiki page etc. as discussed=20
 in the last thread about D GPGPU? I've been working on a fork of=20
 cl4d that's shaping up ok (I'm thinking of publishing to=20
 code.dlang.org once I've written a test-suite), but i'm=20
 relatively inexperienced with openCL.
I have been up to my neck in Python activity over the last 4 months, I had to put responding to your email in that thread and doing the "leg work" to keep things bubbling, on the back burner. Sorry. Things settle down after end of October. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Sep 19 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Sep 19 2013
next sibling parent "Chris" <wendlec tcd.ie> writes:
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?
Sep 19 2013
prev sibling parent reply "PauloPinto" <pjmlp progtools.org> writes:
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. 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.
Well, nothing that cannot be cured with PGO, just like in C++'s case. -- Paulo
Sep 19 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 19 September 2013 at 11:23:10 UTC, PauloPinto wrote:
 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. 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.
Well, nothing that cannot be cured with PGO, just like in C++'s case.
PGO do not allow finalization of method that can dynamically overriden. Only a JIT can do that. The main difference between JIT and OAT optimizaer is that JIT can be optimistic, and fix later if it turns out to be wrong. AOT must consider the worst case scenario. The benefit of AOT being, obviously, to pay the cost ahead of time instead of at runtime. In java, all classes are dynamically loadable, and most functions are virtual. This is a deal breaker for the AOT.
Sep 19 2013
parent reply "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 19 September 2013 at 11:38:35 UTC, deadalnix wrote:
 On Thursday, 19 September 2013 at 11:23:10 UTC, PauloPinto 
 wrote:
 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. 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.
Well, nothing that cannot be cured with PGO, just like in C++'s case.
PGO do not allow finalization of method that can dynamically overriden. Only a JIT can do that. The main difference between JIT and OAT optimizaer is that JIT can be optimistic, and fix later if it turns out to be wrong. AOT must consider the worst case scenario. The benefit of AOT being, obviously, to pay the cost ahead of time instead of at runtime. In java, all classes are dynamically loadable, and most functions are virtual. This is a deal breaker for the AOT.
Wrong. The Java AOT compilers that target embedded systems produce static binaries. -- Paulo
Sep 19 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 19 September 2013 at 13:05:17 UTC, PauloPinto wrote:
 Wrong. The Java AOT compilers that target embedded systems 
 produce static binaries.
I don't think that address anything. As long as you CAN dynamically load override, then you can't optimize AOT, and if you can't then, it isn't java, but some kind of java like dialect that is amputed of some of its capabilities.
Sep 19 2013
next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 19 September 2013 at 14:28:04 UTC, deadalnix wrote:
 On Thursday, 19 September 2013 at 13:05:17 UTC, PauloPinto 
 wrote:
 Wrong. The Java AOT compilers that target embedded systems 
 produce static binaries.
I don't think that address anything. As long as you CAN dynamically load override, then you can't optimize AOT, and if you can't then, it isn't java, but some kind of java like dialect that is amputed of some of its capabilities.
Why would you dynamically load firmware during code execution? This is for embedded systems. -- Paulo
Sep 19 2013
prev sibling next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 19 September 2013 at 14:28:04 UTC, deadalnix wrote:
 On Thursday, 19 September 2013 at 13:05:17 UTC, PauloPinto 
 wrote:
 Wrong. The Java AOT compilers that target embedded systems 
 produce static binaries.
I don't think that address anything. As long as you CAN dynamically load override, then you can't optimize AOT, and if you can't then, it isn't java, but some kind of java like dialect that is amputed of some of its capabilities.
Just to provide a bit more of detail what I am talking about, here you can read about how AOT works in Websphere Realtime VM case. http://www.ibm.com/developerworks/library/j-rtj5/index.html -- Paulo
Sep 19 2013
prev sibling parent "Nikita Lipsky" <nlipsky excelsior-usa.com> writes:
On Thursday, 19 September 2013 at 14:28:04 UTC, deadalnix wrote:
 On Thursday, 19 September 2013 at 13:05:17 UTC, PauloPinto 
 wrote:
 Wrong. The Java AOT compilers that target embedded systems 
 produce static binaries.
I don't think that address anything. As long as you CAN dynamically load override, then you can't optimize AOT, and if you can't then, it isn't java, but some kind of java like dialect that is amputed of some of its capabilities.
If the most of your classes are known before run and are loaded by known to AOT compiler classloader (99.99% of your classes usually), you can optimize them with AOT. For other classes (that appear at runtime only or loaded by unknown classloader) JVM with AOT may have JIT or interpreter. Excelsior JET runtime has JIT, GCJ has interpreter for this purpose.
Sep 19 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/19/13 6:05 AM, PauloPinto wrote:
 In java, all classes are dynamically loadable, and most functions are
 virtual. This is a deal breaker for the AOT.
Wrong. The Java AOT compilers that target embedded systems produce static binaries.
That's not wrong. Java AOT compilers usually (or at least last time I looked) make it clear they support no dynamic loading/invocation etc. so in a sense they don't support 100% of Java. Andrei
Sep 19 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.09.2013 19:21, schrieb Andrei Alexandrescu:
 On 9/19/13 6:05 AM, PauloPinto wrote:
 In java, all classes are dynamically loadable, and most functions are
 virtual. This is a deal breaker for the AOT.
Wrong. The Java AOT compilers that target embedded systems produce static binaries.
That's not wrong. Java AOT compilers usually (or at least last time I looked) make it clear they support no dynamic loading/invocation etc. so in a sense they don't support 100% of Java. Andrei
In Websphere Real Time VM you can have a mixed deployment mode. Not sure about other AOT compilers. I was stating the specific case of targeting embedded processors, where I think dynamic loading and reflection are anyway not that relevant. Even C and C++ are not fully supported in all types of embedded scenarios. -- Paulo
Sep 19 2013
prev sibling parent "Dmitry Leskov" <dleskov excelsior-usa.com> writes:
On Thursday, 19 September 2013 at 17:21:16 UTC, Andrei 
Alexandrescu wrote:
 On 9/19/13 6:05 AM, PauloPinto wrote:
 In java, all classes are dynamically loadable, and most 
 functions are
 virtual. This is a deal breaker for the AOT.
Wrong. The Java AOT compilers that target embedded systems produce static binaries.
That's not wrong. Java AOT compilers usually (or at least last time I looked) make it clear they support no dynamic loading/invocation etc. so in a sense they don't support 100% of Java.
You have not looked for way too long it seems. Our JVM with AOT compiler passes the official compliance tests (Java Compatibility Kit), which includes reflaction/invocation tests. Of course, if the class being loaded dynamically was known at compile time, it will resolve to the precompiled image, otherwsie, a JIT compiler kicks into action. GCJ has an interpreter serving the same purpose. We even went a step further and created an interesting technique that enables you to reduce application download size and disk footprint by omitting the unused parts of the Java platform: http://www.excelsior-usa.com/java-download-size.html In order to remain spec compliant, the runtime is capable of downloading the omitted on demand. However, for sample apps that you can download from the above URL, there was not a single such download ever.
Sep 19 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 September 2013 09:31, Russel Winder <russel winder.org.uk> wrote:
 On Thu, 2013-09-19 at 00:53 +0100, Iain Buclaw wrote:
 [=85]
 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.
I think I had a bit too much to drink (see cocktail thread). But yes, that is the general essence, though I was more leaning on Java's class hierarchy and being virtual by default. This is something that you can't get away from in native code, where as in most Java JIT implementations, they are designed explicitly for lots of virtual calls, such as the ability to inline virtual functions at runtime which makes virtual calls as cheap as non-virtual. In native code however, there is no way for the compiler to optimise this at compile-time, and the slowdown grinds as the code base grows (gcc's libjava is 230K LOC for example), and the result is that you end up paying through the nose without asking - we've already discussed this plentiful in D's design choice to go virtual by default. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Sep 19 2013
parent reply "Dmitry Leskov" <dleskov excelsior-usa.com> writes:
On Thursday, 19 September 2013 at 17:55:22 UTC, Iain Buclaw wrote:
 But yes, that is the general essence, though I was more leaning 
 on
 Java's class hierarchy and being virtual by default. This is 
 something
 that you can't get away from in native code, where as in most 
 Java JIT
 implementations, they are designed explicitly for lots of 
 virtual
 calls, such as the ability to inline virtual functions at 
 runtime
 which makes virtual calls as cheap as non-virtual.

 In native code however, there is no way for the compiler to 
 optimise
 this at compile-time, and the slowdown grinds as the code base 
 grows
 (gcc's libjava is 230K LOC for example), and the result is that 
 you
 end up paying through the nose without asking - we've already
 discussed this plentiful in D's design choice to go virtual by
 default.
Our AOT compiler does inline virtual calls of non-final methods that are not overloaded in any subclass known at compile time. Of course, there is a runtime check and a backup virtual call, but the check is cheap and code size increase in negligible. What we don't do (yet) is profile-guided optimizations, but that is on our to-do list. -- Dmitry www.ExcelsiorJET.com
Sep 19 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 20 September 2013 at 05:31:09 UTC, Dmitry Leskov wrote:
 Our AOT compiler does inline virtual calls of non-final methods 
 that are not overloaded in any subclass known at compile time. 
 Of course, there is a runtime check and a backup virtual call, 
 but the check is cheap and code size increase in negligible.

 What we don't do (yet) is profile-guided optimizations, but 
 that is on our to-do list.
So basically what you do is : funptr = load from vtbl; if (funptr == compile_time_known_value) { compile_time_known_value(); } else { funptr(); } Which avoid the indirection if the function is actually called most of the time. Am I right ?
Sep 20 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/20/13, deadalnix <deadalnix gmail.com> wrote:
 So basically what you do is :

 funptr = load from vtbl;
 if (funptr == compile_time_known_value) {
      compile_time_known_value();
 } else {
      funptr();
 }
OT: This reminds me of a small benchmark I did recently where using a signal implementation with two pointers (function and delegate, to allow connecting to both) is faster than using a single delegate and converting a function pointer to a delegate via toDelegate(). It boiled down to: if (funcPtr !is null) funcPtr(...); else if (delegPtr !is null) delegPtr(...);
Sep 20 2013
prev sibling parent "Dmitry Leskov" <dleskov excelsior-usa.com> writes:
On Friday, 20 September 2013 at 07:19:44 UTC, deadalnix wrote:
 On Friday, 20 September 2013 at 05:31:09 UTC, Dmitry Leskov 
 wrote:
 Our AOT compiler does inline virtual calls of non-final 
 methods that are not overloaded in any subclass known at 
 compile time. Of course, there is a runtime check and a backup 
 virtual call, but the check is cheap and code size increase in 
 negligible.

 What we don't do (yet) is profile-guided optimizations, but 
 that is on our to-do list.
So basically what you do is : funptr = load from vtbl; if (funptr == compile_time_known_value) { compile_time_known_value(); } else { funptr(); } Which avoid the indirection if the function is actually called most of the time. Am I right ?
Almost: funptr = load from vtbl; if (funptr == compile_time_known_value) { // Inlined body of compile_time_known_value() goes here } else { funptr(); }
Sep 22 2013