[Sablevm-developer] Re: while building ant... and some other stuff

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 17:55, Etienne M. Gagnon pisze:=20
> On Sun, Aug 11, 2002 at 02:17:40PM +0200, Grzegorz Prokopski wrote:
> > Hello!
> >=20
> > My first mail, sent to sablevm-developer list (after I subscribed)
> > still hasn't reached my mailbox. So I am Cc:ing Etienne.
> Usually, posting is restricted to official SableVM developers, by I
> have now added you to the white list.
Thanks.

> > It is very nice that /usr/bin/sablevm is designed to be replacement
> > of /usr/bin/java.
> I don't see what you mean...  java supports a different set of
> command-line options.  In particular, sablevm uses '--' for long
> options and '-' short options are one letter long.
Hmm... I was looking at manual page for kaffe's 'java' and sablevm
--help. Yes there are differencies. Don't you think it would be good
to have sablevm understanding standard 'java' options?

If not - I'll probably try to create some kind of shell wrapper.
Having (Sun's?) 'java' compatible command is very important for wide
acceptance.

> > It is also very nice that it doesn't need to be given classpath path
> > on the commandline,
> You mean a "bootstrap-classpath", which is a different beast from a
> "classpath".  Yes, this can get confusing, but it is so much nicer for
> users when both are managed separately!
Exactly.

> Now, SableVM supports a single path on its bootstrap-classpath.  It is
> a pain to do fancy things there, as it has to be coded in C, and
> eveyone knows that string manipulation (and related memory management)
> is tedions in C.
OK, I changed it to have no $VERSION part for now, but it's probably not
final solution here. I'll find a way so that I didn't need to manually
write new version number to the scripts every time I update the source.
Else it would be errorprone.

> Why is this important?  Because through the invocation interface,
> libsablevm.so could be used as a scripting engine (or embedded VM) by
> another application.  Imagine that the Mozilla project decided to
> eventually use SableVM.  They would not be interested in the
> /usr/bin/sablevm executable, but they would link with libsablevm.so.
> If I was to release a binary incompatible new libsablevm.so, it could
> break mozilla, but it won't because SableVM uses libtool versioning to
> avoid such problems.  But, libsablevm.so internally depends on a
> specific set of sablevm/java*.so files (dependencies which are NOT
> visible through ldd) and on classes-VERSION.  So, we must take care of
> this too.
I like you're looking so far into the future.

> Consequences of this for Debian:
> 1- You should probably break SableVM into 2 packages: sablevm and
> libsablevm.
Ah yes - I was about to ask about it. OK.

> 2- The sablevm package will be pretty small.  It should mainly include
> /usr/bin/sablevm.
Uhm... and probably some JAVA_HOME related stuff.

> 3- The libsablevm should include all of:
> /usr/lib/libsablevm.[so,la,...], the /usr/lib/sablevm directory
> content and all subdirectories.
Right

> 4- You will have to document clearly the fact that different component
> of the libsablevm Debian package are under distinct copyright/license
> terms.
I thought everything in sablevm source is LGPL?
And 'the rest' - classlib and nativelib are GPL+exception?
No?

> 5- Instead of 4, you could instead make a sablevm-library package, or
> even sablevm-class-library and sablevm-native-library packages, as I
> have done, and add a dependency of libsablevm on them.  Just make sure
I have done it like this. 3 packages. It makes sense, because nativelib
must be compiled separeately for every architecture (just like sablevm)
while -classlib is arch-indep.

> that distinct versions could eventually be installed on the same
> system, in case some other application decides to link directly
> against libsablevm.so. (Maybe libsablevm-class/native-library is a
> more appropriate name for Debian? I'm not sure; I haven't read all of
> the Debian policy manual yet...;-)
I think that we'll have:

from sablevm source:
* sablevm (/usr/bin/sablevm, JAVA_HOME and other helper stuff)
* libsablevm[012...] - with libs of sablevm=20
* libsablevm[012...]-dev - with *.h headers (I know they're small,
but else they also tend to conflict with other packages like libgcj)

from sablevm-nativelib source:
* libsablevm-native[012...] - arch. dependant stuff extracted from
   classpath; we don't have any -dev here

from sablevm-classpath source:
* libsablevm-classpath[012...]-java - according to java policy - java
   libs should have lib prefix and -java suffix

I must say there's NO JVM in Debian that has it's components divided
into different packages as above. usually it is like for ORP - two
packages: orp and orp-classpath
But that doesn't mean they're right with what they do!
I belive our way can be cleaner.

For normal user apt-get install sablevm will be sufficient anyway.

> > java/lang/UnsatisfiedLinkError
> > ... Failed Building Ant Distribution !
> I have looked at Ant.  It seems to require some reflection primitives
> that are not all yet implemented.  Using the precompiled ant.jar on
> unstable with the CVS version of SableVM (which has a little less
> holes in reflection support than 1.0.1), I get:
Right - when I was trying some pre 1.0.7 version (3 months old now) -
I was getting some "reflecion" errors. Probably they had problems
with it too. But now they have the reflecion code fixed.

FWIW: I talked with kaffe authors for long and Dalibor Topic
<ro...@ya...> caimed he was digging into that code.
We had a talk about licensing and he said he would happily relicense
any piece of kaffe he owns copyright to under GPL+exception (outside
of kaffe). I belive that it would be possible to ask him for
relicensing it under LGPL.

I must admit don't really know what reflections are - if that
thing closely related to particluar JVM - then it can be hard.
But if that's a bit largish work and not very JVM specific -
I could ask him what he would think about eventuall relicensing
his reflecion code under LGPL.

Does it makes any sense?

> Method.invokeNative (which should show as Method.invoke in your
> version) is a little painful to code.  The equivalent
> java.lang.reflect.Construction.newInstance() is already implemented,
> but Method.invoke has this painful return value wrapping to do... Let
> me see what I can do.
OK

> Rant: Why does it require all this reflection stuff?  Reflection is
> inherently slow in Java!  Programmers shouldn't be messing with it,
> unless it is absolutely critical.
*g*

> > It works with kaffe and blackdown 1.3 java.
> > Any hints are welcome. On my side - I was told that the latest jikes,
> > which is currently in unstable (I use unstable, so I used this version
> > of compiler too) - has some serious problems. I'll try to recompile
> > sablevm-classpath with previous version and if that changes anything
> It is also written in SableVM's README file.  Please read it again!
> Unstable's Jikes-1.16 is broken.  Jikes official repository contains
> some patches that haven't made it to Debian yet, but if I was you, I
> would stick to testing's 1.15.  You could discuss the problem with
> Jikes' maintainer, but first, read his opinion in bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D148169&repeatmerged=3D=
yes
I already reverted as I said in my previous mail.

> > PSS: Is this really needed to show all that long information about
> > SableVM and all stuff about it when the only important part is
> > one-liner message about error?
> > IMVHO a kind of 2-4 liner information would be more in place here.
> Maybe you should try "sablevm --help" and learn about the "-Y" option.
Shouldn't -Y work otherwise? _enabling_ the copyright not disabling it?
 ;-) I'll think if not change it  when I have nothing else to do ;-))

