Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Drop Java 8 support and start using Java 11 only features #1287

Closed
3 tasks done
wborn opened this issue Dec 21, 2019 · 20 comments
Closed
3 tasks done

Drop Java 8 support and start using Java 11 only features #1287

wborn opened this issue Dec 21, 2019 · 20 comments
Milestone
3.0.0.M1

Comments

@wborn
Copy link
Member

wborn commented Dec 21, 2019 •
edited by kaikreuzer
Loading

Do you think we should already start using Java 11 only functionality in openhab-core 3.x and thus drop Java 8 support?

It would simplify builds and dependency management. But there is a very significant downside because there may not be a Java 11 JVM for all embedded platforms on which OHC is used.

Currently I don't have a very strong preference myself on this subject. Perhaps the other @openhab/add-ons-maintainers have a recollection of the criteria used for embracing Java 8 and dropping Java 7 support in openHAB?

There are now some WIP PRs for this change:

What still needs to be done is:

  • Adapt Jenkins build jobs to use Java 11
  • Update documentation, it would be better to prevent confusion and first make sure the website shows the "2.5" documentation instead of "latest" by default
  • Test the impact on a distro build with these changes. It would be nice to see that Xtext is still properly working
@kaikreuzer
Copy link
Member

I'd be all for it. The only thing that may hinder us is if there are still Java8 dependencies in any add-ons or the distro.
What is the state of openhab/openhab-distro#768? Is there still any open issue left?

@5iver
Copy link

5iver commented Dec 21, 2019

There may be a problem with this if we move to the new rule engine and promote Jython for use with scripted automation. Jython 2.7.2b2 is available in Maven Central, but I have not tested it with Java 11. However, I did find some issues testing it with Java 8... #1252. I also ran into issues when using 2.7.2b2 in the Jython bundle... #1253.

@wborn
Copy link
Member Author

wborn commented Dec 22, 2019

What is the state of openhab/openhab-distro#768?

  • The alarming illegal reflective access warnings I ran into have been suppressed by adding "add-opens"
  • The incompatbilities with RRD4J and MaryTTS have been resolved
  • There still is a critical issue when using nrjavaserial on Windows 10 because it will crash the JVM.
  • Recently I ran into some issues with the LIFX binding on Java 11 which I still need to further analyze. For some reason handling incoming packets using the NIO Selector behaved different. I think it has to do with some underlying implementation change so packets can no longer be casted to a certain type.

So there can also be similar issues with other add-ons where in the worst case native libraries crash the JVM and some Java code may need some tweaking for Java 11 compatibility.

I think a lot of this can be fixed before there is a final OH3.

@pfink
Copy link
Contributor

pfink commented Dec 23, 2019 •
edited
Loading

I also think it's definitely time to switch - also because we removed guava and need some of the API improvements to make things easier here and there. End of 2020, Java 8 JVM support will end for most users anyway.

@kaikreuzer kaikreuzer mentioned this issue Dec 23, 2019
Merged
@kaikreuzer
Copy link
Member

I think a lot of this can be fixed before there is a final OH3.

I'd agree. So it seems to make a lot of sense to move to Java11 right away for 3.x.
Especially considering that we want to remove usage of Apache Commons libs, allowing Java 11 syntax should be a good replacement in many situations.

@wborn
Copy link
Member Author

wborn commented Dec 28, 2019 •
edited
Loading

