Re: java dependency substvars and native compilation
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
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
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
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
* 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
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]
