JDK 11 with OpenSAML v4

423 views
Skip to first unread message

Misagh

unread,
Mar 10, 2020, 9:46:04 AM3/10/20
to pac4j-dev
OpenSAML v4 has been released; It specifically requires JDK 11 at
build-time, which makes it problematic/impossible for pac4j-saml to
use since its based on JDK 8. Now that we are working on a major
release of pac4j, it's the perfect time to consider switching the
platform requirement to JDK 11, as we likely won't be able to do so
until pac4j v5. It's important to that we consider this now, given
open-saml is a critical component for pac4j and its SAML support and
its maintenance policy for bug fixes and patches likely will be based
on the v4 line going forward.

So, could we consider JDK 11 for pac4j v4?

--
- Misagh

Jérôme LELEU

unread,
Mar 10, 2020, 11:33:18 AM3/10/20
to Misagh, pac4j-dev
Hi,

Yes, I saw that.

I'm reluctant to upgrade pac4j 4 to JDK 11 as I fear that most users still use Java 8: https://www.jetbrains.com/lp/devecosystem-2019/java/
That said, I understand your concern as pac4j v5 is far far away.

The impact is huge as it means that all pac4j implementations will also need to upgrade to JDK 11.

I'm trying to think of a good compromise: release a JDK 8 pac4j v4 and a few weeks after (time to fix bugs), release a JDK 11 pac4j v5?

Thanks.
Best regards,
Jérôme


--
You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAGSBKken%3Db6AJtaypNv-_E7PBUCj3Zg9vyGQEMWw5yH0CgnSVQ%40mail.gmail.com.

Incerto

unread,
Mar 10, 2020, 11:44:32 AM3/10/20
to Pac4j development mailing list
Hi,

I wouldn't break the JDK 8 support. Many applications (mine included) see JDK 11 just as another intermediate release to JDK 17 (which will have all the meaty features).

I guess the alternative for applications like mine would be not to upgrade.

Misagh

unread,
Mar 10, 2020, 11:46:23 AM3/10/20
to pac4j-dev
That would be a good route, sure. We can keep both v4 and v5 as active
release lines until we decide to discontinue v4. Doing this under a v5
is also a good idea because the upgrade to opensaml v4 is non-trivial
and is best done under a major release.

Thanks!
--
- Misagh

Jérôme LELEU

unread,
Mar 10, 2020, 1:31:11 PM3/10/20
to Misagh, pac4j-dev

Jérôme LELEU

unread,
Mar 26, 2020, 12:35:15 PM3/26/20
to Pac4j development mailing list
The study I was looking for: https://blog.newrelic.com/technology/state-of-java/

JDK11: 11% vs JDK8: 85%
>> To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+unsubscribe@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAGSBKken%3Db6AJtaypNv-_E7PBUCj3Zg9vyGQEMWw5yH0CgnSVQ%40mail.gmail.com.



--
- Misagh

--
You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+unsubscribe@googlegroups.com.

Misagh

unread,
Mar 27, 2020, 4:10:48 AM3/27/20
to Pac4j development mailing list
Interesting.

Of course, I feel like this is a bit of a chicken-and-egg problem too.
Frameworks/libraries won't force applications to use JDK 11 in fear of
losing users who're reluctant to make a change because "why the extra
work? works just fine now". Users won't switch, unless they absolutely
have to as mandated by a framework/library...and so on :)

For example in this case, if open-saml had continued to baseline
against JDK 8 we likely wouldn't have had this conversation for quite
some time :) We are only motivated to make a change, usually, if it's
by force in absence of all other comfortable options. otherwise, "dont
fix it if it ain't broke" sort of thing which is a reasonable thing to
do anyway.
>>> >> To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+...@googlegroups.com.
>>> >> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAGSBKken%3Db6AJtaypNv-_E7PBUCj3Zg9vyGQEMWw5yH0CgnSVQ%40mail.gmail.com.
>>>
>>>
>>>
>>> --
>>> - Misagh
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/29ca9cde-2955-4965-bcc4-1bc37535757e%40googlegroups.com.



--
- Misagh

Jérôme LELEU

unread,
Mar 27, 2020, 4:17:05 AM3/27/20
to Misagh, Pac4j development mailing list
Yes.

Opensaml is a bit harsh on this: upgrade to JDK11 if you want to use version 4.

Our solution (pac4j v4 / v5) is smoother as we'll foster the upgrade by moving our efforts more and more to v5...



Emond Papegaaij

unread,
Mar 27, 2020, 5:48:21 AM3/27/20
to Pac4j development mailing list
Maybe it's worth considering supporting both OpenSAML 3 and 4 in pac4j v4? You can make 2 submodules: pac4j-saml-v3 and pac4j-saml-v4. The first will work with JDK8 and OpenSAML 3.x, the second will require JDK11 and use OpenSAML 4.x. It does require some configuration to setup a dual-JDK build, but it is doable. This is best done with toolchains so you actually compile with the correct JDK. This way, there is no need to keep 2 supported versions of pac4j for a longer time, only the saml code is duplicated.

Best regards,
Emond
>>> >> To unsubscribe from this group and stop receiving emails from it, send an email to pac4...@googlegroups.com.

>>> >> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAGSBKken%3Db6AJtaypNv-_E7PBUCj3Zg9vyGQEMWw5yH0CgnSVQ%40mail.gmail.com.
>>>
>>>
>>>
>>> --
>>> - Misagh
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to pac4...@googlegroups.com.

>>> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAGSBKkdMa69ZTA8hDAC4zL-j-GxtgYiBEcNAMLuFsOKfME%3Dj2Q%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pac4...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/29ca9cde-2955-4965-bcc4-1bc37535757e%40googlegroups.com.



