Hi Daniel, I fully agree, @SuppressWarnings should be avoided wherever possible.
So, thanks for coming up with this alternative suggestion. It works and so I updated my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/ Any reviews for the other 3 files? Thanks Christoph > -----Original Message----- > From: Daniel Fuchs <daniel.fu...@oracle.com> > Sent: Donnerstag, 9. Mai 2019 17:24 > To: Langer, Christoph <christoph.lan...@sap.com>; core-libs-dev <core-libs- > d...@openjdk.java.net>; net-dev <net-dev@openjdk.java.net> > Cc: compiler-...@openjdk.java.net > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the > Eclipse Java Compiler > > 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/s > hare/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html > > I have a profound dislike for using @SuppressedWarnings, unless > it's the only alternative. My preference would be to introduce > local variables, if that can make the compiler happy, until such time > where the issue is actually resolved... > > For instance, it seems that the following would work: > > // Use local variable assignments to keep other java compilers > // happy and avoid unchecked casts warnings > BiFunction<Http2Connection, Throwable, CompletableFuture<? extends > ExchangeImpl<U>>> > factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange, > connection); > Function<CompletableFuture<? extends ExchangeImpl<U>>, > CompletableFuture<? extends ExchangeImpl<U>>> > identity = (cf) -> cf; > return c2f.handle(factory).thenCompose(identity); > > > best regards, > > -- daniel > > On 08/05/2019 09:02, Langer, Christoph wrote: > > 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 compiler claims that it's following > > the spec more strictly and bails out at these places. I had posted about > > this on compiler-dev but got no reaction [0]. > > > > So, as this seems to be some field of open work for the compiler/spec > > folks, I'd like to get EC4J quiesced by introducing some slight > > modifications to the original places which makes the code appeal a bit > > less elegant and fluent but will get rid of the compile errors. > > > > Please review: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ > > > > The modification to > > > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav > a > > belongs to JSR-166, so I don't know if it needs some special handling. > > > > Thanks & Best regards > > > > Christoph > > > > [0] > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019- > March/013054.html > >
