B4J Question < Solved> Boundery reached when compiling a program?

[BlueVision]

I got this when building a standalone package of a large programme with B4JPackager11 Version 1.40 since I added a sub into the source code. New code works. Removing another sub and building the package works. So it is not the last addition of code.

Error: java.lang.RuntimeException: Method code too large!

Looks like a limitation. Program works in debug mode and in release mode, but packing with the packager will force this error.
The projects code itself is about 7000 lines (incl. comments), the layout script is very large too.

Any ideas how to prevent this?

 

[walterf25]

I got this when building a standalone package of a large programme with B4JPackager11 Version 1.40 since I added a sub into the source code. New code works. Removing another sub and building the package works. So it is not the last addition of code.

Error: java.lang.RuntimeException: Method code too large!

Looks like a limitation. Program works in debug mode, compiling not possible.
The projects code itself is about 7000 lines (incl. comments), the layout script is very large too.

Any ideas how to prevent this?

My first thought would be that maybe you have a method or function that exceeds 64k bytes threshold, you may try breaking down said function into smaller size functions.

Walter

 

[BlueVision]

breaking down said function into smaller size functions.

How should I do that? Smaller subroutines? Putting some code into a class?

What's crazy about the whole thing is that I can get the actual programme code through the packager without errors if I reduce some of the newly added design elements in the designer script for the layout, i.e. if I don't place these elements correctly in the view via the script (simply comment them out).
Is it possible that the descriptions in the designer script are simply too extensive? Are there any limitations? Has it perhaps simply become too big and I am exceeding the 64k limit with the designer script? From a purely logical point of view, the script must also be processed in some way by the packager and integrated into the build.

 

[emexes]

Error: java.lang.RuntimeException: Method code too large!

Is a Java implementation limit rather than a B4X limit. Java modules (or perhaps their data segments) can only be up to 64 kB.

Best way to get 15K integers from spreadsheet to B4J

I have computed with Excel about 15K integers which are polynomial arguments, and which need to be entered in an array, list, table, type or whatever. They must all be available for calculations as soon as the program starts. They will be broken down into multiple subsets to simplify their use...

www.b4x.com

How should I do that? Smaller subroutines? Putting some code into a class?

If you have multiple Subs in the one (large) source file, then move half of them into a new source file.

B4J IDE menu: Project, Add New Module, Code Module

Well, actually, move just one Sub to start with, before investing time in moving more of them.

Watch out for variables that are shared between Subs; you might need to repeat their declaration in the new source file.

 

[emexes]

I can get the actual programme code through the packager without errors if I reduce some of the newly added design elements in the designer script for the layout, i.e. if I don't place these elements correctly in the view via the script (simply comment them out).
Is it possible that the descriptions in the designer script are simply too extensive? Are there any limitations?

That is an interesting question: I thought designer scripts would be compiled into their own custom bytecode, not into Java and then Java bytecode. Perhaps that was a bold assumption.

But... what kind of designer script would approach 64 kB anyway? Feels a bit like it might be for a large number of individual views where a runtime array of views might be a better approach. Any chance of a peek at the repetitive part of the designer script, so that we're not flying blind here?

 

[BlueVision]

But... what kind of designer script would approach 64 kB anyway? Feels a bit like it might be for a large number of individual views where a runtime array of views might be a better approach. Any chance of a peek at the repetitive part of the designer script, so that we're not flying blind here?

Exactly! I suspect the designer script and somehow have a bad conscience about it. The programme itself grew more and more over time, more and more functions were added. In principle, there are now 10 panels, which are shown and hidden depending on the function, but are always available in a view (i.e. a single designer script). An infinite number of labels, buttons, B4XTables and many other controls.
Perhaps these should be separated as single view and then not hidden, as I have done so far, but loaded as a separate view into the new pane when the corresponding function is called.
Yesterday I took out all the new subroutines and also the new controls in the script and was able to run the packager. Then I added the new subroutines step by step and started the packager. It runs fine with all of the new routines. The error occurs when I exceed a certain amount of controls in the DesignerScript. That's why I have the idea to reduce this script step by step by adding a new layout with a separate script for each function.
I have simply packed the DesignerScript into a text file. The size of this file is suspiciously close to the 64k limit (57k). Now the packager will probably not include the DesignerScript in this way. But it could be an indication... Hope this is it.

