Make Pi4J JDK 11 compatible

[thegreystone]

Either branch a new major version of Pi4J that only supports JDK 11+ (I guess technically JDK 9+, but since 11 is the next LTS, that will be the version people care about), or reflectively access things like sun.misc.SharedSecrets vs. jdk.internal.misc.SharedSecrets.

I'd be happy to help.

[savageautomate]

Agreed. This will be targeted in version 2.0. We will start a new branch for 2.0 soon.

[thegreystone]

Very good. The biggest decision will be whether or not to go all-in JDK 11 or not. By all-in I mean modules, and using the JDK 11 APIs exclusively (no reflective access, tunneling or proxying to bind to the right version of a sun.misc class etc). I just started a branch in the Robo4J fork where I’m planning on going all in. That is the thing Miro was referring to in the other issue.

[savageautomate]

I would prefer to get rid of any reflective access, etc. moving forward. If you want to help with this effort, I can add you to the developers list.

[thegreystone]

Sure, would be happy to help. I am currently designing a version 2 of Coff-E (my robot), so will have to get this up and running anyways (Robo4J now require JDK Flight Recorder, open sourced in JDK 11). When are you planning on setting up the 2.0 branch?

[savageautomate]

Soon. Working to get 1.2 out the door first. So probably next week.

[savageautomate]

I also want to see about changing the open source license for the project in V2. We had to comply with the GPL license in previous versions and force the project to inherit the GPL license because we were compiling/linking in the WiringPi project. As of 1.2 we are not longer statically linking against WiringPi and in V2 we will drop support for the other platforms that may still have static linking against WiringPi platform derivatives.

[thegreystone]

Excellent! I will be traveling the next two weeks, but will bring a pi with me to have something to do in the weekends. I’ve ordered an ydlidar G4 and some other fun stuff that I’ll pick up when in the US. :)

[savageautomate]

2.0 branch created:
https://github.com/Pi4J/pi4j/tree/develop/2.0

Untested at this point, but I have started removing parts of the project we no longer intend on maintaining/supporting.

[thegreystone]

Excellent! Do you want me to work directly in the branch, or do you want me to fork and do PRs?

[savageautomate]

@thegreystone

What do you think is best/most efficient? I'm open to working directly in the branch until we get a 2.0 release. That way there is not a single gatekeeper. However, we probably need a means for collaborative communication on v2.0 project efforts. Any suggestions? I was thinking of maybe using a private forum, but maybe some project management app like Basecamp would be better?

[thegreystone]

We're using Slack in some other projects, and it seems to be working fairly well. Problem with slack is that the history is limited, and the illusion of persistence is just that - an illusion. OpenTracing is using Gitter. Not sure what the Gitter policy is in terms of persistence. Never tried Basecamp myself. Mailinglists are used as the primary channel for "offical" communication in OpenJDK, and IRC for more informal discussions. For JMC there is a slack workspace as well.

[thegreystone]

Is there, by any chance, a Pi4J slack available? Otherwise I could set one up, and we could start there and see how it works for us?

[savageautomate]

@thegreystone

I have actually already started setting up a forum. I wanted a tool that can handle a bit more organizational structure/support, provide open access for non-registered users and also serve as a replacement for the current Pi4J Google Groups moving forward. Let's try it out and see how it works for us. You can register here and optionally use your GitHub account to login. Pi4J Community Forum

[thegreystone]

Excellent!

[thegreystone]

I tried creating a new topic under 2.0, but I don't think I have the rights required.

Wanted to check if you'd be interested in doing a talk together at CodeOne 2019 around running Java 11 on the RaspberryPi. :)

[savageautomate]

@thegreystone

I put your account in the "Contributors" group after you registered. That group should have access to create new topics under 2.0. I wonder if you have to logout and re-login to get the updated permissions applied?

Sure, I would be interested in a talk. I have given talks about Pi4J at JavaOne and Devoxx in the past. Let chat more on the forum. There is also a "Chat" feature in the forum similar to private messaging.

[thegreystone]

Hm. Still can't post. Tried from both Safari and Chrome. Chatting seems to work though (at least I seem to be able to send messages).

[pg-adm1n]

@savageautomate
I had check the 2.0 branch, for REMOVE JDK INTERNAL REFS I think we can use a JDK tool call jdeps, It will show which code is internal ref, and what can replace it.
Thanks.

[thegreystone]

We're running on JDK 11 in the Pi4J fork at Robo4J. But there is still much to do.

https://github.com/Robo4J/pi4j

[thegreystone]

I'll get the first few changes over into the repo this weekend.

[savageautomate]

I've got some radical (API breaking) changes planned for the API in v2. Do you think its best to start with the existing codebase (what's currently in the develop/2.0 branch) or basically start with a clean slate.

[eitch]

Maybe starting with a clean slate can be a really good idea, that is if you want to go all-in with modules, which will make a lot of changes in the code anyhow.

[FDelporte]

I'm working on a blog "series" of Java 11 on PI (see https://webtechie.be/index.php). My next planned step was having a working compiled Java application toggling a led (https://github.com/FDelporte/PiJavaGPIO), with the final goal to have some kind of dashboard application using TilesFX (https://github.com/FDelporte/PiJava). As I was failing with the LED step, I ended up here in this issue.

