8253455: Record Classes javax.lang.model changes

[vicente-romero-oracle]

Please review the fix for JDK-8253455 which is part of the effort to make records a final feature of the Java Language. The rest of the code has been published in PR#290

Thanks,
Vicente

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Testing

	Linux x64	Windows x64	macOS x64
Build	✔️ (3/3 passed)	✔️ (2/2 passed)	✔️ (2/2 passed)
Test (tier1)	✔️ (9/9 passed)	❌ (1/9 failed)	✔️ (9/9 passed)

Failed test task

• Windows x64 (hs/tier1 gc)

Issue

• JDK-8253455: Record Classes javax.lang.model changes

Reviewers

• Joe Darcy (@jddarcy - Reviewer) ⚠️ Review applies to cd27384

Download

$ git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291
$ git checkout pull/291

[vicente-romero-oracle]

/csr

[bridgekeeper]

👋 Welcome back vromero! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@vicente-romero-oracle has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@vicente-romero-oracle please create a CSR request and add link to it in JDK-8253455. This pull request cannot be integrated until the CSR request is approved.

[openjdk]

@vicente-romero-oracle The following label will be automatically applied to this pull request: compiler.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label (add|remove) "label" command.

[mlbridge]

Webrevs

• 06: Full - Incremental (a037310)
• 05: Full - Incremental (cd27384)
• 04: Full - Incremental (f5682fc)
• 03: Full - Incremental (aeb799f)
• 02: Full - Incremental (f0845f6)
• 01: Full - Incremental (9b24af7d629fb9541943967c375a91424f43828b)
• 00: Full (4814f9e96f90055ef435f83ccdfb516e8a7f2b22)

[openjdk]

⚠️ @vicente-romero-oracle This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

[ChrisHegarty]

The @since tags will all need to be updated to 16, right?

[mlbridge]

Mailing list message from Joe Darcy on compiler-dev:

On 9/30/2020 2:00 AM, Chris Hegarty wrote:

