Hi Joe,
The revised webrev looks good.
Side note on whether a private constructor should be empty or should throw some
Throwable. There are actually two (or more) use cases for private constructors:
1) intending to prevent instances from being created other than through
well-controlled APIs,
+1
Mandy
On 12/9/19 1:34 PM, Joe Darcy wrote:
PS That should be
http://cr.openjdk.java.net/~darcy/8230771.1
Cheers,
-Joe
On 12/9/2019 12:39 PM, Joe Darcy wrote:
Updated webrev:
http://cr.openjdk.java.net/~darcy/8230771.0/
Found a class extending Modifier to the the static definit
PS That should be
http://cr.openjdk.java.net/~darcy/8230771.1
Cheers,
-Joe
On 12/9/2019 12:39 PM, Joe Darcy wrote:
Updated webrev:
http://cr.openjdk.java.net/~darcy/8230771.0/
Found a class extending Modifier to the the static definitions; I
replaced this with a static import.
To
Updated webrev:
http://cr.openjdk.java.net/~darcy/8230771.0/
Found a class extending Modifier to the the static definitions; I
replaced this with a static import.
To make sure a class isn't instantiated, I usually have it throw
AssertionError or some exception, although as you say that i
It seems a bit overly cautious to throw AssertionError. JDK has many
private no-arg constructor and it can be as simple as empty
constructor. Just my preference.
Mandy
On 12/9/19 10:16 AM, Joe Darcy wrote:
Corrected patch:
diff -r 153e5f76551d
src/java.base/share/classes/java/lang/invoke/
Corrected patch:
diff -r 153e5f76551d
src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
---
a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
Mon Dec 09 23:00:13 2019 +0530
+++
b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
Mon
Doh! Will correct. That is why I want to get the no-arg constructor
added as a javac warning (JDK-8071961) ;-)
Thanks all for catching this,
-Joe
On 12/9/2019 9:29 AM, Mandy Chung wrote:
Good catch! Daniel also pointed that out. I overlooked it. It needs
to add back a private no-arg constru
Good catch! Daniel also pointed that out. I overlooked it. It needs
to add back a private no-arg constructor.
Mandy
On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote:
If you remove the deprecated constructor, the compiler will add a
default one. Wouldn't it be a better idea to make
Hi Joe,
I'm sure I'm going to say something stupid but:
doesn't this adds back the public implicit no args constructors?
best regards,
-- daniel
On 08/12/2019 18:58, Joe Darcy wrote:
Hello,
Please review this small API changes for JDK 15:
JDK-8230771: Remove terminally deprecated con
If you remove the deprecated constructor, the compiler will add a default
one. Wouldn't it be a better idea to make the deprecated constructor
private and throwing an exception?
Em seg., 9 de dez. de 2019 às 14:13, Mandy Chung
escreveu:
> Looks good.
>
> Mandy
>
> On 12/8/19 10:58 AM, Joe Darcy
Looks good.
Mandy
On 12/8/19 10:58 AM, Joe Darcy wrote:
Hello,
Please review this small API changes for JDK 15:
JDK-8230771: Remove terminally deprecated constructors in java.base
CSR: https://bugs.openjdk.java.net/browse/JDK-8235548
webrev: http://cr.openjdk.java.net/~darcy/82307
> On 8 Dec 2019, at 18:58, Joe Darcy wrote:
>
> Hello,
>
> Please review this small API changes for JDK 15:
>
> JDK-8230771: Remove terminally deprecated constructors in java.base
> CSR: https://bugs.openjdk.java.net/browse/JDK-8235548
> webrev: http://cr.openjdk.java.net/~darcy/
+1
> On Dec 8, 2019, at 1:58 PM, Joe Darcy wrote:
>
> Hello,
>
> Please review this small API changes for JDK 15:
>
> JDK-8230771: Remove terminally deprecated constructors in java.base
> CSR: https://bugs.openjdk.java.net/browse/JDK-8235548
> webrev: http://cr.openjdk.java.net/~da
Hello,
Please review this small API changes for JDK 15:
JDK-8230771: Remove terminally deprecated constructors in java.base
CSR: https://bugs.openjdk.java.net/browse/JDK-8235548
webrev: http://cr.openjdk.java.net/~darcy/8230771.0/
Patch below.
Thanks,
-Joe
---
old/src/java.base/
14 matches
Mail list logo
