Re: java dependency substvars and native compilation
On Wed, May 02, 2007 at 03:15:39PM +0100, Matthew Johnson wrote:
> On Wed May 02 15:57, Michael Koch wrote:
> > On Wed, May 02, 2007 at 01:58:46PM +0100, Matthew Johnson wrote:
> > > Two subjects to this mail. Firstly, I had a go at writing a dh_javadeps
> > > which will search for jar files, find the classes they reference and
> > > find the packages they are in. This can be found at
> > > http://mjj29.matthew.ath.cx/dh_javadeps It updates $package.substvars so
> > > you can use ${java:Depends} in control files.
> >
> > Thats really nice to have. Unfortunately it didnt worked on a pretty
> > simple example for me.
>
> Hmm, could you let me know what the example was (it worked on my pretty
> simple example)
I created debian/test and put ant.jar into it. Then I executed
dh_javadeps -p test
As output I got this:
xargs: unmatched einfache quote; by default quotes are special to xargs
unless you use the -0 option
jar: invalid option -- D
Try `jar --help' for more information.
jar: invalid option -- D
Try `jar --help' for more information.
jar: invalid option -- D
Try `jar --help' for more information.
jar: invalid option -- D
Try `jar --help' for more information.
jar: invalid option -- D
Try `jar --help' for more information.
jar: invalid option -- D
...
> > I tried to this some ago too but there are are some problems that cannot
> > be solved easily. Sometimes you dont want to hardly depend on some lib,
> > you want only to recommend or suggest. That can be easily fixed I think.
>
> If the class is used in your jar, surely it needs to be there at
> runtime? or would some other switching be applied first so that the JVM
> never tries to load the class, even though bits of the code use it?
I think about code paths that are only used when you use certain
features of a program. When the dependency itself has a long list of
depdencies it can make sense to not hardly depend on it when its only
needed/used by 0.1% of the users of a program.
> > The much bigger problem is reflection. Some code uses reflection to load
> > classes. Often the class names are computed at runtime and not visible
> > in some binary.
>
> I'm happy not providing a 100% solution, people can always add extra
> depends. The idea is just to provide the simple cases. Reflection isn't
> that common.
Reflection is more common then you might think.
> > Another problem is that very often different jars
> > provide classes in the same namespace. Which package do you want to put
> > into the dependencies? (javax.servlet comes to my mind)
>
> It searches by class name rather than package name; I would expect only
> one package to provide any given class (as distinct from implementations
> of an interface, which should have different packages). Multiple
> packages shipping the same classes/interfaces I would consider a bug
> (although I've not thought 100% about different versions)
No, thats no bug. E.g. we ship different versions of the servlet
specification in Debian. ASM is another example. We have currently two
major versions in Debian. A third is coming soon. All have similar to
equal class names (with sometimes different APIs). Thats no bug. Thats
common practice in Java-land.
> > > I have also been trying to get dh_nativejava to work with no luck. As
> > > far as I can tell, it does nothing regardless of how I run it. What is
> > > it meant to do?
> >
> > It does only something when foo and foo-gcj packages exist. It compiles
> > the jars in foo to native and puts them into foo-gcj and registers them
> > on installation in the classmap.db.
>
> ah, right, the documentation is unclear. Do you think there would be any
> call for something that compiles the jars to native at install time
> (a-la python-support)?
No. We decided against this becuase bigger jars need a long time to
compile to native. I experienced times of compile one jar to native for
about half an hour on a 1.7 Ghz machine.
It also doesnt make sense on some of our archs in Debian, e.g. arm or
mips/el.
Cheers,
Michael
--
.''`. | Michael Koch <konqueror@gmx.de>
: :' : | Free Java Developer <http://www.classpath.org>
`. `' |
`- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B
Reply to: