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

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

W li=B6cie z nie, 11-08-2002, godz. 20:25, Etienne M. Gagnon pisze:=20
> 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?
>=20
> 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).
I agree with everything above, but that doesn't really deny that
sablevm _could_ be itself compatible with 'java'!
Kaffe does it the same way - it has /usr/bin/kaffe and
/usr/lib/kaffe/bin/java script
/usr/lib/kaffe is kaffe's JAVA_HOME - oh - here it is (FYI):
greg:/# ls /usr/lib/kaffe/bin/
appletviewer jar javadoc javap kaffeh kopi rmic serialver install-jar
java javakey jdb kjc native2ascii rmiregistry

I took a look at the wrapper - it plays with _many_ env. variables,
but it does NOT touch commandline params - kaffe binary is able
to handle all standard 'java' params itself.
It would be a bit hard to analize '-classpath /some/dir/:/other/one.jar'
- wouldn't it? I'll think of it. I know shell - _maybe_ shift will
be sufficient? we'll see.

Anyway - if we want to have sablevm available to the users as java
using alternatives - we _need_ to provide 'java' compatible
command.

Oh... OK - EOT for now I think. I'll try to write something, but
first I need to cut the packages into pieces.

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

> 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.
OK, you're right - I take it back.
However your name doesn't take 15 lines on the screen? ;-)

> > 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.
We'll see into that.

> > OK, I changed it to have no $VERSION part for now, but it's probably no=
t
> > 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.
OK, ok, we'll suspend a bit now.
I have TODO:
0) read the archive
a) repackaging
b) java wrapper

> > I think that we'll have:
> >=20
> > 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)
> >=20
> > from sablevm-nativelib source:
> > * libsablevm-native[012...] - arch. dependant stuff extracted from
> >    classpath; we don't have any -dev here
> >=20
> > from sablevm-classpath source:
> > * libsablevm-classpath[012...]-java - according to java policy - java
> >    libs should have lib prefix and -java suffix=20
> Yep.  This is good (better than my above stuff; I should have read all of=
 your message first...).
;-) we're good at writing _a lot_ ;-) aren't we? ;-))

> > 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?  :-)
Of course - why not ;-)
You need to know I am good at it
http://people.debian.org/~igenibel/packages.php?gpg_key=3DA4B8FDE9
show that I managed to divide FireBird (InterBase derived&compat) into
13 pieces! ;-)

> 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).
OK, I hope ant maintainer will join our conversation/efforts.
In case you didn't know why I started with ant - it is because _a lot_
of DFSG-free packages depend on it, and ant is still in contrib.
I belive this one with a few other packages from Apache (xml and more
general stuff) - once moved from contrib to main - can allow us to
move _a lot_ of Java programs to main.
Yes - that's another reason I am doing all of this...

> > 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...
OK, ok - it's your right.

> > I think /usr/lib/sablevm with bin directory would be sufficient, OR
> > we could recomment using JAVA_HOME=3D/usr but providing java and javado=
c
> > wrappers that can be used by alternatives mechanism (yeah, I'd recommen=
d
> > that one).
> I am inclined towards the second solution too "JAVA_HOME=3D/usr".
will do, at least for now
JAVA_HOME is not absolutely _necessery_ but simplifies a lot of things.
BUT we have alternatives which do more-less the same!

> > 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)?
Sure. But any DFSG-compat license would do. It is only a wrapper, so
it is not linking to anything really.

> Probably the "java" wrapper would eventually have to convert $CLASSPATH i=
nto
> a --classpath argument (in absence of one, to mimic the behavior of
> the normal "java").
if sablevm doesn't use env. vars (which is the case it seems) - then Yes

> > 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 jus=
t
> > USE javadoc 'program' to create some output. So _even_ if it stayed pur=
e
> > 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.
It may be just oversight.
BTW: do you know if classpathx project(s) are already packaged for
Debian?

I thought about other thing too. Machines of all 11 architectures of
Debian are available to debian developers. To port sablevm to new
architectures you could become debian developer. Just a thought.

Regards

						GBP