On Tue, 29 Sep 2020 21:37:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort
to make records a final feature of the Java Language. The rest of the code has been published in
[PR#290](https://github.com//pull/290) Thanks,
Vicente
Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

adding a comment to PreviewFeature.Feature
src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 114:

112: /**
113: * A record type.
114: * @SInCE 14
The `@since` tags will all need to be updated to `16`, right?

While I acknowledge that is what the current version of the JEP directs
to happen in this situation, the API elements in question really are
present in 14 and 15 so I don't think saying they are "since 16" is
necessarily clearer.

-Joe

[mlbridge]

Mailing list message from Alex Buckley on compiler-dev:

On 9/30/2020 2:29 PM, Joe Darcy wrote:

Vicente Romero has updated the pull request incrementally with one
additional commit since the last revision:

?? adding a comment to PreviewFeature.Feature
src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java
line 114:

112:???? /**
113:????? * A record type.
114:????? * @SInCE 14
The `@since` tags will all need to be updated to `16`, right?

While I acknowledge that is what the current version of the JEP directs
to happen in this situation, the API elements in question really are
present in 14 and 15 so I don't think saying they are "since 16" is
necessarily clearer.

The reason that JEP 12 says to have @SInCE reflect the
final-and-permanent release rather than a preview release is to provide
a JEP owner with a simple rule that applies regardless of whether an API
element evolves between preview and permanent status. Just because an
API element exists in 14 and 15 (as preview) and 16 (as permanent)
doesn't mean it has exactly the same semantics in 16 as in 14 or 15 --
previewing is the one avenue by which an element can materially change
its behavior between 14 and 15 and 16. Also, where API elements are
previewed over time, the choice to have some elements be @SInCE 14 while
others are @SInCE 15 or @SInCE 16 would cause confusion in future --
"Are the 14 and 15-era elements associated with records considered to be
final, given that records weren't finalized until 16? Might the 14 and
15-era elements be removed one day?" -- so I think it's best to focus
@SInCE consistently on the release where a feature becomes
final-and-permanent.

Alex

[mlbridge]

Mailing list message from Joe Darcy on compiler-dev:

On 9/30/2020 3:57 PM, Alex Buckley wrote:

On 9/30/2020 2:29 PM, Joe Darcy wrote:

Vicente Romero has updated the pull request incrementally with one
additional commit since the last revision:

?? adding a comment to PreviewFeature.Feature
src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java
line 114:

112:???? /**
113:????? * A record type.
114:????? * @SInCE 14
The `@since` tags will all need to be updated to `16`, right?

While I acknowledge that is what the current version of the JEP
directs to happen in this situation, the API elements in question
really are present in 14 and 15 so I don't think saying they are
"since 16" is necessarily clearer.

The reason that JEP 12 says to have @SInCE reflect the
final-and-permanent release rather than a preview release is to
provide a JEP owner with a simple rule that applies regardless of
whether an API element evolves between preview and permanent status.
Just because an API element exists in 14 and 15 (as preview) and 16
(as permanent) doesn't mean it has exactly the same semantics in 16 as
in 14 or 15 -- previewing is the one avenue by which an element can
materially change its behavior between 14 and 15 and 16.

Conversely, the fact that an API element is preview on one release and
non-preview in a subsequent one does not necessarily imply the spec has
changed. (Although it might have changed, of course.)

Non-preview methods don't necessarily have *exactly* the same semantics
between releases either, subject to our general API evolution policies.

Also, where API elements are previewed over time, the choice to have
some elements be @SInCE 14 while others are @SInCE 15 or @SInCE 16
would cause confusion in future -- "Are the 14 and 15-era elements
associated with records considered to be final, given that records
weren't finalized until 16? Might the 14 and 15-era elements be
removed one day?" -- so I think it's best to focus @SInCE consistently
on the release where a feature becomes final-and-permanent.

Another kind of consistency would be "use the @SInCE tag for the release
the API element was first added." For readers, it would be a simple rule
that non-preview and not-deprecated-for-removal API elements can be
assumed to be present in the next release.

-Joe

[mlbridge]

Mailing list message from Alex Buckley on compiler-dev:

On 9/30/2020 4:48 PM, Joe Darcy wrote:> Conversely, the fact that an API
element is preview on one release and

non-preview in a subsequent one does not necessarily imply the spec has
changed. (Although it might have changed, of course.)

Non-preview methods don't necessarily have *exactly* the same semantics
between releases either, subject to our general API evolution policies.

I recognize that a permanent API element may have its behavior changed
in some situations, and we would leave @SInCE alone in that context. For
example, a method flagged with @SInCE 8 might have been extended in 9 to
handle modules, and we would not dream of saying @SInCE 9.

However, a preview API element has an order of magnitude more freedom to
change than a permanent API element. This means that the element
previewing in 15 might have the same name and signature as the element
which previewed in 14, but with novel behavior in some _or even all_
situations ... if that happens, then it would be misleading to suggest
that the novel aspect of the element's spec has been present since 14
just because the element itself has been present since 14. The element
in 15 is not really the same element as in 14, and the element in 16
might not be the same element as in 15. Updating @SInCE to 16 when the
element becomes permanent wipes the slate clean (the preview behavior no
longer matters) and lets the element join the club of "non-preview and
not-deprecated-for-removal API elements" which "can be assumed to be
present in the next release."

Alex

[vicente-romero-oracle]

thanks for the comments, I have updated the PR changing @since 14 to @since 16

[jddarcy]

It doesn't really matter, but it would look more consistent if TEXT_BLOCKS and RECORDS used the same kind of comment syntax.

[vicente-romero-oracle]

thanks for the comment, I have uploaded commit a037310 to fix this

[openjdk]

@vicente-romero-oracle This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8253455: Record Classes javax.lang.model changes

Reviewed-by: darcy

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 163 new commits pushed to the master branch:

• d43f141: 8254351: Minimal VM build fails with undeclared identifier 'MaxVectorSize' after JDK-8252847
• cc52358: 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it
• 4b5ac3a: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions
• ec41046: 8254348: Build fails when cds is disabled after JDK-8247536
• e4469d2: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
• 7ec9c8e: 8233214: Remove runtime code not needed with CMS removed
• 536b35b: 8254319: Shenandoah: Interpreter native-LRB needs to activate during HAS_FORWARDED
• be26972: 8253379: [windows] Several jpackage tests failed with error code 1638
• 52e45a3: 8229186: Improve error messages for TestStringIntrinsics failures
• 6d2c1a6: 8254292: Update JMH devkit to 1.26
• ... and 153 more: https://git.openjdk.java.net/jdk/compare/b1ce6bdba9ce9a9dcdeb63bca1b2a502bc61bd63...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[vicente-romero-oracle]

/integrate

[openjdk]

@vicente-romero-oracle Since your change was applied there have been 258 commits pushed to the master branch:

• c17d585: 8246774: implement Record Classes as a standard feature in Java
• 0b3e6c5: 8194126: Regression automated Test '/open/test/jdk/javax/swing/JColorChooser/Test7194184.java' fails
• ce1aac1: 8028707: javax/swing/JComboBox/6236162/bug6236162.java fails on azure
• 83ea863: 8253559: The INDEX page should link to Serialized Form and Constant Values pages
• e66c6bb: 8254349: The TestNoScreenMenuBar test should be updated
• 402d01a: 8254795: Remove obsolete template files
• 07ec35e: 8254623: gc/g1/TestHumongousConcurrentStartUndo.java still fails sometimes
• 0570cc1: 8254855: Clean up and remove unused code in vmIntrinsics
• 1742c44: 8254695: G1: Next mark bitmap clear not cancelled after marking abort
• 34583eb: 8254161: Prevent instantiation of EnumSet subclasses through deserialization
• ... and 248 more: https://git.openjdk.java.net/jdk/compare/b1ce6bdba9ce9a9dcdeb63bca1b2a502bc61bd63...master

Your commit was automatically rebased without conflicts.

Pushed as commit 272bb5d.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.