try {
** svnCredentials =**
** SVNWCUtil.createDefaultAuthenticationManager().getFirstAuthentication(**
** ISVNAuthenticationManager.PASSWORD,**
** ‘<Collabnet_URL:443> Authorization Realm’,**
** SVNURL.parseURIEncoded( ‘Collabnet_URL’ ) )** } catch ( SVNAuthenticationException e ) {
** throw new Exception( “Your credentials must have been saved in SVN. Please, connect with TortoiseSVN and check ‘Save authentication’”, e )** }
But i always end up with the exception:
“Your credentials must have been saved in SVN. Please, connect with TortoiseSVN and check 'Save authentication”… Altough i saved the credentials locally
After i try to run a debug session using the full svnkit, i get the following: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.tmatesoft.svn.core.internal.util.SVNSocketFactory (file:/J:/org.tmatesoft.svn_1.10.1.standalone/svnkit-1.10.1/lib/svnkit-1.10.1.jar) to method sun.security.ssl.SSLSocketImpl.setHost(java.lang.String) WARNING: Please consider reporting this to the maintainers of org.tmatesoft.svn.core.internal.util.SVNSocketFactory 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 same code runs with the java8 with svnkit 1.10.1 but with java11 it’s throws the exception. Can you please be so kind and suggest a solution for this problem?
As you may see, the reason for the warning is “reflective access” used to call SSLSocket.setHost(String) method. This method is internal and may be present in some JDK version, but not in the others.
SSLSocketImpl.setHost method is called to workaround a bug in JDK that otherwise fails to set target host name as part of SSL client handshake (this feature is called SNI - server name identification).
For more information check these links:
Of course, we would like to avoid calling this internal method, but unfortunately it is required, as otherwise SNI SSL feature would not work with certain versions of JDK.
When method is not present, method call will fail, but socket creation will proceed without an error as all exception are caught at the call site.
I think you may hide the warning and allow reflective access by adding the following JVM option:
According to the articles you linked, this seems like a problem with Java 8 before 8u141, which was released in 2016Q2.
The illegal access you’re using will go away and was made illegal for good reasons, AFAICT.
I’d like to see a fix that only makes the J9+ illegal call if it’s needed, i.e. if it has either failed in the way that indicates that it’s needed or (if that’s not possible to detect), which detects the versions of J8 with the issue and uses a code branch with the illegal access.
Hi, co-incidentally we are just moving to Java 11, and have found this warning too. Looking at the code it seems like there has been some work done in the _createSSLSocket method, but I guess thats not the one causing the warning?
All seems to be working ok for now, but as @BadHorseMonkey said, maybe if the java version is greater than 8 the call can be not made (I’m not clear if the call can just be skipped now that the JVM issue is resolved)?