Hi Serguei, thanks for the review. The reordering of the imports was done by my Eclipse tooling. And as it builds (and also jtreg did not show a regression (on Windows)), I would suspect it is ok.
Best regards Christoph From: serguei.spit...@oracle.com [mailto:serguei.spit...@oracle.com] Sent: Mittwoch, 28. Juni 2017 10:04 To: Langer, Christoph <christoph.lan...@sap.com>; serviceability-dev@openjdk.java.net Subject: Re: RFR 10 (L): 8183012: Code cleanup in com.sun.tools.jdi Hi Christoph, It looks good to me. I do not have time to check the imports and their sorting. Thanks a lot for the cleanup! Serguei On 6/27/17 12:09, Langer, Christoph wrote: Hi, I’ve got another contribution for cleaning up the jdk.jdi classes. This time it’s about package com.sun.tools.jdi. Bug: https://bugs.openjdk.java.net/browse/JDK-8183012 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8183012.0/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8183012.0/> What I’ve done: I’ve largely cleaned up the import statements (removing obsolete imports, expanding “*” wildcards, sorting). Furthermore I did quite a few whitespace cleanups to make the code look nicer. And I removed the types in constructors of typed classes. The more interesting stuff which should probably closely be reviewed is the following: a) Remove unnecessary casts in BooleanValueImpl.java, ByteValueImpl.java, CharValueImpl.java, FloatValueImpl.java, LongValueImpl.java, PacketStream.java, ShortValueImpl.java b) Remove redundant super interfaces in the class declarations of ClassLoaderReferenceImpl.java, ConnectorImpl.java, RawCommandLineLauncher.java, SunCommandLineLauncher.java, ThreadGroupReferenceImpl.java, ThreadReferenceImpl.java c) ObjectReferenceImpl.java: Remove some code in void validateClassMethodInvocation(Method method, int options). Some very old comment suggests that the code was still there because nobody divined what it was useful for. But I couldn’t find anything that seems to be really useful here, except if the caller maybe wants to get some exception if such occurred in the course of resolving the class or something like that. d) SocketTransportService.java: pull out SocketConnection to an own file SocketConnection.java, pull class SocketTransportServiceCapabilities into anonymous class within SocketTransportService.capabilities() e) RawCommandLineLauncher.java, SunCommandLineLauncher.java: Modifications to constructing the TransportService object in its constructors Module jdk.jdi still builds without warnings after my change and I’m currently running the jdi jtreg suite. Thanks in advance and best regards Christoph
