IOS builds failing: error unexpected statement

[Dave Dyer]

Ios builds are again failing - if you just swapped in some new translator code, you've got a problem.

/IntermediateBuildFilesPath/Develop.build/Release-iphoneos/Develop.build/Objects-normal/armv7/com_codename1_ui_Container.dia -c /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build1560409686451700725xxx/dist/Develop-src/com_codename1_ui_Container.m -o /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build1560409686451700725xxx/dist/build/Build/Intermediates/ArchiveIntermediates/Develop/IntermediateBuildFilesPath/Develop.build/Release-iphoneos/Develop.build/Objects-normal/armv7/com_codename1_ui_Container.o
/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build1560409686451700725xxx/dist/Develop-src/com_codename1_ui_Container.m:1916:1: error: expected statement
}
^
1 error generated.

[Dave Dyer]

This repeated 3 times, but the fourth attempt at the same build succeeded.

I'd feel better about this if you told me there was a problem you understand and fixed.

[Shai Almog]

Nope, we are all offsite so no one touched anything to trigger or fix the issue. We haven't touched the translation code in a while.
I'll login to the servers and peek around.

[Dave Dyer]

As fragile as your build process is, you really ought to have 24 hour coverage. 
I'm currently on the 4'th attempted build.  If nothing else, these crapped-out builds
cause your server load to be much higher than it ought to be.

.

[Shai Almog]

You are the only person to run into any of these problems and slow builds. You can save a lot of time by adapting your code to Codename One properly and shrinking it.

[Dave Dyer]

I'm afraid that breaking my app into 75 separate game apps would be a terrible idea and not a net saving of my time
or an improvement of the user experience.  It's a shame that codenameone doesn't support any kind of modularity
(as java does) that would permit me to rebuild only the parts that change.  But I understand that would be hard.

[Shai Almog]

Java doesn't support AoT modularity and doesn't support it at all at the current release anyway.
Java wasn't designed for modern mobile devices either...

[Dave Dyer]

It is actually a positive thing that codenameone works with such an outlier as my app, but you can't blame me for
Also wishing that it work reliably and faster.

[Shai Almog]

I agree.
Some of the size issues are things we can't realistically resolve for your app. There are bandwidth limits that are inherent.
Some of the background processing issues are also problematic, AWT was mostly threadsafe and this led it down a problematic road.

[Dave Dyer]

There are definitely some things you could do that are not too difficult or drastic.  Segregating
the published APIs from the used APIs for the classes you compile would result in a huge speedup
with change in the result, and it would be self-checking; if you didn't get it right then your
compiles would break.

[Shai Almog]

It would slow things down.
If we do that this would mean we would need to compile and link the whole class library without stripping anything until link stage.

This will balloon the result especially if a user clicks include source. Since more time is spent uploading/downloading than compiling for many users this would slow down almost all apps including yours.

Try a typical app, even a large one, builds take 3 - 5 minute for iOS assuming no queuing

[Dave Dyer]

An interesting bit about this "statement expected" error.  I've been generating my own builds, and out of a few dozen builds that
I got as far as feeding to xcode, TWO so far have failed due to this.  Since I was watching for it, I re-ran the identical build and
the error did not repeat.    The errant label seems to be a free floating label, inserted randomly at the end of a method.  Everything
else about the file looks well-formed.

So, based on this evidence, theories involving resource exhaustion, rogue processes and other bolts from the blue
are less likely.

JAVA_VOID com_codename1_ui_Display_invokeAndBlock___java_lang_Runnable_boolean(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT  __cn1ThisObject, JAVA_OBJECT __cn1Arg1, JAVA_BOOLEAN __cn1Arg2) {
    volatile JAVA_INT ilocals_2_ = 0; /* dropEvents */
    DEFINE_INSTANCE_METHOD_STACK(4, 7, 0, 2603, 2629);
    locals[0].data.o = __cn1ThisObject; locals[0].type = CN1_TYPE_OBJECT;     locals[1].data.o = __cn1Arg1;
    locals[1].type = CN1_TYPE_OBJECT;
  ...

label_L1075083982: END_TRY();
    __CN1_DEBUG_INFO(1230);
    BC_ASTORE(6);
    __CN1_DEBUG_INFO(1231);
    set_field_com_codename1_ui_Display_dropEvents(threadStateData, 0 /* ICONST_0 */, __cn1ThisObject);
    __CN1_DEBUG_INFO(1232);
    BC_ALOAD(6);
    throwException(threadStateData, POP_OBJ());

label_L986065593:
    __CN1_DEBUG_INFO(1231);
    set_field_com_codename1_ui_Display_dropEvents(threadStateData, 0 /* ICONST_0 */, __cn1ThisObject);
    __CN1_DEBUG_INFO(1233);
    releaseForReturnInException(threadStateData, cn1LocalsBeginInThread, methodBlockOffset);
    return;

label_L590511187:
}