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

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 07:48:25PM +0200, Grzegorz Prokopski wrote:
> 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?

On the principle, SableVM is not "TM" Java;-).  Also, I like sablevm
to behave as a typical Debian GNU/Linux app.  Now, my plan was to
effectively provide bassh scripts to emulate java; but I continue to
see a "sablevm" binary executable in /usr/bin.  This would allow, for
example, some people to select another vm as default through Debian's
alternative magic, yet be able to use sablevm explicitly.  It would
also allow some packages to depend directly on sablevm, instead of
"java", if they wish so for some reason (e.g. eventual sablevm
extentions).

Writing such a wrapper that would by default set the -Y option, among
other things, would be fairly easy.

I insist to keep the default -Y behavior as it is now (in the sablevm
executable).  It is a prerogative of the Copyright holder to self
advertize.  It's my only payback for giving away the stuff; please be
indulgent.

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

This should be fairly simple, as long as you are litterate in bash/sh.
Don't forget to turn on the -Y option by default in the script for
maximum compatibility.

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

As soon as I get more time, we could discuss this in depth, and I
would go ahead and make the appropriate changes in the tar.gz
distribution to simplify your life.

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

.../lib/libsablevm.so is LGPLed, whereas lib/sablevm/lib*-VERSION.so are GPL + exception.


So, I see 4 packages:
- sablevm: sablevm, java* wrappers, etc.  [LGPL]
- libsablevm: /usr/lib/libsablevm.so [LGPL]
- sablevm-native-library: /usr/lib/sablevm/*.so [GPL+excp]
- sablevm-class-library: .../classes-VERSION/* [GPL+excp]

with the following dependencies:

sablevm: depends on libsablevm
libsablevm: depends on sablevm-native-library and sablevm-class-library

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

Yep.  This is good (better than my above stuff; I should have read all of your message first...).

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

Why not?  :-)

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

The reflection stuff can be partly done in a platform independent way
using JNI, but not all of it, and such an implementation would be even
slower.  It has normally to be done in the VM itself.  I was planning
to fix the whole thing once my thesis is written, but I can try to get
enough of it working for basic ant operation (at least for a simple
<javac/> task, of possible).

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

See my request for indulgence above, and the solution for the java
script...

> 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
>... 
> I think /usr/lib/sablevm with bin directory would be sufficient, OR
> we could recomment using JAVA_HOME=/usr but providing java and javadoc
> wrappers that can be used by alternatives mechanism (yeah, I'd recommend
> that one).

I am inclined towards the second solution too "JAVA_HOME=/usr".

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

Do you think you can try writing one (and LGPL it)?

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

Probably the "java" wrapper would eventually have to convert $CLASSPATH into
a --classpath argument (in absence of one, to mimic the behavior of
the normal "java").

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

I have already filed a bug report on Classpath.  If this is their
intent, they should move the stuff to the classpathx (or something
similar) GNU project.  The GNU Classpath web page is pretty eloquent
about the GPL + exception.  They even explicitly display its whole
text there.

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