Date: Thu, 18 Jun 1998 11:22:01 -0700 From: Raimondas Lencevicius Organization: Computer Science Dept., UCSB Subject: JLex Bug: Yylex.class includes methods longer than 65K Hi, I was successfully using JLex in my research project for some time, but now I have a problem. I have to run some code under Java verifier, and it throws an error saying that method in Yylex is longer than 65K. Also, it appears that JDK 1.2Beta3 enforces the verification more strictly, so my program may become unusable. :-((( Here is the warning produced by JDK 1.2Beta3 "javac qbd.lex.java": javac qbd.lex.java qbd.lex.java:2308: This code requires generating a method with more than 64K bytes. Virtual machines may refuse the resulting class file. { -1, -1, -1, -1, -1, -1, -1, -1, ^ 1 warning --------------------------------------------------- Date: Thu, 25 Jun 1998 11:45:37 -0700 From: Raimondas Lencevicius Subject: Re: Fixing JLex Bug: Methods longer than 65K Dear Dr. Appel, I have modified the JLex program in the following way. I have fixed the yy_nxt[][] assignment to take a result of a function that unpacks a string to an integer array. To achieve that, I added "private int [][] unpackFromString(int size1, int size2, String st)" function and coded the yy_nxt[][] values into a string by printing integers into a string and representing sequences of the same integer as "value:length" pairs. This encoding was simpler to implement and, I believe, more compact than encoding of each integer as a character or Unicode escape sequence. If someone wants to apply more sophisticated compression scheme, it's possible to do that. However, the .java file size was reduced 2 times (104K to 52K) with current encoding, which, I think, is reasonable. The .class file size was reduced from 193K to 32K (6 times) for the same grammar. The rewritten JLex compiles and runs under JDK 1.1.5 and JDK 1.2B3. I generated .java file and Yylex.class for my grammar and for the sample grammar available at JLex home page. I have encountered no errors including no 64K limit error. There are a couple of possible negatives of the new version. Some editors and operating systems may not be able to handle the huge one-line generated string. This could be circumvented by cutting the string into more manageable parts while keeping in mind .class constant pool size. Also String unpacking may be slower than a direct array initialization. I have attached the modified version of JLex to this message. My comments are added at the beginning of the file. You are welcome to integrate them into the "release" comments, if you decide to use this version as an official JLex release. Sincerely, Raimondas