"The code of method mTokens() is exceeding the 65535 bytes limit"
The method is antlr generated, so I struggle to find any workaround. Perhaps I'm missing some magic JVM parameter setting? Aren't 16 bit integers relics of the past century?
aloha.kakuikanu wrote: > "The code of method mTokens() is exceeding the 65535 bytes limit"
> The method is antlr generated, so I struggle to find any workaround. > Perhaps I'm missing some magic JVM parameter setting? Aren't 16 bit > integers relics of the past century?
It's a hard limit in Java, I'm afraid. No way around it (with current versions of Java) because it's a limit of the classfile format itself, rather than a limit of the Java compiler, or of the JVM.
(Actually, the limit in the classfile is rather more complicated than that, and you can, structurally, have more than 64K bytes of bytecode per method, but there are various auxiliary structures in the classfile which do have a 64K limits.)
> "The code of method mTokens() is exceeding the 65535 bytes limit"
> The method is antlr generated, so I struggle to find any workaround. > Perhaps I'm missing some magic JVM parameter setting?
Anything that compiles to class files in a straightforward way will hit this limit, as Chris explained.
There are basically two workarounds: Use a compiler that synthesizes additional classes to work around the limit (I don't know if one exists), or a compiler that does not compile to class files, such as an earlier GCJ version. The latter approach might work if your intention is to get the code running. (Nowadays, GCJ uses class files as well.)
Roedy Green wrote: > On 1 Mar 2007 13:24:13 -0800, "aloha.kakuikanu" > <aloha.kakuik...@yahoo.com> wrote, quoted or indirectly quoted someone >>Perhaps I'm missing some magic JVM parameter setting? Aren't 16 bit >>integers relics of the past century? > Nope. Using 32 bit addressing would double the size of a class file. > It is rare to blow the limit unless you are mechanically generating > code.
If you used an escape or prefix code for larger addresses it wouldn't double the size. I believe that might have been part of the design, but was never (as far as I know) implemented. Yes, it is exactly mechanically generated code that needs this.
(The IBM z/OS system only allows code below the 2GB bar. There has been discussion on the need for this restriction, but again it is only machine generated code that is likely to cause problems.)
