-
Notifications
You must be signed in to change notification settings - Fork 975
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARGC exceptions when translating #1471
Comments
Try addressing the TypeUtil.asTypeElement() NPE (that method hasn't changed in the ARGC branch) with:
This isn't likely to fix the underlying problem, but hopefully you'll get more descriptive errors. What version of Joda Convert are you transpiling? The current version doesn't have an AbstractTypeStringConverter class, so I cannot recreate this issue locally. Also, what j2objc flags do you set? |
Thanks for response, much appreciated
We're using 1.8 but I've also tried with 1.9.2
I've rebuilt with the change you proposed but the error description remains the same:
|
Try removing the jre_emul.jar from the classpath, and instead define the
-bootclasspath with it (like the j2objc script does). jre_emul.jar is not a
full JRE emulation (use the JVM's jar or module), but is used by j2objc to
verify that the API being translated adheres to the API supported by j2objc.
…On Wed, Sep 16, 2020 at 5:05 AM Tomek Kopycki ***@***.***> wrote:
Thanks for response, much appreciated
What version of Joda Convert are you transpiling?
We're using 1.8
<https://www.joda.org/joda-convert/changes-report.html#a1.8> but I've
also tried with 1.9.2
<https://www.joda.org/joda-convert/changes-report.html#a1.9.2>
Also, what j2objc flags do you set?
def classPath = "${System.env.J2OBJC_HOME}/lib/jre_emul.jar:" +
"${System.env.J2OBJC_HOME}/lib/guava-25.1-jre.jar:" +
"${System.env.J2OBJC_HOME}/lib/jsr305-3.0.0.jar:" +
"${System.env.J2OBJC_HOME}/lib/javax.inject-1.jar:" +
"${System.env.J2OBJC_HOME}/lib/jre_emul.jar:" +
"${System.env.J2OBJC_HOME}/lib/j2objc.jar:" +
"$projectDir/src/main/java/:" +
"$projectDir/build/j2objc/java/source:" +
"$projectDir/build/generated/source/apt/main"
executable "${System.env.J2OBJC_HOME}/j2objc"
args "-source", "1.8"
args "-classpath", classPath
args "-encoding", "utf-8"
args "--prefixes", "$projectDir/prefixes.properties"
args "--doc-comments"
args "--static-accessor-methods"
args "--nullability"
args "--generate-deprecated"
args "-g" //debug flag
args "-sourcepath", "$projectDir/src/main/java/:$projectDir/build/j2objc/java/source:$projectDir/build/generated/source/apt/main"
args "-d", "$projectDir/build/j2objc/objc/source"
args "--dead-code-report", "$projectDir/build/proguard/usage.log"
Try addressing the TypeUtil.asTypeElement() NPE
I've rebuilt with the change you proposed but the error description
remains the same:
error: internal error translating "/Users/tomaszkopycki/Projects/fabulous-ios/fabulous-core/fabulous-core/build/j2objc/java/source/org/joda/convert/ToStringConverter.java"
com.google.devtools.j2objc.ast.TreeVisitorError: /.../build/j2objc/java/source/org/joda/convert/ToStringConverter.java:26: NullPointerException: null
at com.google.devtools.j2objc.util.TypeUtil.asTypeElement(TypeUtil.java:238)
at com.google.devtools.j2objc.ast.TypeDeclaration.acceptInner(TypeDeclaration.java:95)
at com.google.devtools.j2objc.ast.TreeNode.accept(TreeNode.java:82)
at com.google.devtools.j2objc.ast.ChildLink.accept(ChildLink.java:76)
at com.google.devtools.j2objc.ast.ChildList.accept(ChildList.java:90)
at com.google.devtools.j2objc.ast.CompilationUnit.acceptInner(CompilationUnit.java:194)
at com.google.devtools.j2objc.ast.TreeNode.accept(TreeNode.java:82)
at com.google.devtools.j2objc.ast.UnitTreeVisitor.run(UnitTreeVisitor.java:50)
at com.google.devtools.j2objc.pipeline.TranslationProcessor.applyMutations(TranslationProcessor.java:152)
at com.google.devtools.j2objc.pipeline.TranslationProcessor.processConvertedTree(TranslationProcessor.java:107)
at com.google.devtools.j2objc.pipeline.FileProcessor.processCompiledSource(FileProcessor.java:169)
at com.google.devtools.j2objc.pipeline.FileProcessor.access$000(FileProcessor.java:43)
at com.google.devtools.j2objc.pipeline.FileProcessor$1.handleParsedUnit(FileProcessor.java:141)
at com.google.devtools.j2objc.javac.JavacParser.parseFiles(JavacParser.java:299)
at com.google.devtools.j2objc.pipeline.FileProcessor.processBatch(FileProcessor.java:146)
at com.google.devtools.j2objc.pipeline.FileProcessor.processInputs(FileProcessor.java:71)
at com.google.devtools.j2objc.pipeline.TranslationProcessor.processInputs(TranslationProcessor.java:83)
at com.google.devtools.j2objc.J2ObjC.runEx(J2ObjC.java:138)
at com.google.devtools.j2objc.J2ObjC.main(J2ObjC.java:200)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1471 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAW2JL7WHPSUX6BIUAJ5YMLSGCS2NANCNFSM4RM25G2Q>
.
|
Thanks for suggestion. I tried that, result was the same. Another thing was suggested though to remove which produces I've tried translating without |
The ARGC branch is experimental from an external contributor, so it hasn't gone through any rigorous code review yet (that's our next task, now that 2.7 has released). This change looks to be caused by the ARGC compiler generating code to support java.lang.String.intern(), by moving Objective C string constants into a local table and then in the initialize method interning them. So it should be harmless, though that design will probably need improvement. I can certainly believe that dead-code stripping may be broken; although the ARGC compiler succeeds for me with a simple dead-code-report file, your file is probably stripping something which causes the breakage. Would you mind attaching the joda-convert (org/joda/convert) related entries from your dead-code-report? Since that library is open-source, those entries shouldn't accidentally expose any proprietary API in your app. |
FYI, you can get 99% of the benefits of the ARGC compiler without using it, since it's design uses LLVM's ARC for most of the memory management, with a lightweight garbage collector just to clean up any remaining leaks. ARC will help even if the memory issues you are facing are leaks, and both the cycle_finder tool and Xcode Instruments can find leaks that can be addressed using J2ObjC's memory management annotations. It's more work to do that, but hopefully less work than wrestling with an experimental compiler. :-) To update a project using j2objc to use ARC:
If you embedded Objective-C native code in any Java sources, the cleanup involves:
The macros are declared here, as well as other useful memory management macros. Although those messages can be deleted in ARC sources, these macros allow your code to be built correctly using either ARC or manual resource counting. The final cleanup is to conditionally call
|
One last point: ARC and manual reference counting can co-exist, so your project can have native code that does reference counting, and transpiled Java that uses ARC. |
Here are the rules that we use:
Besides those we just have a few more And here are the joda convert related logs:
That's exactly our problem, we've neglected task of taking care of leaks for quite a long time and now wrestling with an experimental compiler has become a chance for an easy way out :) Our hope was this garbage collector would help us resolve those leaks to some extent at least but I suppose it's time to pull up the sleeves and start working on those ourselves :) We did try ARC in the past and it didn't change much in terms of the memory-related issues we're facing. Anyway thanks for all the help! Given how we rely on j2objc I suppose we'll give the garbage collector another go once it's more stable. |
We are trying to use garbage collection approach in our project to see if it helps with some of the memory issues we're facing, but we've been struggling with exceptions that arise during translation. We've built j2objc from
master-ARGC
branch according to the instructions (we've successfully did this with previous releases). The issues we're having arise when translating dependencies that we use, specifically Joda Convert (v1.8) and jtry.We have this exception for ~50 files. Stacktrace is exactly the same for all of them. We're using Java 1.8.0_221. None of these exceptions arise when translating with 2.4, 2.5 or 2.6
I'd greatly appreciate any suggestions to make this work for us 🙏
The text was updated successfully, but these errors were encountered: