java_lang_reflect_Field.h not found

[adrian...@googlemail.com]

If you are experiencing an issue please mention the full platform your issue applies to:
IDE: NetBeans
Desktop OS: Linux
Simulator
Device: iOS

Hi, I try to build an app for iOS. This app uses a library which makes references to java.lang.reflect.Field and I get a build error

fatal error: 'java_lang_reflect_Field.h' not found

when I look through the error.log I can't see that anything from java.lang.reflect is parsed. Is it not possible to use Reflection on iOS builds ? - which would be killer.

Thanks, Adrian.

error log attached

[Steve Hannah]

Reflection is not supported in Codename One.

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
Visit this group at http://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/e70b9ed1-6c38-4fdc-b748-56a697b3e82e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[Shai Almog]

To clarify this, using reflection makes no sense for mobile development.
On iOS this would mean we would effectively need to package the whole VM with all of its symbols into your app raising the total overhead to over 30mb (64bit and 32bit versions of the code).
On Android this would mean we won't be able to obfuscate your apps which negates Googles recommended practices.

Reflection is slow and fragile, it was designed for things like runtime manipulation in GUI builders and not for production code. You shouldn't use it for client applications and should probably avoid it for server apps as well.

[adrian...@googlemail.com]

I think this clarifies nothing.

