code of method is exceeding the 65535 bytes limit
Hi
Is there some way how to persuade the javac compiler to accept very long methods? The code in question is the result of a meta-compilation from another language(using the IDL-to-Java Compiler --idlj command), and it turned out that this compiler generated a pretty long java code.
Is there any kind of tweaking that can be done to make this code
acceptable?
Thanks a lot for your help!
Regards
Glnnca
[450 byte] By [
iamkagomea] at [2007-10-3 10:31:02]
u can use linked list...
ttrra at 2007-7-15 5:53:47 >
> u can use linked list...That will not help.@Op. You could manually refactor the code and break it up into shorter methods (but I do understand that that isn't a nice solution)Kaj
that's a nasty one. I was about to decry the folly of writing such a long method, but clearly that's not appropriate here
I think your only route is a manual refactor. if this code is to be generated repeatedly, it's probably worth automating the refactor, as well. custom Ant task, perhaps?
I hate when generated code violates your principles :-(
It depends on what's causing the method to be so long.
If it's due to everything using fully-qualified class names then perhaps some code clean-up tool will fix this easily. Just a thought.
Actually, that's a stupid thought - ignore it!
Using a code clean-up tool to remove unused local variables, etc. might sort it out but it seems unlikely.
Message was edited by:
KPSeal
Or try and ask the people who wrote that compiler/ report it as a bug. Maybe they can do something.-Puce
Pucea at 2007-7-15 5:53:47 >
> It depends on what's causing the method to be so
> long.
> If it's due to everything using fully-qualified class
> names then perhaps some code clean-up tool will fix
> this easily. Just a thought.
>
> Actually, that's a stupid thought - ignore it!
> Using a code clean-up tool to remove unused local
> variables, etc. might sort it out but it seems
> unlikely.
>
> Message was edited by:
> KPSeal
you beat me to it!
unused locals are I think removed by the compiler so don't take up space (unused locals that have assignments but no reads are AFAIK not removed).
But such steps will only stave off the inevitable. A method that results in over 64KB bytecode is unmaintainable.
I've only seen it happen twice in 10 years. Both were extremely complex JSPs written by people who'd not yet heard of dynamic JSP includes and had made large scale use of static includes.
As a result some JSPs resulted in massive amounts of generated Java code (and thus massively large bytecode).
Refactoring those JSPs cured the problem (as well as making changes to common code much smoother, no longer requiring clearing compiler caches on the webservers).
> But such steps will only stave off the inevitable. A
> method that results in over 64KB bytecode is
> unmaintainable.
Amen.
> I've only seen it happen twice in 10 years. Both were
> extremely complex JSPs written by people who'd not
> yet heard of dynamic JSP includes and had made large
> scale use of static includes.
Or JSTL, from the sound of it. Or layering. Or MVC.
> As a result some JSPs resulted in massive amounts of
> generated Java code (and thus massively large
> bytecode).
>
> Refactoring those JSPs cured the problem (as well as
> making changes to common code much smoother, no
> longer requiring clearing compiler caches on the
> webservers).
What's that much code doing in a JSP?
%
> > I've only seen it happen twice in 10 years. Both
> were
> > extremely complex JSPs written by people who'd not
> > yet heard of dynamic JSP includes and had made
> large
> > scale use of static includes.
>
> Or JSTL, from the sound of it. Or layering. Or
> MVC.
>
No JSTL yet at that stage.
Just some JSPs that generated reams of code.
> > As a result some JSPs resulted in massive amounts
> of
> > generated Java code (and thus massively large
> > bytecode).
> >
> > Refactoring those JSPs cured the problem (as well
> as
> > making changes to common code much smoother, no
> > longer requiring clearing compiler caches on the
> > webservers).
>
> What's that much code doing in a JSP?
>
No JSTL, so a lot of iterating over collections by hand and extracting data from objects contained in those collections.
Combine that with JSPs serving to create tabbed dialogs, with the tabs being contained inside the JSP rather than each being its own JSP (no iframes).
The people who originally wrote it hadn't had decent training in writing web applications nor Java (just an intro course).
They were good, but had no experience in how to best set things up for maintainability (their experience was mostly in C).
Some code-obfuscators replace all variable names and method names with short, sequential names to make reverse engineering a pain.
class A{
int a;
double b;
long c;
public int aa(){
}
etc.
}
And this makes maintenace a REAL pain. For a one-off, though, it might work.
And if there's comments in the code, obviously you can eliminate them.
If there's a bunch of hardcoded strings, you may find it worthwhile to move them to an interface class, and implement that interface in the class containing the method.
BobCa at 2007-7-15 5:53:47 >
> Some code-obfuscators replace all variable names and> method names with short, sequential names to make> reverse engineering a pain.Good god, no.I'd recommend refactoring those JSPs and introducing JSTL.%
> Some code-obfuscators replace all variable names and
> method names with short, sequential names to make
> reverse engineering a pain.
Shortening variable names has no effect on the length of bytecode.
> If there's a bunch of hardcoded strings, you may find it worthwhile
> to move them to an interface class, and implement that interface
> in the class containing the method.
Moving strings to interfaces has no effect on bytecode length. Moving strings to other classes makes bytecode longer.
> And this makes maintenace a REAL pain. For a one-off,
> though, it might work.
Don't...do...it
> And if there's comments in the code, obviously you
> can eliminate them.
This will do nothing. Comments are ignored by the compiler
> If there's a bunch of hardcoded strings, you may find
> it worthwhile to move them to an interface class, and
> implement that interface in the class containing the
> method.
That's the 'constant interface antipattern'. Don't do it.
Can you tweak the settings on your IDL-to-java compiler? If not, you're going to have to refactor the java code by hand. Eclipse has a good refactoring suite that may help your life be a little less miserable.
No matter how you slice it, this sounds like a mess. No amount of lipstick will make this anything other than a pig.%
> And if there's comments in the code, obviously you> can eliminate them.> > This will do nothing. Comments are ignored by the> compiler> Oops, I was thinking it was a source code limit.
BobCa at 2007-7-21 13:18:37 >
> It depends on what's causing the method to be so
> long.
> If it's due to everything using fully-qualified class
> names then perhaps some code clean-up tool will fix
> this easily. Just a thought.
>
> Actually, that's a stupid thought - ignore it!
> Using a code clean-up tool to remove unused local
> variables, etc. might sort it out but it seems
> unlikely.
It is wrong because it will have absolutely no impact one way or the other.
Class and method names are stored as strings in the class string store. They are not in the byte code for a method.
Moreover class files always contain fully resolved names.
Local variables that are not used do not impact byte code creation. If they are initialized (which means used) then they would be in the byte code.
> unused locals are I think removed by the compiler so
> don't take up space (unused locals that have
> assignments but no reads are AFAIK not removed).
A local declaration like the following can not generate code.
int i;
A local initialization statement like the following would generate code which a compiler might choose to remove.
int i=3;
>
> But such steps will only stave off the inevitable. A
> method that results in over 64KB bytecode is
> unmaintainable.
>
It is generated. It isn't really a maintainance issue.
> I've only seen it happen twice in 10 years. Both were
> extremely complex JSPs written by people who'd not
> yet heard of dynamic JSP includes and had made large
> scale use of static includes.
> As a result some JSPs resulted in massive amounts of
> generated Java code (and thus massively large
> bytecode).
>
I have seen a knowledge/rules system generate a C method which the compiler could not handle. The creators of that system just had not anticipated that complex single point rules could exist and that a C compiler would have a method length limit.
>
> And this makes maintenace a REAL pain. For a one-off,
> though, it might work.
>
Absolutely no impact on this problem.
> And if there's comments in the code, obviously you
> can eliminate them.
>
Definitely no impact on this problem.
> If there's a bunch of hardcoded strings, you may find
> it worthwhile to move them to an interface class, and
> implement that interface in the class containing the
> method.
Again no impact on this problem in general. It might impact it because the code that used the strings changed by moving them.
> Is there any kind of tweaking that can be done to make this code
> acceptable?
1. Change the source so the generated code is shorted.
2. Manually edit the output.
3. Create a tool to break the generated output into smaller routines. The difficulty of this depends on what the generated code is doing.
> Local variables that are not used do not impact byte
> code creation. If they are initialized (which means
> used) then they would be in the byte code.
No doubt.
However this was about what a code cleaner considers "unused", not what the compiler does. Obviously there's a risk that the behaviour of the method might change if it's too aggressive!
Eclipse, for example, can remove initialised primitives/strings that aren't used from the code and that does affect the method size. Admittedly it would have to be one seriously messed up bit of code to benefit significantly from this!
With you on everything else, though!
I've actually seen examples of code where removing an unused but initialised variable changed the behaviour of an application to the point it no longer ran correctly.
The initialisation code happened to be extremely timing sensitive and the few milliseconds saved by not performing that operation caused it to fail (so did running it on newer, faster, hardware of course).
That wasn't Java code though, it was Assembler.
But in Java something similar can happen if the initialisation code that's being performed to initialise that unused variable has some side effects which the "cleaner" doesn't take into consideration.
> I've actually seen examples of code where removing an
> unused but initialised variable changed the behaviour
> of an application to the point it no longer ran
> correctly.
> The initialisation code happened to be extremely
> timing sensitive and the few milliseconds saved by
> not performing that operation caused it to fail (so
> did running it on newer, faster, hardware of
> course).
Amusing.
annoying too, having the code run perfectly on an 8MHz machine, fail sporadically on a 12MHz machine, and disastrously on a 16MHz machine (it was that long ago :) ).
> annoying too, having the code run perfectly on an 8MHz machine, fail
> sporadically on a 12MHz machine, and disastrously on a 16MHz
> machine (it was that long ago :) ).
Nah, I still deal with Atmel 4MHz and 8MHz little processors. In a perverted
way I like counting clock cycles and actual time. It's a tedious job but it
pays off in the long run ;-)
kind regards,
Jos
JosAHa at 2007-7-21 13:18:37 >
you mean counting clockcycles in real time, in synch with the CPU, of course.Haven't done that in some time, I'm getting older and can't keep up anymore with those newfangled eeelektrohniks thingies they make these days.
> you mean counting clockcycles in real time, in synch
> with the CPU, of course.
yup ...
> Haven't done that in some time, I'm getting older and can't keep up
> anymore with those newfangledb eeelektrohniks thingies they make
> these days.
Oh dear; please stand in that corner where Sabre is sitting ;-)
Old men ... duh
kind regards,
Jos (goes down to the bare metal; always, well ... not always ;-)
^^^ < young
JosAHa at 2007-7-21 13:18:37 >
> > Haven't done that in some time, I'm getting older
> and can't keep up
> > anymore with those newfangledb eeelektrohniks
> thingies they make
> > these days.
>
> Oh dear; please stand in that corner where Sabre is
> sitting ;-)
>
> Old men ... duh
You have just two choices - become old or become dead. I'm just growing old disgracefully!
> > > Haven't done that in some time, I'm getting older and can't keep up
> > > anymore with those newfangledb eeelektrohniks thingies they make
> > > these days.
> >
> > Oh dear; please stand in that corner where Sabre is sitting ;-)
> >
> > Old men ... duh
>
> You have just two choices - become old or become
> dead. I'm just growing old disgracefully!
lol! I'll buy you one whenever we meet in person.
kind regards,
Jos (< not old ;-)
JosAHa at 2007-7-21 13:18:42 >
> > > > Haven't done that in some time, I'm getting
> older and can't keep up
> > > > anymore with those newfangledb eeelektrohniks
> thingies they make
> > > these days.
> >
> > Oh dear; please stand in that corner where Sabre
> is sitting ;-)
> >
> > Old men ... duh
>
> You have just two choices - become old or become
> dead. I'm just growing old disgracefully!
>
> lol! I'll buy you one whenever we meet in person.
>
> kind regards,
>
> Jos (< not old ;-)
SUBTLE PROBE FOR DATE ALERT! SUBTLE PROBE FOR DATE ALERT :)
> SUBTLE PROBE FOR DATE ALERT! SUBTLE PROBE FOR DATE ALERT :)You young pervert, there's nothing wrong with a pint or two ;-)kind regards,Jos ;-)
JosAHa at 2007-7-21 13:18:43 >
>
> You have just two choices - become old or become
> dead. I'm just growing old disgracefully!
Nothing wrong with being dead. Lots of people seem to not mind it too much, at least until the neighbours start complaining about bits of your falling onto the sidewalk.
> > SUBTLE PROBE FOR DATE ALERT! SUBTLE PROBE FOR DATE> ALERT :)> > You young pervert, there's nothing wrong with a pint> or two ;-)> > kind regards,> > Jos ;-)sure. just ask Marc Almond :-)
> >
> > You have just two choices - become old or become
> > dead. I'm just growing old disgracefully!
>
> Nothing wrong with being dead. Lots of people seem to
> not mind it too much
Absolutely. When I am dead it will be somebody else's problem.
