On 11/5/2020 4:45 AM, Jan Lahoda wrote:
FWIW, a javadoc generated with the current version of the patch:
http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
Allow me to draw people's attention to the PREVIEW link in the banner of
the generated javadoc. It shows all the pr
On 9/23/2020 5:26 PM, Mandy Chung wrote:
What is the policy of `@since` release value when a preview API
becomes final.I would expect `@since` should be updated from 14
to 16 because 16 is the Java SE release these APIs are added??
Yes. Per
http://openjdk.java.net/jeps/12#Specifications-of
I attached text-blocks-jls.html which contains the current unified text
blocks + new escape sequences spec. Edited the CSR's Specification
section refer specifically to section 3.10.7 of the attachment rather
than reproducing some of that section. Made some small edits elsewhere
related to havi
This should be answered in JEP 368, which currently introduces \s with
its definition rather than a connecting line back to the final line of
the Motivation. JEP 355 had text about the octal escape sequence \040
and now Remi has raised \u0020 -- both should be positioned in 368 as
less-clear op
On 10/16/2019 5:50 AM, Jan Lahoda wrote:
-loosened the handling of essential preview APIs when --enable-preview
and @SuppressWarnings is applied - there is no warning for the essential
APIs (as there is no warning in such a case for non-essential APIs).
This is per the discussion in the CSR:
h
On 6/10/2019 12:54 PM, Joe Darcy wrote:
It is fair for the top-level interfaces to more fully discuss type vs
declaration annotations. Such top-level discussion is a complement to
introducing a statement of the type vs declaration distinction in the
method-as-implemented/overridden-in-this-paricu
On 6/8/2019 4:04 PM, Joe Darcy wrote:
Please review the doc clarifications to address
JDK-708660: (reflect) Clarifications to javadoc for getGeneric*Type
methods in j.l.r
webrev: http://cr.openjdk.java.net/~darcy/7086604.0/
specdiff:
http://cr.openjdk.java.net/~darcy/7086604.0.spe
It's a bit heavy to cite a JLS section in the summary of a method.
Recommend:
"Returns a string whose value is this string, with escape sequences
translated as if in a string literal." [Not mentioning text blocks for
simplicity. Plus, if you mention them, then it looks like you forgot
charac
On 5/21/2019 4:19 PM, Alex Buckley wrote:
On 5/21/2019 2:10 PM, Jim Laskey wrote:
Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02
API spec looks good, but it was a surprise to learn that stripIndent
performs normalization of line terminators:
"@return string
On 5/21/2019 2:10 PM, Jim Laskey wrote:
Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02
This webrev substantially updates the API spec, which is really a topic
for amber-spec-experts (keep reading to see why). Cross-posting between
-dev and -spec-experts lists is not goo
On 5/21/2019 7:56 AM, Jim Laskey wrote:
Please do a code review of the new String::stripIndent instance method.
My interest is in the API spec because the JLS will make normative
reference to it.
"Removes horizontal white space margins from the essential body of a
Text Block originated stri
On 4/28/2017 3:39 PM, Paul Sandoz wrote:
On 28 Apr 2017, at 14:55, Alex Buckley wrote:
On 4/26/2017 4:06 PM, Paul Sandoz wrote:
Please review some documentation changes to VarHandle:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-varhandle-docs/webrev/index.html
I notice that "
On 4/26/2017 4:06 PM, Paul Sandoz wrote:
Please review some documentation changes to VarHandle:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-varhandle-docs/webrev/index.html
I notice that "shape" is still mentioned throughout the
MethodHandles.Lookup class.
59 * {@code CT1, CT2, ..
Option A: If the annotation @Documented is present on the declaration of
an annotation type T, then any @T annotation on an element is considered
part of the element's public contract.
Option B: The annotation type Documented is used to indicate that
annotations of a given annotation type (nam
On 12/3/2013 9:23 PM, Joe Darcy wrote:
+ *
+ * There are several compatibility concerns to keep in mind if an
+ * annotation type T is not repeatable in one release
+ * of a library and retrofitted to be repeatable in a subsequent
+ * release.
The term "retrofitted" is linguistically correct bu
The text you quoted ("When the new...") is a high-level explanation - a
policy - of how Core Reflection should work. The text then proceeds to
give definitions suitable for the API spec: "This policy for Java SE 8
is reified in the following definitions: ...".
Alex
On 10/22/2013 7:06 AM, Pete
On 9/4/2013 8:30 AM, Peter Levart wrote:
At getDeclaredMethods() the 2nd paragraph says:
"If this Class object represents a type that has multiple declared
methods with the same name and parameter types, but different return
types, then the returned array has a Method object for each such method
-spec-discuss, since
it needs to correspond with compile-time constraints.
Alex
On 1/31/2013 12:13 PM, Alex Buckley wrote:
On 1/31/2013 9:45 AM, Joe Darcy wrote:
With Joel's recent push of 8005712, the repeating annotations feature
has now transitioned from using the pair of annotation
On 1/31/2013 9:45 AM, Joe Darcy wrote:
With Joel's recent push of 8005712, the repeating annotations feature
has now transitioned from using the pair of annotation types
{ContainedBy, ContainerFor} to the single Repeatable annotation.
Please review the removal of the pair of old types:
800
This is a design/spec question, so should be discussed on
enhanced-metadata-spec-discuss, not core-libs-dev.
Alex
On 1/24/2013 11:33 AM, Eric McCorkle wrote:
The current version of the spec for parameter reflection, found here:
http://cr.openjdk.java.net/~abuckley/8misc.pdf
states that if a
Hi Remi,
Rémi Forax wrote:
Because in my opinion, there is a bug in the JLS3 regarding covariant
return type.
No, there isn't.
Let us take an example, a library defines Buffer and SubBuffer
public class Buffer {
Buffer duplicate() { ... }
}
public class SubBuffer extends Buffer {
}
And i'v
21 matches
Mail list logo
