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.

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

Java 7 - no more direct support by the Eclipse CI #2229

Open
boaks opened this issue Mar 1, 2024 · 11 comments
Open

Java 7 - no more direct support by the Eclipse CI #2229

boaks opened this issue Mar 1, 2024 · 11 comments

Comments

@boaks
Copy link
Contributor

boaks commented Mar 1, 2024

Just to let all know:

Since yesterday, there is no more java 7 support for the CI Jenkins.
If java 7 would be required, that would need a special docker build image.
If using the compiler switch "-release" works, isn't known by me. In that past such similar approaches frequently failed for different reasons and therefore using a jdk 7 via the toolchain was the best option.
Anyway, I don't see, that I'm able to spend my time in overcome that. For Cf 4.0.0 the current plan is anyway to move to at least java 8. So, please try to check the nightly SNAPSHOT build, if that works for you and report, if you have some trouble.

@sbernard31
Copy link
Contributor

sbernard31 commented Mar 1, 2024

Just to be clear for Californium 2.x and 3.x you will use -release right ?

@boaks
Copy link
Contributor Author

boaks commented Mar 1, 2024

yes.

@sbernard31
Copy link
Contributor

sbernard31 commented Mar 1, 2024

At Leshan we use it for a while and nobody complain until now.
We also have a nightly build which builds with -release then execute tests with toolchains for minimal supported version + all Java LTS version above. E.g for Leshan 1.x, we execute tests with jdk toolchain 7, 8 , 11, 17, 21.

@boaks
Copy link
Contributor Author

boaks commented Mar 2, 2024

Not sure, if I remember it well, but java 8 introduces "covariant return types". Compiling code using java 8 API jars and just configure the compiler to generate java 7 classes failed then on that functions when executed with java 7.
I don't think, that java 7 is really still in use. And anyway, the next major release will not longer support java 7.

@boaks boaks pinned this issue Mar 3, 2024
@sbernard31
Copy link
Contributor

I think -release option aims to solve this kind of issue : https://bugs.openjdk.org/browse/JDK-8058150

@boaks
Copy link
Contributor Author

boaks commented Mar 4, 2024

One small downside:
Using --release doesn't work for toolchains targeting still java 8, because --release was introduced after java 8.
The build instructions need therefore also an update.

@sbernard31
Copy link
Contributor

I missed that because I moved to Java 11 for building when I migrate to --release.
At the same time there is more more maven plugin which require java 11 as minimal version so maybe not so bad to move to java 11 for maven build.

@boaks
Copy link
Contributor Author

boaks commented Mar 4, 2024

Currently only "actinium" fails without real "toolchain" (I guess it's more about using oracle java 8 there, than just java 8.)

@boaks
Copy link
Contributor Author

boaks commented Mar 4, 2024

using

<maven.compiler.release></maven.compiler.release>

and the toolchain with oracle java 8 does it for actinium.

So, I guess removing the toolchain for californium and californium.tools works,
And I don't plan to keep "actinium" in Cf 4.0, so I also don't care too much about it.

@boaks
Copy link
Contributor Author

boaks commented Mar 5, 2024

Learning from my side:
It is less work to support only builds with newer jdks and only support to run it with older ones using the -release option ;-).

@rogierc
Copy link
Contributor

rogierc commented Mar 10, 2024

Mule CoAP Connector requires java 8 support. No problem to drop java 7 support from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants