19

I just compiled the following code

public class A {
    public static void main(String... args) {
        int i = 3;
        ++i; 
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        // repeat writing the expression ++i for 20,000 times

        System.out.println(i);
    }
}

And got the following error message

The code of method main(String...) is exceeding the 65535 bytes limit

Why does Java implement this limit? I don't see the rational since Java does include a goto_w instruction.

Konstantin Weitz
  • 6,180
  • 8
  • 26
  • 43

1 Answers1

26

See the Java Virtual Machine Specification section 4.10:

4.10 Limitations of the Java Virtual Machine

  • The amount of code per non-native, non-abstract method is limited to 65536 bytes by the sizes of the indices in the exception_table of the Code attribute (§4.7.3), in the LineNumberTable attribute (§4.7.8), and in the LocalVariableTable attribute (§4.7.9).

There's few good reasons to have a method that long in an object-oriented programming language.

Community
  • 1
  • 1
WhiteFang34
  • 70,765
  • 18
  • 106
  • 111
  • 21
    Actually there is a fairly good reason ... code generation. http://www.velocityreviews.com/forums/t146001-reached-the-65535-bytes-limit.html – Konstantin Weitz Apr 16 '11 at 21:51
  • 2
    Yeah, I'm aware that people hit that limit in JSP files. I still don't buy that as a good reason. That means that almost certainly there's too much complexity in a single JSP file. – WhiteFang34 Apr 16 '11 at 21:55
  • 1
    Modern JSP-compilers know how to circumvent that limitation. – Thorbjørn Ravn Andersen Apr 16 '11 at 21:56
  • 1
    @WhiteFang: You linked to (and quoted from) the Java Virtual Machine Specification instead of Java Language Specification, and actually should have copied the next item instead. – Paŭlo Ebermann Apr 16 '11 at 22:02
  • 4
    Whatever the reason was for this decision - the thought "We'll have a 64k limit somewhere." should have been alarming. What limits did we not have seen fall in the last years! Experience shows that everytime someone thinks: This should be more than enough! he is falsified a few years later. – Ingo Apr 16 '11 at 23:18
  • 5
    @WhiteFang - sure,this would be "too much" complexity and no, we can't imagine that a program could really need more than 640k memeory, can we? – Ingo Apr 16 '11 at 23:20
  • 1
    @Ingo: A reasonable limitation on code complexity and a future scaling limitation are two entirely different things. Just because we can use more memory in the future doesn't mean the code that uses it should also be more complex. A specification shouldn't limit the amount of memory we can use, however I'd argue a specification that limits poor design is perfectly fine. – WhiteFang34 Apr 16 '11 at 23:30
  • 2
    @WhiteFang - the fact is that it does not limit only "poor design". It doesn't limit anything, it just makes some things more clumsy. Who are you that you think you know it is poor design if its 64k? Then you can certainly explain to me why even a mid size parser table is "poor design" and must not be set up in one static method? – Ingo Apr 16 '11 at 23:40
  • 2
    @Ingo: alright, I suppose there's some argument for tools that generate code like JavaCC. Then it is just extra work to generate code that gets around the limitation. Whether or not they were trying to save 2 bytes per offset in the spec or there's a deeper reason, I don't know. Either way I don't think it's as alarming as the 640k memory limit. – WhiteFang34 Apr 16 '11 at 23:57
  • Well, @WhiteFang, saving 2 bytes on every other instruction is really an argument, even today. But fearing too much poor design if methods are allowed to be grater than 64k is not. I think if we knew how few C functions (for sake of example) are actually larger than 64k, we'd be surprised. And yet there are tons of really, really bad code (whether C or Java) out there. – Ingo Apr 17 '11 at 00:07
  • 2
    @Ingo: fair enough, I changed "no" to "few" in my answer :) – WhiteFang34 Apr 17 '11 at 00:12
  • 5
    @Ingo, at some level, we always have to worry about size. Modern languages often hide this, but it doesn't mean there are no tradeoffs being made. For example, how big should we allow a URL to get? (See http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url ) – Dilum Ranatunga Apr 17 '11 at 00:38
  • 2
    For that matter, why limit a stackoverflow comment to 600 characters? – Dilum Ranatunga Apr 17 '11 at 00:38
  • 1
    @Dilum - or a filename or path name, for that matter. I remember the days when a UNIX filename could be 14 characters long - a directory entry was 16 bytes and 2 bytes were for the inode number. Still that was an enhancement, other OSs at that time allowed 8+3 or just 8 characters. – Ingo Apr 17 '11 at 00:50
  • @Dilum Why not let the programmer worry about their binary sizes? Building this restriction into the language is short sighted. – B T Oct 10 '18 at 22:24
  • @BT because system constraints allow designers to not worry about some aspect, and worry about others. Imagine telling Ford "Why have a towing limit on the F-150? Let the driver decide how much he wants to tow." Ford would have to massively over-engineer it for a very small percentage of users. In this case, the 64K limit allows designers to allocate 2 bytes per index that maps each bit of byte code to the source code line. Supporting larger would bloat the table, or increase complexity of the code (support bigger indexes only when necessary.) All for addressing a very small minority's need. – Dilum Ranatunga Oct 17 '18 at 05:27
  • @DilumRanatunga These are very different scenarios. Its far more expensive to add the ability to tow more weight in a car. The same is not at all true for a byte limit on files. Supporting tables would only bloat the table if you designed it poorly. "increase complexity of the code (support bigger indexes only when necessary." - This doesn't sound significantly difficult. Its far more important that the language be easy to use for the programmer than that it be easy to implement by the language designer. The added complexity is worth eliminating a needless language limitation. – B T Oct 17 '18 at 20:55
  • @BT my point is that scope control -- and capacity constraining *is* a form of scope control -- is a fundamentally important part of software engineering. I for one am glad they spend time on areas other than bytecode support for functions netting more than 64k bytes. I think that every alternate code/data path adds to the combinatorial explosion of testing, so yes, alternate codepaths for bigger indexes do add complexity. Even otherwise, there are possibly other downstream effects of relaxing this constraint. – Dilum Ranatunga Oct 18 '18 at 23:52