--
- Misagh

--
You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4...@googlegroups.com.

Jérôme LELEU

unread,
Mar 27, 2020, 6:17:23 AM3/27/20
to Emond Papegaaij, Pac4j development mailing list
Hi,

I like this option: we could have a new pac4j-saml-jdk11 or pac4j-saml-opensaml4 module compiled for Java 11 (or rename the old one to pac4j-saml-opensaml3), the rest would remain built for Java 8.

It would still foster the upgrade to JDK11 for those who want to use the latest pac4j-saml module and make things much easier for us, the pac4j contributors.

Misagh, what do you think?

Thanks.
Best regards,
Jérôme



To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/300c0077-7b0d-4a5e-82c3-94d81f74d21b%40googlegroups.com.

Misagh

unread,
Mar 27, 2020, 6:35:52 AM3/27/20
to Pac4j development mailing list
This will also be a good option. Some complications:

1. Can we allow one module in the source tree to build against JDK 11
while the rest builds against JDK 8? Maven build magic required?
2. Can we do the same thing with Travis CI? Any foreseen issues?

I have a pending local branch that has upgraded open-saml to v4. I
could push the new changes to a new module as proposed for v4 and keep
the old one in tact (and perhaps renamed to be more explicit).
> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAP279LxGj1B0LjV9zWwRkTcG78m0ZEj%3DrWmQnt5i3AukByZH2A%40mail.gmail.com.



--
- Misagh

Emond Papegaaij

unread,
Mar 27, 2020, 6:45:58 AM3/27/20
to Pac4j development mailing list
This will also be a good option. Some complications:

1. Can we allow one module in the source tree to build against JDK 11
while the rest builds against JDK 8? Maven build magic required?

With Maven Toolchains (http://maven.apache.org/plugins/maven-toolchains-plugin/) this should be possible. You will need to have both JDKs installed on your system and configured in your toolchain. It should also be possible to put this in a profile, so you can still build with only one JDK installed but do the releases with the correct JDKs.
 
2. Can we do the same thing with Travis CI? Any foreseen issues?

For Travis CI this can be a bit more difficult. AFAIK toolchain is not supported. You can use the JDK 11 build for travis or maybe use 2 builds, one with JDK8 with all but one module and one with JDK11.

Best regards,
Emond

Jérôme LELEU

unread,
Mar 27, 2020, 6:56:32 AM3/27/20
to Emond Papegaaij, Pac4j development mailing list
Hi,

We can simply build with JDK11, have this configuration globally:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>

and locally for the new module:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<release>11</release>
</configuration>
</plugin>

The best is to rename the current module as pac4j-saml-opensaml3 as it won't change anymore regarding the opensaml version.

I can handle that.

And have the new module simply named pac4j-saml.

Thanks.
Best regards,
Jérôme




--
You received this message because you are subscribed to the Google Groups "Pac4j development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-dev+...@googlegroups.com.

Misagh

unread,
Mar 27, 2020, 7:09:20 AM3/27/20
to Pac4j development mailing list
Sounds good, and I like the option of keeping the new module as
"pac4j-saml", since it will make my job/PR much easier to merge. So
let's do this :)
> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAP279LzcBCs0ssNQ%2B2RM2F9dgh-vHyRLf0skxiGkuLkQf-BsYw%40mail.gmail.com.



--
- Misagh

Jérôme LELEU

unread,
Mar 27, 2020, 7:32:40 AM3/27/20
to Misagh, Pac4j development mailing list

Misagh

unread,
Mar 27, 2020, 7:34:51 AM3/27/20
to Pac4j development mailing list
Thanks. I'll sync and push a PR based on OSv4 shortly.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-dev/CAP279LxM1iC9k0KSO_NJnC%3DPqkPUjr5Moa%2BbpAd7SxfymRN2Dw%40mail.gmail.com.



--
- Misagh

Misagh

unread,
Mar 31, 2020, 10:37:47 AM3/31/20
to Pac4j development mailing list
So I have tested the OS v4 changes in the latest pac4j snapshot both
as an IDP and an SP. Changes seem to work quite OK. Jérôme, do you
think you might able to cut the next RC for pac4j (and the spring-mvc)
so we can open this up more publicly for testing? I would prefer to
not reference snapshot versions of pac4j in deployments.
--
- Misagh

Jérôme LELEU

unread,
Mar 31, 2020, 11:05:41 AM3/31/20
to Misagh, Pac4j development mailing list
Hi,

Thanks for testing.

I will do some more tests with week and cut all releases (pac4j, buji-pac4j, spring-webmvc-pac4j, play-pac4j, jee-pac4j, spring-security-pac4j) next week.

Thanks.
Best regards,
Jérôme


Misagh

unread,
Mar 31, 2020, 11:56:08 AM3/31/20
to pac4j-dev
That's great. Thanks!
--
- Misagh

Jérôme LELEU

unread,
Apr 2, 2020, 2:20:05 AM4/2/20
to Misagh, pac4j-dev
Hi,

I'm done with my tests. I will start cutting the releases. It will take a few days.
Thanks.
Best regards,
Jérôme


Misagh

unread,
Apr 2, 2020, 2:23:26 AM4/2/20
to pac4j-dev
Sounds great. Merci beaucoup!

-- Misagh

Jérôme LELEU

unread,
Apr 6, 2020, 4:48:25 AM4/6/20
to Misagh, pac4j-dev
Hi,

Everything has been released, I will update the documentation and make the announcements in the next few days...
Thanks.
Best regards,
Jérôme


Reply all
Reply to author
Forward
0 new messages