Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support JDK 17 PermittedSubclasses in classfiles #10105

Merged
merged 1 commit into from Apr 25, 2023

Conversation

som-snytt
Copy link
Contributor

@som-snytt som-snytt commented Aug 6, 2022

Fixes scala/bug#12171
Fixes scala/bug#12159

Also adds test coverage for scala/bug#12474

ClassfileParser hint from #9228

Implementation: a quick hack takes non-sealed in Java sources as three tokens.

@scala-jenkins scala-jenkins added this to the 2.13.10 milestone Aug 6, 2022
@som-snytt som-snytt marked this pull request as ready for review August 6, 2022 23:10
@SethTisue SethTisue modified the milestones: 2.13.10, 2.13.9 Aug 10, 2022
@SethTisue SethTisue added the release-notes worth highlighting in next release notes label Aug 10, 2022
@SethTisue SethTisue changed the title Accept (non-)sealed in Java Support JDK 17 Aug 10, 2022
@SethTisue SethTisue changed the title Support JDK 17 Support JDK 17's sealed feature in Java sources and Java-generated classfiles Aug 10, 2022
@SethTisue
Copy link
Member

SethTisue commented Aug 10, 2022

Does Scala's sealed set the classfile flag (under -target:17 or higher)? Should it?

Copy link
Member

@lrytz lrytz left a comment

Choose a reason for hiding this comment

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

I had some WIP branch for this, sorry I didn't share... LGTM already.

In my branch I included Flags.SEALED in the modifiers of the ClassDef, which triggers population of children in the namer (IIRC) and enables exhaustivity checking. However, that's not enough, because Java symbols are only completed lazily, so only completed symbols are going to be known children. We can defer that to later I guess.

@SethTisue SethTisue modified the milestones: 2.13.9, 2.13.10 Sep 1, 2022
@lrytz lrytz modified the milestones: 2.13.10, 2.13.11 Sep 26, 2022
@SethTisue
Copy link
Member

@som-snytt care to respond to the review feedback? this one would be really nice to get into 2.13.11

@som-snytt
Copy link
Contributor Author

That is not sarcastic 👍 . I don't know if we need to stipulate that every time now?

@SethTisue
Copy link
Member

Is that a reference to https://www.walesonline.co.uk/news/uk-news/generation-z-ers-giving-passive-25249315 ?

In my world, thumbs-up are always assumed to be sincere 👍

@som-snytt
Copy link
Contributor Author

I'm aware that 👎 is always sincere.

@som-snytt som-snytt marked this pull request as draft October 31, 2022 09:18
@som-snytt
Copy link
Contributor Author

Children added per PermittedSubclasses. Drafting to support permits clause.

@SethTisue
Copy link
Member

@som-snytt this still seems like a high-value PR to me; let us know if you could use any input from the team in helping it get across the finish line

@som-snytt
Copy link
Contributor Author

@SethTisue thanks, I just checked out this branch today as part of my periodic attempt to "groom" and "reduce" my open PRs. Please let me know if 2.13.11 is imminent.

@som-snytt som-snytt marked this pull request as ready for review February 11, 2023 21:12
@SethTisue
Copy link
Member

Please let me know if 2.13.11 is imminent.

Well, it won't come out before 3.3.0. I started https://contributors.scala-lang.org/t/scala-2-13-11-release-planning/6088 just now.

@SethTisue
Copy link
Member

With any luck, a rebase on top of #10310 will fix Travis-CI. :knockonwood:

@SethTisue SethTisue self-assigned this Feb 20, 2023
@SethTisue
Copy link
Member

SethTisue commented Mar 29, 2023

[Von Neumann] was consulted by a group who was building a rocket ship to send into outer space. When he saw the incomplete structure, he asked, "Where did you get the plans for this ship?" He was told, "We have our own staff of engineers." He disdainfully replied: "Engineers! Why I have completely sewn up the whole mathematical theory of rocketry. See my paper of 1952." Well, the group consulted the 1952 paper, completely scrapped their 10 million dollar structure, and rebuilt the rocket exactly according to Von Neumann's plans. The minute they launched it, the entire structure blew up. They angrily called Von Neumann back and said: "We followed your instructions to the letter. Yet when we started it, it blew up! Why?" Von Neumann replied, "Ah yes; that is technically known as the blow-up problem - I treated that in my paper of 1954."

