(Just grabbed the latest SDK and NDK on 10.9) 7:29.66 Processing annotations... 7:29.67 ProGuard, version 4.7 7:29.67 The output seems up to date 7:29.68 DX classes.dex 7:30.46 Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang 7:30.46 at java.lang.ClassLoader.preDefineClass(ClassLoader.java:485) 7:30.46 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) 7:30.46 at java.lang.ClassLoader.defineClass(ClassLoader.java:621) 7:30.46 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) 7:30.46 at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) 7:30.46 at java.net.URLClassLoader.access$000(URLClassLoader.java:58) 7:30.46 at java.net.URLClassLoader$1.run(URLClassLoader.java:197) 7:30.46 at java.security.AccessController.doPrivileged(Native Method) 7:30.46 at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 7:30.46 at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 7:30.46 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 7:30.47 at java.lang.ClassLoader.loadClass(ClassLoader.java:247) 7:30.47 at java.lang.ClassLoader.defineClass1(Native Method) 7:30.47 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) 7:30.47 at java.lang.ClassLoader.defineClass(ClassLoader.java:621) 7:30.47 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) 7:30.47 at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) 7:30.47 at java.net.URLClassLoader.access$000(URLClassLoader.java:58) 7:30.47 at java.net.URLClassLoader$1.run(URLClassLoader.java:197) 7:30.47 at java.security.AccessController.doPrivileged(Native Method) 7:30.47 at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 7:30.47 at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 7:30.47 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 7:30.47 at java.lang.ClassLoader.loadClass(ClassLoader.java:295) 7:30.47 at java.lang.ClassLoader.loadClass(ClassLoader.java:247) 7:30.47 at java.lang.Class.getDeclaredMethods0(Native Method) 7:30.47 at java.lang.Class.privateGetDeclaredMethods(Class.java:2484) 7:30.47 at java.lang.Class.getDeclaredMethods(Class.java:1827) 7:30.47 at org.mozilla.gecko.annotationProcessors.utils.GeneratableElementIterator.<init>(GeneratableElementIterator.java:32) 7:30.47 at org.mozilla.gecko.annotationProcessors.AnnotationProcessor.main(AnnotationProcessor.java:77) 7:30.50 make[5]: *** [GeneratedJNIWrappers.cpp] Error 1 7:30.50 make[5]: *** Waiting for unfinished jobs.... 7:36.91 make[4]: *** [mobile/android/base/libs] Error 2 7:36.91 make[3]: *** [libs] Error 2 7:36.91 make[2]: *** [default] Error 2 7:36.91 make[1]: *** [realbuild] Error 2 7:36.91 make: *** [build] Error 2 7:36.94 781 compiler warnings present.

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #0) > (Just grabbed the latest SDK and NDK on 10.9) Hi ehsan, can we get the SDK and NDK versions, please? (You can get this from the |android| tool.) And maybe the relevant lines of your mozconfig?

I have the ndk r9b and the Android 4.4 SDK version 19, both of which should be the latest as of last night. ;-) Here's my mozconfig: $ cat .mozconfig-fennec # Add the correct paths here: ac_add_options --with-android-ndk="$HOME/src/android-ndk-r9b" ac_add_options --with-android-sdk="$HOME/src/adt-bundle-mac/sdk/platforms/android-19" # android options ac_add_options --enable-application=mobile/android ac_add_options --target=arm-linux-androideabi

I am experiencing the same issue while building on Mac

The same problem persists using android ndk r9c and android sdk api 19 revision 2. The javac version is 1.6.0_65.

