RFR: 8260517: implement Sealed Classes as a standard feature

2021-04-15 Thread Vicente Romero
Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Thanks --

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2]

2021-04-15 Thread Vicente Romero
ases. Please also review the > related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to > [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated > after it. Vicente Romero has updated the pull request

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2]

2021-04-15 Thread Vicente Romero
On Fri, 16 Apr 2021 02:10:05 GMT, David Holmes wrote: > Hi Vicente, > > Hotspot and hotspot tests all look fine. One query: why was this test removed? > > test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java > > is that functionality tested elsewhere? (The other deleted test seemed

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3]

2021-04-15 Thread Vicente Romero
ases. Please also review the > related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to > [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated > after it. Vicente Romero has updated the pull request

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3]

2021-04-21 Thread Vicente Romero
On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore wrote: > Compiler changes look good (I have not checked SymbolGenerator). > > Why were some tests removed? thanks for the review. The removed tests were already covered in langtools regression tests, so I only removed duplicated tests ---

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v4]

2021-04-22 Thread Vicente Romero
ases. Please also review the > related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to > [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated > after it. Vicente Romero has updated the pull reques

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v5]

2021-04-30 Thread Vicente Romero
ases. Please also review the > related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to > [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated > after it. Vicente Romero has updated the pull reques

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6]

2021-05-01 Thread Vicente Romero
ases. Please also review the > related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to > [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated > after it. Vicente Romero has updated the pull request

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v7]

2021-05-06 Thread Vicente Romero
ases. Please also review the > related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to > [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated > after it. Vicente Romero has updated the pull reques

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v8]

2021-05-19 Thread Vicente Romero
ases. Please also review the > related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to > [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated > after it. Vicente Romero has updated the pull reques

Integrated: 8260517: implement Sealed Classes as a standard feature in Java

2021-05-20 Thread Vicente Romero
On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote: > Please review this PR that intents to make sealed classes a final feature in > Java. This PR contains compiler and VM changes. In line with similar PRs, > which has made preview features final, this one is mostly removin

Re: RFR: 8267312: Resolve should use generated diagnostic factories

2021-05-25 Thread Vicente Romero
On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore wrote: > This patch allows Resolve to use more static diagnostic factories. Resolution > errors support generation of diagnostics. This generation is very flexible > and allows creating either a toplevel (error or warning) diagnostic, or a

Re: RFR: 8267312: Resolve should use generated diagnostic factories

2021-05-27 Thread Vicente Romero
On Wed, 26 May 2021 14:09:39 GMT, Maurizio Cimadamore wrote: > > Some general comments about the generated code. I wonder if it would make > > sense to change the implementation of the toType() method which will fold > > common cases in the switch expression into a default case or generate a

Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12]

2021-06-04 Thread Vicente Romero
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for >> switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/je

Re: RFR: 8266036: class file for sun.misc.Contended not found

2021-06-10 Thread Vicente Romero
On Wed, 9 Jun 2021 11:05:37 GMT, Jan Lahoda wrote: > The ct.sym may contain classfiles referring to annotations that are not > present in ct.sym (liek JDK's internal annotation `sun.misc.Contended`). If > javac will try to load them (while discovering annotations for the purpose of > detecting

RFR: 8275771: JDK source code contains redundant boolean operations in jdk.compiler and langtools

2021-11-29 Thread Vicente Romero
Hi, Please review this PR which is basically rewriting some redundant boolean expressions in the compiler. TIA - Commit messages: - 8275771: JDK source code contains redundant boolean operations in jdk.compiler and langtools Changes: https://git.openjdk.java.net/jdk/pull/6599/fi

Re: RFR: JDK-8231176: Test tools/javac/options/BCPOrSystemNotSpecified.java broken on Windows

2019-09-18 Thread Vicente Romero
looks good, Vicente On 9/18/19 7:33 AM, Jan Lahoda wrote: Hi, The newly added tools/javac/options/BCPOrSystemNotSpecified.java test is failing on Windows, so tier 1 is failing. I'd like to temporarily problem list the test, so that it can be properly investigated: http://cr.openjdk.java.net

Re: RFR: JEP 367: Remove the Pack200 Tools and API

2019-11-21 Thread Vicente Romero
ges? This removal seems okay, but I found one additional reference: ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false Thanks, David - On 21/11/2019 8:54 am, Vicente Romero wrote: Hi, I need a reviewer for t

Re: RFR: JEP 367: Remove the Pack200 Tools and API

2019-11-21 Thread Vicente Romero
please wait, I found some additional dependencies on module jdk.pack, will submit another webrev, sorry Vicente On 11/21/19 2:53 PM, Vicente Romero wrote: Hi, I think I have covered all the proposed fixes so far. This is the last iteration of the webrev [1], all the current changes are in

Re: RFR: JEP 367: Remove the Pack200 Tools and API

2019-11-21 Thread Vicente Romero
, Vicente Romero wrote: please wait, I found some additional dependencies on module jdk.pack, will submit another webrev, sorry Vicente On 11/21/19 2:53 PM, Vicente Romero wrote: Hi, I think I have covered all the proposed fixes so far. This is the last iteration of the webrev [1], all the current

Re: RFR: JEP 367: Remove the Pack200 Tools and API

2019-11-22 Thread Vicente Romero
Hi all, On 11/22/19 3:21 AM, Alan Bateman wrote: On 21/11/2019 19:53, Vicente Romero wrote: Hi, I think I have covered all the proposed fixes so far. This is the last iteration of the webrev [1], all the current changes are in this one, the code hasn't been split into different we