> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated for a constructor `A()` in a class `A`
> when the compiler
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated for a constructor `A()` in a class `A`
> when the compiler
On Sat, 7 Jan 2023 18:03:04 GMT, Alan Bateman wrote:
> I don't think the implementation notes should be included as part of the
> adding the lint warning as I think it creates an attractive nuisance.
I agree with you - not only for that reason, but also because as others have
pointed out the a
On Fri, 6 Jan 2023 23:08:27 GMT, Archie L. Cobbs wrote:
> I've moved the `@SuppressWarnings` annotations onto a new branch
> `ThisEscapeAnnotations`. This is just for future reference in case somebody
> wants to add them back someday and doesn't want to start from scratch.
>
> > I suspect some
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated for a constructor `A()` in a class `A`
> when the compiler
On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is gener
I’ve started working on the RFE mentioned in the title. At the moment
I’ve implemented the method in |BaseStream| in order to cover every
stream type: is that alright or should I restrict it to |Stream|? And if
there’s anything else that I should know, then please let me know. Thanks.
On Fri, 6 Jan 2023 22:38:13 GMT, Justin Lu wrote:
> When ID is null, TimeZone.getTimeZone(String ID) throws a
> NullPointerException.
>
> For example,
>
>
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ```
>
> throws a `NullPointerException`
>
> This change updat
On Wed, 4 Jan 2023 21:49:18 GMT, Justin Lu wrote:
> Within _test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java_
>
> GregorianCalendar alone handles all the necessary imports, Calendar is not
> needed
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.org/
On Fri, 6 Jan 2023 21:59:13 GMT, Justin Lu wrote:
>> Removed constructors of primitive wrapper classes (deprecated for removal)
>> in _javax.xml.stream.XMLOutputFactory_
>>
>> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE
>
> Justin Lu has updated the pull request increme
On Fri, 6 Jan 2023 21:15:38 GMT, Mandy Chung wrote:
>> Trivial fix. Fix `Invokers.checkExactType` to call
>> `newWrongMethodTypeException(actual, expected)` with parameters in right
>> order.
>
> Mandy Chung has updated the pull request incrementally with two additional
> commits since the la
On Fri, 6 Jan 2023 17:57:47 GMT, Naoto Sato wrote:
> Due to the fact that JLine spawns native processes to obtain terminal
> information on macOS/Linux, we decided to disable the JLine by default for
> performance degradation reasons. It is still possible to enable it by
> specifying it on the
12 matches
Mail list logo