> > PST: It would be nice to have a kind of JAVA_HOME environment.
> > Is there some documentation about what should be there?
> > (I can _look_ at what kaffe/blackdown put there of course) -
> > what do you think of JAVA_HOME? How should it be set for SableVM?
> How does that JAVA_HOME work?  I sincerely don't know.
<disclaimer>
I don't claim I know Java. I started packaging java programs _because_
I didn't to it before (I know Java theorethically ;-)
However I can speak from my (not so wide and not surerly right)
expirience.
</disclaimer>
I am looking at /usr/lib/j2sdk1.3 from blackdown java now.

It seems that it's kind of real home for java engine (you didn't expect
it - did you ;-). It seem the most normalized dirs there are:
include - *.h files (jawt.h, jni.h, jvmdi.h, jvmpi.h) - unimportant for
           us IMO
lib - contains all the jars that sdk carries - not really important IMHO
bin - that's the main point

in bin there is a lot of different wrappers - about 25!
I don't even know what most of them do (would need to take look at
manuals, but that's unimportant now).

I think we would need mainly:
*java (wrapper to /usr/bin/sablevm that understands 'java' parameters
  or symlink to /usr/bin/sablevm if sablevm could understand the
  options directly - which would not be stupid)
*jar - we could just symlink to /usr/bin/fastjar and depend on fastjar
  or even better - symlink to /usr/bin/jar which is handled by
  alternatives mechanism (recommends fastjar)
*javac - just like above (recommends jikes)
*javadoc - trivial wrapper script copied (rewrote with looking at) from
  kaffe

> Also, SableVM is structured as a typical *NIX application, unlike the
> jdk.  So, libsablevm.so goes into /usr/lib, some files go in
> /usr/share/sablevm, etc.  So, where would that JAVA_HOME point?  I
> have no intention whatsoever to make sablevm read any environment
> variable; this is a painful mess for users, specially if you install
> more than one sablevm version on your system.  Think of those who use
> the build-many script, and get 6 distinct versions.  What would the
> appropriate JAVA_HOME be?
I think /usr/lib/sablevm with bin directory would be sufficient, OR
we could recomment using JAVA_HOME=3D/usr but providing java and javadoc
wrappers that can be used by alternatives mechanism (yeah, I'd recommend
that one).

We NEED java wrapper if we want sablevm to be used more widely, because
every java program uses just 'java' invocation (with parameters) to
start. It would be stupid to expect any program that wants to work
with sablevm to change it's wrapper script.

So if we want to Provide: not only java-virtual-machine but also
java-runtime-environment - we need to be able to be called by
standard 'java' invocation.

> Instead of reading environment variables, SableVM supports traditional
> configuration files.  So, you can create a ...etc/sablevm file and/or
> a $HOME/.sablevm file, and write into it things like:
>=20
> classpath=3Dblah
> no-copyright
> verbose-gc
I belive it was discussed (probably many times) at debian-java but I
didn't find out (reading the archives) that consensus was made. For now
program expect having working 'java' and that's all that matters.
I belive I could quite easily just copy kaffe's 'java' wrapper and
adopt it to sablevm needs (haven't checked it though).

Regards

					Grzegorz B. Prokopski

PS: About javadoc - in that particular case - I don't see any problem
as we don't need to link javadoc classes with anything external. We just
USE javadoc 'program' to create some output. So _even_ if it stayed pure
GPL forever - we don't really want to remove this stuff.
Maybe that the whole point and the authors knew it?