Re: GCJ Native Proposal
On Tue, Mar 15, 2005 at 07:30:33PM +0100, David Schmitt wrote:
> On Tuesday 15 March 2005 14:10, Michael Koch wrote:
> > > Hmmm, the idea has its merits. Implementationwise, it'd make more sense
> > > to have $lib-jbi Build-Depend on $lib-java. The $lib-jbi would have to be
> > > a sperate source, but I imagine that cuold be a very small standard
> > > template, which fetches most of it information via grep-dcrtl at
> > > build-time, thus being essentially the same for all -jbi packages out
> > > there. Both can be uploaded at the same time, the buildds can sort it out
> > > for themselves.
> >
> > I think this idea puts more burden on the shoulders of the package
> > maitainers then really needed. The native library and and the according
> > jar has to be always in sync. This means the native library depends on
> > exact same version as the jar. We need to install both always a
> > reasonable large Java aplications always play tricks with the bytecode.
> > E.g. Eclipse loads bytecode from its own jars at runtime and tries to
> > run in. GIJ/GCJ then uses the native code too but the bytecode needs to
> > be there in the same version as GCJ calcs a checksum over the bytecode
> > to find the according native code,
>
> Pardon my ignorance regarding java issues, I'm just a creative mind floating
> some ideas around.
>
> Can all .jars be recompiled into .sos? Then it would even be possible to have
> a bunch-o-scripts hanging on debian-devel-changes and automatically download
> the -java package, create a -jbi from a template and do an upload. The rest
> of work is done by the autobuilders.
>
> The template would look like this:
>
> Source: @parent@-jbi
> Section: @parent-section@
> Priority: @parent-priority@
> Maintainer: @parent-maintainer@
> Uploaders: @parent-uploaders@
> Build-Depends: @parent-binary@ (= @parent-version@), gcj-4.0
> Standards-Version: 3.6.1
>
> Package: @parent@-jbi
> Architecture: any
> Depends: @parent@ (= @parent-version@)
> Description: @parent-description@ (native)
> This is the nativly compiled version.
> .
> @parent-long-description@
>
> Where the @@ parts would have to be extracted from the Arch: all package.
>
> At build-time the installed jar had to be located, compiled and put into the
> package with something like
>
> dpkg -L @parent@ | grep jar$ | while read jar; do
> mkdir -p build/$(dirname $jar)
> gcj $(GCJFLAGS) $jar -o build/$jar.so
> done
> cp -r build/* $(DESTDIR)
>
>
> But probably I have missed something important which can't be automated :(
Thats doable. But most probably not what we want and need currently.
This would mean an exxessive archive bloat. The dependecies of Eclipse
on i386 only will use an additional 300 MB of archive space. We have a
lot java packages in debian that are not a depenedency for Eclipse.
We have move more then one architecture in Debian. Doing stuff blindly
without thinking is really not what we want. The other side is the
improvements we will really gain when we compile jars to native. These
native .sos can currently only be used by GCJ. By no other free or
proprietary VM. And there is still no proof that they gain any small or
big performance boost with gcj. Lets go the "traditional" way for now
and make free java work now in debian and look for improvements later.
Michael
--
Java Trap: http://www.gnu.org/philosophy/java-trap.html
Reply to: