Will Java go native?

[Iain Buclaw]

On 19 September 2013 09:31, Russel Winder <russel at winder.org.uk> 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.
>

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.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';