separation of rascal-jdt into an independent library project

[jurgenvinju]

this is to propose that the java support in the standard library, which is wholly based on the Eclipse JDT, be separated into an independent library project called rascal-jdt in the usethesource orginization. The idea would be that rascal-jdt be bundled with the Eclipse and VScode IDE's such that "batteries stay included".

• Project: rascal-jdt
• Lead: @jurgenvinju
• URL: github.com/usethesource/rascal/src/org/rascalmpl/library/lang/java/jdt

Motivation

• the rascal standard library is too large
• the rascal independent commandline jar contains the whole of Eclipse's JDT as a result of the JDT support being in the standard library
• we want to independently evolve the JDT support (independent version number)
• we want to independently track issues on this project

So..

• Let's not wait for the compiler project to finish to make this separation of concerns
• Let's package the new jar with all the IDEs we have, such that users of the library do not notice it has moved.

Votes

• [x] @jurgenvinju
• [ ] @PaulKlint
• [x] @tvdstorm
• [x] @DavyLandman

[DavyLandman]

Yes, I like this idea 👍

also 3 years back I worked together with @PaulKlint and @lmove to split out as much as interpreter specific stuff from the jdt-m3 code. That stuff is now contained in a very small interface, that I suspect with the recent changes to the typestore could be even factored away a lot more.

[jurgenvinju]

I've recently begun to remove all dependencies on interpreter API from this library. I think that would be a necessary maintenance step to make this a viable library project. I can commit to that.

[jurgenvinju]

There are also some known issues which still have to be resolved. Such as missing AST nodes for the uses of modifiers. Also support for Java 9, 11, 13 features is missing. The library needs some ❤️

[jurgenvinju]

Note that this library also contains a jar and bytecode analysis framework based on the asm library. It belongs here because it produces the "same" m3 output as far as possible.

[jurgenvinju]

just checked: this is now the constructor of EclipseJavaCompiler:

public EclipseJavaCompiler(IValueFactory vf, TypeStore definitions, IRascalMonitor monitor) {

This means that the entire libraru does not depend anymore on the @reflect feature of the JavaBridge and thus also not on interpreter-internal API.

[DavyLandman]

nice 👍

[jurgenvinju]

the question becomes when, if @PaulKlint and @tvdstorm agree, to do this.

• the eclipse IDE and its users depend on a readily available rascal-jdt implementation
• so rascal-eclipse would depend on rascal-jdt and include it in its standard library?
• rascal-eclipse is currently not under maintenance due to the Java11 thing.
• so let's postpone separating the jdt library from the standard library until after we port to Java 11?
• that way we can make sure to have continued support for our Eclipse users (students at different universities)

[jurgenvinju]

rascal (master=) $ jar tvf target/rascal-0.19.4-SNAPSHOT.jar  | grep "\.class" | wc -l
   14484
rascal (master=) $ jar tvf target/rascal-0.19.4-SNAPSHOT.jar  | grep "\.class" | grep eclipse | wc -l
    3753
rascal (master=) $ echo "(3753 / 14484) * 100" | bc -l
25.91135045567522783700

In other words this would remove 26% of the .class files in the rascal-shell jar.

a total of 21mb (21367007) of class files would be put elsewhere.

[DavyLandman]

the question becomes when, if @PaulKlint and @tvdstorm agree, to do this.

• the eclipse IDE and its users depend on a readily available rascal-jdt implementation
• so rascal-eclipse would depend on rascal-jdt and include it in its standard library?
• rascal-eclipse is currently not under maintenance due to the Java11 thing.
• so let's postpone separating the jdt library from the standard library until after we port to Java 11?
• that way we can make sure to have continued support for our Eclipse users (students at different universities)

Nou really sure why java 11 is related to this? Eclipse works, as long as you use java 8 and a version of eclipse max 2020-06. But this extraction of jdt can be seperate from that right? We just keep it as is. Release a java 8 version. Ship that together with rascal eclipse. And if we want, after make a version which supports java 11. But first step is purely splitting it out of rascal right?

[jurgenvinju]

The reason is that I can not test the eclipse plugin while eclipse does not work on my machine. If we separate jdt from rascal-eclipse, testing will be required to see if the integration of the separate jar into the eclipse plugin works again as expected.

We can split rascal-jdt out of Rascal without removing it from rascal-eclipse. That way I could test the separate project on the commandline and in vscode, but that would create a confusing situation for others who would not be able to use rascal-eclipse with the new rascal-jdt project for there will be weird classpath and rascal source path conflicts.

If we first go to Java 11, I'm hoping my Eclipse will start functioning again and all this confusion can be resolved by simply testing the new way of working with rascal-jdt.