Migrate usages of com.sun.tools.* to provided alternatives about scip-java HOT 6 CLOSED

I think we can close this issue for now. We use com.sun.source to access certain necessary APIs like com.sun.tools.javac.code.Symbol and com.sun.tools.javac.tree.JCTree. We can revisit this issue when we add support for more Java versions.

from scip-java.

Reopening issue as this is the reason for semanticdb-javac failing with java projects JDK9+ 😅 com.sun.tools.javac.code.Kinds is no longer an enum in JDK9+, with the enum being moved to being an inner class of it. These may further change down the line, so its best we move to supported APIs while we're here 🙂

As part of #90 I will migrate to supported public APIs.

@olafurpg I dont think this will conflict with anything youre working on currently, given youre doing build tool related work, but in the chance that it does, please do go ahead with whats there currently, and I will handle those changes if they arise

from scip-java.

Would it make sense to close this issue as a duplicate of #90? It's an implementation detail IMO if we migrate off com.sun.tools or if we refactor the code to handle the breaking changes. Judging by the compile errors, I suspect we can work around them with fairly minimal diffs.

from scip-java.

Ill take some time today to gather how we might approach this. Im leaving out multi-release JARs for now (the one sbt plugin only supports jdk9 😔 )

Having another look at this, theres at least one non-obvious change, here being one, where Scope.Entry has become private. Worst case we make it public with reflection (but I'd really rather not have to introduce that kinda workaround).
The aforementioned enum changing is perhaps a trickier one, we cant guard that with a runtime flag as it will fail compile time regardless of the jdk we use to compile.

Im personally leaning towards following through with the issue title, I feel itd be the least awkward (Id rather spend time cross-referencing the replacements than messing around with build tooling or version-specific magic), unless you feel strongly about this

from scip-java.

It would be great if we can implement the plugin with public APIs. That would be the best outcome so it's worth exploring.

leaving out multi-release JARs for now (the one sbt plugin only supports jdk9 😔 )

We can ignore multi-release jars for now, it's a future concern.

Worst case we make it public with reflection (but I'd really rather not have to introduce that kinda workaround).

Using setAccessible(true) via reflection would be a fine solution IMO, if it works. I recall that Java 11 is more restrictive with runtime reflection.

from scip-java.

Fixed in #91 🔥

from scip-java.