One UI class generated by NetBean(5.5) has one method(initComponents) with 6000 lines. When I compile it with jdk1.5/1.6, it shows "code too large" error message. I know there is a 64K limits for one method in JVM. my question is if there is a way to exceed this limitation by parsing some parameters to javac.
Or the worst case, I have to refactor this method to some small size sub-methods.
Can anyone help? Thanks in advance.
Hi CaptainMorgan08,
Thanks for your reply.
An in-house application creates this UI class and its .form file, then I load it up into NetBean. so I can modify the layout, fonts, and so on in NetBean. You can see this class is automatically generated. In fact, the major thing NetBean does is to generate the initComponents() method. I just want to find a way to compile this mess, instead of refactoring it.
Thanks.
> Hi CaptainMorgan08,
> Thanks for your reply.
>
> An in-house application creates this UI class and its
> .form file, then I load it up into NetBean. so I can
> modify the layout, fonts, and so on in NetBean. You
> can see this class is automatically generated. In
> fact, the major thing NetBean does is to generate the
> initComponents() method. I just want to find a way to
> compile this mess, instead of refactoring it.
>
> Thanks.
I don't know of any way to make the compile just accept the code. But one thing you could do is to organize your UI into sections that are stored in different classes, so the that code generated by netbeans will be smaller. If you have one method that's 6000 lines long, even for UI code generated by netbeans, it sounds like that form you are creating is FAR too complicated.
Try to cut down on code by:
Using the most suitable layout manager - This means less tweaking;
Instead of changing fonts, colors, borders, etc, of each component manually, change the defaults in the layout manager.
Any containers (JPanels, etc) that have multiple related children could become their own class that extends JPanel, and you should be able to use your new classes in NetBeans as well.
Following the three pointers above, your code size should shrink down quite quickly, and will also drastically speed up your development time from here on out.
- Adam
IMHO anything that generates code is suspect, including humans (and sub-humans).
The good thing about automatic code generators is that they generate lots of code that you can't be bothered writing.
The bad thing about automatic code generators is that they generate lots of code that you wouldn't be bothered with writing, or would have the sense to stop writing about 20% of the way in.
And the other bad thing is that they tend to insulate the programmer from the true costs of what he or she is doing.
> The bad thing about automatic code generators is that
> they generate lots of code that you wouldn't be
> bothered with writing, or would have the sense to
> stop writing about 20% of the way in.
>
> And the other bad thing is that they tend to insulate
> the programmer from the true costs of what he or she
> is doing.
not to mention, maintenance is a *****.
Maintaining generated code can be made less of a hassle if done properly, and by "properly", I mean treating the input to the system as source code, and the generation as part of the build process.
However, whenever I've seen code generation used, invariably the generated code is what's source-controlled, and that's the stuff you have to maintain. The inputs are just lost, or kept at the consultant's site, or whatever.
Code generation never made a lot of sense to me anyway. There''s some process that generates code. There is some kind of activity and data in that process -- so shouldn't that activity and data make its way into a framework or library, that can be directly used and reused without generating anything? The only code that should be generated is the object code.
