Subclipse fails on java 17

[patric-r]

Subclipse fails on Java 17 - any chance to get a new release soon?
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=576745

java.lang.reflect.InaccessibleObjectException: Unable to make field private java.lang.Throwable java.lang.Throwable.cause accessible: module java.base does not "opens java.lang" to unnamed module @371030b
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
	at org.tmatesoft.svn.core.javahl17.SVNClientImpl.getClientException(SVNClientImpl.java:1543)
	at org.tmatesoft.svn.core.javahl17.SVNClientImpl.status(SVNClientImpl.java:164)
	at org.tmatesoft.svn.core.javahl17.SVNClientImpl.status(SVNClientImpl.java:136)
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:584)
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:564)
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:557)
	at org.tigris.subversion.svnclientadapter.svnkit.SvnKitClientAdapter.getStatus(SvnKitClientAdapter.java:107)
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:550)
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:543)
	at org.tigris.subversion.subclipse.core.status.NonRecursiveStatusUpdateStrategy.statusesToUpdate(NonRecursiveStatusUpdateStrategy.java:56)
	at org.tigris.subversion.subclipse.core.status.StatusCacheManager.refreshStatus(StatusCacheManager.java:301)
	at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.refreshStatus(FileModificationManager.java:265)
	at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.access$2(FileModificationManager.java:256)
	at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager$2.run(FileModificationManager.java:210)
	at org.tigris.subversion.subclipse.core.util.JobUtility$1$1.run(JobUtility.java:29)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2405)
	at org.tigris.subversion.subclipse.core.util.JobUtility$1.run(JobUtility.java:26)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

[markphip]

That is with SVNKit library, not Subclipse. I feel like that happened ever since modules were introduced but we do not get asked about it much so maybe not. I definitely feel like the general error has been reported before. I assume there is some generic solution with JVM settings.

This project is alive in name only at this point. I do not believe SVNKit has been very responsive the last several years either but they did put out a new release recently and someone mentioned if you download and install it via the archive it works: https://svnkit.com/download.php

[patric-r]

Right, it's svnkit. According to the svnkit changelog at https://svnkit.com/download.php, it has been fixed in svnkit 1,10.4.
Up to java 16, there was an jvm argument to circumvent this problem but for java 17 this option has been removed.

Would you mind doing another release for subclipse (I saw that master is ahead of more than 50 commits) with an up to date svnkit? Thanks.

[patric-r]

@markphip any updates on this?
If you don't plan any further updates of subclipse I would consider it fair to the community to explicitly state that, thanks.

[markphip]

Subclipse itself does not need a new release (there is nothing to release). I assume you are asking me to update SVNKit. It is more work than it sounds like it ought to be and I do not have the time to do all of the testing it would require. It is not SVNKit that I would need to test it is publishing the update site and making sure it is working. Not to mention all of the time it would take just to remember how I do it. But there are always weird things going on with their metadata I need to fix manually to get it right.

The main issue is that for some reason SVNKit maintains an update site but it has never worked and they never fix it. I sent them information on how to do it years ago. If their site just worked, I would just be able to reference it from our site and we would never have to worry about this.

As it stands, you need to download their zipped archive and do the install from that.

[kjsmita6]

Their update site DOES work btw, http://eclipse.svnkit.com/1.10.x. You can't use it in the browser but it does show artifacts in Eclipse.

I don't know much about how Subclipse works and how it interfaces with svnkit/javahl, but from looking at things it looks like:

1. Update the version of svnkit-javahl16 here https://github.com/subclipse/svnclientadapter/blob/master/svnkit/pom.xml#L35 and make a new release of this client adapter.
2. Check-in the new jar and update it here https://github.com/subclipse/subclipse/blob/master/bundles/svnapi.svnkit/META-INF/MANIFEST.MF#L14 and make a new release.

There might be some other versions scattered around, but this seems like it could do it. If it requires more than this, please let me know and I can see if I can find the time to contribute. SVNkit 1.10.4 (that supposedly fixes this) was released over a year ago so it would be nice if this was fixed here as well. This error, while not happening all the time, is super annoying when sometimes it gets spammed if you have many projects.

---

Note: Why are you checking in jars and referencing them using Bundle-Classpath? This is probably not good practice and you would be much better off doing it properly with a target definition file (since you are already using Tycho). I imagine it would be much easier to update things in the future this way. Also, I just noticed the p2 repository being used is still Juno. https://github.com/subclipse/subclipse/blob/master/releng/subclipse.configuration/pom.xml#L16 Time to upgrade?

I don't want to make a commit that basically changes everything (because it's not my project), but let me know if it would be helpful and I'll see if I can find any extra time.

[markphip]

If they are providing a working update site now then just use it to install their library. It has never required anything more than that. The issue is they have never published P2 metadata so it was not a valid P2 site and so the modern Eclipse installer will not pull from it and we have to republish our own version where we generate the metadata. Since no one works on this project anymore we are no longer doing that.

[kjsmita6]

"no one works on this project anymore"

If subclipse is no longer in development can you make some kind of announcement about that? It's important for people to know things like that.

[patric-r]

Thanks @kjsmita6 for your update and offer for help.
I fully agree.

@markphip
If subclipse is really dead / end of life / no new release will be done anymore
(which would be bad for many users, especially in non-public company projects),
please announce this officially so that everyone can adapt to reality instead of hoping for a new release.

[markphip]

Any OSS project relies on contributors. I managed this project and other than dealing with the release management and some work on SVNClientAdapter I have never been a core developer. You can see from the History that there have been barely any changes contributed in the last 10 years.

I no longer work at CollabNet so just do what I can as a volunteer to help shepherd the occasional PR we get as well as answer questions that I can but I moved to Git like most everyone else a very long time ago.

In terms of this issue though, this project has never been affiliated with SVNKit. We worked more closely with Subversion itself and therefore the native JavaHL library. Since SVNKit emulated the interface we have been willing to include the option to use it. We long ago made it so all you need is the latest version of their library (which is a separate plugin so can be installed separately). What has sucked is SVNKit has never posted a working P2 update site. If they did we could just reference their site from ours and Eclipse would handle it all seamlessly. Instead if we want to help users at all we have to repackage it and every time there are always several things that have to be manually fixed.

SVNKit seems to have stopped supporting SVNKit many years ago too (certainly they do not spend much time on it) and they just seem unwilling to post a valid update site. I gave them the simple instructions years ago.