Re: java dependency substvars and native compilation

[Florian Weimer]

* Arnaud Vandyck:

> On 5/11/07, Matthew Johnson <[EMAIL PROTECTED]> wrote:
>> On Fri May 11 07:19, Michael Koch wrote:
>> > On Thu, May 10, 2007 at 02:11:27PM +0100, Matthew Johnson wrote:
>> > > OK, so as an alternative, I have a version which reads the Class-Path:
>> > > variable from the jar.
>> > Setting the Class-Path attribute in the manifest only makes sense for
>> > applications. It doesn't makes sense for libraries. The problem is that
>> > the VM only uses the Class-Path attribute when you execute
>> It also makes sense for libraries; Java recursively adds the classpath,
>> so a library which depended on other libraries would have one so that
>> applications don't have to guess what libraries their libraries may use.
>
> This is true if the application is launched with java -jar myapp.jar.

It also happens for JARs which are on the classpath, AFAICT.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Arnaud Vandyck]

On 5/11/07, Michael Koch <[EMAIL PROTECTED]> wrote:
[...]

We could put into the policy that we need to make sure the Class-Path
attribute has a sensible value.


This is a very very good idea! I fully support this.

--
Arnaud Vandyck


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Arnaud Vandyck]

On 5/11/07, Matthew Johnson <[EMAIL PROTECTED]> wrote:

On Fri May 11 07:19, Michael Koch wrote:
> On Thu, May 10, 2007 at 02:11:27PM +0100, Matthew Johnson wrote:
> > OK, so as an alternative, I have a version which reads the Class-Path:
> > variable from the jar.
> Setting the Class-Path attribute in the manifest only makes sense for
> applications. It doesn't makes sense for libraries. The problem is that
> the VM only uses the Class-Path attribute when you execute
It also makes sense for libraries; Java recursively adds the classpath,
so a library which depended on other libraries would have one so that
applications don't have to guess what libraries their libraries may use.


This is true if the application is launched with java -jar myapp.jar.

Any way, setting Class-Path property in the MANIFEST file is a very good idea.

--
Arnaud Vandyck


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Florian Weimer]

* Matthew Johnson:

> It also makes sense for libraries; Java recursively adds the
> classpath, so a library which depended on other libraries would have
> one so that applications don't have to guess what libraries their
> libraries may use.

Looking at the spec, this doesn't seem to be required.  But it makes
sense to do this, and according to my limited experiments, the
reference implementation behaves that way.

Otherwise, we would be in the unlucky position that adding an internal
dependency to a library would break all reverse dependencies of that
library.  Now we only need a replacement for symbol versioning, and
Java has got a real linker. 8-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Michael Koch]

On Fri, May 11, 2007 at 06:09:40PM +0100, Matthew Johnson wrote:
> On Fri May 11 07:19, Michael Koch wrote:
> > On Thu, May 10, 2007 at 02:11:27PM +0100, Matthew Johnson wrote:
> > > OK, so as an alternative, I have a version which reads the Class-Path:
> > > variable from the jar. This is rather more efficient as well. I assume
> > > upstream's build should set this to sensible values and that therefore
> > > the packaging can just include a call to make or ant then dh_javadeps
> > > and doesn't need to list them anywhere.
> > > 
> > > This also solves the problem of 'which jar containing the same class to
> > > use'; there should never be two packages providing the same jar.
> > > 
> > > new version at http://mjj29.matthew.ath.cx/dh_javadeps
> > 
> > Setting the Class-Path attribute in the manifest only makes sense for
> > applications. It doesn't makes sense for libraries. The problem is that
> > the VM only uses the Class-Path attribute when you execute

Ah, thanks. Thats new to me. Good to know.

> It also makes sense for libraries; Java recursively adds the classpath,
> so a library which depended on other libraries would have one so that
> applications don't have to guess what libraries their libraries may use.
> 
> > We could put into the policy that we need to make sure the Class-Path
> > attribute has a sensible value. I havent thought about this deeply yet.
> 
> I think this is a very sensible thing to have in policy.

Definitely.


