Skip to content

Migrate to JMLtk - #3966

Open
wadoon wants to merge 7 commits into
mainfrom
weigl/jmltk
Open

Migrate to JMLtk#3966
wadoon wants to merge 7 commits into
mainfrom
weigl/jmltk

Conversation

@wadoon

@wadoon wadoon commented Aug 15, 2026

Copy link
Copy Markdown
Member

Intended Change

With this PR, wadoon/key-javaparser becomes obsolete in favour of the JMLtk fork!

This PR does not

  • use JMLtk to parse JML.
  • use JML-AST classes.

Regressions:

  • Positioning on invalid ExpressionStmt (int x = ;)

Changes to key-javaparser

  • JML modifiers are printed escaped => (/*@ ghost */ int x;)
  • KeyRangeExpression gone
  • KeyMarkerStatement gone
  • Consistent names are in favour of JavaParser (e.g., XStatement vs. XStmt)

Plan

Things to do after review:

  • decide when to make JMLtk first release

    • update K counter on JMLtk
  • discuss sacrifices in JMLtk for KeY compat:
    /*@ghost*/ int #x; vs. ghost int #x;

  • How to proceed further with exchanging JML parsing

Type of pull request

  • Refactoring (behaviour should not change or only minimally change)

Ensuring quality

  • I made sure that introduced/changed code is well documented (javadoc and inline comments).
  • I have tested the feature as follows: unit-tests

@wadoon wadoon self-assigned this Aug 16, 2026
@wadoon wadoon added JavaJMLParser Feature New feature or request Java Parser Java Pull requests that update Java code labels Aug 16, 2026
@wadoon wadoon added this to the v3.1.0 milestone Aug 16, 2026
@wadoon
wadoon marked this pull request as ready for review August 16, 2026 23:48
@wadoon

wadoon commented Aug 16, 2026

Copy link
Copy Markdown
Member Author

Squash before merge

@wadoon
wadoon requested a review from unp1 August 16, 2026 23:49

@unp1 unp1 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think all the mentioned issues are just one comment. Otherwise the changes to error reporting seem to be a regression in the reported position, so we should fix that position reporting not the tests. I'll look into that myself.

It is still a regression, as the reported token is now "int" and not "=" as before.
@unp1

unp1 commented Aug 17, 2026

Copy link
Copy Markdown
Member

Improved the position recording slightly. But the parser now reports "int" as last successfull token and no longer "=", so the position is no longer as precise as before where the dialog underlined the empty space after '='

@unp1 unp1 closed this Aug 17, 2026
@unp1
unp1 deleted the weigl/jmltk branch August 17, 2026 21:30
@unp1 unp1 reopened this Aug 17, 2026
@unp1

unp1 commented Aug 17, 2026

Copy link
Copy Markdown
Member

Sorry my fault, restored to open.

First pushed to the wrong branch due to a typo jmtk and then deleted the correct one....
Nothing got lost everything restored

@wadoon

wadoon commented Aug 18, 2026

Copy link
Copy Markdown
Member Author

The question is rather: Can we get rid of the stupid ghost and model modifier on Java-level?
See here: https://github.com/jmltoolkit/jmltk/blob/168dfa039c2d26582e57450c7029da434242daa8/javaparser-key-testing/src/test/java/com/github/javaparser/ast/key/GhostTest.java

Correctly, it should be /@ghost int x;*/ as the whole thing has JML semantics.
To be clearly, /*@ ghost #t #a = #se;*/ should be translated into /*@ ghost #t #a;*/ /*ghost #a = #se; */.

@wadoon
wadoon requested a review from unp1 August 18, 2026 03:41
@unp1

unp1 commented Aug 19, 2026

Copy link
Copy Markdown
Member

The question is rather: Can we get rid of the stupid ghost and model modifier on Java-level? See here: https://github.com/jmltoolkit/jmltk/blob/168dfa039c2d26582e57450c7029da434242daa8/javaparser-key-testing/src/test/java/com/github/javaparser/ast/key/GhostTest.java

Correctly, it should be /@ghost int x;*/ as the whole thing has JML semantics. To be clearly, /*@ ghost #t #a = #se;*/ should be translated into /*@ ghost #t #a;*/ /*ghost #a = #se; */.

I assume you mean /*@ ghost #t #a;*/ /*@ set #a = #se; */? But yes, it would be better if JML is not on the Java level.

@unp1 unp1 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot. Fine from my side. Only question if you want to have a second review from someone else in addition.

Comment thread gradle/libs.versions.toml
@wadoon

wadoon commented Aug 19, 2026

Copy link
Copy Markdown
Member Author

Thanks a lot. Fine from my side. Only question if you want to have a second review from someone else in addition.

We need to have a discussion on the needed ghost modifier at the Java level.

In JMLtk, I have the syntax /*@ ghost <stmt>; */ on the statement level. The following is valid:

public void foo() {
  //@ ghost int x = e;
  //@ ghost if(x>2) x = -2;
  //@       else    x =  1/0;
}

Allowing JML in Taclets would now allow writing Taclets specific to ghost code, i.e., appropriate handling of exceptions (WD problem).

All in all, ghost should not be considered as a Java modifier for long in JMLtk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Feature New feature or request Java Parser Java Pull requests that update Java code JavaJMLParser

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants