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