It seems that the programming sins of the past have now caught up with me. Who wants to revise 7000 lines of code because of that? Apparently I have to now... Step by Step.

Showing the script here might not help. It is a gigantic conglomeration of SetToPandBottom, SetLeftandRight, HorizontallyCenter and x% and y%. Everything scales wonderfully, depending on each other. And it's huge. Almost 900 lines. Actually, it should have been clear to me that this construct would implode at some point. I think that might not be a bad approach. What do you think?

 

[emexes]

What do you think?

I think you might be on to something here:

It seems that the programming sins of the past have now caught up with me.

tempered by:

"He that is without sin among you, let him cast the first stone"

I think we all have code that has outgrown the original plan of back when things were simple and obvious.

Having said that, it sounds like you're well on the way to cleaning it up.

My first thought was to move the designer script machinations into regular Subs, although I'm not sure if multiple code modules can be associated with the one B4XPage or Activity.

My second thought is that it sounds like you have multiple (overlaid) "pages" in the one layout file, and you're disabling all views that are not in the current active "page", and that another way might be to have multiple layout files (ie, one for each "page")

and to move/change to a new "page", clear all currently-loaded views and then load just the layout that is the (new) current active "page".

 

[agraham]

I'm not sure it is your designer script that is the problem. My understanding is that the designer scripts are interpreted using, I think, a version of the Basic4ppc interpreter, so the compiler doesn't see them as an actual method. The usual reason for this error is that you have too much code in a Sub, and it will be exacerbated if using debug mode as that adds extra code to each Sub.

 

[Erel]

My understanding is that the designer scripts are interpreted using, I think, a version of the Basic4ppc interpreter, so the compiler doesn't see them as an actual method.

This is true in design mode. The script is compiled together with the app.

There isn't enough information in the first post to say anything.

 

[BlueVision]

My second thought is that it sounds like you have multiple (overlaid) "pages" in the one layout file, and you're disabling all views that are not in the current active "page", and that another way might be to have multiple layout files (ie, one for each "page")

and to move/change to a new "page", clear all currently-loaded views and then load just the layout that is the (new) current active "page".

Thats exactly what I did over the years by adding new features

 

[BlueVision]

I'm not sure it is your designer script that is the problem. My understanding is that the designer scripts are interpreted using, I think, a version of the Basic4ppc interpreter, so the compiler doesn't see them as an actual method. The usual reason for this error is that you have too much code in a Sub, and it will be exacerbated if using debug mode as that adds extra code to each Sub.

Well, the programme code itself works including the new routines.
Both in debug mode and in release mode. I only have the problem when "tying up the package" with the packager. There, the message comes up. If I leave the code completely activated (without commenting out subroutines), this does not change the problem.
However, I can eliminate the problem by deactivating only three of the new controls in the view in the designer script. There seems to be a critical point that creates an "overflow".

It may be a feasible method to change the appearance of the programme by enabling and disabling panes. To be honest, I was never really happy with it. I'm now trying to put the new controls into an extra layout and then load that layout into a pane. If the problem is then solved, the problem comes from the huge designer script. I can then work through this piece by piece "backwards" and make it smaller, outsourcing the script code to the other layouts in this way. Trial and error makes perfect. There is probably no other way to eliminate the error, as it is not really possible to find out what is causing this problem. A lot of work...

 

[BlueVision]

There isn't enough information in the first post to say anything.

I have changed the text of the first post to make the problem clearer. The problem is created or recognised by the packager.

 

[Erel]

Please post the full text from the logs.

 

[BlueVision]

Please post the full text from the logs.

Not sure if this will help...

B4J Version: 10.00
Parse den Code.    (0.57s)
    Java Version: 11
Building folders structure.    (0.06s)
Kompiliere den Code.    (0.58s)
   
Die Datei ObfuscatorMap.txt wurde im Objects-Verzeichnis angelegt.
Kompiliere Layoutcode.    (0.10s)
Organisiere Libraries.    (0.00s)
Kompiliere generierten Java Code.    (2.82s)
Erstelle jar Datei.    (15.98s)
    jar Datei erstellt. C:\B4J\Projects\Shark\B4J\Objects\SHARK.jar
Aufbau-Paket. Überprüfen Sie die Protokolle auf weitere Informationen.    Error

