missing symbol complaint in Android build

[Dave Dyer]

    [javac] G:\share\projects\eclipse\boardspace core CN1\src\lib\G.java:1954: error: cannot find symbol
    [javac]         if(f.isTTFNativeFont() && (f.getPixelSize()==size))
    [javac]             ^
    [javac]   symbol:   method isTTFNativeFont()

IsTTFNativeFont() is a public api in font.Java, which has been there since 11/16/2015

[Shai Almog]

I'm guessing you are building against an older version of the libs then.

[Dave Dyer]

I built my installation well after the date in question.  What is the process of getting
the eclipse plugin in sync with the latest official sources?

[Shai Almog]

We push out a plugin or lib update occasionally (roughly once every 3-5 weeks). When we do that you can either just send a build which will fetch the update or use the "update client libs" button in the Codename One section of the project properties.

[Dave Dyer]

so if i get you to accept a new public method, it may be 3-5 weeks before I can use it in builds?

[Shai Almog]

http://stackoverflow.com/questions/34830911/how-does-a-codename-one-update-work/34835039

If you use the source as I understand you do, you don't need to wait much. The servers already have the change.

[Dave Dyer]

That may be the theory, but the practice seems to be less than faithful to the theory.  The isTTf change went into the sources in november,
but I still can't submit builds that use it.

On the other hand, the repairs I made to the sockets code seem to be in place, thanks.

[Shai Almog]

That's related to the classpath you are using. You are compiling against the jar instead of against your local sources. The compilation error you get is local and the changes are already in the sources.

Notice that within the build.xml there is a section that validates that you aren't using an unsupported API before sending a build. You need to reference your modified jars in order for this to work.

[Dave Dyer]

Thanks, that gives me a direction to look in.  In the eclipse environment there are no explicitly created jars for the codename1 codebase,
but I presume if I remove the references to the obsolete jars in the build script, I'll discover a way to use the live environment.

[Dave Dyer]

Ok, I modified my build process to build against my sources,  and I can now build using the
recently added methods.  These builds (android) succeed, but if they actually use the new
APIs they crash without a trace of cause.   I would guess that the new APIs are not actually
available on your build servers, but I'm disturbed that the builds succeeded.

How would I get more information (more than zero) out of the android device in this case?

--

[Shai Almog]

No its all implemented.

Connect the device with a cable and the DDMS tool from the Android SDK to see the actual printouts of the device.

[Dave Dyer]

I got to the bottom of this.  When you installed my getPixelSize() api, you fixed the text style
to conform to your formatting standards, but you also changed the signature from double to
float.   public double getPixelSize()  became public float pixelSize()

The jars I was building embedded/expected the original signature, and when invoked, resulted
in this error

 java.lang.NoSuchMethodError: No virtual method getPixelSize()D in class Lcom/codename1/ui/Font; or its super classes (declaration of 'com.codename1.ui.Font' appears in /data/app/com.boardspace-1/base.apk)

[Dave Dyer]

All this is pretty normal, except that your build process did not generate any complaint
about the mismatched signatures.

 

[Shai Almog]

That's because Android links classes dynamically so we can't tell you compiled against a "broken" jar.

[Dave Dyer]

yes, but when your build process encountered my request for a method teturning a double, that was not checked against your list of functions that were available to be linked to.

the client side makes that check before submitting the build,
why isn't the same check made in the actual build?

[Shai Almog]

The client side compiles your code and javac makes that check.
We get pre-compiled code which "should work". We don't need to check it for Android build. Adding such a check would just slow the build as it was already done on the client side.

[Dave Dyer]

True if your build process is perfectly synchronized with the client's.  That's manifestly not true.  Current case in point - you installed a different change
than I submitted.  Any number of accidents could result in a mismatch like this, and as we see, they are only manifest at runtime in deployed applications; which is not a very satisfactory q/a procedure.

[Shai Almog]

If you hack the source code your safety net is smaller.
Our servers have no way of knowing you did it so adding such verification for Android would slow down builds for everyone.

[Dave Dyer]

if you are on the cutting edge, contributing to the development of the product, you deserve the best safety net available.
Cycles are cheap. People time is expensive.
Errors completely on your side are possible too.
It could be an option.

[Shai Almog]

If you are on the cutting edge you should be aware of the risks and be cautious. Despite the myth CPU cycles are not cheap and do add up both in servers and mobiles.

[Dave Dyer]

Another instance of unnecessary arrows in my back.  I accidentally included javafx in by project's
build path, which allowed me to use Line2D methods.  This was not detected as an error by either
the local or the remote build process, and resulted in an android runtime error, but only when I actually
tried to use the Line2D methods.

Having this kind of latent error in delivery builds is like leaving a bomb in the basement.

+ $0.02

[Shai Almog]

That's only when you work with the sources and since you disabled the compile checks on the client.