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

Brought to you by: egagnon

sablevm-developer

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

From: Grzegorz P. <ga...@de...> - 2002-08-11 12:16:44

Hello!

My first mail, sent to sablevm-developer list (after I subscribed)
still hasn't reached my mailbox. So I am Cc:ing Etienne.

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.
It is also very nice that it doesn't need to be given classpath path
on the commandline, 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)

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=3D.
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 !


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
- I'll tell you.

Regards

				Grzegorz B. Prokopski

PS: As I am not sure if my subscription works (I have received message
that claims I _am_ subscribed) - please Cc: me.
I don't understand why in sablevm-developer archive at
http://sourceforge.net/mailarchive/forum.php?forum_id=3D4154
newest message is dated 2001-09-24 ?

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.

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?

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

From: Grzegorz P. <ga...@de...> - 2002-08-11 15:27:41

W li=B6cie z nie, 11-08-2002, godz. 14:17, Grzegorz Prokopski pisze:=20
> 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.
I seem to be getting the mail from ml but it takes hours... we'll see...

> So as I said before - I tried to compile ant. the critical part, that
> gives me problems is this:
The new version of jikes I belive - really was causing trobules.
I reverted to older version, recompiled all sablevm-classpath stuff
(and cleaned/polished the packages - they're almost ready)
and I am getting this now:

greg@greg:/opt/media/build/ant-1.5$ /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=3D.
org.apache.tools.ant.Main -emacs jars javadocs

java.lang.ClassNotFoundException: build/classes:src/main::
 /usr/share/java/antlr.jar:/usr/share/java/bsf.jar:/usr/share/java/junit.ja=
r:
 /usr/share/java/log4j.jar:/usr/share/java/oro.jar:/usr/share/java/regexp.j=
ar:
/usr/share/java/xalan2.jar:/usr/share/java/xercesImpl.jar:
/usr/share/java/xml-apis.jar:/usr/lib/sablevm/classes:/usr/lib/tools.jar
	at gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:73)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:259)
	at java.lang.VirtualMachine.main(VirtualMachine.java:79)

[I removed self-advertising stuff]

Which class is missing? java.lang.VirtualMachine ?

I am doing sth wrong - am I?

					Grzegorz B. Prokopski

PS: I will not continue sending such requests for help while compiling
programs with sablevm once I am sure that I have it up and working.
Now I am not, so I am plying this "FYI: error and HINTs please" game.

Re: [Sablevm-developer] while building ant... Success!

From: Grzegorz P. <ga...@de...> - 2002-08-11 16:12:52

W li=B6cie z nie, 11-08-2002, godz. 17:28, Grzegorz Prokopski pisze:=20
> W li=B6cie z nie, 11-08-2002, godz. 14:17, Grzegorz Prokopski pisze:=20
> > So as I said before - I tried to compile ant. the critical part, that
> > gives me problems is this:
> The new version of jikes I belive - really was causing trobules.
> I reverted to older version, recompiled all sablevm-classpath stuff
> (and cleaned/polished the packages - they're almost ready)

So I played a bit with it, cleaned up the packages a little bit more,
and... it worked!

I got ant compiled and ant.jar got created.

Now I got to the stage where 'javadoc' program is being used...
(it didn't worked as you could expect) hmm...
I belive we have com.sun.javadoc in classpath - should we have
some kind of a wrapper in sablevm package?

It seems that kaffe for ex. has 'javadoc' wrapper. It's this:
#! /bin/sh
# Script to run Sun's documenter
prefix=3D/usr
exec_prefix=3D${prefix}
exec ${exec_prefix}/bin/kaffe sun.tools.javadoc.Main ${1+"$@"}

So the packages are working, now I'll be looking forward for ideas
on how to improve them. Currently I mostly think of how to provide
JAVA_HOME environment (I think in /usr/lib/sablevm/), with any needed
wrappers etc. in it. Any thoughts are welcomed.

The packages are available at http://debian.sente.pl/debian
/etc/apt/sources.lists line is this:
deb http://debian.sente.pl ./

apt-get update; apt-get install sablevm
should do the the trick

Best regards

					Grzegorz B. Prokopski

PS: I am Cc:ing ant maintainer.

Re: [Sablevm-developer] while building ant... Success!

From: Etienne M. G. <eti...@uq...> - 2002-08-11 16:36:28

On Sun, Aug 11, 2002 at 06:13:47PM +0200, Grzegorz Prokopski wrote:
> So I played a bit with it, cleaned up the packages a little bit more,
> and... it worked!

Wow!

> I got ant compiled and ant.jar got created.

Amazing.

> Now I got to the stage where 'javadoc' program is being used...
> (it didn't worked as you could expect) hmm...
> I belive we have com.sun.javadoc in classpath - should we have
> some kind of a wrapper in sablevm package?

Isn't this the bit which is missing the "legal" linking exception?  I
was planning to remove that stuf...

> It seems that kaffe for ex. has 'javadoc' wrapper. It's this:
> #! /bin/sh
> # Script to run Sun's documenter
> prefix=/usr
> exec_prefix=${prefix}
> exec ${exec_prefix}/bin/kaffe sun.tools.javadoc.Main ${1+"$@"}

Yes, we could make some utility scripts.  As long as they are LGPL'ed,
I could include them in sablevm-x.y.z.tar.gz.

> So the packages are working, now I'll be looking forward for ideas
> on how to improve them. Currently I mostly think of how to provide
> JAVA_HOME environment (I think in /usr/lib/sablevm/), with any needed
> wrappers etc. in it. Any thoughts are welcomed.

Can you explain to me how this JAVA_HOME works?  What is it useful for?

> The packages are available at http://debian.sente.pl/debian
> /etc/apt/sources.lists line is this:
> deb http://debian.sente.pl ./

Great!!!

> apt-get update; apt-get install sablevm
> should do the the trick

I'm just trying it now.

> 
> Best regards

Thanks a lot!

Etienne

PS: As I said before, actually running ant can get you into trouble,
because of some reflection holes.  I'll try to fix the Method.invoke
one, and I'll keep you informed as soon as it is done.

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

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

From: Etienne M. G. <eti...@uq...> - 2002-08-11 16:00:42

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/

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

From: Grzegorz P. <ga...@de...> - 2002-08-11 17:47:31

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?