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