JDK-6464451 : javac in 5.0ux can not compile try-catch block which has a lot of "return"
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-08-28
  • Updated: 2017-05-19
  • Resolved: 2011-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7
5.0u14Fixed 6u4Fixed 7 b08Fixed
Related Reports
Relates :  
JDK-6491544 - Compiling try-finally within code size limit
Relates :  
JDK-6276307 - javac consumes too much memory generating stackmap in extreme cases
Description
javac in 5.0ux can not compile try-catch block having a lot of "return".

REPRODUCE :
 1) Try to compile the attached .java program.
    You will see the following message.

    Note: the messages in () originally appears in Japanese.

K:\javac-ompiler>javac *.java
TEST_FINALLY10B.java:2006: (too big code in try statement)
      } catch(Exception e) { e.printStackTrace();
        ^
TEST_FINALLY10B.java:5: (too big code in try statement)
      try {
          ^
TEST_FINALLY10B.java:4: (too big code in )
   static public int func(int i) {
                     ^
(3 errors)


NOTE: 
  This problem does not occur in 1.4.2_XX javac.
Comments
EVALUATION We will go back to jsr/ret to compile try-finally when code size is too big for subroutine inlining. This workaround will be implemented in 5.0 and 6.0 updates. We are also working on a long term solution without using jsr/ret. It is targeted JDK 7 and 6.0ux. Please see RFE 6491554.
09-11-2006
EVALUATION We are investigating new ideas that may allow us to work around the code attribute limits.
28-09-2006
EVALUATION The compiler tries to avoid using the jsr instructions and the result is that some degenerate cases will fail to compile. Bug 4640034 describes the motivation for this change in behavior. Since then, the class file format has been improved with a new (faster) verification scheme. This new scheme does not support the jsr instruction at all and it will not be possible to avoid the inlining when generated class files of version 50 or above.
29-08-2006