It is an anti-pattern to rely on an implicit default constructor in a
publicly exported class in a library. There are (at least) three good
reasons to avoid this:
1. The default constructor will have no API docs
2. You could end up with a public constructor in a class where you don't
want a
Just for my curiosity, what issues can arise relying on default
constructors? I couldn't find anything with google (apart from links back
to these messages!)
Thanks,
Peter
On Tue, 15 Sep 2020 09:38:02 GMT, Conor Cleary wrote:
>> Marked as reviewed by serb (Reviewer).
>
> Now awaiting CSR approval as advised
The CSR needs some updates to put the spec inline
-
PR: https://git.openjdk.java.net/jdk/pull/153
On Mon, 14 Sep 2020 21:27:46 GMT, Sergey Bylokhov wrote:
>> This issue relates to JDK-8250639 '☂ Address reliance on default
>> constructors in the java.desktop module'. The changes
>> address the reliance on default constructors by adding in basic constructors
>> in the following classes:
>>
On Mon, 14 Sep 2020 14:32:18 GMT, Conor Cleary
wrote:
> This issue relates to JDK-8250639 '☂ Address reliance on default constructors
> in the java.desktop module'. The changes
> address the reliance on default constructors by adding in basic constructors
> in the following classes:
> -
On Mon, 14 Sep 2020 19:02:27 GMT, Phil Race wrote:
>> This issue relates to JDK-8250639 '☂ Address reliance on default
>> constructors in the java.desktop module'. The changes
>> address the reliance on default constructors by adding in basic constructors
>> in the following classes:
>> -
On Mon, 14 Sep 2020 14:32:18 GMT, Conor Cleary
wrote:
> This issue relates to JDK-8250639 '☂ Address reliance on default constructors
> in the java.desktop module'. The changes
> address the reliance on default constructors by adding in basic constructors
> in the following classes:
> -
This issue relates to JDK-8250639 '☂ Address reliance on default constructors
in the java.desktop module'. The changes
address the reliance on default constructors by adding in basic constructors in
the following classes:
- java.awt.Image
- java.awt.PrintJob
- java.awt.font.GlyphVector
-
Hi, Conor
The change looks fine, please note that you will need to crate a PR on the
GitHub to integrate this fix.
* CSR: https://bugs.openjdk.java.net/browse/JDK-8252495The CSR could be
improved, take a look to this example:
https://bugs.openjdk.java.net/browse/JDK-8250581
The body of
Hi everyone.
Thanks for the feedback!
Firstly, I changed the wording from 'Creates' to 'Constructs' as per
Philip's suggestion (and corrected a spelling mistake).
Secondly, for the protected constructors (in the abstract classes) I
used the wording "Constructor for subclasses to call." as
Right we have started to be consistent using "Constructor for subclasses
to call":
Also I prefer constructs over creates, even for the concrete classes, eg
this :
+
+/**
+ * Creates an {@code ImageFilter}.
+ */
+public ImageFilter() {}
+
should be "Constructs an {@code
Hi, Conor.
Please use such spec for the protected constructor: "Constructor for subclasses to
call":
https://cr.openjdk.java.net/~psadhukhan/8250850/webrev.1/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java.sdiff.html
Actually the current text is also fine to me, but looks
Hello all,
Could someone please review my changes for JDK-8250855, 'Address
reliance on default constructors in the Java 2D APIs'? This issue
relates to JDK-8250639 '☂ Address reliance on default constructors in
the java.desktop module'. The changes address the reliance on default
13 matches
Mail list logo
