Open Source Java

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

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

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

[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

[Tomas]

Piru wrote:
@Tomas

Is the solaris license even compitable with the linux license?

GPL does not require that applications running on top of GPL operating system are GPL aswell. Read the license.

I am no GPL expert, but i know most linux distros refuse to bundle certain OSS with the distro because of license not being compitable.

[SamuraiCrow]

smithy wrote:

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?

The difference is that GCJ can compile bytecode into native binary.  It can also compile source into native binary.  It is a static compiler based on GCC and, as such, is GPL so no Linux distro would need to do without it for reasons of licence incompatibiltiy.