Another reason for moving to Java 11 together with OH3 is that the namespace change (#1290) will prevent issues when JARs compiled using Java 11 are used on Java 8 (OH2).

Can we continue with this @openhab/core-maintainers or do we want to wait for more input?

The next steps would be:

@Hilbrand
Copy link
Member

Add to that:

  • Updating documentation to refer to java 11 for OH 3 development.

@kaikreuzer
Copy link
Member

do we want to wait for more input?

I didn't hear anybody asking to keep Java 8, so imho no need to wait any longer.

@kaikreuzer kaikreuzer mentioned this issue Dec 29, 2019
Closed
@5iver
Copy link

5iver commented Dec 29, 2019

I didn't hear anybody asking to keep Java 8, so imho no need to wait any longer.

Jython scripts used in scripted automation will break. Jython support for Java 11 was introduced with 2.7.1, but there are currently issues when using anything other than 2.7.0. I haven't checked the most recent builds of 2.7.2.

#1287 (comment)

If we are moving over to the new rule engine and focusing on Jython, then moving to Java 11 throws a wrench into things.

@wborn wborn mentioned this issue Dec 29, 2019
Merged
@J-N-K
Copy link
Member

J-N-K commented Dec 29, 2019

For me the issue raised by @openhab-5iver is a show-stopper.

@kaikreuzer
Copy link
Member

It might be a show-stopper for Jython scripts, but not for Java 11. We cannot say that we can't support Java 11 by the end of 2020...

@J-N-K
Copy link
Member

J-N-K commented Dec 29, 2019

Jython is probably the most used scripting engine for the new rule engine.

@Hilbrand
Copy link
Member

Since we're changing things anyway. Can't we adopt Graal instead of Nashorn or is that not yet feasible? There is a pr to add Graal as add-on. So some work has already been done. Is something to consider to use Graal?

@5iver
Copy link

5iver commented Dec 29, 2019

We cannot say that we can't support Java 11 by the end of 2020...

Agreed, but if there is no rush, I'd like to at least get the answers needed to move #1253 forward while Jython still works with OH! I have not tested a recent build of Jython, but I'll go take a look now. The one issue may already be resolved, but it looked like we did something else in core that also caused some problems.

Is something to consider to use Graal?

IMO, GraalVM is definitely something to consider in the future, but it will be a while before the graal languages, like graalpython, will be mature enough. Graaljs is the most advanced and it also includes a legacy javax.script.ScriptEngineFactory, which is what is used in the PR that you mention. Unfortunately, none of the other graal languages have included these yet, but I've considered working on one for graalpython.

This was referenced Dec 29, 2019
Merged
Merged
Merged
Merged
Merged
@wborn
Copy link
Member Author

wborn commented Dec 30, 2019 •
edited
Loading

As you may have noticed I've created a couple of PRs for this and updated the first post with links to all of them and a small to do list.

@wborn wborn self-assigned this Dec 30, 2019
@wborn wborn mentioned this issue Jan 2, 2020
Merged
@wborn
Copy link
Member Author

wborn commented Jan 4, 2020

I've finished and tested my changes so these are ready to be merged.

There are only 2 remaining items:

  • Use Java 11 with applicable build jobs on Jenkins
    Can you help with this @kaikreuzer? I don't know how it is all setup and don't have access to everything.
  • Update documentation
    After we discussed this the best way may be to create issues for documentation that needs to be fixed/updated for OH3 in the openhab-docs issue tracker. Then we can track them and fix them when all development is shifted towards OH3 (2020Q3). IMHO it doesn't make sense to create OH3 documentation PRs now if they aren't merged. They will only pollute PR lists and collect merge conflicts.

@wborn wborn mentioned this issue Jan 4, 2020
Merged
@kaikreuzer
Copy link
Member

kaikreuzer commented Jan 10, 2020 •
edited
Loading

Hey @wborn, sorry for the delayed answer, it has been a busy week...

Can you help with this @kaikreuzer? I don't know how it is all setup and don't have access to everything.

You are admin on Jenkins, so I would claim you have access to everything.
But no worries, I have now added OpenJDK11 as a Java option and changed https://ci.openhab.org/view/Pull%20Request%20Builds/job/PR-openHAB-Core for a start to use it - will do the same for the other master build plans, once it works and your PRs are merged.

Update documentation

Hm, I so far thought that we should start right away with working on OH3 docs as there'll be a lot that needs to be changed (due to new UI, rules, etc.). But I see your point about merge conflicts with 2.5.x updates and we are probably not keen on having to manually resolve a lot of them.

So yes, maybe we should do it similarly to the code repos: Only start working on OH3 docs in summer, when the 2.5.x docs should be more or less final. By then, we should also have some stability wrt the new UI so that screenshots might make sense then.

Entering issues in openhab-docs for things to change makes sense.

@Confectrician Wdyt? Does @wborn's suggestion make sense to you?

@kaikreuzer
Copy link
Member

so these are ready to be merged.

I'd suggest to go ahead and merge them. If there are issues with Jython on Java 11, we can still sort them out. We do not need a working distro with scripting right now as we anyhow have work in progress on UI, persistence and other topics.

@wborn
Copy link
Member Author

wborn commented Jan 11, 2020

will do the same for the other master build plans

I can help updating the other builds similarly. The only issue might be that the 2.5.x PR builds would then also start building code with Java 11. Which may give issues when users download Java 11 artifacts from the build server or the 2.5.x PR repo (also commonly used by Eclipse IoT marketplace add-ons).

Do you also want to create additional 2.5.x PR builds that use Java 8? It will probably require additional webhooks. Another approach could be to keep the existing PR jobs but configure the compiler to cross compile to Java 8 on the 2.5.x branches (see: https://www.baeldung.com/maven-java-version#java9).

@kaikreuzer
Copy link
Member

Do you also want to create additional 2.5.x PR builds that use Java 8?

Yes, this probably makes sense. We should keep the current ones for 2.5.x and create new ones for master that use Java 11.

@wborn wborn removed their assignment Aug 26, 2020
@wborn wborn added this to the 3.0 milestone Oct 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
3.0.0.M1
Development

No branches or pull requests
6 participants
@Hilbrand @kaikreuzer @J-N-K @pfink @wborn @5iver