From robert.field at oracle.com  Thu Sep  5 21:36:13 2019
From: robert.field at oracle.com (Robert Field)
Date: Thu, 5 Sep 2019 14:36:13 -0700
Subject: RFR 8210527: NullPointerException in
 jdk.jshell.Eval.translateExceptionStack
In-Reply-To: <8ff12294-eb70-5fff-e27e-a25b5193d54e@oracle.com>
References: <8ff12294-eb70-5fff-e27e-a25b5193d54e@oracle.com>
Message-ID: <e455ae1f-be38-93e2-34f4-50ac2e756c78@oracle.com>

I'm still looking for a review.

Thanks,
Robert


On 8/26/19 6:09 PM, Robert Field wrote:
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8210527
>
> Webrev:
>
> http://cr.openjdk.java.net/~rfield/8210527/
>
>
> Thanks,
> Robert
>
>

From talden at gmail.com  Mon Sep 16 04:19:50 2019
From: talden at gmail.com (Aaron Scott-Boddendijk)
Date: Mon, 16 Sep 2019 16:19:50 +1200
Subject: RFR 8210527: NullPointerException in
 jdk.jshell.Eval.translateExceptionStack
In-Reply-To: <e455ae1f-be38-93e2-34f4-50ac2e756c78@oracle.com>
References: <8ff12294-eb70-5fff-e27e-a25b5193d54e@oracle.com>
 <e455ae1f-be38-93e2-34f4-50ac2e756c78@oracle.com>
Message-ID: <CAE=ECuRxNcqU4rD_jYBMHPq0t21hG=hcpjae=QLveDcao1xoUQ@mail.gmail.com>

I'm curious about the policies within the JDK and whether there's a reason
not to follow a policy we practice.

In the supplied web-rev, the bug is identified as 'r.getFileName()'
resolving to null and then attempting to dereference null to invoke equals
against a literal argument.

That is attempting to evaluate:

    r.getFileName().equals("<none>")

The solution presented has been to explicitly add a null check:

    r.getFileName() != null && r.getFileName().equals("<none>")

In this scenario our practices would result in inverting the subject and
target of the equals call:

    "<none>".equals(r.getFileName())

Here as the literal is never null and the contract for equals specifies the
result is false if the target is null, the solution evaluates the getter
only once and is overall simpler.

Is there a reason not to do this? It seems to be a common recommendation of
static analysis tools. The only reason that I can think of, is to more
clearly indicate that r.getFileName() _could_ be null.

Could this result in less favourable optimisation?

--
Aaron Scott-Boddendijk


On Fri, Sep 6, 2019 at 9:38 AM Robert Field <robert.field at oracle.com> wrote:

> I'm still looking for a review.
>
> Thanks,
> Robert
>
>
> On 8/26/19 6:09 PM, Robert Field wrote:
> > Bug:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8210527
> >
> > Webrev:
> >
> > http://cr.openjdk.java.net/~rfield/8210527/
> >
> >
> > Thanks,
> > Robert
> >
> >
>

From jan.lahoda at oracle.com  Fri Sep 20 12:34:01 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 20 Sep 2019 14:34:01 +0200
Subject: RFR: JDK-8199907: JShell: NoSuchFieldError occurred due to accessing
 variables of intersection type inferred by `var`
Message-ID: <cdd6fc91-7044-ea26-d3ad-3a25d69d224c@oracle.com>

Hi,

I ran into JDK-8199907 again - I apologize for missing it before.

I think Shinya's patch from:
https://mail.openjdk.java.net/pipermail/kulla-dev/2018-March/002248.html

is fine. But I'd like to enhance that a little, so that when the type of 
the variable changes (e.g. because of a change in the return type of a 
method that is called in the initializer), it is automatically 
recomputed (please see 
VariablesTest.lvtiRecompileDependentsWithIntersectionTypes2 for an example).

Proposed patch:
http://cr.openjdk.java.net/~jlahoda/8199907/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8199907

Thanks,
     Jan

From joe.darcy at oracle.com  Thu Sep 26 17:44:46 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 26 Sep 2019 10:44:46 -0700
Subject: JDK 14 RFR of JDK-8231545: Suppress warnings on non-serializable
 instance fields in jdk.jshell module
Message-ID: <9e6b38fa-1c0a-9b11-f291-5697c9264baa@oracle.com>

Hello,

Another part of the cleanup of library serialization usage ahead of 
augmented javac -Xlint warnings (JDK-8160675), the non-serializable 
instance fields of serializable types in the jdk.jshell module should 
have their serial warnings suppressed.

The analogous issue in core libs is JDK-8231202.

Patch below.

Thanks,

-Joe

diff -r e23e560afbcb 
src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java
--- a/src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java 
Wed Sep 25 21:26:38 2019 -0700
+++ b/src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java 
Thu Sep 26 10:43:05 2019 -0700
@@ -149,6 +149,7 @@
 ???? private static class Result extends Error {

 ???????? static final long serialVersionUID = -5942088234594905629L;
+??????? @SuppressWarnings("serial") // Not statically typed as 
Serializable
 ???????? final TreePath expressionPath;

 ???????? Result(TreePath path) {