classes cannot be resolved in ios project.
JojoIce opened this issue · 6 comments
When creating a project with iOS as a target, it will be in a state where several classes "cannot be resolved".
What it really should say is that they violate the requirement of "unique visibility", since for example String is implemented in both the module java.base and package java.lang as well as in robovm-rt-2.3.19.jar
javac apparently handles this somehow, but there is a ticket that it really should not.
This problem will show also on a Windows machine using Eclipse, so no Mac HW is needed to replicate it.
This is only a problem for Java > 8 (the addition of modules is probably the root of the problem here), so a 'workaround' is to set Java to 8 and and create the project and then it works.
This might be a problem that only shows up in Eclipse, but in this case it seems like it is because Eclipse does handle it as it should and for example javac and AndroidStudio does not.
The problem goes away if the JRE system library is removed from the classpath, since then only the robovm-rt provides the java.lang and String (and all other classes in java.lang for example) can then be uniquely identified. The problem will come back as soon as a grade refresh is done since that brings the jre back into the classpath.
I am not quite sure how this should be solved, but maybe it is possible to use gradle to not include the jre even though the ios project still is a java project?
The type java.lang.String cannot be resolved. It is indirectly referenced from required type org.robovm.apple.uikit.UIApplicationShortcutItem
I would suggest asking about this in the RoboVM/MobiVM Gitter (you typically just log in with GitHub credentials, so it's pretty easy if you haven't used Gitter already). If they don't already know about this, they probably should... They may have a way around this issue already.
I am afraid that it really is a question of how to set up the project and not really related to RoboVM itself. Sure, it is a bit unusual that a different dependency other than JVM RT should be used and that is specific for iOS but, really I think that it only is a matter of not depending on the JVM RT and instead only depend on the robovm-rt for the standard rt libs.
How to do that, I don't know. Maybe the iOS project cannot be a java project or something, so that the JVM RT is not pulled in. Then everything seems to work, or possibly use the module voodoo to select only the things needed so that not multiple implementations of the same class is pulled in. I did not get gdx-setup to work on macos after having been spoiled by liftoff, but it would be interesting to see how that handles the same thing... Still it could be good to ask if someone is using liftoff and java >8 and Eclipse over there to see how it is solved maybe.
I think RoboVM only supports Java language level 8 anyway, unless you use one of the early releases with the updated libcore (and those are now quite old). I'm not sure if any part of it is aware of modules. I think using Java 8, or at least language level 8, is going to be required even if this were fixed.
Ah, OK I recalled some mentioning of robovm java 8+ and desugar stuff some time ago, and thought I was just behind times when liftoff defaulted to java 12. That is probably good for everything but iOS then? Android handles (most?) Java 12 or is it only 8 plus maybe a small subset of 8+ things? I guess what really is needed is a "Compiler compliance level" in the IDEs and only a lib that is the smallest common denominator of the JVM, Android, and robovm, but that will probably never happen. So maybe the solution is to default to Java 8 if iOS is selected or if that is tricky, just add a comment in the troubleshooting. However, it seems logical that there should only be one implementation of each class so the complaint from Eclipse is still valid I think, but can maybe be ignored as long as things anyway works... Especially if it is tricky to remove the JVM from the iOS project.
Liftoff defaults to 11 currently, because all platforms except iOS support it (and because TeaVM, which more and more people are using Liftoff to try, absolutely requires 11). I think I can force the language level down to 8 for projects that include iOS, which really means that most developers just shouldn't select iOS, even as a "just in case I get a Mac" situation (and no one can check both iOS and TeaVM). Android has supported at least some Java 11 features for a while on many (not sure if most) devices, and more devices support Java 11 by the day. Unfortunately, the branch/fork of MobiVM that supports a more recent Android core has stagnated for years.
Neither Java 8 nor 11 are supported by Oracle unless you have an "extended support" plan ( https://www.oracle.com/java/technologies/java-se-support-roadmap.html ), though that extended support goes through at least 2030, and it only applies to Java obtained from Oracle (which seems like a really bad idea given Oracle's track record, and you should use some form of OpenJDK with a clear license). Everyone seems to be updating to at least Java 11, except MobiVM; GWT can use Java 11, TeaVM requires it, Android can use it, all desktop varieties can use it. It's frustrating, but while MobiVM cannot understand the concept of JPMS, you really can't use any JPMS concepts in conjunction with the iOS backend. That seems to include forcing language level 8.