Cheers,
Michael
-- 
 .''`.  | Michael Koch <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Matthew Johnson]

On Fri May 11 07:19, Michael Koch wrote:
> On Thu, May 10, 2007 at 02:11:27PM +0100, Matthew Johnson wrote:
> > OK, so as an alternative, I have a version which reads the Class-Path:
> > variable from the jar. This is rather more efficient as well. I assume
> > upstream's build should set this to sensible values and that therefore
> > the packaging can just include a call to make or ant then dh_javadeps
> > and doesn't need to list them anywhere.
> > 
> > This also solves the problem of 'which jar containing the same class to
> > use'; there should never be two packages providing the same jar.
> > 
> > new version at http://mjj29.matthew.ath.cx/dh_javadeps
> 
> Setting the Class-Path attribute in the manifest only makes sense for
> applications. It doesn't makes sense for libraries. The problem is that
> the VM only uses the Class-Path attribute when you execute

It also makes sense for libraries; Java recursively adds the classpath,
so a library which depended on other libraries would have one so that
applications don't have to guess what libraries their libraries may use.

> We could put into the policy that we need to make sure the Class-Path
> attribute has a sensible value. I havent thought about this deeply yet.

I think this is a very sensible thing to have in policy.

Matt

--
Matthew Johnson


signature.asc
Description: Digital signature

Re: java dependency substvars and native compilation

[Michael Koch]

On Thu, May 10, 2007 at 02:11:27PM +0100, Matthew Johnson wrote:
> OK, so as an alternative, I have a version which reads the Class-Path:
> variable from the jar. This is rather more efficient as well. I assume
> upstream's build should set this to sensible values and that therefore
> the packaging can just include a call to make or ant then dh_javadeps
> and doesn't need to list them anywhere.
> 
> This also solves the problem of 'which jar containing the same class to
> use'; there should never be two packages providing the same jar.
> 
> new version at http://mjj29.matthew.ath.cx/dh_javadeps

Setting the Class-Path attribute in the manifest only makes sense for
applications. It doesn't makes sense for libraries. The problem is that
the VM only uses the Class-Path attribute when you execute

  java -jar name.jar

I will be very hard to tell upstreams of libraries to set the Class-Path
attribute correctly.

We could put into the policy that we need to make sure the Class-Path
attribute has a sensible value. I havent thought about this deeply yet.


Cheers,
Michael
-- 
 .''`.  | Michael Koch <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Matthew Johnson]

On Thu May 03 10:02, Florian Weimer wrote:
> * Michael Koch:
> 
> > On Thu, May 03, 2007 at 03:51:11AM +0200, Florian Weimer wrote:
> >> * Matthew Johnson:
> >> 
> >> > 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.
> >> 
> >> I assume that nowadays, you want to set the Classpath: attribute in
> >> JARs, so that you don't have to list all dependencies recursively in
> >> wrapper scripts.  This means that the dependency information is
> >> already needed when building the JAR file.
> >
> > This is no replacement for package dependencies. And its not very
> > optimal.
> 
> What I meant is that you need to determine the dependencies earlier in
> the process, not just when writing the control file.
> 

OK, so as an alternative, I have a version which reads the Class-Path:
variable from the jar. This is rather more efficient as well. I assume
upstream's build should set this to sensible values and that therefore
the packaging can just include a call to make or ant then dh_javadeps
and doesn't need to list them anywhere.

This also solves the problem of 'which jar containing the same class to
use'; there should never be two packages providing the same jar.

new version at http://mjj29.matthew.ath.cx/dh_javadeps

Matt

--
Matthew Johnson


signature.asc
Description: Digital signature

Re: java dependency substvars and native compilation

[Andrew Haley]

Matthew Johnson writes:
 >  Ideally
 > I'd write (not in bash) a real byte-code parser which can find the class
 > references properly.

 $ jcf-dump --print-constants java.lang.Object | grep 'Class name:'
#2: Class name: 1="java/lang/Object"
#8: Class name: 7="java/lang/Throwable"
#18: Class name: 17="java/lang/InterruptedException"
#26: Class name: 25="java/lang/StringBuffer"
#32: Class name: 31="java/lang/Class"
#46: Class name: 45="java/lang/Integer"
#59: Class name: 58="java/lang/CloneNotSupportedException"
#63: Class name: 62="java/lang/NoSuchMethodError"

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 
1TE, UK
Registered in England and Wales No. 3798903


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Andrew Haley]