When trying to build from release channel. It crashes at AnnotationProcessor.java:44 This error occurs while getting declared methods for class, "org.mozilla.gecko.menu.GeckoMenuInflater" 0:43.29 Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang 0:43.29 at java.lang.ClassLoader.preDefineClass(ClassLoader.java:485) 0:43.29 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) 0:43.29 at java.lang.ClassLoader.defineClass(ClassLoader.java:621) 0:43.29 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) 0:43.29 at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) 0:43.29 at java.net.URLClassLoader.access$000(URLClassLoader.java:58) 0:43.29 at java.net.URLClassLoader$1.run(URLClassLoader.java:197) 0:43.29 at java.security.AccessController.doPrivileged(Native Method) 0:43.30 at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 0:43.30 at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 0:43.30 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 0:43.30 at java.lang.ClassLoader.loadClass(ClassLoader.java:247) 0:43.30 at java.lang.ClassLoader.defineClass1(Native Method) 0:43.30 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) 0:43.30 at java.lang.ClassLoader.defineClass(ClassLoader.java:621) 0:43.30 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) 0:43.30 at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) 0:43.30 at java.net.URLClassLoader.access$000(URLClassLoader.java:58) 0:43.30 at java.net.URLClassLoader$1.run(URLClassLoader.java:197) 0:43.30 at java.security.AccessController.doPrivileged(Native Method) 0:43.30 at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 0:43.30 at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 0:43.30 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 0:43.30 at java.lang.ClassLoader.loadClass(ClassLoader.java:295) 0:43.30 at java.lang.ClassLoader.loadClass(ClassLoader.java:247) 0:43.30 at java.lang.Class.getDeclaredMethods0(Native Method) 0:43.30 at java.lang.Class.privateGetDeclaredMethods(Class.java:2484) 0:43.30 at java.lang.Class.getDeclaredMethods(Class.java:1827) 0:43.30 at org.mozilla.gecko.annotationProcessors.AnnotationProcessor.main(AnnotationProcessor.java:44) 0:43.46 make[5]: *** [GeneratedJNIWrappers.cpp] Error 1 0:43.47 make[4]: *** [libs] Error 2 0:43.47 make[3]: *** [libs] Error 2 0:43.47 make[2]: *** [default] Error 2 0:43.47 make[1]: *** [realbuild] Error 2 0:43.47 make: *** [build] Error 2

Any chance of this issue being resolved anytime soon?

Chris, do you have time to take a look at this? I don't see anything obvious that I can fix.

