Bug#661632: javahelper: jh_depends determines incorrect class version on sparc

[Niels Thykier]

On 2012-02-28 19:08, Kai Ruschenburg wrote:
> Package: javahelper
> Version: 0.32
> Severity: normal
> Tags: patch
> 
> Hi,
> 

Hi,

Thanks for the report.

> when packaging Java programs on sparc (using the sources fetched by apt-get
> source), on some programs (e.g. sat4j) this warning is printed:
> 
> $ debuild
> [...]
> jh_depends -i
> Warning: Class version too new to recognise (88), might not run with any JVMs
> [...]
> 
> This is caused by hd in the function getclassversion() in jh_depends.
> 
> The output of hd seems to depend on the endianness of the architecture.
> Therefore probably not only sparc, but all big-endian architectures are
> affected.
> 
> Changing line 37 from
> new=`hd -s 7 -n 1 -d "$i" | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'`
> to
> new=`hexdump -s 6 -n 2 -e '/1 "%u "' -e '/2 " r 256 * + p"' "$i" | dc`
> should fix this.
> 

To be honest, I do not see why the "old" code should fail.  The
specification says that bytes "6 and 7" are read as an unsigned short in
big-endian.
  Sure, our code fails if the class version suddenly jumps above 255
(because we only read the last byte).  However, we are at 51 with Java7
so I do not see that coming anytime soon.

Can you give me a hexdump of the 16 characters of the class file?

> Some examples:
> 
> $ [...]
> 
> Best regards
> 
> Kai
> 
> 
> [...]

~Niels