Amiga.org
The "Not Quite Amiga but still computer related category" => Alternative Operating Systems => Topic started by: asian1 on October 28, 2006, 12:03:36 AM
-
Sun Microsystem plan to release the source code of Java in the next 60 days.
If this source code can be ported to AmigaOS 3.X, 4.X, AROS and MorphOS, is it possible to create multi platform application on the above OS?
Will this enable many new applications to run on the above OS?
From Cnet:
"Sun Microsystems is likely to use the Community Development and Distribution License to govern the forthcoming open source Java software project, chief executive Jonathan Schwartz said on Wednesday. "We're within 30 to 60 days of announcing the open sourcing of the core Java platform, using an OSI-approved licence — likely the same licence as we use for the Solaris operating system," Schwartz said during an Oracle OpenWorld speech in San Francisco."
-
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.
-
Please note that they said "We're within 30 to 60 days of announcing the open sourcing of the core Java platform" which means that in two months it will be officialy announced that Java goes open-source, not that the source will be available at that time. Moreover, so far they are open-sourcing only the core.
-
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.
-
Is the solaris license even compitable with the linux license?
-
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.
-
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.
-
@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.
-
@Karlos
Actually, GCJ (http://gcc.gnu.org/java/) can compile Java directly to machine language so the code can theoretically outperform a JIT. However, the GNU ClassPath isn't as well optimized as Sun's classes.
-
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
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.
-
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 ;-)
-
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.
-
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!
-
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 ;-)
-
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.
-
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.
-
@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.
-
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:
-
SamuraiCrow wrote:
Likewise, AFAIK, GNU ClassPath is implemented in C++ rather than Java.
That's improved my confidence in it already ;-)
-
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
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?
-
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 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 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
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 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:
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).
-
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 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!
-
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.
:-)
-
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
-
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 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).
-
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
-
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.
-
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.