(In reply to Michael Comella (:mcomella) from comment #7) > ... anything obvious that I can fix. Use Linux :P This bug is weird. This error seems to mostly be associated with attempts to redefine classes in java.lang - which isn't something we try and do (at least, not on purpose). Were we incorrectly doing so, it'd fail on all platforms - surely the semantics of Java classes must be the same across platforms! That's the whole point of Java! That's what it's *for*. The other strange thing is that it's failing on a call to getDeclaredMethods - an operation that you are allowed to do just fine to classes in java.lang (at least, it works on Linux. I can't remember what the spec says about it). The other strange thing is that we shouldn't ever be encountering such a class object in GeneratableElementIterator (unless the build system is including classes from java.lang in the jar, which it both isn't and can't (since attempting to do so would produce this error at build time (of the jars, that is))). So, it's failing to do something that it seems to be allowed to do, but even if it isn't, it can't possibly be doing it to the thing it claims to be doing it do. If Comment 5 is to be believed, the failing class is org.mozilla.gecko.menu.GeckoMenuInflater. Unless someone very hastily restructured a few things while I wasn't looking, GeckoMenuInflater isn't in java.lang. Wat. I suspect Comment 5's stack trace is incomplete. If it's not, that's sort of interesting, since the offending line in AnnotationProcessor.java is: >>Iterator<ClassWithOptions> jarClassIterator = IterableJarLoadingURLClassLoader.getIteratorOverJars(args); How can that call not be on the stack? A reference to args is hardly going to throw this exception (java.lang.String must have been loaded already because line 38, so even the fruitiest possible edgecase isn't happening there...) It might be fun to write some code that catches the error and carries merrily along, just to see what happens. So, things that might allow more (hopefully less wild speculation): A complete version of Comment 5's stack trace (Or verification that is *is* complete and that someone's been adding hallucinogens to my tea) Confirmation of the class that's being passed to GeneratableElementIterator at the point the call to getDeclaredMethods fails. Bonus points for printing *ALL* the things about that class (Although if the class is failing to load, good luck with that). Post me a Mac. :P

If you can tell me exactly what to do, I'll be happy to try to get you more info here, but please be warned. I know zero things about Java, so "print this stuff" is too high-level for me :-)

(In reply to Chris Kitching [:ckitching] from comment #8) > Were we incorrectly doing so, it'd fail on all platforms... Has anyone tried this with the latest sdk/ndk for Linux?

Well, I might have changed a few lines to get the name of the class it breaks on. But the offending line in fact is: Iterator<MethodWithAnnotationInfo> methodIterator = new GeneratableEntryPointIterator(aClass.getDeclaredMethods()); It breaks on getDeclaredMethods(). I put a try catch on just "aClass.getDeclaredMethods()" statement and printed the name of the class "aClass" it threw an exception on and that was: "org.mozilla.gecko.menu.GeckoMenuInflater"

(In reply to Chris Kitching [:ckitching] from comment #8) > I suspect Comment 5's stack trace is incomplete. If it's not, that's sort of > interesting, since the offending line in AnnotationProcessor.java is: > >>Iterator<ClassWithOptions> jarClassIterator = IterableJarLoadingURLClassLoader.getIteratorOverJars(args); I think my stack trace was complete but still I am doing a fresh clone of latest release channel will report back if there's something more in stack trace. Also, the offending line was Iterator<MethodWithAnnotationInfo> methodIterator = new GeneratableEntryPointIterator(aClass.getDeclaredMethods()); not what you mentioned. There might be difference in line numbers (I messed around to get the class name). > How can that call not be on the stack? A reference to args is hardly going > to throw this exception (java.lang.String must have been loaded already > because line 38, so even the fruitiest possible edgecase isn't happening > there...) > > It might be fun to write some code that catches the error and carries > merrily along, just to see what happens. > > > > So, things that might allow more (hopefully less wild speculation): > > A complete version of Comment 5's stack trace (Or verification that is *is* > complete and that someone's been adding hallucinogens to my tea) > Confirmation of the class that's being passed to GeneratableElementIterator > at the point the call to getDeclaredMethods fails. Bonus points for printing > *ALL* the things about that class (Although if the class is failing to load, > good luck with that). > Post me a Mac. :P I got the name of the failing class by putting try catch around aClass.getDeclaredMethods(). Let me know if you need something other than class name. I really don't know what you mean by *ALL* the things about that class. Let me know and I will happy to report back.

After trying to debug everything that I could to find "Prohibited package name: java.lang" exception. It seemed more like a java issue than anything else. I updated jdk from default mac 1.6.0_65 to latest oracle 1.7.0_45, and the issue was resolved. No more exception and it builds perfectly. But is there something else we can do (or not do) to make it build on mac on default jdk as the previous versions of fennec are building fine? Or should we just put it on mac/oracle for old version and call it a day? HTH

(In reply to Sajjad Naveed from comment #13) Great work! I didn't think to try it with JDK6, as I've always used JDK 7. My guess is this is just some slightly obscure bug in the way JDK6 on Macs handles some of the stranger edgecases of classloaders. I vote for just bumping the dependency to JDK7. That way, we can start using source level 7 and do a bunch of code cleanup (multicatch, try-with-resources, diamonds, etc.) Not sure who to ask about that suggestion, though...

(In reply to Chris Kitching [:ckitching] from comment #14) > I vote for just bumping the dependency to JDK7. That way, we can start using > source level 7 and do a bunch of code cleanup (multicatch, > try-with-resources, diamonds, etc.) > Not sure who to ask about that suggestion, though... nalexander, what say you?

(In reply to Michael Comella (:mcomella) from comment #15) > (In reply to Chris Kitching [:ckitching] from comment #14) > > I vote for just bumping the dependency to JDK7. That way, we can start using > > source level 7 and do a bunch of code cleanup (multicatch, > > try-with-resources, diamonds, etc.) > > Not sure who to ask about that suggestion, though... > > nalexander, what say you? AFAIK Android officially recommends JDK 1.6. I don't support going against that. Drop a link one way or the other, please. It's reasonable to require Mac devs to build against JDK 1.7 until we *know* it breaks, or it's worked for O(1) months. We can't hope to push automation to JDK 1.7 anytime soon, and I'd rather not do it without a compelling reason. I don't care about JDK 1.7 code clean up; I have no reason to expect a big win from that. (Small wins, yes; but time, and churn.) mfinkle, blassey: what have I missed?

Sounds like JDK 1.7 is a Mac-only local build fix. We can recommend Mac devs use it, but we should not expect to move to it via automation.

AFAIK, our officially supported build config is NDK r8e (or r8c for 32bit machines) and SDK 16. Do these problem exist with those configurations?

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #18) > AFAIK, our officially supported build config is NDK r8e (or r8c for 32bit > machines) and SDK 16. Do these problem exist with those configurations? But the Android NDK/SDK isn't the JDK. The JDK version is the thing that's being changed here... Or do you think that changing the NDK version may somehow have the same effect?

Using NDK r8e and SDK v16 fixed the issue for me. I updated the OS X build docs here <https://wiki.mozilla.org/Mobile/Fennec/Android#Mac_OS_X>, please review!

Glandium just saw this on Linux with JDK6. Worked when upgrading to JDK7.

Re Nick's comment 16, the Android Studio docs recommend 1.6 or higher: http://developer.android.com/sdk/installing/studio.html Looks like Android quietly acquired 1.7 support (and, indeed, recommendation) around the end of 2013. And now Android *code* supports some Java 7 features, so I think the 1.6 recommendation is dead.