Re: java bytecode / java runtime version mismatch

2008-11-10 Thread Matthew Johnson
On Mon Nov 10 10:51, Michael Tautschnig wrote: On Mon, Nov 10, 2008 at 3:46 AM, Matthew Johnson [EMAIL PROTECTED] wrote: snip That version uses javap -verbose, which is rather slow, other suggestions welcome. It uses the following table: highest version in the package = depends

Re: java bytecode / java runtime version mismatch

2008-11-10 Thread Michael Tautschnig
On Mon, Nov 10, 2008 at 3:46 AM, Matthew Johnson [EMAIL PROTECTED] wrote: snip That version uses javap -verbose, which is rather slow, other suggestions welcome. It uses the following table: highest version in the package = depends line 50 = java-runtime6 49 = java-runtime6 |

Re: java bytecode / java runtime version mismatch

2008-11-10 Thread Matthew Johnson
On Mon Nov 10 10:36, Matthew Johnson wrote: This is really nice except that you have got the dependency names wrong. They should be java6-runtime, java5-runtime, java2-runtime etc. Oh, whoops, good catch, I'll rev the version in experimental tonight with this names correct in

Re: java bytecode / java runtime version mismatch

2008-11-09 Thread Matthew Johnson
On Tue Oct 28 09:25, Matthias Klose wrote: I filed bug reports for packages building with openjdk-6 or cacao-oj6, producing java bytecode for version 50, and which still depend on java-runtime5, or earlier (attached at the end). (minor thread hijacking) I've just uploaded a version of

Re: java bytecode / java runtime version mismatch

2008-11-09 Thread Onkar Shinde
On Mon, Nov 10, 2008 at 3:46 AM, Matthew Johnson [EMAIL PROTECTED] wrote: snip That version uses javap -verbose, which is rather slow, other suggestions welcome. It uses the following table: highest version in the package = depends line 50 = java-runtime6 49 = java-runtime6 | java-runtime5

re: libgdata-java: java bytecode / java runtime version mismatch

2008-10-31 Thread Eric Lavarde - Debian
Hi, peter green said: It is preferred to build the bytecode so that it runs on older jvms. This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks setting ANT_OPTS to -Dant.build.javac.source=1.[45]. are you sure, the javac manpage only states that option affects the version the

re: libgdata-java: java bytecode / java runtime version mismatch

2008-10-30 Thread peter green
It is preferred to build the bytecode so that it runs on older jvms. This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks setting ANT_OPTS to -Dant.build.javac.source=1.[45]. are you sure, the javac manpage only states that option affects the version the source is assumed to

java bytecode / java runtime version mismatch

2008-10-28 Thread Matthias Klose
I filed bug reports for packages building with openjdk-6 or cacao-oj6, producing java bytecode for version 50, and which still depend on java-runtime5, or earlier (attached at the end). For lenny+1, when using openjdk/cacao as the default, there will be a lot more of these mismatches (I fixed

Re: java bytecode / java runtime version mismatch

2008-10-28 Thread Mark Wielaard
Hi Matthias, On Tue, 2008-10-28 at 09:25 +0100, Matthias Klose wrote: I filed bug reports for packages building with openjdk-6 or cacao-oj6, producing java bytecode for version 50, and which still depend on java-runtime5, or earlier (attached at the end). This package builds with

Re: java bytecode / java runtime version mismatch

2008-10-28 Thread Matthias Klose
Mark Wielaard writes: Hi Matthias, On Tue, 2008-10-28 at 09:25 +0100, Matthias Klose wrote: I filed bug reports for packages building with openjdk-6 or cacao-oj6, producing java bytecode for version 50, and which still depend on java-runtime5, or earlier (attached at the end).

Re: java bytecode / java runtime version mismatch

2008-10-28 Thread Mark Wielaard
On Tue, 2008-10-28 at 10:03 +0100, Matthias Klose wrote: Mark Wielaard writes: I thought all (free) runtimes accepted version 50 bytecode these days, even if they say they implement only java-runtime5. Is this a problem in practice? And if so against which runtimes? We might want to just

Re: java bytecode / java runtime version mismatch

2008-10-28 Thread Eric Lavarde - Debian
Hi, I thought, you need to set ant.build.javac.source _and_ ant.build.javac.target to be on the safe side (resp. -target and -source)? Wouldn't it make sense to police this? i.e. to state that all packages should be explicitly compiled with 1.5 source/target unless they use 6's features? Eric

Java Policy [Was: java bytecode / java runtime version mismatch]

2008-10-28 Thread Sylvestre Ledru
Le mardi 28 octobre 2008 à 13:40 +0100, Eric Lavarde - Debian a écrit : Wouldn't it make sense to police this? i.e. to state that all packages should be explicitly compiled with 1.5 source/target unless they use 6's features? It is a good idea. Some information are missing in the current Java

Re: java bytecode / java runtime version mismatch

2008-10-28 Thread Vincent Fourmond
Hello, On Tue, Oct 28, 2008 at 9:25 AM, Matthias Klose [EMAIL PROTECTED] wrote: I filed bug reports for packages building with openjdk-6 or cacao-oj6, producing java bytecode for version 50, and which still depend on java-runtime5, or earlier (attached at the end). Hmmm... Don't you find

Re: Java Policy [Was: java bytecode / java runtime version mismatch]

2008-10-28 Thread Matthew Johnson
On Tue Oct 28 14:19, Sylvestre Ledru wrote: Wouldn't it make sense to police this? i.e. to state that all packages should be explicitly compiled with 1.5 source/target unless they use 6's features? It is a good idea. Some information are missing in the current Java Policy. A few others

Re: Java Policy [Was: java bytecode / java runtime version mismatch]

2008-10-28 Thread Andrew Overholt
* Matthew Johnson [EMAIL PROTECTED] [2008-10-28 11:34]: On Tue Oct 28 11:15, Andrew Overholt wrote: * Matthew Johnson [EMAIL PROTECTED] [2008-10-28 11:15]: I'm also still convinced we need to mandate the use of Class-Path: entries in manifests to avoid transitions in rdeps when you update