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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On Sun, Aug 11, 2002 at 02:17:40PM +0200, Grzegorz Prokopski wrote:
> Hello!
> 
> 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.

> So I have got early packages, they're:
> sablevm
> sablevm-nativelib
> sablevm-classlib
> 
> 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.

> 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!

> however I'd like it to search not only for
> /usr/lib/sablevm/classes-$VERSION, but at least for
> /usr/lib/sablevm/classes if the above is not found.
> (it will be a symlink to /usr/share/sablevm/classes anyway, but that's
> another story)

Hmmm... I have explicitely make it look into
/usr/lib/sablevm/classes-$VERSION so that you could install 2 distinct
versions of libsablevm.so on the same system.  The .so numbering avoid
name clashes for both libsablevm and sablevm/libjava-*-VERSION.so, but
it won't work with /usr/lib/sablevm/classes.

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.

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.

Consequences of this for Debian:

1- You should probably break SableVM into 2 packages: sablevm and
libsablevm.

2- The sablevm package will be pretty small.  It should mainly include
/usr/bin/sablevm.

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

4- You will have to document clearly the fact that different component
of the libsablevm Debian package are under distinct copyright/license
terms.

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
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...;-)

> 
> So as I said before - I tried to compile ant. the critical part, that
> gives me problems is this:
> 
> /bin/sh bootstrap.sh
> ... Bootstrapping Ant Distribution
> ... Compiling Ant Classes
> ... Copying Required Files
> ... Building Ant Distribution
> /usr/bin/java -classpath
> build/classes:src/main::/usr/share/java/antlr.jar:/usr/share/java/bsf.jar:
> /usr/share/java/junit.jar:/usr/share/java/log4j.jar:/usr/share/java/oro.jar:
> /usr/share/java/regexp.jar:/usr/share/java/xalan2.jar:
> /usr/share/java/xercesImpl.jar:/usr/share/java/xml-apis.jar:
> /usr/lib/sablevm/classes:/usr/lib/tools.jar -Dant.home=.
> org.apache.tools.ant.Main -emacs jars javadocs
> 
> SableVM version 1.0.1
> Copyright (C) 2000-2002 Etienne M. Gagnon <eti...@uq...> and
> others.  All rights reserved.
> 
> This software comes with ABSOLUTELY NO WARRANTY.  This is free
> software, and you are welcome to redistribute it under certain
> conditions.
> 
> To get the name of all copyright holders and detailed license
> information, type "sablevm --license" or look in the directory
> "/usr/share/sablevm".
> 
> The SableVM web site is located at http://www.sablevm.org/ .
> 
> 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:

$sablevm -Yc /usr/share/java/ant.jar org.apache.tools.ant.Main
Buildfile: build.xml
*** Couldn't bind native method Java_java_lang_reflect_Method_invokeNative ***
*** or Java_java_lang_reflect_Method_invokeNative___3B_3C_3Ljava_lang_Object_2 ***
*** Couldn't bind native method Java_java_lang_Class_isInstance ***
*** or Java_java_lang_Class_isInstance__Ljava_lang_Object_2 ***
java.lang.UnsatisfiedLinkError
        at java.lang.Class.isInstance(Class.java)
        at java.text.MessageFormat.format(MessageFormat.java:357)
        at java.text.MessageFormat.format(MessageFormat.java:379)
        at java.text.MessageFormat.format(MessageFormat.java:401)
        at java.text.Format.format(Format.java:82)
        at org.apache.tools.ant.util.DateUtils.formatElapsedTime(DateUtils.java:165)
        at org.apache.tools.ant.DefaultLogger.formatTime(DefaultLogger.java:308)
        at org.apache.tools.ant.DefaultLogger.buildFinished(DefaultLogger.java:192)
        at org.apache.tools.ant.Project.fireBuildFinished(Project.java:1871)
        at org.apache.tools.ant.Main.runBuild(Main.java:629)
        at org.apache.tools.ant.Main.start(Main.java:196)
        at org.apache.tools.ant.Main.main(Main.java:235)
        at java.lang.VirtualMachine.invokeMain(VirtualMachine.java)
        at java.lang.VirtualMachine.main(VirtualMachine.java:88)

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.

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.

> 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=148169&repeatmerged=yes
.

> 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.

> 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.

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?

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:

classpath=blah
no-copyright
verbose-gc

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/