Paul Cager writes:
 >   * Using the "strings" command seems to me a bit unsafe, in that you
 > could get false positives if there are (normal) strings that end in
 > "class". I'm not sure if that is a real-life concern, or just my
 > over-active imagination.

It's unsafe.  strings prints the printable character sequences that
are at least 4 characters long and are followed by an unprintable
character.  A better plan would be to extract the strings by using
jcf-dump --print-constants.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 
1TE, UK
Registered in England and Wales No. 3798903


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Michael Koch]

On Thu, May 03, 2007 at 08:45:47AM +0100, Paul Cager wrote:
> On Thu, May 3, 2007 12:14 am, Matthew Johnson wrote:
> >
> > It's a tricky one. A debhelper command in debian/rules is exactly where
> > it _ought_ to be.
> 
> I agree; I'm just not sure how feasible it is to make it sufficiently
> robust for all cases.
> 
> On the other hand quite a large proportion of Java packages are
> near-trivial, and could benefit from your idea. Maybe all you need to do
> is rename it as "dh_simplejavadeps" (for example), and let the packager
> decide if it is appropriate. Even with cdbs the maintainer would have to
> explicitly
> specify the use of ${java:Depends}.

I really like the idea. I just wonder how good it will work in the real
world.

> Would you want to attempt to derive "Build-Depends" from "Depends"?

Build-Depends is hard. You need to know them before you build anything.
We should avoid something like debian/control.in for trivial packages.

> > Does dh_shlibs not have similar problems which they've
> > fixed?
> 
> dh_shlibs is a bit different. E.g. the compiled object contains the name
> and version of the *library* it requires.

The version of the library is not always included, but in general the
job of dh_shlibs is much easier.

> > Ideally
> > I'd write (not in bash) a real byte-code parser which can find the class
> > references properly.
> 
> I would recommend "bcel" for this job (assuming you are coding in Java).
> It's nice and easy to use.

I would recommend ASM. Easier to use and even recommended by BCEL
developers for new projects. BCEL is more or less dead ... I mean in
maintenance mode. ASM even includes the dependency recognition as an
example.

We use ASM a lot at work. In my try to write such a tool like your
dh_javadeps I used it too.


Cheers,
Michael
-- 
 .''`.  | Michael Koch <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Paul Cager]

On Thu, May 3, 2007 12:14 am, Matthew Johnson wrote:
>
> It's a tricky one. A debhelper command in debian/rules is exactly where
> it _ought_ to be.

I agree; I'm just not sure how feasible it is to make it sufficiently
robust for all cases.

On the other hand quite a large proportion of Java packages are
near-trivial, and could benefit from your idea. Maybe all you need to do
is rename it as "dh_simplejavadeps" (for example), and let the packager
decide if it is appropriate. Even with cdbs the maintainer would have to
explicitly
specify the use of ${java:Depends}.

Would you want to attempt to derive "Build-Depends" from "Depends"?

> Does dh_shlibs not have similar problems which they've
> fixed?

dh_shlibs is a bit different. E.g. the compiled object contains the name
and version of the *library* it requires.

> No, it matches the whole path to the package (actually uses the internal
> package/class representation, which is convenient for finding them in
> jars)

I'd misunderstood your code. Thanks for the clarification.

> Ideally
> I'd write (not in bash) a real byte-code parser which can find the class
> references properly.

I would recommend "bcel" for this job (assuming you are coding in Java).
It's nice and easy to use.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Florian Weimer]

* Michael Koch:

> On Thu, May 03, 2007 at 03:51:11AM +0200, Florian Weimer wrote:
>> * Matthew Johnson:
>> 
>> > 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.
>> 
>> I assume that nowadays, you want to set the Classpath: attribute in
>> JARs, so that you don't have to list all dependencies recursively in
>> wrapper scripts.  This means that the dependency information is
>> already needed when building the JAR file.
>
> This is no replacement for package dependencies. And its not very
> optimal.

What I meant is that you need to determine the dependencies earlier in
the process, not just when writing the control file.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Michael Koch]

On Thu, May 03, 2007 at 03:51:11AM +0200, Florian Weimer wrote:
> * Matthew Johnson:
> 
> > 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.
> 
> I assume that nowadays, you want to set the Classpath: attribute in
> JARs, so that you don't have to list all dependencies recursively in
> wrapper scripts.  This means that the dependency information is
> already needed when building the JAR file.

This is no replacement for package dependencies. And its not very
optimal.

Been there, done that.


Cheers,
Michael
-- 
 .''`.  | Michael Koch <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Florian Weimer]

