Skip to content

Jumpstart java8#1507

Merged
msridhar merged 67 commits intomasterfrom
jumpstart-java8
Aug 25, 2025
Merged

Jumpstart java8#1507
msridhar merged 67 commits intomasterfrom
jumpstart-java8

Conversation

@juliandolby
Copy link
Copy Markdown
Contributor

We have been working on Java 8 supports in the source front end, and this is work on lambda expressions, complete with two tests.

@github-actions
Copy link
Copy Markdown

github-actions bot commented May 14, 2025

Test Results

  713 files  + 6    713 suites  +6   4h 54m 14s ⏱️ + 33m 21s
  773 tests + 8    754 ✅ + 8   19 💤 ±0  0 ❌ ±0 
4 522 runs  +48  4 406 ✅ +48  116 💤 ±0  0 ❌ ±0 

Results for commit 57eaf3d. ± Comparison against base commit 9665ec2.

♻️ This comment has been updated with latest results.

Copy link
Copy Markdown
Member

@msridhar msridhar left a comment

Choose a reason for hiding this comment

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

This is awesome @juliandolby! It will take me a little while to review this; I hope that's ok. A couple of initial slightly nit-picky comments are below.

High-level questions:

  1. Is the lambda support here intended to be complete? Or are there cases with lambdas that are still not handled?
  2. Are method references handled at all, or is that a separate effort?

CAstCallGraphUtil.dumpCG(B.getCFAContextInterpreter(), B.getPointerAnalysis(), CG);
}

