Check and Reduce uses of Internal APIs and Reflection

[cdietrich]

We should Check and Reduce uses of Internal APIs e.g. in JDT and others. Same for the use of reflective api e.g. in JavaBuildState Discuss with the JDT guys what can be done better or if for certain stuff apis could be introduced.

[cdietrich]

https://github.com/eclipse/xtext-eclipse/issues/530

[cdietrich]

#!/bin/bash
grep -ril "import org.eclipse.jdt.internal" . | grep -v "/target/" | grep -v "/bin/" | grep -v "/build" | grep -v "/repository/"
grep -ril "org.eclipse.jface.internal" . | grep -v "/target/" | grep -v "/bin/" | grep -v "/build" | grep -v "/repository/"
grep -ril "org.eclipse.team.internal" . | grep -v "/target/" | grep -v "/bin/" | grep -v "/build" | grep -v "/repository/"
grep -ril "org.eclipse.ui.internal" . | grep -v "/target/" | grep -v "/bin/" | grep -v "/build" | grep -v "/repository/"
grep -ril "org.eclipse.core.internal" . | grep -v "/target/" | grep -v "/bin/" | grep -v "/build" | grep -v "/repository/"
grep -ril "org.eclipse.debug.internal" . | grep -v "/target/" | grep -v "/bin/" | grep -v "/build" | grep -v "/repository/"

[kthoms]

How about org.eclipse.jdt.internal.core.DefaultWorkingCopyOwner? Could we make a copy of it? The docs of WorkingCopyOwner state that clients should subclass it.

[cdietrich]

no we actually use it to hook into jdts search. that is a point where they should offer a factory/api see eclipse/xtext#2389

[kthoms]

Maybe a static WorkingCopyOwner#getDefault/getPrimary method?

[cdietrich]

or a constant/method at javacore

[cdietrich]

see eclipse/xtext#2411 as well. maybe we should maintain the internal/xfriends for xtext itself so we can set second party usages of internal api to warning

org.eclipse.jdt.core.compiler.problem.discouragedReference=warning

[cdietrich]

maintained x-friends for xtext 2 xtext dependencies with https://github.com/eclipse/xtext/issues/1173

[mehmet-karaman]

@cdietrich anything to do in this issue? I am currently checking internal API usages/reflection and I am trying to find out if there are still references to old eclipse platform version which xtext isn't supporting anymore.

[cdietrich]

we still have a gazillion uses of platform and jdt api. (see the warnings in the workspace) minimal eclipse version we support / test against is 202203

for jdt we were thinking about creating a facade project

with the move to java 17 / full support of j21 we will move to a newer minimal platform but i currently dont have cappa to work on that.

maybe @szarnekow / @LorenzoBettini have

we also considered to introduce a jdt facade project so that the usages are consolidated into one project @LorenzoBettini do we have a ticket for that

[LorenzoBettini]

@cdietrich yes, I had already created the ticket https://github.com/eclipse/xtext/issues/3129 and was planning to start working on that ASAP.

Concerning the move to Java 17 and move to a new minimal jdt version I'm willing to take care of that, but I'd need to know whether we agree to do the move.

[cdietrich]

@szarnekow wanted to check What his q4 Cappa is Unfortunately mine is towards zero

we agreed in the call this week we want to move The question is when

and to what version My proposal is to use the newest That is Java 21 free Which is 2024-03 If I am correct

[mehmet-karaman]

Thank you. I guess i understood it wrong.. My task was to just get rid of the reflection (and/or replace them by regular calls) of older and not supported platforms. So I will check the target platform for minimal version and identify the reflections and internal usages and adjust these.

[cdietrich]

The problem is platform api that is not api