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 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?
> 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.
> 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)
> > 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)?
Matt
--
Matthew Johnson
Attachment:
signature.asc
Description: Digital signature