/*
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.

Can we put this change in a separate PR if we really want it? Doesn't seem to relate to Java 8. On Gradle if you want to skip these slow tests you can add the flag -PexcludeSlowTests

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

i didn't know about that option... in that case, we likely don't need it.

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.

Ok, sounds good can we revert to the version in the master branch then?

org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate
org.eclipse.jdt.core.compiler.codegen.targetPlatform=11
org.eclipse.jdt.core.compiler.codegen.targetPlatform=17
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.

I'm not sure if all these changes to the Eclipse config files were intended to be part of this PR. But specifically, we might want to revert these changes that target JDK 17 instead of JDK 11, as WALA still supports running on JDK 11. Otherwise, an Eclipse developer might erroneously not see errors when using Java 17 constructs (though the Gradle build should still fail).

Copy link
Copy Markdown
Contributor Author

@juliandolby juliandolby May 14, 2025

Choose a reason for hiding this comment

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

Ah, that is an oversight due to the fact that much work here requires Java 17. Most likely my Eclipse updated that without my asking. Sorry about that.

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.

No worries, could you revert the changes to all the Eclipse config files then for this PR?

@juliandolby
Copy link
Copy Markdown
Contributor Author

juliandolby commented May 14, 2025

This is awesome @juliandolby! It will take me a little while to review this; I hope that's ok. A couple of initial
slightly nit-picky comments are below.

High-level questions:

  1. Is the lambda support here intended to be complete? Or are there cases with lambdas that are still not handled?

It is intended to be complete, but whether it really is complete and bug free is another question. We do have two tests of basic functionality, and the implementation relies on the same machinery that supports inner classes. However, more rigorous testing would be a good thing.

  1. Are method references handled at all, or is that a separate effort?

This request is focused on lambda expressions. But aren't method references and their friends mostly a library thing anyway? The existing support for them in bytecode might be sufficient...

@juliandolby
Copy link
Copy Markdown
Contributor Author

This is awesome @juliandolby! It will take me a little while to review this; I hope that's ok. A couple of initial
slightly nit-picky comments are below.
High-level questions:

  1. Is the lambda support here intended to be complete? Or are there cases with lambdas that are still not handled?

It is intended to be complete, but whether it really is complete and bug free is another question. We do have two tests of basic functionality, and the implementation relies on the same machinery that supports inner classes. However, more rigorous testing would be a good thing.

  1. Are method references handled at all, or is that a separate effort?

This request is focused on lambda expressions. But aren't method references and their friends mostly a library thing anyway? The existing support for them in bytecode might be sufficient...

And now we have a third test, and needed fixes...

@msridhar
Copy link
Copy Markdown
Member

This request is focused on lambda expressions. But aren't method references and their friends mostly a library thing anyway? The existing support for them in bytecode might be sufficient...

A method reference is something like A::foo and it will often occur in source code. But, completely fine to handle that in a separate PR. It might already work; under the hood it desugars to a lambda. But worth testing, eventually.

@juliandolby
Copy link
Copy Markdown
Contributor Author

This request is focused on lambda expressions. But aren't method references and their friends mostly a library thing anyway? The existing support for them in bytecode might be sufficient...

A method reference is something like A::foo and it will often occur in source code. But, completely fine to handle that in a separate PR. It might already work; under the hood it desugars to a lambda. But worth testing, eventually.

Ah yes. We have not (yet) attempted to handle those.

@codecov
Copy link
Copy Markdown

codecov bot commented May 18, 2025

Codecov Report

❌ Patch coverage is 88.14815% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.20%. Comparing base (9665ec2) to head (57eaf3d).
⚠️ Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
...st/java/translator/jdt/JDTJava2CAstTranslator.java 86.86% 4 Missing and 9 partials ⚠️
...la/cast/java/translator/jdt/JDTTypeDictionary.java 70.00% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1507      +/-   ##
============================================
+ Coverage     50.15%   50.20%   +0.05%     
- Complexity    12632    12652      +20     
============================================
  Files          1365     1365              
  Lines         85113    85204      +91     
  Branches      14717    14732      +15     
============================================
+ Hits          42691    42780      +89     
+ Misses        37630    37628       -2     
- Partials       4792     4796       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Copy Markdown
Member

@msridhar msridhar left a comment

Choose a reason for hiding this comment

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

Hoping we can clean up a couple high-level things and then I can glance through the code more easily

org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate
org.eclipse.jdt.core.compiler.codegen.targetPlatform=11
org.eclipse.jdt.core.compiler.codegen.targetPlatform=17
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.

No worries, could you revert the changes to all the Eclipse config files then for this PR?

CAstCallGraphUtil.dumpCG(B.getCFAContextInterpreter(), B.getPointerAnalysis(), CG);
}

/*
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.

Ok, sounds good can we revert to the version in the master branch then?

@@ -0,0 +1,265 @@
/*
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.

It looks like a top-level java directory was added erroneously in this PR. Assuming that's correct could we delete it?

Copy link
Copy Markdown
Member

@msridhar msridhar Jul 11, 2025

Choose a reason for hiding this comment

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

It seems this comment has still not been addressed? I still see an unneeded top-level java directory

output.. = bin/test
bin.includes = META-INF/,\
.,\
bin.includes = .,\
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.

Is this change important for this PR? If not could we undo it?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

All of your changes sound good to me. I am not sure how the top-level java dir got there, rather than cast/java, but it was not deliberate.

I think the change to ide/tests/build.properties made a warning go away in Eclipse, which I still use, but it is not vital.

reverting the .prefs files and TestSimpleCallGraphShape is all fine.

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, @juliandolby. Please let me know once you've had time to make all these changes (no hurry on my end), and then after that I'll take another look. I expect we'll be able to land the PR soon after.

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.

If we could also undo changes to build.properties files that'd be great; we can put them in a separate PR maybe? If it's too painful to undo it's ok.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

reverted that file too

@juliandolby
Copy link
Copy Markdown
Contributor Author

juliandolby commented Jul 9, 2025

Took a while to get back to this, but we finally did. @patricklapgar and I have attempted to address the comments on this pull request: we have put the Java version back to 11 and undone our change on the slow JS test. We have also merged the latest WALA. More comments, suggestions and requests are welcome.

@msridhar
Copy link
Copy Markdown
Member

@juliandolby let me know when this is ready for another look 🙂

@juliandolby
Copy link
Copy Markdown
Contributor Author

@juliandolby let me know when this is ready for another look 🙂

I think it is ready now...

msridhar
msridhar previously approved these changes Aug 25, 2025
Copy link
Copy Markdown
Member

@msridhar msridhar left a comment

Choose a reason for hiding this comment

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

LGTM now! So great to see source frontend lambda support finally landing!

@msridhar msridhar enabled auto-merge August 25, 2025 19:24
@msridhar msridhar added this pull request to the merge queue Aug 25, 2025
Merged via the queue into master with commit 69e3035 Aug 25, 2025
20 checks passed
@msridhar msridhar deleted the jumpstart-java8 branch August 25, 2025 20:30
@msridhar
Copy link
Copy Markdown
Member

@juliandolby would it be helpful to have a WALA release that includes this support?

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JDTJava2CAstTranslator.visitNode Unhandled JDT node type org.eclipse.jdt.core.dom.LambdaExpression

3 participants