Classes of the future

[Wieland, Jacob]

Hello folks,

is there any plan to get rid of the ridiculously low restrictions on the current class-file-format that seem to be a remnant of another (low-memory) age?

The barriers that I continually run into (when generating Java source code) are:
- only 64KB bytecode per method (with no really good way of estimation how much source code produces how much bytecode),
=> especially annoying as the anonymous constructor is also a method and all initializations of final fields need to be part of either the anonymous or a non-anonymous constructor (which cannot be split into several methods, unfortunately). This leads to having to declare the fields as non-final so that the initializing code can be split into normal methods.
- only 64K class members (leading to unnatural refraction of classes into sub-classes)
- only 64K constants (which is especially annoying when using lots of inner classes as ever inner class consumes at least one constant (I think it is actually 2), so the number of inner classes is implicitly restricted by that (leading to lots of anonymous runnables to wrap the code using the constants)

Of course, for every such barrier, I have found workaround solutions, but these both make the code much less readable and often a lot less efficient, and of course, much longer which again is a drain on resources both on memory, storing and compiler-capacity.

The other way to go would be to redesign the source-code-to-byte-code mapping so that the generated byte-code always respects the barriers (i.e. implementing the workarounds I now have to do in the source code automatically in the byte-code), but that is probably a much heftier feat than "simply" raising these rather low barriers to a more comfortable height (i.e. 4 bytes instead of 2 should suffice for most cases).

BR, Jacob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160210/2db50ca3/attachment-0001.html>