«

Thomas Richter wrote:
> Hi folks,
>
> is there some way how to persuade the javac compiler to accept very long
> methods? No, don't worry, I'm not writing this kind of mess. The code in
> question is the result of a meta-compilation from another language, and
> it turned out that this compiler generated a pretty long java code from
> a seemingly simple source. Unfortunately, the compilation of the
> generated java code then fails with the infamous "code too large" error.
>
> Is there any kind of tweaking that can be done to make this code
> acceptable (besides fixing the compiler that generated the java code
> in first place, that is.)?
>
> So long,
> Thomas

VerifyError yes.
Check with the copy and paste detector and see how much code that will
save you. Then see if you can't get the simple source and then the
other languages compilation to deal with it. Used to get these all the
time with Jasper (tomcat) and tags that were in the service method and
not in their own module/method.

John Gagon

"jmcgill" <> wrote in message
news_R8g.4871$_c1.217@fed1read05...
> 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
>

I'd go further than Sun vs. other JVMs, though. My claim is that Java is a
language with its own definition, and that JVM-related restrictions are not
part of that language definition per se.

Thought experiment: consider a Java environment that isn't JVM-based;
rather, it compiles Java to .class files, and allows you to link those files
into a native executable. If it can compile methods too large for javac,
would you consider this a violation of the language spec? Does is matter if
they can theoretically be presented in 65K of bytecode?

Mike Schilling wrote:
> "jmcgill" <> wrote in message
> news_R8g.4871$_c1.217@fed1read05...
>> 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
>>
>
> I'd go further than Sun vs. other JVMs, though. My claim is that Java is a
> language with its own definition, and that JVM-related restrictions are not
> part of that language definition per se.
>
> Thought experiment: consider a Java environment that isn't JVM-based;
> rather, it compiles Java to .class files, and allows you to link those files
> into a native executable. If it can compile methods too large for javac,
> would you consider this a violation of the language spec? Does is matter if
> they can theoretically be presented in 65K of bytecode?
>
>

Mike we're much closer to full agreement than you seem to think.

But I've got the mindset where, if something doesn't work in practice,
you miss the delivery of your iteration. All the theory in the world
won't put words in the email to your project manager that spins it like
a positive thing

I saw the OP's routine. It's in some vector-based language that I think
I haven't ever seen. It's obvious that, where the original language
declares things as sets, the translation to java has to implement
loops... and naturally, unrolls those loops. 8K iterations, some of them.

I have to admit that I don't understand the source language, that if I
did understand it, I don't understand the physics or geometry behind
the original problem (Ising model/thermodynamic analysis; I got far
enough in physics to have heard of it, but not far enough to understand
what it's useful for.)

I'm still really curious though, because it's rare that I see a
programming language I don't recognize.

What language is this?

topology = torus in {bounded,torus};
width = 512 in {64..4096}; #defines a default and a range.
height = 512 in {64..4096};

or this:

bonds = ([0,1] << 0) + ([0,-1] << 1) + ([1,0] << 2) + ([-1,0] << 3);

"jmcgill" <> wrote in message
news:Cj59g.4946$_c1.4025@fed1read05...
>
> I saw the OP's routine. It's in some vector-based language that I think I
> haven't ever seen.
[...]
> I don't understand the physics or geometry behind the original problem
> (Ising model/thermodynamic analysis; I got far enough in physics to have
> heard of it, but not far enough to understand what it's useful for.)
>
> I'm still really curious though, because it's rare that I see a
> programming language I don't recognize.
>
> What language is this?
>
> topology = torus in {bounded,torus};
> width = 512 in {64..4096}; #defines a default and a range.
> height = 512 in {64..4096};
>
> or this:
>
> bonds = ([0,1] << 0) + ([0,-1] << 1) + ([1,0] << 2) + ([-1,0] << 3);
>

It's not unusual to invent a new domain specific language to facilitate
implementing the solution to domain specific problem. Many times, these
languages are unnamed. We've got a few unnamed languages here at my company.

- Oliver

"jmcgill" <> wrote in message
news:Cj59g.4946$_c1.4025@fed1read05...
> Mike Schilling wrote:

>>
>> Thought experiment: consider a Java environment that isn't JVM-based;
>> rather, it compiles Java to .class files, and allows you to link those
>> files into a native executable. If it can compile methods too large for
>> javac, would you consider this a violation of the language spec? Does is
>> matter if they can theoretically be presented in 65K of bytecode?
>
> Mike we're much closer to full agreement than you seem to think.
>
> But I've got the mindset where, if something doesn't work in practice, you
> miss the delivery of your iteration. All the theory in the world
> won't put words in the email to your project manager that spins it like a
> positive thing

We don't diasgree there either. My sugggestion (upthread, a bit) was to
write a postprocessor that splits the method into small enough pieces (that
is, private methods) that javac can deal with it.

Oliver Wong wrote:

> It's not unusual to invent a new domain specific language to
> facilitate implementing the solution to domain specific problem. Many
> times, these languages are unnamed. We've got a few unnamed languages
> here at my company.

I'm sure it always seems like a good idea at the time....

jmcgill wrote:
> Chris Uppal wrote:
>> I may have forgotten something but I don't remember a limit on method
>> size in
>> the Java Language Specification. (There are limits in classfiles, of
>> course,
>> but that's a different issue.)
>
> The classfile format is the only issue!

It is not necessarily the only issue. You have limitations on branch
statements as well being limited to 64k.
--
Dale King

"Dale King" <"DaleWKing [at]gmail [dot] com"> wrote in message
news:R-...
> jmcgill wrote:
>> Chris Uppal wrote:
>>> I may have forgotten something but I don't remember a limit on method
>>> size in
>>> the Java Language Specification. (There are limits in classfiles, of
>>> course,
>>> but that's a different issue.)
>>
>> The classfile format is the only issue!
>
> It is not necessarily the only issue. You have limitations on branch
> statements as well being limited to 64k.

But this doesn't limit the size of the method, given that the goto_w
instruction uses a 32-bit offset. Longer branches can be generated using
it, e.g.

if (condition
{
more than 64K of code)
}
else
{
}

becomes

if (!condition)
goto_w else_block
if_block.
goto_w after_else_block
else_block

Interestingly, I found a 1995 version of the JVM spec online at
http://sunsite.ee/java/vmspec/vmspec-1.html, and under limitations, it says:

The amount of code per method is limited to 65535 bytes by the sizes
of the indices in the code in the exception table, the line number
table,
and the local variable table. This may be fixed for 1.0beta2.

Mike Schilling wrote:

> Interestingly, I found a 1995 version of the JVM spec online at
> http://sunsite.ee/java/vmspec/vmspec-1.html, and under limitations, it
> says:
>
> The amount of code per method is limited to 65535 bytes by the sizes
> of the indices in the code in the exception table, the line number
> table, and the local variable table. This may be fixed for 1.0beta2.

<chuckle/>

-- chris