>>>>> "Elias" == Elias Martenson <[EMAIL PROTECTED]> writes:
Elias> Going CNI-only would severely limit the number of 3'rd Elias> party component you'd be able to integrate. You can mix and match CNI and JNI in a single process. This happens any time you use JNI in libgcj. Maybe you meant to say that going CNI only would mean that you couldn't use java-gnome on non-libgcj runtimes, which is true. Elias> The fact that Java is heavily dynamic (sandboxed execution, etc...) is Elias> an enormous advantage, and I fail to see how an experienced Java Elias> developer who uses these things could ever even consider turning the Elias> back on everything that is Java, just to gain a little perceived Elias> performance. This is a common misconception of what gcj is all about. It's true that the AOT compiler is the centerpiece of the gcj approach. And it is also true that historically this meant less than perfect compatibility with the Java specification. However, it has always been our plan to provide a complete, compatible Java system. This year we are making great strides in this area. In particular the new binary compatibility ABI will let us erase the few remaining semantic differences; in essence gcj will look like a sort of caching JIT more than a pure AOT compiler. Second, for me at least, the primary consideration isn't the features, the performance, or any facet of the implementation (including even AOT compilation if it comes to that). The primary thing is freedom. Based on what you say, it sounds like we have different priorities here. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
