search

MobiVM / robovm

Ahead of time compiler for JVM bytecode targetting iOS, Mac OSX and Linux
https://mobivm.github.io
942 stars 132 forks source link

Java 8 compatibility in RoboVM 2.3.20 #760

Closed avazquezdev closed 7 months ago

avazquezdev commented 7 months ago

Issue details

Hello, I am planning to upgrade some of my applications to the latest version of RoboVM(2.3.20), but I have discovered that it is not compatible with Java8. It's possible that it occurred in this commit: https://github.com/MobiVM/robovm/commit/2f7810953c85d055ac9fdec2a6ad1358f3d9d31c

Could Java8 compatibility be restored?

Reproduction steps

Launch the IntellJ example in Iphone simulator

./gradlew launchIphoneSimulator

Configuration

Build Tools:

Versions:

Stacktrace

* What went wrong:
A problem occurred evaluating project ':robovm'.
> Could not create task ':robovm:launchIPhoneSimulator'.
   > Could not create task of type 'IPhoneSimulatorTask'.
      > Could not generate a decorated class for type IPhoneSimulatorTask.
         > org/robovm/compiler/log/Logger has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Thanks!!

guillerodriguez commented 7 months ago

At first glance there does not seem to be any Java 9 specific code in that commit, so I assume that there was no real need to move to Java 9 -- @dkimitsa ?

dkimitsa commented 7 months ago

hi, java9 is used to run RoboVM compiler as we use variables in try-with-resources in code. Don't see any reason to stay on J8 when its about compiler itself . More over there is a plan to upgrade to Java16 as there is a need in Unix Domain Sockets for USBMUX.

@avazquezdev you can probably patch sources yourself by workarounding j8 incompatible moments and build it locally.

guillerodriguez commented 7 months ago

Don't see any reason to stay on J8 when its about compiler itself .

The problem is that it is not only about the compiler itsefl.

The fact that the Logger class is compiled with Java9 also means that it is not possible to run an app using the launchIPhoneSimulator task unless the app is also compiled with Java9 (see stack trace in original post)

dkimitsa commented 7 months ago

@guillerodriguez its about org/robovm/compiler/log/Logger -- its just a first file that it was not able to load as it was in java9 .class file. its part of RoboVM compiler and not about iOS application being compiled by robovm. its about version of Java on host to run RoboVM itself.

guillerodriguez commented 7 months ago

@dkimitsa

Yes, I know that Logger is part of the compiler and not part of the application being compiled.

But if you were using Java8 on the host, things that worked fine until RoboVM 2.3.19 now suddenly break with RoboVM 2.3.20.

So that means you must either use a separate JDK for compiling the app vs running RoboVM, or you need to switch to Java9+ for both.

That's why I say that the switch to Java9 is not something "internal" to the compiler. It also affects users of the compiler who are now forced to use Java9 (which was not necessary until 2.3.19).

dkimitsa commented 7 months ago

that's sad part of it. I believe it's new minimal requirement today. same things with 2yo Xcode or Idea -- you will not be able to use 2.3.20 with it. recent releases are intended to support modern versions of environment as first thing.

Tom-Ski commented 7 months ago

What is the issue with upgrading jdk on the host @avazquezdev ? You still will be able to use java 8 as your target in your application

avazquezdev commented 7 months ago

What is the issue with upgrading jdk on the host @avazquezdev ? You still will be able to use java 8 as your target in your application

In my company, all members of the team use OpenJDK8 for multiple applications, and changing to a different version always poses risks.

dkimitsa commented 7 months ago

@avazquezdev you always can have several JDKs installed and switch between them when required. also, how do you build for Android (in case you do). As it requires JDK17 for some time already

guillerodriguez commented 7 months ago

@dkimitsa

@avazquezdev you always can have several JDKs installed and switch between them when required.

Not sure how this addresses the "changing to a different version always poses risks" concern...

avazquezdev commented 7 months ago

@dkimitsa

@avazquezdev you always can have several JDKs installed and switch between them when required.

Not sure how this addresses the "changing to a different version always poses risks" concern...

Yes.

@avazquezdev you always can have several JDKs installed and switch between them when required. also, how do you build for Android (in case you do). As it requires JDK17 for some time already

I understand your point of view, but the change of version is not something I can decide on my own. To persuade my boss and colleagues to make changes, I must present them with solid arguments. According to recent surveys, Java 8 remains one of the most popular versions used by developers and as I said before, there are always risks when upgrading to new versions. For Android, we are using the latest Android Gradle Plugin that is compatible with Java 8 (version 4.2.0)

obigu commented 7 months ago

For Android, we are using the latest Android Gradle Plugin that is compatible with Java 8 (version 4.2.0)

AGP is currently on version 8.1.4 iirc and requires Java 17 to run. May be time to update.

dkimitsa commented 7 months ago

For Android, we are using the latest Android Gradle Plugin that is compatible with Java 8 (version 4.2.0)

you can do same thing here and stay on 2.3.19. the best option for you might be to fork repo and adapt changes that up to your setup and use local adapted version of compiler.

as I pointed -- there are high chances that we jump to Java16 due requirement to support Unix Domain Sockets. And supporting back J8 in this case makes no sense.

avazquezdev commented 7 months ago

as I pointed -- there are high chances that we jump to Java16 due requirement to support Unix Domain Sockets. And supporting back J8 in this case makes no sense.

Perfect, no problem. Thanks for the clarifications.