* Matthew Johnson:

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

I assume that nowadays, you want to set the Classpath: attribute in
JARs, so that you don't have to list all dependencies recursively in
wrapper scripts.  This means that the dependency information is
already needed when building the JAR file.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Paul Cager]

Matthew Johnson wrote:
> On Wed May 02 16:54, Michael Koch wrote:
>> 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
> 
> Hmm, odd. I've just updated the one at that URL in case I rewrote it and
> the following works for me:
> 
>  mkdir -p debian/test
>  cp /usr/share/java/ant-1.6.jar debian/test
>  touch debian/control
>  dh_javadeps -p test
>  cat debian/test.substvars 
> 
>> 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.
> 
> and you assume the program nicely handles this case? I think anything
> which causes the JVM to throw an exception failing to load a class
> requires a depends. (not that my code above does this, it's a bit of a
> hack and is likely to over-depend)
> 
>> 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.
> 
> Hmm, that feels totally wrong to me. Possibly a --prefer= parameter?
> 
> Matt

Thanks for submitting this idea - you've reawakened my interest in
compiling a "Java Packagers Wishlist"!

I think the idea of writing a program to determine Jar dependencies is a
good one, but I'm not sure it can ever be fully automatic, for the
reasons Michael has given above. As such I don't think it would be
appropriate to make it a debhelper dh_xx command - these are
expected to work flawlessly without the need for any user "tweaking".

But I think your idea would work very well if integrated into "dh_make".
 The expectation of dh_make is that it will make a good "first draft"
which must then be tweaked by the user. (Assuming dh_make is ever
enhanced to recognise Java packages of course).

I've got a couple of queries about your program:

  * It's getting late so I may have misread the regular expressions, but
are you only searching for a matching _class_ name (without the package
part). E.g. org.codehaus.plexus.classworlds.realm.Entry might match
against org.someone.else.Entry? Or have I misunderstood your RE?

  * Using the "strings" command seems to me a bit unsafe, in that you
could get false positives if there are (normal) strings that end in
"class". I'm not sure if that is a real-life concern, or just my
over-active imagination.

At this point I should probably confess that I've written a fairly
similar utility myself. It generates a package cross-reference as an
HTML file, and has its own set of problems - e.g. if more than one Jar
provides a class. I've never got around to finishing it, so it's a bit
rough around the edges.

If you are interested:

Example output for the Maven Jars:
http://www.paulcager.org/debian/Maven-2.0.5.html

Example output for all Jars (warning: about 100KB):
http://www.paulcager.org/debian/AllJars.html

Source Code (you will need libbcel-java to compile / run it):
http://www.paulcager.org/debian/JarDepends.java

Run by:
  cd /usr/share/java
  java -cp /download/dir:/usr/share/java/bcel.jar cager.jars.JarDepends
`find -type f | sort` >/var/www/paul/AllJars.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Matthew Johnson]

On Thu May 03 00:00, Paul Cager wrote:
 
> Thanks for submitting this idea - you've reawakened my interest in
> compiling a "Java Packagers Wishlist"!
> 
> I think the idea of writing a program to determine Jar dependencies is a
> good one, but I'm not sure it can ever be fully automatic, for the
> reasons Michael has given above. As such I don't think it would be
> appropriate to make it a debhelper dh_xx command - these are
> expected to work flawlessly without the need for any user "tweaking".
> 
> But I think your idea would work very well if integrated into "dh_make".
>  The expectation of dh_make is that it will make a good "first draft"
> which must then be tweaked by the user. (Assuming dh_make is ever
> enhanced to recognise Java packages of course).

