Community
Participate
Working Groups
I got "Code for the static initializer is exceeding the 65535 bytes limit" compile error from an interface containing a String[] of 8297 elements. I don't get the same error when I compile with javac. The interface looks like following: public interface I { String s[] = { "a", "b", . . . }; }
Please provide the whole source in attachment. We need it to reproduce the problem and compare generated code between javac and our compiler.
This could indeed be a scenario where you are getting close to the threshold were we throw the towel and refuse to compile the method as it would be to big. It might be a good idea to consider using a separate file to load this table from, given it will cost you twice in memory: once for the big classfile loaded in memory, and once more for the runtime table data structure. Now this being said, it is still a valid test case for us to check our behavior against other compilers.
Created attachment 1220 [details] test case
JDK1.3.1 and 1.4 don't complain anymore about methods bigger than 65535 bytes. However JDK1.2.2 reports the following warning: D:\temp>javac CoreBagKeyNames.java CoreBagKeyNames.java:10135: This code requires generating a method with more than 64K bytes. Virtual machines may refuse the resulting class file. "VADESUREAY", ^ 1 warning We might want to issue a warning as well and allowed the .class file to be generated. I checked that the JDK1.4 procuded a method with 65565 bytes. Here is the end of the disassembled .class file: 65531 sipush 8296 65534 ldc_w #7842 <String VADESUREAY> 65537 aastore 65538 dup 65539 sipush 8297 65542 ldc_w #7843 <String VADESUREGUN> 65545 aastore 65546 dup 65547 sipush 8298 65550 ldc_w #7844 <String MEKTUPBASIMTARIHI> 65553 aastore 65554 dup 65555 sipush 8299 65558 ldc_w #7845 <String RISKUNSURU> 65561 aastore 65562 putstatic #7846 <Field tr.com.cs.core.bagkeys.CoreBagKeyNames>bagKeyNames java.lang.String[]> 65565 return
Good, we can close this, since it is a bug in javac implementations. They should check it.
Indeed this is clearly spec'd in the VM specs: http://java.sun.com/docs/books/vmspec/html/ClassFile.doc.html#6253 If you replace your code with the second attachment, javac reports: CoreBagKeyNames.java:10142: code too large for try statement } catch(RuntimeException e) { ^ 1 error So they do check it when a try/catch is used. According to the specs, our behavior is ok.
Created attachment 1226 [details] Defining class with a try/catch statement
