Java Question Class doesn't come with an associated EnclosingMethod attribute

[warwound]

I'm compiling an app with a few libraries that i have created and it's failing to compile with this error:

Compiling generated Java code. 13.44
Convert byte code - optimized dex. Error
warning: Ignoring InnerClasses attribute for an anonymous inner class
(nu.xom.Verifier$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.apache.xerces.dom.CharacterDataImpl$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.apache.xerces.dom.ParentNode$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.apache.xerces.dom.SecuritySupport$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
** Followed by many more simlar lines **

The nu.xom package is an external .jar file used by my XOM library.

The org.apache.xerces.dom package is again part of an external file named dtd-xercesImpl.jar which is required by the XOM library.

The error implies that these external .jar files have been compiled in a way that makes then unsuitable for B4A.
I can download the java XOM source code and compile it myself and hopefully that'll fix that problem, and i'll have to Google to see if there's a compatible version of the dtd-xercesImpl.jar library.

But before i started looking for a solution i tried the simple demo B4A project from my XOM library thread.
It compiles and runs perfectly.

So i'm just asking why one B4A project fails to compile and another successfully compiles with the exact same collection of library files.
Searching the forum i found a reference to a similar error and the reason for the error was that two referenced libraries include the same class.
My project that fails to compile is a large project written by someone else, i'm pretty sure that there's no class being included more than once.

Has anyone got any suggestions?
Shall i simply recompile these two external .jar files from source and hope that'll be a solution or is it more likely that somewhere in the failing project there is a class being included more than once?

Thanks.

Martin.

 

[Erel]

These are only warnings. Is there any error message?

 

[warwound]

The error messages end with:

UNEXPECTED TOP-LEVEL ERROR:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at com.android.dx.ssa.back.LivenessAnalyzer.constructInterferenceGraph(LivenessAnalyzer.java:93)
at com.android.dx.ssa.back.SsaToRop.<init>(SsaToRop.java:82)
at com.android.dx.ssa.back.SsaToRop.convertToRopMethod(SsaToRop.java:69)
at com.android.dx.ssa.Optimizer.optimize(Optimizer.java:101)
at com.android.dx.ssa.Optimizer.optimize(Optimizer.java:72)
at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:303)
at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:139)
at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:94)
at com.android.dx.command.dexer.Main.processClass(Main.java:682)
at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634)
at com.android.dx.command.dexer.Main.access$600(Main.java:78)
at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572)
at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
at com.android.dx.command.dexer.Main.processOne(Main.java:596)
at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264)
at com.android.dx.command.dexer.Main.run(Main.java:230)
at com.android.dx.command.dexer.Main.main(Main.java:199)
at com.android.dx.command.Main.main(Main.java:103)
Optimized dexer failed. Switching to Standard dexer.

So compilation fails with an out of memory error rather than continuing with 'Standard dexter'.

Martin.

 

[Erel]

What is the size of this jar?

You can increase the memory limit: http://www.b4x.com/android/forum/th...zed-dex-error-need-help-pls.10428/#post-58036

 

[warwound]

Thanks.
Increasing the ini file MaxRamForDex value from 512 to 1024 has fixed the problem.

This is a large project with 58 various types of modules, it uses 20 different libraries.
Guess the default setting of 512MB just wasn't enough.

Martin.

 

[socialnetis]

I have a very similar problem (which I mention here).
And increasing the MaxRamForDex value also fixed the problem.

Does this have any impact in the final apk which is installed in a device?

 

[Erel]

I have a very similar problem (which I mention here).
And increasing the MaxRamForDex value also fixed the problem.

Does this have any impact in the final apk which is installed in a device?

No. This is just the memory setting of the "dexer", which is one of the compilation steps.