For some reason, the discussion went offline from this group, so let me
repost my latest response to Clayton:
> For myself, I'd like to see an alternative to Mono and C# for things like
> PlayStation hobbyist development, and I don't believe that runtime
> performance is a significant barrier to the JVM being used for that.
Fair enough. There is no doubt that the JVM is uber-optimized and, for
a large class of tasks, it is awesome at what it does once it's warmed
up. I'm just... less interested in the runtime engine itself and
ideally would just want to replace Mono with Dalvik, JVM, Parrot...
you name it.
> I don't understand this. How does Mono assist in using code from other
> languages?
Are you a *NIX/POSIX guy and know about libc? Say you have a need for
doing fast base2 logarithms (not native in java.util.Math package nor
System.Math namespace. In C#, you can encapsulate libc's
implementation easily doing something like this:
class ExtendedMath
{
[DllImport ("libc.so.6")]
private static extern double log2(double);
public static double Log2(double arg)
{
return log2(arg);
}
}
You wouldn't believe the horrorshow of doing this via JNI, using javah
to generate header files, add these to the projects build path, write
wrapper in C/C++, write wrapper in Java using System.loadLibrary(). In
other words, while the JVM/Java is about *platform interoperability*,
the CLR/C# is about *code interoperability*. As someone who lives in a
heterogeneous world, recognizing that some tools/languages are better
than others for a given task, I rather like code interoperability.
> This is one issue I really strongly disagree with you about. Both the JVM
> specification and the JVM software implementation are completely malleable
> entities. Absolutely every line of code in that JVM can be changed for
> future versions. The premise that some past design decisions of the JVM
> somehow prevent you from adding features like this for future versions is
> unreasonable. Some changes impose backwards compatability costs or various
> other costs, of course, but most things can be changed.
Nothing you've said above, serves to contradict what I say or convince
me that I am wrong. Fact: To support multiplication, the JVM specifies
imul, lmul, fmul and dmul instructions (same overhead for addition,
subtraction, division, modulus, negation, load, store etc.) and there
simple aren't enough instructions left of the 255 available, to do
this in a backwards compatible way. I'd like to be proven wrong, but
changing binary backwards compatability is extremely unlikely scenario
among the conservative gang of Oracle developers.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/Scb5OUifzkAJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
