> Overall, introducing a local variable is more-or-less reasonable even if it's
> used only once. One point is that somebody might come along and "clean
> up" the
> code and inline local variables and reintroduce the problem. Another point is
> that, hypothetically, if in the future Eclipse is chan
On 5/23/19 6:39 AM, Langer, Christoph wrote:
big thanks for your great updates here. This all looks a lot cleaner:
http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/
Great, glad to help. While I'm still unsure about the underlying reasons for
this disagreement between the compilers, th
On 23/05/2019 14:39, Langer, Christoph wrote:
big thanks for your great updates here. This all looks a lot
cleaner:http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/
I concur. Thanks Stuart!
best regards,
-- daniel
gt; Cc: David Holmes ; Daniel Fuchs
> ; core-libs-dev d...@openjdk.java.net>; net-dev ; compiler-
> d...@openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
>
> Hi Christoph,
>
> I'm still not entir
Hi Christoph,
I'm still not entirely sure why this is so, but the introduction of a local
variable in MethodHandles.java seems to make things work for Eclipse. Addition
of a local variable seems to be minimally invasive, so it makes sense to see if
this technique can be applied to other cases.
Stuart's cool type system hack is hard for me to grok, but it seems alright
to put into ConcurrentSkipListMap.java. We could add it to the current
jsr166 integration.
*From: *Stuart Marks
*Date: *Thu, May 16, 2019 at 3:11 PM
*To: *Martin Buchholz, David Holmes, Doug Lea, Langer, Christoph
*Cc:
On 5/14/19 9:16 PM, Martin Buchholz wrote:
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
Regarding the change in this particular file, I'd suggest the following:
diff -r 006dadb903ab -r 92e1fdce45e0
src/java.base/share/classes/java/util/concurrent/ConcurrentS
gt;; net-dev
> Cc: compiler-...@openjdk.java.net; Martin Buchholz
>
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
>
> Hi Christoph,
>
> I'm very reluctant to see changes like this that the compiler folk have
> not de
I feel the same as David - reluctant to change anything. Introducing a raw
type makes an ugly cast uglier.
*From: *David Holmes
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> As you note this should be ok'd by jsr166 folk so I've cc'd Martin
> Buccholz. I
d
Thanks
Christoph
-Original Message-
From: Daniel Fuchs
Sent: Dienstag, 14. Mai 2019 18:04
To: Langer, Christoph ; core-libs-dev ; net-dev
Cc: compiler-...@openjdk.java.net
Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
Eclipse Java Compiler
Hi Christoph
Christoph
> -Original Message-
> From: Daniel Fuchs
> Sent: Dienstag, 14. Mai 2019 18:04
> To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; net-dev
> Cc: compiler-...@openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile wi
Hi Christoph,
That looks much better, thanks!
(but still not commenting on the other changes ;-))
best regards,
-- daniel
On 14/05/2019 13:57, Langer, Christoph wrote:
Hi Daniel,
unfortunately, your proposed solution does not work with javac. I get this
in the build:
Oh darn. I should hav
Hi Daniel,
> > unfortunately, your proposed solution does not work with javac. I get this
> in the build:
>
> Oh darn. I should have double checked.
> Can we at least reduce the scope of the @SuppressedWarnings by
> introducing a private method that just has the return call?
Sure, what about thi
Hi Christoph,
On 13/05/2019 08:29, Langer, Christoph wrote:
Hi Daniel,
unfortunately, your proposed solution does not work with javac. I get this in
the build:
Oh darn. I should have double checked.
Can we at least reduce the scope of the @SuppressedWarnings by
introducing a private method t
Fuchs ; core-libs-dev d...@openjdk.java.net>; net-dev
> Cc: compiler-...@openjdk.java.net
> Subject: RE: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
>
> Hi Daniel,
>
> I fully agree, @SuppressWarnings should be avoided w
> -Original Message-
> From: Daniel Fuchs
> Sent: Donnerstag, 9. Mai 2019 17:24
> To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; net-dev
> Cc: compiler-...@openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
&g
Hi Christoph,
I'm only commenting on the HttpClient changes, I'll let
others comment on the other changes...
http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html
I have a profound dislike for using @SuppressedWa
Hi,
please review a small change that I'd like to see in OpenJDK to get rid of
compilation errors in the Eclipse IDE.
It seems the root cause for the compilation errors is that javac would
sometimes widen capture variables and is hence able to compile the places that
I touch here. The EC4J com
18 matches
Mail list logo