(this PR = 1952 paper, #10348 = 1954 paper)

@som-snytt
Copy link
Contributor Author

This PR gets you to ISS, if you want to dock with Tiangong then you need the other PR.

@som-snytt
Copy link
Contributor Author

@SethTisue rebased in honor of today's Starship test launch. Can we merge this? Then I can rebase the follow-up for mixed compilation.

@preveen-stack
Copy link

preveen-stack commented Apr 22, 2023

Just to provide some reference blog post on java sealed classes

@lrytz
Copy link
Member

lrytz commented Apr 24, 2023

If we split up the support for Java sealed in two merges, I think this first one should not add the incomplete support for sealed children. IIUC, what works is

  • support for the new syntax
  • support for children in the ClassfileParser

So I suggest removing the SEALED flag from symbols of sealed interfaces that come from source files. WDYT?

@SethTisue
Copy link
Member

SethTisue commented Apr 24, 2023

Since we're so close to release, having two separate PRs makes me uncomfortable as well.

If there are two PRs, we can only merge the first one if it would be acceptable (if not ideal) to release even if the second PR has to be pushed to 2.13.12.

But surely it makes the most sense to either include both, or neither? I think it's confusing to users to ship partial support. (Som, I understand that your intention is not to ship partial support, but regardless, I think being this close to release time forces us to be more careful than we might otherwise be.)

@som-snytt
Copy link
Contributor Author

Reverted to Aug 10, when flag was not set.

@som-snytt som-snytt changed the title Support JDK 17's sealed feature in Java sources and Java-generated classfiles Support JDK 17's sealed feature in Java-generated classfiles Apr 24, 2023
@som-snytt som-snytt changed the title Support JDK 17's sealed feature in Java-generated classfiles Support JDK 17 PermittedSubclasses in classfiles Apr 24, 2023
@som-snytt
Copy link
Contributor Author

The flaky test

image

but also

image

Accept (non-)sealed in Java sources.

Defer setting sealed from source to follow-up PR,
which will populate child classes lazily.
@som-snytt som-snytt merged commit ab8feac into scala:2.13.x Apr 25, 2023
3 checks passed
@som-snytt som-snytt deleted the issue/12159-java-sealed branch April 25, 2023 00:37
@SethTisue SethTisue removed the prio:hi high priority (used only by core team, only near release time) label Apr 27, 2023
SethTisue added a commit to SethTisue/scala that referenced this pull request Apr 27, 2023
@SethTisue
Copy link
Member

a bit of followup at #10383

@som-snytt
Copy link
Contributor Author

@SethTisue from now on, I'm only going to use the word "support" in the sense of "moral support".

dongjoon-hyun pushed a commit to apache/spark that referenced this pull request Jun 19, 2023
### What changes were proposed in this pull request?
This PR aims to upgrade Scala to 2.13.11
- https://www.scala-lang.org/news/2.13.11

Additionally, this pr adds a new suppression rule for warning message: `Implicit definition should have explicit type`, this is a new compile check introduced by scala/scala#10083, we must fix it when we upgrading to use Scala 3,

### Why are the changes needed?
This release improves collections, adds support for JDK 20 and 21, adds support for JDK 17 `sealed`:
- scala/scala#10363
- scala/scala#10184
- scala/scala#10397
- scala/scala#10348
- scala/scala#10105

There are 2 known issues in this version:

- scala/bug#12800
- scala/bug#12799

For the first one, there is no compilation warning messages related to `match may not be exhaustive` in Spark compile log, and for the second one, there is no case of `method.isAnnotationPresent(Deprecated.class)` in Spark code, there is just

https://github.com/apache/spark/blob/8c84d2c9349d7b607db949c2e114df781f23e438/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/JavaTypeInference.scala#L130

in Spark Code, and I checked `javax.annotation.Nonnull` no this issue.

So I think These two issues will not affect Spark itself, but this doesn't mean it won't affect the code written by end users themselves

The full release notes as follows:

- https://github.com/scala/scala/releases/tag/v2.13.11

### Does this PR introduce _any_ user-facing change?
Yes, this is a Scala version change.

### How was this patch tested?
- Existing Test
- Checked Java 8/17 + Scala 2.13.11 using GA, all test passed

Java 8 + Scala 2.13.11: https://github.com/LuciferYang/spark/runs/14337279564
Java 17 + Scala 2.13.11: https://github.com/LuciferYang/spark/runs/14343012195

Closes #41626 from LuciferYang/SPARK-40497.

Authored-by: yangjie01 <yangjie01@baidu.com>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
czxm pushed a commit to czxm/spark that referenced this pull request Jun 19, 2023
### What changes were proposed in this pull request?
This PR aims to upgrade Scala to 2.13.11
- https://www.scala-lang.org/news/2.13.11

Additionally, this pr adds a new suppression rule for warning message: `Implicit definition should have explicit type`, this is a new compile check introduced by scala/scala#10083, we must fix it when we upgrading to use Scala 3,

### Why are the changes needed?
This release improves collections, adds support for JDK 20 and 21, adds support for JDK 17 `sealed`:
- scala/scala#10363
- scala/scala#10184
- scala/scala#10397
- scala/scala#10348
- scala/scala#10105

There are 2 known issues in this version:

- scala/bug#12800
- scala/bug#12799

For the first one, there is no compilation warning messages related to `match may not be exhaustive` in Spark compile log, and for the second one, there is no case of `method.isAnnotationPresent(Deprecated.class)` in Spark code, there is just

https://github.com/apache/spark/blob/8c84d2c9349d7b607db949c2e114df781f23e438/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/JavaTypeInference.scala#L130

in Spark Code, and I checked `javax.annotation.Nonnull` no this issue.

So I think These two issues will not affect Spark itself, but this doesn't mean it won't affect the code written by end users themselves

The full release notes as follows:

- https://github.com/scala/scala/releases/tag/v2.13.11

### Does this PR introduce _any_ user-facing change?
Yes, this is a Scala version change.

### How was this patch tested?
- Existing Test
- Checked Java 8/17 + Scala 2.13.11 using GA, all test passed

Java 8 + Scala 2.13.11: https://github.com/LuciferYang/spark/runs/14337279564
Java 17 + Scala 2.13.11: https://github.com/LuciferYang/spark/runs/14343012195

Closes apache#41626 from LuciferYang/SPARK-40497.

Authored-by: yangjie01 <yangjie01@baidu.com>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
dongjoon-hyun pushed a commit to apache/spark that referenced this pull request Sep 16, 2023
### What changes were proposed in this pull request?
This PR aims to re-upgrade Scala to 2.13.11, after SPARK-45144 was merged, the build issues mentioned in #41943 should no longer exist.

- https://www.scala-lang.org/news/2.13.11

Additionally, this pr adds a new suppression rule for warning message: `Implicit definition should have explicit type`, this is a new compile check introduced by scala/scala#10083, we must fix it when we upgrading to use Scala 3

### Why are the changes needed?
This release improves collections, adds support for JDK 20 and 21, adds support for JDK 17 `sealed`:
- scala/scala#10363
- scala/scala#10184
- scala/scala#10397
- scala/scala#10348
- scala/scala#10105

There are 2 known issues in this version:

- scala/bug#12800
- scala/bug#12799

For the first one, there is no compilation warning messages related to `match may not be exhaustive` in Spark compile log, and for the second one, there is no case of `method.isAnnotationPresent(Deprecated.class)` in Spark code, there is just

https://github.com/apache/spark/blob/8c84d2c9349d7b607db949c2e114df781f23e438/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/JavaTypeInference.scala#L130

in Spark Code, and I checked `javax.annotation.Nonnull` no this issue.

So I think These two issues will not affect Spark itself, but this doesn't mean it won't affect the code written by end users themselves

The full release notes as follows:

- https://github.com/scala/scala/releases/tag/v2.13.11

### Does this PR introduce _any_ user-facing change?
Yes, this is a Scala version change.

### How was this patch tested?
- Existing Test

### Was this patch authored or co-authored using generative AI tooling?
No

Closes #42918 from LuciferYang/SPARK-40497-2.

Authored-by: yangjie01 <yangjie01@baidu.com>
Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-notes worth highlighting in next release notes
Projects
None yet
5 participants