Open Source Java

[smithy]

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.

I think it's safe to assume that the classes will be open sourced too (what would be the point otherwise?).  The source code for the classes is already supplied with the Java 2 SDK anyway and has been for years.

[smithy]

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! :-)

edit:
And I'd guess the developer tools would be open-sourced too.  All of the substance of the dev tools are written in Java and are part of the core class library, so no porting required.  The binaries in the SDK/JRE's bin folder are just stubs that don't do much beyond calling the corresponding stuff in the (private) API.

[smithy]

SamuraiCrow wrote:
The trouble is in the porting.  Sun's code will likely only work on Linux.  Amiga has a few virtual machines that will work but the Swing, AWT, and similar such GUI classes haven't been ported yet.

Swing is written entirely in Java, so again, no porting needed here.

AWT is written partially in Java.  How much I don't know for sure.  How much of the native stuff can be ported, as opposed to being re-implemented is the key question.  You'd hope their SAL just does dumb stuff like open windows, rather than implement any of Java's horribly complicated GUI layouters.

[smithy]

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!

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

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

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

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

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

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

[smithy]

Karlos wrote:

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?

I've never had the need to do it myself, so I don't know all the ins and outs, but it's a useful abstraction layer.

If you want to store your .class files somewhere else that a default classloader could never find, on a database say, or a on particular place on your network.. your custom classloader might handle the connection and issue SQL, or look in that place on the network.

Or you could support unloading classes that might only be used a few times (depends on your application needs).