«

"jmcgill" <> wrote in message
news:sjM8g.4849$_c1.241@fed1read05...
>
> The compiler should know when it's writing an invalid classfile and should
> abort with a fatal error.

The OP mentions that the compiler is throwing a "Code too large" error.

- Oliver

Oliver Wong wrote:

> The OP mentions that the compiler is throwing a "Code too large" error.

Ah, so the ball is in the translator's court.

I still want to know if the input to javac looks reasonable. Somehow I
doubt it.

"Oliver Wong" <> wrote in message
news:XWN8g.8741$Qq.252@clgrps12...
>
> "Chris Uppal" <> wrote in message
> news:44638c8d$2$652$...
>> jmcgill wrote:
>>
>>> I also stand by my first comment -- if a code generator outputs
>>> something that's plainly invalid according to the target language spec,
>>> it's broken.
>
> From my understanding, the OP has some compiler which takes source code
> written into some language (call it language A), and produces code written
> in another language (language B). It just so happens that language B is a
> superset of Java. I.e., it is exactly like Java, but without various size
> limitations.

The limitations on the amount of byte code in a method can't reasonably be
called part of the Java language, since the translation from source to byte
code isn't part of the language definition. There are programs with methods
large enough to be near the limit that, one compiler, say javac, can
compile, while another, say jikes, can't, and quite possibly vice versa.

To put it another way, the program:

class Big
{
int i;

void meth()
{
i = 12; // 10922 of these
...
}
}

compiles successfully under javac 1.4.2_08. Make it 10923 copies of that
line, and it no longer compiles. Nothing in the language specification
will allow you to determine that 10922 is the magic number.

Mike Schilling wrote:

> compiles successfully under javac 1.4.2_08. Make it 10923 copies of that
> line, and it no longer compiles. Nothing in the language specification
> will allow you to determine that 10922 is the magic number.

I have a feeling that's a version of the Halting Problem or something
related. You can't know until you've actually gone through the
compilation process, and by then it's too late.

However, in my mind I cannot separate the JVM spec from the language spec.

On the other hand, if you showed me a method that was ten thousand lines
long, I wouldn't agree that it was reasonable, even if machine
generated. I don't care if it won't compile, or won't run, because I
don't consider it reasonable to expect it to.

However, my participation in this thread is because I'm still curious
about what code situation led to the problem for the OP. He claims a
quite simple routine has generated ab uncompilable java class. So I'm
still hoping to see the 20 lines of C or Cobol or Befunge or whatever,
that creates 20,000 lines of java, or (even more interesting) the 20, or
400, lines of java that choke the compiler.

I'm tired of speculating and I really want to see the code that caused
the failure.

jmcgill wrote:
> But it's still not clear whether the problem is javac turning reasonable
> java statements into invalid bytecode, or whether the problem is a code
> translator that creates unreasonable (or invalid) java source.

It's perfectly clear that it's a translator outputting lots of Java
source from a short sequence in the source language. Javac and invalid
byte code have nothing to do with it except that javac reports 'method
too long'.

EJP wrote:
> It's perfectly clear that it's a translator outputting lots of Java
> source from a short sequence in the source language.

If you say so. I didn't find it all that clear.


>Javac and invalid
> byte code have nothing to do with it except that javac reports 'method
> too long'.

That's everything to do with it. There's not a clear, well-defined
limit for the length of a method, and I assume that's at least partly
because this boundary cannot be determined easily, if at all.

Are we arguing that the language allows arbitrarily large methods while
a given language implementation does not?

Like I said, I'm tired of speculating on this, and I just wish the OP
would post the original snippet, the resulting java, I could rub my
beard in curiosity and then move on

"jmcgill" <> wrote in message
news:4DP8g.4858$_c1.3659@fed1read05...
> Mike Schilling wrote:
>
>> compiles successfully under javac 1.4.2_08. Make it 10923 copies of that
>> line, and it no longer compiles. Nothing in the language specification
>> will allow you to determine that 10922 is the magic number.
>
> I have a feeling that's a version of the Halting Problem or something
> related. You can't know until you've actually gone through the
> compilation process, and by then it's too late.

If you really wanted to, you could assign costs to various language
constructs, require compilers to generate bytecode sequences no longer than
the total of those costs, and define the maximum cost of a method. This
would be silly, of course, but it's possible.

> and I cannot separate the JVM spec from the language spec.

That's a shame; you should. One describes a language, one describe an
implementation of that language. They are not the same thing.

Mike Schilling wrote:

> That's a shame; you should. One describes a language, one describe an
> implementation of that language. They are not the same thing.

In my narrow corner of the real world, there is only Sun. I'm not
particularly proud of that

The truth is I understand the distinction fully.

jmcgill wrote:

> EJP wrote:
>
>> It's perfectly clear that it's a translator outputting lots of Java
>> source from a short sequence in the source language.
>
> If you say so. I didn't find it all that clear.

I don't know why not. Nobody else talked about the compiler producing
invalid byte code, you made that up. It doesn't, it produces an error
message instead, which is what the OP is talking about.

> There's not a clear, well-defined
> limit for the length of a method, and I assume that's at least partly
> because this boundary cannot be determined easily, if at all.

There is a clear well-defined limit for the length of a method of 65535
bytes specified in #4.10 of the Java Virtual Machine Specification.

The distinction between what the language permits and what the JVM
permits is meaningless. We are as always talking about a specific
compiler which has a specific target machine, in this case the JVM. The
same thing would happen with a C compiler targeting a 16-bit machine:
the code won't compile. It doesn't mean it's illegal C but it still
won't produce an object file. And the Java compilers which *dont'*
target the JVM and therefore encounter this limit form a rather small
and IMHO not very useful set.

EJP wrote:
>> If you say so. I didn't find it all that clear.
>
> I don't know why not.

Because there were no code examples, or even enough specific information
about the code in question to get a reasonable picture of what is going
on. I had to speculate that the code he's trying to compile is some
insanely long method.

> Nobody else talked about the compiler producing
> invalid byte code you made that up.

You're splitting hairs; it gives a message because its only alternative
is to write an invalid class file.

> There is a clear well-defined limit for the length of a method of 65535
> bytes specified in #4.10 of the Java Virtual Machine Specification.

Yes I cited that myself a while back.

> The distinction between what the language permits and what the JVM
> permits is meaningless.

Matter of opinion, and I don't care about that. I just want to see the
code that caused this mess, or at least hear a better description of it.