Illegal reflective access by com.sun.mail.util.SocketFetcher

[oliviercailloux]

Connecting to a store while running on OpenJDK 11 produces the following warning.

WARNING: An illegal reflective access operation has occurred`
WARNING: Illegal reflective access by com.sun.mail.util.SocketFetcher (file:/home/olivier/.m2/repository/com/sun/mail/mailapi/1.6.3/mailapi-1.6.3.jar) to method sun.security.util.HostnameChecker.getInstance(byte)
WARNING: Please consider reporting this to the maintainers of com.sun.mail.util.SocketFetcher
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

The problem seems to lie in SocketFetcher#matchCert.

I can provide a detailed test case to reproduce the problem, but I suppose it is not necessary, as the source of the problem seems clear.

[KevinAtSesam]

Can confirm. Issue occurs using JDK 11 and Jakarta Mail 1.6.5

WARNING: Illegal reflective access by com.sun.mail.util.SocketFetcher (file:/home/kevin/.var/app/com.jetbrains.IntelliJ-IDEA-Community/cache/coursier/v1/https/repo1.maven.org/maven2/com/sun/mail/jakarta.mail/1.6.5/jakarta.mail-1.6.5.jar) to method sun.security.util.HostnameChecker.match(java.lang.String,java.security.cert.X509Certificate)

[DenWav]

This can temporarily be suppressed by adding either:

• --add-opens 'java.base/sun.security.util=ALL-UNNAMED' if you are using a single shaded jar
• --add-opens 'java.base/sun.security.util=jakarta.mail' if you're using separate jars

to your JVM args.

[oliviercailloux]

Is there a programmatic equivalent?

[DenWav]

No, it must be a command line option.

[Xset-s]

Any updates?

[maffe]

As access to the JDK method will be denied in the future and there already is an alternative implementation below the call of the JDK method, the obvious solution would be the removal of the JDK method call. I am not going to create that simple pull request because I don’t want to create an Eclipse account.

[KevinAtSesam]

Damn. 2.0.0-RC6 still has this issue. The one moment when this would be trivial to fix, and they missed it.

[Maninda]

Observed this warning even in Jakartha Mail 2.0.1 as well. WARNING: Illegal reflective access by com.sun.mail.util.SocketFetcher (file:/home/computer/j/java11/platform/java11/jakarta.mail-2.0.1.jar) to method sun.security.util.HostnameChecker.getInstance(byte)

[poyrazus]

Still no progress on this?

[patrick-rosendaal]

There is a PR in the new angus-mail repo that looks promising: #https://github.com/eclipse-ee4j/angus-mail/pull/11

[jmehrens]

Note that this is being fixed in Angus Mail under https://github.com/eclipse-ee4j/angus-mail/issues/124

Also note that since the split of the implementation from the API the SocketFetcher moved from module jakarta.mail to org.eclipse.angus.mail. This means that workaround when using mail-api with Angus Mail as the implementation is:

--add-opens 'java.base/sun.security.util=org.eclipse.angus.mail'

[jmehrens]

This has been fixed in Augus Mail 2.0.3 under https://github.com/eclipse-ee4j/angus-mail/issues/124#issuecomment-1946903451

Existing Angus Mail configurations that are using mail.<protocol>.ssl.checkserveridentity=true will opt-in to the new way of having the SSL API perform the hostname validations and opt-out of doing the Angus Mail hostname validations. Illegal reflective access messages are removed by default. Read the COMPAT.txt in Angus Mail for more details. If you are using a custom SSLSocketFactory or custom TrustManager then you need to evaluate your session property entries to ensure hostname is validated.

I'll keep this ticket open to use as a backport to v1.x