Bug#156407: ITP: free-java-sdk -- Complete Java SDK environment consising of free Java tools
Hi,
I have hacked on GNU Classpath (which sablevm uses as its standard class
library) and gjdoc. I am really glad that you took the effort to package
them for Debian. Especially since I am a Debian user :)
Since I have also hacked a little on (lib)gcj (which is now being merged
with GNU Classpath) I think I understand a little what Tom is getting
at.
On Tue, 2002-08-13 at 21:09, Grzegorz Prokopski wrote:
> W liście z wto, 13-08-2002, godz. 20:40, Tom Tromey pisze:
> > I considered discussing Etienne's other points in detail, but I doubt
> > this is the appropriate forum. My only concern is that people not
> > spread misinformation about gcj and gij: gcj is not only about native
> I think you'll be able to ask him directly about where the problems
> exactly are. However i don't think he ever thought about spreading
> misinformation - he surely has proves behind his words.
> [...]
> The point here was to more-less explain why I will give a chance to
> another free tools, not kaffe, not gij (with gcj) - but SableVM.
> It appears (if you belive in what he said) - that there _are_ reasons
> to make such choice.
And I think they are good reasons if you are looking for a traditional
java environment. As a byte code interpreter it is probably very nice
but I couldn't check since it doesn't compile on my powerpc machine. I
will certainly try as soon as possible on my 686 machine, but this is a
major drawback that both Kaffe and gcj/gij don't have, they work
(however flawed they otherwise are) on a lot of different architectures.
The smart thing about gcj is that it was started as a frontend for GCC.
This means that it is mainly an ahead-of-time compiler (but includes a
traditional byte code interpreter gij) that can in theory be used to
produce programs for all backends that GCC supports. This means that you
don't have to write a JIT engine for every platform separately!
It is the byte code interpreter gij that is flawed according to Etienne.
I believe him and I am eager to read his thesis on how to fix the issues
with it. But in practice you mainly use gcj to compile your programs to
native code.
> > code, it intends to be a complete java environment. It already
> Yes, we're aiming at the same goal apparently.
>
> > provides quite a bit toward that goal. Lack of a bytecode interpreter
> > can't be considered as a reason to avoid gcj. (Quality of the
> > interpreter may be, but that is a different sort of discussion.)
> I only hope you're not trying to blame me for not choosing "your"
> solution? ;-))
It is probably the other way around I think you should blame Tom for not
making clear enough why you have to go through all the trouble creating
this assembly of free java tools when GCJ already provides them :)
Seriously, there is value in having these tools in a pure java version
that can be used together with traditional byte code interpreted java
classes. But the gcj team never made it obviously clear that they
already provide these tools (optimized for use in a non-traditional
"java" setting).
If you look at the latest tools that come with the gcj distribution you
will find most of the tools you want in there. But they have been
adapted/improved for use in a GNU java system build around the gcj
compiler:
- The standard class library (based on GNU Classpath): libgcj.jar.
(This also comes as precompiled native shared and static libraries.)
- A java compiler (generates native code or byte code): gcj.
- A traditional byte code interpreter: gij.
- A very fast jar tool: fastjar.
- A classfile inspection and decompilation tool (like javap): jcf-dump.
- A RMI stub generator: rmic.
- A CNI/JNI headers and stubs generator for C/C++ (like javah): gcjh.
(This tool can also do dependency analyzes.)
- A file encoding converter (like native2ascii): jv-convert
- A java source file analyzer: jv-scan.
The rest of the tools are not yet packaged with gcj but they can be
gotten from the GNU Classpath-Tools project and compiled to native code
for your particular platform for fast startup and execution times (which
is how I use them) such as gjdoc.
But gcj was never really marketed as a complete GNU java environment but
more as another GCC frontend that happened to compile programs in the
java language. And I really think you can blame the gcj hackers for not
making their vision more clear. They have a very good vision of how a
java like system can be integrated with the GNU system. It might not be
a traditional java environment but it is clearly a complete and
innovative environment for people that want to hack on a free system
with free java tools (and also easily and efficiently interact with
traditional libraries written in C or C++ through CNI - or JNI).
I really hope that message will be told a bit more.
Note that all of the above does not mean that I want to discourage your
new Debian packages. I really want to see them next to the gcj tools!
Let those gcj hackers prove their tools are better :)
Cheers,
Mark
Reply to: