broken by design?

DUMP FILE: /home/saces/temp/small.tar
DUMP ENTRY:
Name: small/
Begin PAX item
PAX len: 0 (1) '3'
PAX len: 3 (2) '4'
PAX len: 34 (3) ' '
PAX len2: 34 (4) p
PAX len2: 34 (5) a
PAX len2: 34 (6) t
PAX len2: 34 (7) h
PAX len2: 34 (8) =
PAX keyword: path
PAX len3: 34 (8) =
PAX value: 'path=small/ÜTF-8-breäker.txt
2'
Begin PAX item
PAX len: 0 (1) ' '
PAX len2: 0 (2) c
PAX len2: 0 (3) t
PAX len2: 0 (4) i
PAX len2: 0 (5) m
PAX len2: 0 (6) e
PAX len2: 0 (7) =
PAX keyword: ctime
PAX len3: 0 (7) =
Exception in thread "main" java.lang.NegativeArraySizeException
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.paxHeaders(TarArchiveInputStream.java:257)
	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:227)
	at test.Test.main(Test.java:24)

note to self: http://svn.apache.org/repos/asf/commons/proper/compress/trunk@978842

I had upgraded to Commons Compress 1.1 but I now have to implement backwards compatibility support for 1.0 so I'm trying to simulate the behaviour which would have occurred before they added PAX support. In doing so I read their paxHeaders() method and wondered if the length value really was the length in UTF-8 characters... Turns out it isn't, it's the length in bytes. I bet that's what's going on here.

exactly.
see the patch: saces/foe@a47b113#FreenetCompress