It's a tricky one. A debhelper command in debian/rules is exactly where
it _ought_ to be. Does dh_shlibs not have similar problems which they've
fixed?

> I've got a couple of queries about your program:
> 
>   * It's getting late so I may have misread the regular expressions, but
> are you only searching for a matching _class_ name (without the package
> part). E.g. org.codehaus.plexus.classworlds.realm.Entry might match
> against org.someone.else.Entry? Or have I misunderstood your RE?

No, it matches the whole path to the package (actually uses the internal
package/class representation, which is convenient for finding them in
jars)

>   * Using the "strings" command seems to me a bit unsafe, in that you
> could get false positives if there are (normal) strings that end in
> "class". I'm not sure if that is a real-life concern, or just my
> over-active imagination.

Not even that, anything that matches identifier//identifier. Ideally
I'd write (not in bash) a real byte-code parser which can find the class
references properly. This was just a first cut to find what the issues
were though.

> At this point I should probably confess that I've written a fairly
> similar utility myself. It generates a package cross-reference as an
> HTML file, and has its own set of problems - e.g. if more than one Jar
> provides a class. I've never got around to finishing it, so it's a bit
> rough around the edges.

cool (-:

The other thing I wondered about was a pkg-config-alike for making it
easier to write wrappers for Java programs. It would generate the
correct classpath for the libraries you use. Something like:

#!/bin/sh --

java -cp `pkg-config --classpath libcvs-java 
libunix-java`:/usr/share/java/myprogram.jar org.me.MyProgram "$@"

Incidentally, is:

   java -cp  -jar  

meant to work?
 


signature.asc
Description: Digital signature

Re: java dependency substvars and native compilation

[Michael Koch]

On Wed, May 02, 2007 at 05:01:27PM +0100, Matthew Johnson wrote:
> On Wed May 02 16:54, Michael Koch wrote:
> > 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
> 
> Hmm, odd. I've just updated the one at that URL in case I rewrote it and
> the following works for me:
> 
>  mkdir -p debian/test
>  cp /usr/share/java/ant-1.6.jar debian/test
>  touch debian/control
>  dh_javadeps -p test
>  cat debian/test.substvars 

Hmmm, I did exactly this. What I guess is that I have a lot of java
packages installed in /usr/share/java and the command lines become too
long for the shell script to handle.

> > 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.
> 
> and you assume the program nicely handles this case? I think anything
> which causes the JVM to throw an exception failing to load a class
> requires a depends. (not that my code above does this, it's a bit of a
> hack and is likely to over-depend)

Yes. The code only throws an exception when its run. And its only run by
0.1% of the users. An entry in README.Debian is enough for such cases.

> > 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.
> 
> Hmm, that feels totally wrong to me. Possibly a --prefer= parameter?

Thats normal business. When introducing a --prefer= switch thats like
hardcoding again. In such cases a helper doesnt really help. It just
causes additional work.


Cheers,
Michael
-- 
 .''`.  | Michael Koch <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Matthew Johnson]

On Wed May 02 16:54, Michael Koch wrote:
> 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

Hmm, odd. I've just updated the one at that URL in case I rewrote it and
the following works for me:

 mkdir -p debian/test
 cp /usr/share/java/ant-1.6.jar debian/test
 touch debian/control
 dh_javadeps -p test
 cat debian/test.substvars 

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

and you assume the program nicely handles this case? I think anything
which causes the JVM to throw an exception failing to load a class
requires a depends. (not that my code above does this, it's a bit of a
hack and is likely to over-depend)

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

Hmm, that feels totally wrong to me. Possibly a --prefer= parameter?

Matt

--
Matthew Johnson


signature.asc
Description: Digital signature

Re: java dependency substvars and native compilation

[Michael Koch]

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 <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java dependency substvars and native compilation

[Matthew Johnson]

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


signature.asc
Description: Digital signature

Re: java dependency substvars and native compilation

[Michael Koch]

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.

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

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


Cheers,
Michael
-- 
 .''`.  | Michael Koch <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

java dependency substvars and native compilation

[Matthew Johnson]

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.

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?

Matt


signature.asc
Description: Digital signature