Message12282

Thanks for the explanations, Stefan.

> Re binary data in string: I mainly wondered why I had to use base64 at all if strings can carry arbitrary binary data. I think the answer is that while string maybe able to do this (still concerned with javadoc of String's byte[]-constructor: "Constructs a new String by decoding the specified array of bytes using the platform's default charset."), String literals cannot.

That's right. Literal strings in the class file are characters encoded using the JVM's variant of UTF-8. I believe arbitrary 16-bit values could be stored in a String and represented as a constant. You could pack a byte array into a String at almost 2 bytes/character, but with random data you would end up with nearly 3/2 bytes/byte in the UTF-8, compared to 4/3 now, so base64 is good.

> The bytecode is embedded into the classfile as a sequence of string literals (a single literal is too restrictive in its maximal size). This decomposition logic is contained in insert_code_str_to_classfile. This has a quite expressive javadoc.

The length limit applies to the encoded form, not the text, but for base64 these are the same. I've revised the javadoc to clarify this.

Module.compile: I have to re-indent it as we saved an if-statement, but I don't intend to revise the approach, just improve readability to make checking mny work easier. I thought of a nicer structure (same approach) but I'm not sure I can do it without breakage.

At present I'm going for my own, simplified, base64 encoder/decoder that the Java 8 one could replace directly.

> It was meant to be "// so we use Java-serialization..." rather than "reflection".
I wondered about that. Ok, that's corrected.