B4JPackager11 Version 1.40
Exe name: Shark.exe
build folder: C:\B4J\Projects\Shark\B4J\Objects\temp\build
InputJar: C:\B4J\Projects\Shark\B4J\Objects\SHARK.jar
Running: C:\B4J\Projects\Shark\B4J\Objects\temp\FindDosPath.exe
Running: C:\Java\bin\jar
Package name: b4j.SHARK
Running: C:\Java\bin\jdeps
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Explicitly excluded modules: [javafx.web]
Included modules: [jdk.charsets, jdk.crypto.ec, java.base, java.datatransfer, java.desktop, java.logging, java.naming, java.prefs, java.security.jgss, java.sql, java.xml, java.xml.crypto, javafx.base, javafx.controls, javafx.fxml, javafx.graphics, javafx.media, javafx.swing, java.scripting, jdk.unsupported, jdk.unsupported.desktop, jdk.jsobject, jdk.xml.dom]
Running: C:\Java\bin\javac
.
.
Running: C:\Java\bin\jar
.
.
.
.
.
.
.
.
Running: C:\Java\bin\jlink
.
.
.
.
.
.
.
.
.
Error: java.lang.RuntimeException: Method code too large!

 

[BlueVision]

I have created a new panel in the Main. This is filled with a layout according to the selected function. The design elements and code parts that are responsible for the design of the layout simply move from the old script into the new layout.

Once again I learn to appreciate B4J. Cutting the design elements out of the overcrowded designer script and transporting them into the new layout is very easy with cut & paste. All assigned properties are retained. That saves me a lot of work. Erel, B4J is simply ingenious. It is a joy to work with it and to materialise ideas in your head in the form of software. Only minimal adjustments are needed.
I will create more layouts so that I can largely relieve the design script in the main. By the way, the designer with the scripts has always been my favourite...

In short, the problem seems to have been recognised and solved.
Many thanks to all those who have racked their brains for me. We have all learned something new.

I am cautiously optimistic.
The fault is always in front of the computer with the fingers on the keyboard...

 

[Erel]

It is indeed not clear what caused the error. This is not the compiler limitation that some users reach in debug mode with huge subs. It looks like a bug in the one of the packager tools.

In many cases you can use anchors instead of designer script. It will simplify things.

 

[BlueVision]

It is indeed not clear what caused the error. This is not the compiler limitation that some users reach in debug mode with huge subs. It looks like a bug in the one of the packager tools.

In many cases you can use anchors instead of designer script. It will simplify things.

All is well, Erel. I think the problem is definitely not caused by B4J itself. It is caused by the integrated packager. Strictly speaking, it is not even a malfunction, but a limitation within Java. Seen in this way, it is not really an error but the reaching of a limit within the structure.
The only problem is that there is no indication of where someone is actually justifiably shooting from. So you change the structure and it works. Ultimately, this is a programming sin that has manifested itself over the years. I am now rebuilding the programme step by step, dividing parts of the programme into new layouts, which then have an identical, but then layout-specific designer script. In this way I was able to relieve the designer script in the main layout already in 10%. There is air again.
You are absolutely right about anchoring. But with the anchors, it's also one of those things. Do I anchor an object or do I assign script commands to it? In my opinion, anchoring makes a lot of sense, especially with several objects of the same size and type. With a rather "asymmetrical" design of many different objecttypes, I have always been on the safe side with a script and have generally opted for it. Then I know exactly where I have to change in order to get the desired result and don't have to think about whether the object is simply anchored or controlled via a script.
The disadvantage of this method is, of course, that you create gigantic designer scripts this way. Again, not good, but you can get used to it and above all rely on it. I am more of an advocate of script design for complex views.

But it's good to know where the limit is for such a script and how the error then becomes noticeable. As already mentioned, neither in debug nor in release mode, but when packing with obfuscator in release mode via the integrated packager. It wasn't the obfuscator either, you can switch it off. It was definitely the designerscript. And the workaround for it ultimately makes the structure of the programme more systematic and clearer. If I exported the error-generating script into a text file, saved it and then looked at the size of the file, it was a near 60kByte. A dangerous size and ultimately something like "madness grown over time".
Problem recognised. I mark the thread as <solved>. Maybe someday there will be someone who makes the same mistake I did. and reads this.

Thanks to all of you for the great ideas and help, especially Emexes and you Erel. I hope the current situation in your country will soon change for the better. That is better for everyone. Take care of yourself, your family and your friends. All of us here in the forum, no matter where we come from or how old, we need you too.

Best regards from Berlin, BV