Steve Fosdick fozzy@pelvoux.demon.co.uk writes:
I now have FOP installed though I am little disapointed that the only Java VM it seems to work with is a non-free one, but it now seems to be working.
Is there any JVM which is both current *and* free?
On Sat, 08 Sep 2001 17:45:49 MJ Ray wrote:
Steve Fosdick fozzy@pelvoux.demon.co.uk writes:
I now have FOP installed though I am little disapointed that the only Java VM it seems to work with is a non-free one, but it now seems to be working.
Is there any JVM which is both current *and* free?
I suspect that is the problem.
What I ended up with is the JRE 1.3 from Blackdown which they say they have license from Sun and this is the only one that did not compain.
Some limited functionaility seemed to work with kaffe but before long it threw an exception about an unimplemented method.
Before that I had noted that GCC 3 came with a Java compiler which claimed also to compile java bytecode into native code which seemed like an excellent idea. Unfortunately it doesn't seem to handle the AWT stuff.
All told it would seem that Java is a poor choice for open source software as it ensures it isn't properly free software.
Steve.
Steve Fosdick wrote:
What I ended up with is the JRE 1.3 from Blackdown which they say they have license from Sun and this is the only one that did not compain.
I've been writing serious Java code for about 6 years now (cut my teeth on 1.0 alpha!). In my experience the blackdown port is generally the most stable on linux, Kaffe I have had several problems with and I have generally given up on using it for any of my work, but then I am usually doing some very strange things ;) I have not played with GJC yet so I can't commenet on that.
One Java compiler/runtime I may suggest looking at is Jikes (from IBM). I used it a few years ago and was very impressed. I'm not sure how well it plays with apache/java serverlets though.
Sz
On Sun, 09 Sep 2001 14:46:17 Neill Newman wrote:
I've been writing serious Java code for about 6 years now (cut my teeth on 1.0 alpha!). In my experience the blackdown port is generally the most stable on linux, Kaffe I have had several problems with and I have generally given up on using it for any of my work, but then I am usually doing some very strange things ;)
I seem to remember someone earlier recommending the Blackdown blackdown implementation which is how I came to go there. I just thought I would see if there was a free implementation that works.
Neill, as someone who is a Java expert talking to be who is very definitely looking in at it from the outside, perhaps you could comment on what it's advantages are.
okay fozzy, I'll try my best to give my opinion as unbiased as possible... but it is just that, "my opinion" ;)
Steve Fosdick wrote:
On Sun, 09 Sep 2001 14:46:17 Neill Newman wrote:
I've been writing serious Java code for about 6 years now (cut my teeth on 1.0 alpha!). In my experience the blackdown port is generally the most stable on linux, Kaffe I have had several problems with and I have generally given up on using it for any of my work, but then I am usually doing some very strange things ;)
I seem to remember someone earlier recommending the Blackdown blackdown implementation which is how I came to go there. I just thought I would see if there was a free implementation that works.
Neill, as someone who is a Java expert talking to be who is very definitely looking in at it from the outside, perhaps you could comment on what it's advantages are.
From what I can see it seems to be a slightly cleaner OO
language that C++ and pitched at a slightly higher level but not much which aims for platform indepenance via two mechanisms:
yes, Bill Joy (the main guy who wrote Java, or oak as it was origionally called) didn't like the way in which OO was bolted on to C to form part of C++. I believe he also took on board the concept of garbage collection, memory management, and a clean OO design from smalltalk and other languages.
- Compiling into code to run on a virtual machine rather than any real ones.
yep, the java source gets compiled into bytecode which will run on a virtual machine (VM), each VM is then ported to the desired platform... Mind you, over the years I have found several "platform specific" bugs that are really annoying. I would be very carefull about saying that my code is 100% platform independant unless it has been tested and verified by sun ;)
- Including much more useful functionality in the standard library (such as a GUI toolkit) which means that many more things are done in a standard way.
well yes to an extent, a lot of the standard libraries for C/C++ provide similar functionality to Java (in terms of networking, diskI/O, string manipulation), and Java has a few nice ones like AWT/Swing...
From a programmer perspective, having an extensive standard
library must lift one of the main barriers to writing portable code, though there are other approaches to this, i.e. porting GUI toolkits from one platform to another so that code that uses the toolkit will be portable.
That is certainly why I like it. There used to be a time when I knew most of the API off by heart (back in 1.0.2 days). Nowadays I struggle to know aprox half of the 1.4 API. I would not entirely agree that the Java API is as extensive as C/C++ or other languages. There are some things that are very very dificult to achieve using Java, and what seems like a simple task in one language /can/ be very dificult in Java if it is not part of the API.
The code generation for a virtual machine would obviously appeal to the writers of comercial software because it means they can distribute just one version of the software without having to give away the source code. What I don't see is how this is an advantage to free and open source software where the problem of distributing platform neutral code is usually solved by distributing the source.
I suppose the correct answer to that question is that from a free software point of view, if the software is distributed freely, then there is no benefit to using Java. BUT, in terms of distributing source it cuts down the time involved in porting the software. My C++ GUI programs will not run on any other platform than they were written for, and porting will consume a large amount of time. By writing a program in Java it stands a better chance of working on a platform which supports a compliant JVM. This is a similar analogy to Linux, is runs on powerPC to S390's, and a piece of code written for "redhat 7.1" will work on the sparc or i386 as the same libraries are used on both these. I guess it is just a different level of abstraction..
I have not played with GJC yet so I can't commenet on that.
For me, the interesting thing about GCJ is the claim to be able to translate the java VM code into native code ahead of time and save the result (as an ordinary executable) rather than do it each time the program is run. I am not sure how much difference this would make but it does seem to me that there is a noticable speed penalty associated with Java and this may be a way to remove it.
This is the similar run time compilation technique that is used with Jikes, it loads up the bytecode, converts to machine code, then executes it. In my experience, the speed penalty is usually involved in loading the associated class libraries for the JVM, rather that the bytecode translation (which is effectively a lookup table!)... I have read various article, reports and experiments which say that Java /can/ be almost as fast as native code, while other say the Java bytecode translation is a lot slower that native code. I think it depends greatly on the application, and, to a lesser extend on how well the code has been written (I can write very slow C ;) A friend does real time image processing, which involves a large number of calculations a second. In this case Java is too slow for what he needs to do. Another writes Java GUI's that control native code. As long as the GUI is quick enough to respond to the user there is no problem.
I think it is very early days for GCJ though, so perhaps we need to wait a bit before it is fully usuable.
yes, when it is stable I may switch to it...
One Java compiler/runtime I may suggest looking at is Jikes (from IBM). I used it a few years ago and was very impressed. I'm not sure how well it plays with apache/java serverlets though.
I am pretty sure I have a Java run time environment from IBM installed at work in order to run the Oracle client tools (from the Oracle 8i). It seems to do this OK though there is some strangeness in that if one of these tools is run without a controlling terminal a java coredump occurs in one of the X libraries.
<wild stab in the dark> this is strange, I wonder if they are trying to attach the input/output/error streams to the launching console, and have not caught the exceptions. This would be very sloppy code if this is the case. Have you tried the blackdown code with the oracle client tools ??
anyway, enough Java dribble, I'm off to bed... Sz
Steve.
Open Source Specialists http://www.entora.co.uk/ Tel: +44 (0)701 0723686 Fax: +44 (0)870 3214368
C++ is a decent language if you know what you're doing. Think of it as a stallion, compared to Java's compliant mare. Sometimes you need to wrastle, but it always has the power. Oh, and while it will never refuse a jump, it might get both your necks broken when you fu.
AFA GUI toolkits go, Java's isn't all that platform independent. Forget having a consistent look, and the feel is sometimes a bit flexible (it may be possible to get around this by programming a L&F set of classes). Plus I don't really see why GTK couldn't be implemented under Windows; just get a great big drawable and take it from there.
BUT, in terms of distributing source it cuts down the time involved in porting the software. My C++ GUI
Also, compiling from source is a pain in the a**. Just incidentally, there _are_ Java decompilers out there and they do work fairly decently. The guy who taught Java to my year was new to the uni, and he set a rather difficult AWT/events assignment. So we knew what he wanted, he put an applet on the web.
I did code it myself, but it was very tempting to give him his own code to mark.
This is the similar run time compilation technique that is used with Jikes, it loads up the bytecode, converts to machine code, then executes it. In my experience, the speed penalty is usually involved in loading the associated class libraries for the JVM, rather that the bytecode translation (which is effectively a lookup table!)... I have read various article, reports and experiments which say that Java /can/ be almost as fast as native code, while other say the Java bytecode translation is a lot slower that native code.
It vastly depends on the JVM you use. If you benchmark Sun's 1.0 JVM, it is slow as heck. However, with the advent of HotSpot (from Sun) and MMI (from IBM, which is better), the JVM is able to analyse the bytecode and decide which bits are worth compiling to native. This gives performance near equal to C, and (wild unfounded guess) probably much better than any loose-typed or philosophy-designed language like PHP or Scheme.
Startup time for the JVM is a second or less for me, which is significant if you're doing something mad like one JVM per web request, but not if you're writing an application.
A friend does real time image processing, which involves a large number of calculations a second. In this case Java is too slow for what he needs to do. Another writes Java GUI's that control native code. As long as the GUI is quick enough to respond to the user there is no problem.
The issue here is 'fast enough' really. If your program is compute-bound then ultimately you'll be doing assembler. As Sz says, it's the IO that usually matters, and a decent JVM is fast enough for that.
Alexis
-
Alexis Lee -
MJ Ray -
Neill Newman -
Steve Fosdick