On 6/28/17 01:43, Langer, Christoph wrote:

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.



Yes, I'm thinking about the same.
Thank you for the confirmation.
-Serguei


 

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/

 

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

 

 


Reply via email to