From robert.field at oracle.com  Wed Oct  2 02:47:43 2019
From: robert.field at oracle.com (Robert Field)
Date: Tue, 1 Oct 2019 19:47:43 -0700
Subject: JDK 14 RFR of JDK-8231545: Suppress warnings on non-serializable
 instance fields in jdk.jshell module
In-Reply-To: <9e6b38fa-1c0a-9b11-f291-5697c9264baa@oracle.com>
References: <9e6b38fa-1c0a-9b11-f291-5697c9264baa@oracle.com>
Message-ID: <94440397-f01a-a495-5d3f-6becd283d6f9@oracle.com>

Thumbs up!

-Robert


On 9/26/19 10:44 AM, Joe Darcy wrote:
> 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) {
>

From robert.field at oracle.com  Wed Oct  2 03:28:39 2019
From: robert.field at oracle.com (Robert Field)
Date: Tue, 1 Oct 2019 20:28:39 -0700
Subject: RFR: JDK-8199907: JShell: NoSuchFieldError occurred due to
 accessing variables of intersection type inferred by `var`
In-Reply-To: <cdd6fc91-7044-ea26-d3ad-3a25d69d224c@oracle.com>
References: <cdd6fc91-7044-ea26-d3ad-3a25d69d224c@oracle.com>
Message-ID: <fe95714b-2308-c976-92a1-3b8e43a53516@oracle.com>

Thanks for doing this.

The methods in Unit tend to be called in the main live snippet recursive 
loop.? So, performance can matter.? Calling TreeDissector for every 
variable (an extra compilation step) might be an issue.? For explicitly 
typed variables this is unneeded. 'var' didn't exist when the API was 
created, can we, at least in the internal VarSnippet, a query for 
inferred type variables, and test that in this case?

I know the existing source documentation is sparse, but I'd love brief 
method comments, it will make it easier to maintain (now, and as time 
goes on) and easier to review.

Thanks,
Robert


On 9/20/19 5:34 AM, Jan Lahoda wrote:
> 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