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

8253455: Record Classes javax.lang.model changes #291

Closed

Conversation

@vicente-romero-oracle
Copy link
Contributor

@vicente-romero-oracle vicente-romero-oracle commented Sep 21, 2020

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

Issue

Reviewers

Download

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

@vicente-romero-oracle
Copy link
Contributor Author

@vicente-romero-oracle vicente-romero-oracle commented Sep 21, 2020

/csr

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 21, 2020

👋 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
Copy link

@openjdk openjdk bot commented Sep 21, 2020

@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
Copy link

@openjdk openjdk bot commented Sep 21, 2020

@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.

@openjdk openjdk bot added the compiler label Sep 21, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 21, 2020

Co-authored-by: Vicente Romero <vicente.romero@oracle.com>
Co-authored-by: Joe Darcy <joe.darcy@oracle.com>
@openjdk
Copy link

@openjdk openjdk bot commented Sep 29, 2020

⚠️ @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).

@openjdk openjdk bot added the core-libs label Sep 29, 2020
@vicente-romero-oracle vicente-romero-oracle force-pushed the vicente-romero-oracle:JDK-8253455 branch from 9b24af7 to f0845f6 Sep 29, 2020
@vicente-romero-oracle vicente-romero-oracle changed the title 8253455: Record Classes (final) javax.lang.model changes 8253455: Record Classes javax.lang.model changes Sep 29, 2020
* feature of the Java language. Preview features
* may be removed in a future release, or upgraded to permanent
* features of the Java language.}
*
* A record type.
* @since 14

This comment has been minimized.

@ChrisHegarty

ChrisHegarty Sep 30, 2020
Member

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

@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 30, 2020

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
Copy link

@mlbridge mlbridge bot commented Sep 30, 2020

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
Copy link

@mlbridge mlbridge bot commented Sep 30, 2020

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
Copy link

@mlbridge mlbridge bot commented Oct 2, 2020

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
Copy link
Contributor Author

@vicente-romero-oracle vicente-romero-oracle commented Oct 9, 2020

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

@@ -62,6 +62,13 @@
// JDK 15. Since the JDK 14 codebase uses the enum constant, it is
// necessary for PreviewFeature in JDK 15 to declare the enum constant.
TEXT_BLOCKS,
/*

This comment has been minimized.

@jddarcy

jddarcy Oct 10, 2020
Member

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

This comment has been minimized.

@vicente-romero-oracle

vicente-romero-oracle Oct 10, 2020
Author Contributor

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

@openjdk openjdk bot removed the csr label Oct 11, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Oct 11, 2020

@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.

@openjdk openjdk bot added the ready label Oct 11, 2020
@vicente-romero-oracle
Copy link
Contributor Author

@vicente-romero-oracle vicente-romero-oracle commented Oct 19, 2020

/integrate

@openjdk openjdk bot closed this Oct 19, 2020
@openjdk openjdk bot added integrated and removed ready rfr labels Oct 19, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Oct 19, 2020

@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.

@vicente-romero-oracle vicente-romero-oracle deleted the vicente-romero-oracle:JDK-8253455 branch Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants