Open Source Java

[smithy]

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!  (but the most important Amiga variety does have a x86 version)

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

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

[SamuraiCrow]

smithy wrote:

SamuraiCrow wrote:
@smithy

There is a licence fee that must be paid for distribution of the Java Classes.  That's why AmigaDE didn't ship with them by default but, instead, required you to download them from Sun's site.

Ahhhh.. I didn't know that... but hopefully this will be covered in the open source terms - otherwise it won't really be open source!

That's just the point.  It WON'T likely be completely open-source.  Only the VM itself will be open-source.  This is just an attempt by Sun to disarm the advantages of GCJ over its own JIT.

[SamuraiCrow]

@Karlos

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.

[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 ;-)

[smithy]

SamuraiCrow wrote:
That's just the point.  It WON'T likely be completely open-source.  Only the VM itself will be open-source.

From what I've read it's not clear what they intend to open source.

This is just an attempt by Sun to disarm the advantages of GCJ over its own JIT.

How would Sun's open source JVM impact somebody else's open source Java compiler?  I can't see any affect on GCJ if Sun only opene-sourced their JVM.

[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?

[smithy]

SamuraiCrow wrote:
@Karlos

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.  You could have a proxy class written in Java which then called the corresponding native Classpath class but seems unnecessarily convoluted in return for no advantages.

Even if they did do that, they'd likely hit interoperability problems with third party software... for example JDBC and security providers and JAXP implementations.

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

[smithy]

Karlos wrote:
@Smity

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?

You are talking about the difference between using a JIT JVM and a non-JIT JVM.  But this has nothing to do at all with GCJ because GCJ is just a compiler - it compiles Java source code into bytecode.  It doesn't attempt to run it, so no JIT is involved or needed.

You can run bytecode created by GCJ on any compliant JVM, JIT or not.  There is no need to recompile it based on whether you use a JIT JVM.

So static or dynamic compilation doesn't really apply here, because one, or both can be done, it's up to you.

My original question was, how does Sun's decision to open up it's JVM impact GCJ, a source-compiler?

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

[smithy]

Karlos wrote:
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.

Even if you could change the bootstrap classloader on every JVM (not even sure if you can on Sun's), then you still have the problem of applications that use their own classloaders.  If I wrote a trivial, but badly behaved classloader that didn't delegate to the parent (and I have seen this) and I did:

Code: [Select]

myloader.loadClass("java.lang.Vector");

Then it would fail because my classloader isn't aware that java.lang.Vector has been compiled to machine code and lives in a DLL somewhere.

The problem here is that while it could theoretically work, it will break lots of applications.  I've never seen the GNU Classpath source code but I'd bet a lot of money that it's written in Java (unless they went with the Java proxy -> native class that I mentioned earlier).

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

[smithy]

Karlos wrote:
@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?

When you say static compiler, do you mean compile to machine code rather than byte code?  I still don't think this has any impact on GCJ.  If you use GCJ rather than Sun's "javac" tool, then it means you are probably an open-source, er, "believer", shall we say?  In which case, you'll probably also be using one of the many open source JIT JVMs anyway.

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

Compiling to binary, like you say, might be mainly to protect your source code.  But you won't be doing it because you don't have an open source JIT JVM (there are plenty of them) in which case an open source Sun JIT VM isn't going to help you.

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?

If I was using Java on the server then I'd be using J2EE, of which every implementation has JIT (even the open source JBoss has JIT - you'd have to look hard to find a server JVM without JIT).  There is no prospect of using any native code with J2EE.  But then, if I was really interested in performance, and I mean really, because JIT Java is fast - native will not improve your execution speeds much, then I'd not use Java in the first place!

[smithy]

Karlos wrote:
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?

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

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

Not at all OT!  These are all issues that I'm sure the ClassPath team went through during their design process.
 :-)