On 07/06/2009 06:03 PM, John Rose wrote:
> On Jul 6, 2009, at 11:49 AM, Per Bothner wrote:
>
>> It's really embarassing
>> in this day and age that we're still using such a lame classfile
>> format.
>
> Java's not perfect, but anything that supports such an impressive
> ecosystem isn't exactly lame either.
Java is not perfect, but parts of it are lame (including parts
I've worked on) - given its size, that's inevitable. The
extensibility of the class file format has worked out very well.
But its size limitations and inefficiencies are unfortunate, and
it should have been updated or replaced a long time ago.
> For small integers serialized into the class format, I suggest using
> Pack's UNSIGNED5 format, which scales cleanly from 1 to 5 bytes, is
> monotonic and continuous throughout the 32-bit range, and has
> efficient (bit-twiddling) encoders and decoders.
That seems a good idea. I'll follow up more in a separate message.
> BTW, the HotSpot JVM
> uses this internally for serialized data, so there are already
> encoders and decoders written for it in both C++ and Java.
Does that mean HotSpot can directly execute Pack200 files?
Or could be made to do so without excessive work?
If so, would using Pack200 more-or-less-directly as a
classfile replacement be worth considering? I assume not:
Pack200 is complicated to both produce and decode, and the
Java api is oriented towards batch conversion to/from a
jar file.
--
--Per Bothner
[email protected] http://per.bothner.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
