Open Source Java

[Karlos]

SamuraiCrow wrote:
AARGH!  Without the classes Java is worthless!  We already have versions of the core.  We need the classes.  Maybe somebody should look into GNU ClassPath.

Even if we had them, without a decent JIT VM, any large scale java apps would crawl.

[Karlos]

smithy wrote:

Karlos wrote:
Even if we had them, without a decent JIT VM, any large scale java apps would crawl.

The whole point is to open source Sun's JIT JVM! :-)

Sure, and no doubt it's fantastic if you are only interested in emitting x86 code from the JIT ;-)

[Karlos]

Always the fine print, ey?

A half decent Java runtime for AmigaOS, would be most welcome as it's a fundamentally easier and cleaner language for many developers to get to grips with.

There are also some java compilers that can convert java source directly into native executables. How good they are, I'm not sure (and how they interface to the existing class libraries I don't know) but they could be a good option for java applications for the classic machines.

[Karlos]

smithy wrote:

Karlos wrote:
Sure, and no doubt it's fantastic if you are only interested in emitting x86 code from the JIT ;-)

Doh!  That completely passed my by!.

Er, another reason for a port to.... no, I won't go there ;-)

It's a common enough oversight. People are so used to 'standardised' open source where they think all they have to do is reimplement a few foundation classes for platform X and all is done.

JIT on the other hand is so fundamentally low level that it requires a much greater knowledge of the target platform, it's processor architecture and other low level resource issues. It's not unusual to find code that has been so fine tuned that not only is it tied to a given CPU but even that code doesn't translate that well to another OS using the same CPU :lol:

[Karlos]

SamuraiCrow wrote:
Likewise, AFAIK, GNU ClassPath is implemented in C++ rather than Java.

That's improved my confidence in it already ;-)

[Karlos]

@Smithy

JIT versus statically compiled code becomes an important consideration for people implementing server applications and things of that nature.

Statically compiled code, although often better than JIT initially (and certainly an order of magnitude faster than interpreted) soon ages. When you upgrade your hardware you don't always get the full benefit without recompiling. Therefore, for peak performance you need to keep rebuilding your code whenever you upgrade. That's a headache for most people.

A JIT however, you can just replace with a version that's optimized for your target platform. All the code running on it gets the benefit of the improvements without any additional maintenance. If there's a problem, rolling back is also a trivial matter. This is quite a selling point for most organisations.

Why would they opt to use a third party compiler when they can get the performance advantage from the opened up JIT?

[Karlos]

smithy wrote:
GCJ is based on GCC so it generates code just as well as the C++ that CCJ uses as an intermediate code.  Likewise, AFAIK, GNU ClassPath is implemented in C++ rather than Java.

It can't be written in C++ because the JVM wouldn't be able to execute it.

[/quote]

Surely that depends on the JVM implementation? I mean, a modified classloader could handle the loading and linking native object code and java bytecode seperately without any one java class knowing if the thing it's calling is native or not.

[Karlos]

@Smithy

I think you misunderstood me. Basically, I am asking, who would use a static compiler for their java application deployment if a JIT is able to deliver similar performance without ever having to recompile the application should the hardware get updated?

The main reasons for using a compiler are to get speed on systems where a JIT is not available (for whatever reason) or for protecting your code (bytecode is pretty easy to decompile). The latter isnt much of a problem for a server application however, so the main reason for using a compiler would be the former. If you were running a server, would you prefer to just update the JVM itself whenver you needed to upgrade, or recompile all your code?

Opening up the JIT like this basically kicks out one of the legs from under using a compiler on any given platform, performance is no longer an issue.

[Karlos]

I wasn't aware you had any control over the internal operation of ClassLoader ? I thought all the low level stuff was private and final?

-edit-

Never mind. I'm getting a bit OT :lol:

[Karlos]

When you say static compiler, do you mean compile to machine code rather than byte code?

Aye, the creation of native object code, rather than bytecode. I guess I could have been clearer about that :-D

Regarding the "not using java" for performance reasons, you might not have the luxury depending on what technologies you were using.

Anyway, it's a moot point. The easiest thing to do is look at the ClassPath sources and see what they did :-D

[Karlos]

You can write your own classloaders and override the system's.

Interesting. Are there any practical examples of why and how you'd do this?

[Karlos]

Ok, I can see that you can control where a class is loaded from and how, but going back to the earlier point, unless you have control over the physical inspection of the bytecode and it's runtime linkage, surely some inaccessible implemententation part of the main ClassLoader is invoked to do the real work once you have a handle on the file?

What I'm saying is, that implementation detail might be able to differentiate between native and bytecode implemented classes and you yourself would never know (or need to know) if it was native or not. Just musing :-D