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.

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.

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.

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.

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.")

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

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 :-)

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

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.

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.

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).

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.)

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';

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.

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.

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.

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

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

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.

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...

And Windows native code applications don't ship with a version
of all
the Windows DLLs for every application?
Java is no longer under-performant compared to C, C++, Fortran,
D, Go,
Rust. Check the benchmarks.

Benchmarks in Java are often misleading. The language promote a
style with a lot of indirections, in the code and in datas. Once
your application reach a certain size, cache effect makes it
slowdown dramatically. But most benchmark applications aren't big
enough to exhibit that behavior.
That being said, if you code in D like in java, you'll have the
same trouble (in fact, it is likely to be worse in D). Compile
time polymorphism and value types are here a major benefit of
C/C++/C#/D (pick whatever you like).
Obviously, you'll find some pathologic cases where java is faster
(usually mono-threaded memory allocation intensive benchmark
exhibit that, as the JVM is able to add concurrency to the
equation via the GC). But that doesn't represent the typical way
most a program works (and when they do, you want to fix that as
this is a performance killer, in every language, even if java
suffers less from it).
The main problem of java isn't the VM, it is its addiction to
indirections.

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

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

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

And Windows native code applications don't ship with a version
of all
the Windows DLLs for every application?
Java is no longer under-performant compared to C, C++,
Fortran, D, Go,
Rust. Check the benchmarks.

Benchmarks in Java are often misleading. The language promote a
style with a lot of indirections, in the code and in datas.
Once your application reach a certain size, cache effect makes
it slowdown dramatically. But most benchmark applications
aren't big enough to exhibit that behavior.
That being said, if you code in D like in java, you'll have the
same trouble (in fact, it is likely to be worse in D). Compile
time polymorphism and value types are here a major benefit of
C/C++/C#/D (pick whatever you like).
Obviously, you'll find some pathologic cases where java is
faster (usually mono-threaded memory allocation intensive
benchmark exhibit that, as the JVM is able to add concurrency
to the equation via the GC). But that doesn't represent the
typical way most a program works (and when they do, you want to
fix that as this is a performance killer, in every language,
even if java suffers less from it).
The main problem of java isn't the VM, it is its addiction to
indirections.

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

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

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

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

*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

*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

*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

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.

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

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

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

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

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.

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

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.

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.

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.

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

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.

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.

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

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.

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';

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

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 ?

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(...);

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 ?