How can you say reflection does not make sense ? - beside this sounds quite arrogant, there is no technical reason not to support reflection. We use the Haxe language to transpile to Java (and other targets - C#, C++, JS) and Haxe makes use of reflection for several things like serialization or remoting - cross platform, efficient and reliable - used on many production servers and apps. 

If codenameone can't support reflection crossplattform it disqualifies as a useful target for cross apps. But anyway, after some evaluation I doubt that it will be the right solution, because we will also need to support Windows Phone 8 (10), which will sure feel less native than the iOS solution with cn1.

[Steve Hannah]

The Haxe documentation describes the problems with reflection in more detail.

http://haxe.org/manual/std-reflection.html

They list a number of pitfalls, but the main one that Shai was trying to point out was:

However, even if there are no typing errors it is easy to come across unexpected behavior:
class Main {
static function main() {
// null
trace(Type.resolveClass("haxe.Template"));
}
}
The problem here is that the compiler never actually "sees" the type haxe.Template, so it does not compile it into the output. Furthermore, even if it were to see the type there could be issues arising from dead code elimitation eliminating types or fields which are only used via reflection.

Codename One uses dead-code elimination extensively to optimize the resulting application size.  Nobody wants a 50 meg "hello world" application.  Introducing reflection, while not impossible, would be complex - as it would necessitate additional (manual) housekeeping to try to keep the application size down.  Even if CN1 supported reflection, it would be highly recommended to not use it, as it would just open up a world of hurt for you.

Steve

--

You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
Visit this group at http://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/73a98f86-3000-4e6e-8ee2-0c9683a17d14%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Shai Almog]

Haxe isn't Java so my response was for Java which is what we support.

Our tool is a cross platform tool and you are layering ANOTHER separate tool then blame us for the deficiency of said tool.
 
Reflection is universally bad, my answer comes from a point of a VM developer who worked on several VM's (in Sun and here) quite a few of which didn't support reflection (mobile) those that did were horrible with it.
So I'll accept arrogance here and claim experience.

Proper code that uses such functionality uses bytecode manipulation and not reflection which is redundant since you shouldn't do dynamic code loading in mobile for obvious reasons (even Android restricts you there).
If Haxe was properly written it would be closer to the Mirah work done by Steve which uses bytecode translation: http://www.codenameone.com/blog/mirah-for-codename-one

This isn't just true on mobile, all major ORM tools use bytecode translation and never use reflection.

Serialization is problematic exactly because of those reasons, even on Android Google recommends obfuscation for all apps. This would break serialization (but not externalization that we support).
See this http://www.codenameone.com/blog/json-to-pojo-mapping where bytecode manipulation is used to achieve an effect similar to serialization.

[adrian...@googlemail.com]

ok now we get a little closer to a technical discussion.

Haxe uses dead code elimination as well - there are no classes or functions in the generated code which are not referenced in the app. I need only reflection on the classes which are referenced, so there shouldn't be the need to pull in the full jre and to create 30MB+ apps like CN1 is doing now for the Windows target for example. 

The overhead should only be the code for reflection - which is more or less some lookups in a map and the possibility to invoke a function dynamically. I don't think it is impossible for the iOS target and I don't believe this will be a problem with dead code elimination - because the code is already "clean".

Am Dienstag, 3. März 2015 19:00:20 UTC+1 schrieb Steve Hannah:

The Haxe documentation describes the problems with reflection in more detail.

http://haxe.org/manual/std-reflection.html

They list a number of pitfalls, but the main one that Shai was trying to point out was:

However, even if there are no typing errors it is easy to come across unexpected behavior:
class Main {
static function main() {
// null
trace(Type.resolveClass("haxe.Template"));
}
}
The problem here is that the compiler never actually "sees" the type haxe.Template, so it does not compile it into the output. Furthermore, even if it were to see the type there could be issues arising from dead code elimitation eliminating types or fields which are only used via reflection.

Codename One uses dead-code elimination extensively to optimize the resulting application size.  Nobody wants a 50 meg "hello world" application.  Introducing reflection, while not impossible, would be complex - as it would necessitate additional (manual) housekeeping to try to keep the application size down.  Even if CN1 supported reflection, it would be highly recommended to not use it, as it would just open up a world of hurt for you.

Steve

On Tue, Mar 3, 2015 at 9:21 AM, <adrian...@googlemail.com> wrote:

I think this clarifies nothing.

How can you say reflection does not make sense ? - beside this sounds quite arrogant, there is no technical reason not to support reflection. We use the Haxe language to transpile to Java (and other targets - C#, C++, JS) and Haxe makes use of reflection for several things like serialization or remoting - cross platform, efficient and reliable - used on many production servers and apps. 

If codenameone can't support reflection crossplattform it disqualifies as a useful target for cross apps. But anyway, after some evaluation I doubt that it will be the right solution, because we will also need to support Windows Phone 8 (10), which will sure feel less native than the iOS solution with cn1.

Am Donnerstag, 19. Februar 2015 19:28:30 UTC+1 schrieb Shai Almog:

To clarify this, using reflection makes no sense for mobile development.
On iOS this would mean we would effectively need to package the whole VM with all of its symbols into your app raising the total overhead to over 30mb (64bit and 32bit versions of the code).
On Android this would mean we won't be able to obfuscate your apps which negates Googles recommended practices.

Reflection is slow and fragile, it was designed for things like runtime manipulation in GUI builders and not for production code. You shouldn't use it for client applications and should probably avoid it for server apps as well.

-- 

[Shai Almog]

We would be unable to know what Haxe does or doesn't do in our build process. So we will need to pull in all of Codename One and all of our supported Java API's.
If we would use Haxe in the servers then that would be something different, but we have our hands full with Java and don't have the resources to pick up more work.

Furthermore, we strip the symbols both on iOS and Android (obfuscation) and only leave the bare minimum which is still quite a lot. (16k lines in the C file containing the strings for a small test app). This would really slow everything down considerably.

Assuming Haxe knows exactly what's needed why don't they use something like Javassit instead of reflection so they can get exactly whats needed. Assuming they do that it will boost their performance everywhere not just with us.

[adrian...@googlemail.com]

is reflection from javassist.tools.reflect supported for the iOS target ? than I could try to rewrite the reflection part of the Haxe library to fit with it.

[adrian...@googlemail.com]

I need to read a bit more on this subject...

[Shai Almog]

I'm not deeply familiar with that specific API. When I used Javassist I used different API's and use ASM for most of my bytecode manipulation work (for us speed is crucial).

We expect to get Java 5 bytecode in the build server so if you do bytecode manipulation and insert it into the ant script before the JAR is sent to the servers this "should" work. I can't guarantee that 100% since we only test javac. I know Steve had reasonable success with Mirah which compiles to bytecode so its possible.

[adrian...@googlemail.com]

hi, thanks. I have managed now to get rid of all dependencies to java.lang.reflect and changed the code to use javassist instead. The little test code runs fine in the simulator, but when I build for iOS I get now an error:

fatal error: 'javassist_ClassPool.h' file not found 

what am I doing wrong now ? 

[Shai Almog]

Hi,
that API might be the wrong API to use. I suggest you check out the source code of Steve's POJO mapper to see exactly what he did (he posts everything on github), since I assume he did exactly what you need to enable POJO mapping.
The code above seems to be adding an additional dependency on runtime classes which might be problematic especially since on the device we no longer have bytecode.

[adrian...@googlemail.com]

now I have removed all reflection code, but now I get build errors for a missing java_lang_Number.h. Posted this on another thread about java.lang.Number (from 2013)

[Shai Almog]

The class Number is missing from the VM for historic reasons. This is something we'd really like to fix as we move forward and unify our VM code.
Currently the only workaround is to write horrible code like instanceof Integer.

With the new VM as we unify the various platforms we will probably add support for Number once we start expanding the Java API support again.

[adrian...@googlemail.com]

yes this was a horrible task to get rid of java.lang.Number :)

but now I have the next problem - java.lang.ThreadLocal seems also missing. Is there an alternative way to declare thread local data ? (currently I think I can live without it).

[adrian...@googlemail.com]

made a simulated ThreadLocal with a synchronized hashmap and now it compiles on iOS 

- BUT WHY DOES IT NOT LINK:

Ld build/Release-iphoneos/Bauerfassung2.app/Bauerfassung2 normal armv7

    cd /var/folders/p_/xlvwhg4101z8r81_nl13cds80000gn/T/build3024158836421392786xxx/dist

    export IPHONEOS_DEPLOYMENT_TARGET=6.0

    export PATH="/Applications/Xcode6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode6.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"

    /Applications/Xcode6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch armv7 -isysroot /Applications/Xcode6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.0.sdk -L/var/folders/p_/xlvwhg4101z8r81_nl13cds80000gn/T/build3024158836421392786xxx/dist/build/Release-iphoneos -L/var/folders/p_/xlvwhg4101z8r81_nl13cds80000gn/T/build3024158836421392786xxx/dist/Bauerfassung2-src -F/var/folders/p_/xlvwhg4101z8r81_nl13cds80000gn/T/build3024158836421392786xxx/dist/build/Release-iphoneos -filelist /var/folders/p_/xlvwhg4101z8r81_nl13cds80000gn/T/build3024158836421392786xxx/dist/build/Bauerfassung2.build/Release-iphoneos/Bauerfassung2.build/Objects-normal/armv7/Bauerfassung2.LinkFileList -dead_strip -fobjc-link-runtime -miphoneos-version-min=6.0 -framework OpenGLES -framework CoreGraphics -framework UIKit -framework GLKit -framework Foundation -liconv -framework AdSupport -framework AddressBookUI -framework SystemConfiguration -framework MapKit -framework AudioToolbox -lxml2 -framework QuartzCore -framework AddressBook -lsqlite3 -lsqlite3.0 -framework GameKit -framework Security -framework StoreKit -framework CoreMotion -framework CoreLocation -framework MessageUI -framework MediaPlayer -framework AVFoundation -framework CoreVideo -framework QuickLook -framework iAd -framework CoreMedia -lz -lzbar -Xlinker -dependency_info -Xlinker /var/folders/p_/xlvwhg4101z8r81_nl13cds80000gn/T/build3024158836421392786xxx/dist/build/Bauerfassung2.build/Release-iphoneos/Bauerfassung2.build/Objects-normal/armv7/Bauerfassung2_dependency_info.dat -o /var/folders/p_/xlvwhg4101z8r81_nl13cds80000gn/T/build3024158836421392786xxx/dist/build/Release-iphoneos/Bauerfassung2.app/Bauerfassung2

Undefined symbols for architecture armv7:

  "_virtual_java_lang_Byte_intValue___R_int", referenced from:

      _haxe_lang_Runtime_toInt___java_lang_Object_R_int in haxe_lang_Runtime.o

  "_virtual_java_lang_Byte_doubleValue___R_double", referenced from:

      _haxe_lang_Runtime_doubleValue___java_lang_Object_R_double in haxe_lang_Runtime.o

      _haxe_lang_Runtime_toDouble___java_lang_Object_R_double in haxe_lang_Runtime.o

  "_virtual_java_lang_Short_intValue___R_int", referenced from:

      _haxe_lang_Runtime_toInt___java_lang_Object_R_int in haxe_lang_Runtime.o

  "_java_lang_RuntimeException___INIT_____java_lang_String_java_lang_Throwable", referenced from:

      _haxe_lang_HaxeException___INIT_____java_lang_Object_java_lang_String_java_lang_Throwable in haxe_lang_HaxeException.o

  "_virtual_java_lang_Short_doubleValue___R_double", referenced from:

      _haxe_lang_Runtime_doubleValue___java_lang_Object_R_double in haxe_lang_Runtime.o

      _haxe_lang_Runtime_toDouble___java_lang_Object_R_double in haxe_lang_Runtime.o

  "_virtual_java_lang_Long_intValue___R_int", referenced from:

      _haxe_lang_Runtime_toInt___java_lang_Object_R_int in haxe_lang_Runtime.o

  "_virtual_java_util_Date_toLocaleString___R_java_lang_String", referenced from:

      _com_veithsystem_bauerfassung2_Bauerfassung2_start_74__Fun___hx_invoke1_o___double_java_lang_Object_R_java_lang_Object in com_veithsystem_bauerfassung2_Bauerfassung2_start_74__Fun.o

ld: symbol(s) not found for architecture armv7

clang: error: linker command failed with exit code 1 (use -v to see invocation)

[Steve Hannah]

The Date class in CN1 doesn't implement the toLocaleString() method.  Use the Codename One javadocs to see exactly what is implemented:

https://codenameone.googlecode.com/svn/trunk/CodenameOne/javadoc/java/util/Date.html

Use the L10NManager class as an alternative:

http://codenameone.googlecode.com/svn-history/r358/trunk/CodenameOne/javadoc/com/codename1/l10n/L10NManager.html

Steve

--

You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
Visit this group at http://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/eba6abeb-7301-4054-94eb-72de8c44f361%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[adrian...@googlemail.com]

thanks - I will try. But what I don't understand is why does it compile if something is not implemented ? The compiler should bark out but not the linker.

cheers Adrian.

To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.

Visit this group at http://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/eba6abeb-7301-4054-94eb-72de8c44f361%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[adrian...@googlemail.com]

ok my simple Hello World from Haxe now works - I will release my changes to the Haxe runtime, which were necessary to compile against cn1 as a package. I guess there are still some problems, but now I know what to do. Maybe you get a new audience outside the Java community. 

After my first frustrating attempts, I understand now better why you compile against CLDC11. I tried for example the robovm with a simple hello world which results in a 40MB app for iOS, whereas the CN1 App is reasonable in size.

thanks for the help.

Adrian.

[Shai Almog]

Size is just half the story.
Testing the huge API is just impossible. As ex-Sun VM guys I can tell you that with huge TCK's and a dedicated QA team this was still a pretty hard task.