Anything I can do to help with the JDK 11 "jump"?

[savageautomate]

@FDelporte

The following source branch is compiling using JDK11, however, I don't think much (or any) testing has been done. https://github.com/Pi4J/pi4j/tree/develop/1.4

Snapshot builds can't also be downloaded from the SNAPSHOT repository or from here:
https://pi4j.com/1.4/download.html

Please be aware that major changes (improvements) including API changes are slated for Version 2, so you may have to update the blog article from time to time as things change.

Any help is welcome -- especially in the hardware testing department.

Thanks, Robert

[thegreystone]

I am all in favour of clean slate. I don't mind the 2.0 branch being totally broken for a while whilst getting everything in place.

[savageautomate]

I've been thinking more on this and wanted to get your opinions. Maybe v1.3 (current master branch) should be basic (read "minimal effort") support for JDK11 and version 2.0 should proceed with a clean slate as proposed and seemingly accepted.

This might allow for immediate/near term JDK11 support while Pi4J v2.0 is likely to take more time getting it all built out properly. V2.0 is likely to be highly unstable for some time.

Thanks, Robert

[d-f-clark]

The README's for 1.3-SNAPSHOT and 1.4-SNAPSHOT make no mention of the sun.misc.SharedSecrets issue with Open JDK 11, or reflectivity access in general. Rather than wasting time trying them I thought I'd ask the question here. Do either of these projects fix the sun.misc.SharedSecrets issue, and if so, are there plans to get either of these versions to release? Thank you

[eitch]

@d-f-clark i want to get 1.4 released, and will make sure it works on JDK 11+ and certainly 64-bit. I have been thinking of releasing it under my fork with a new groupId, since i don't have write access to this repository and @savageautomate seems to be currently indisposed.

[savageautomate]

Closing this open issue as the effort is underway. We (including @eitch ) are actively working on both v1.4 (https://github.com/Pi4J/pi4j/tree/develop/1.4) and v2.0 (https://github.com/Pi4J/pi4j-v2) which include support for the newer JDKs.

Thanks, Robert

[d-f-clark]

Is it typical to close an open issue simply because it’s being worked on? A typical software development lifecycle includes development of the solution, and testing, before an issue is closed.

[savageautomate]

@d-f-clark

You are right ... I got caught up in an effort closing tickets in this V1 repository that are getting addressed in V2 which is a separate repository (https://github.com/Pi4J/pi4j-v2). However, in this case, the ticket should remain open as there will be a V1.x release to allow compiling using JDK11.

Let me be clear ... v1.4 can be compiled using JDK11 but only v2.0 will truly be supported as an actual Java module (jigsaw).

[markko1]

Hello! I have tried to run 1.4 build on a Raspberry Zero, but I end up with an error from the native library. Is it because of 1.4 is meant for 64 bit and RPI Zero is 32 bit?
Sorry if it's not the right place to ask.

[eitch]

Hi, i am sorry, but i don't have a pi zero, so i can't test this and i don't know what architecture the pi zero is. If is 32 bit, then it should work, but you still need JDK11, and wiringpi must be installed in the 32bit version.

[markko1]

Thanks for the answer @eitch ! :)
Yep, Pi Zero is indeed 32 bit, I double checked. I am running Jdk 11 from Zulu which is a special build for ARMv6. It turned out that Zero is ARMv6 while most of the newer ones are ARMv8 (link).
I'm not sure if this architecture version plays any other role than picking the right JDK build, though. Because Java8 worked well.

I also have wiringpi installed. gpio -v output:

gpio version: 2.50
Copyright (c) 2012-2018 Gordon Henderson
This is free software with ABSOLUTELY NO WARRANTY.
For details type: gpio -warranty

Raspberry Pi Details:
  Type: Pi Zero, Revision: 03, Memory: 512MB, Maker: Sony
  * Device tree is enabled.
  *--> Raspberry Pi Zero Rev 1.3
  * This Raspberry Pi supports user-level GPIO access.

I started to wonder whether there can be a conflict between my version of wiringpi and the one compiled into PI4J? Not sure if a stupid idea, because I have no clue about how this native code linking works.

I could probably check this idea if I could build PI4J on my Raspberry? Unfortunately I do not know how to do that.
I have built PI4J from develop/1.4 branch using Docker image with instructions from here, but that did not work. This is what I got when running my application with 1.4: link to Github gist. com.jubla are my packages there :)

[markko1]

I was able to build Pi4J on my Pi Zero (branch develop/1.4) but unfortunately it made no difference.

[FDelporte]

For your info @markko1 , I never used a Zero before but your question triggered me to order one :-) will try to reproduce this problem when received

[markko1]

Hi @FDelporte :)
Did you manage to reproduce the problem?

[markko1]

I can confirm that current master (i.e. 1.4-SNAPSHOT) is working with Raspberry Zero as well!
Very happy now, thanks! :)

[FDelporte]

Thanks @markko1 for the feedback! Didn't manage to try out myself yet, so nice to have confirmed this issue is solved.