RFR of JDK-8186610,move ModuleUtils to top-level testlibrary
huaming.li at oracle.com
Thu Oct 11 06:31:56 UTC 2018
Thank you clarifying Igor.
Moving ModuleTargetHelper to local folder has a drawback: it's hard for
future maintainer to found it if they need to use it in other places,
that make it an "*invisible*" library class.
Although I don't fully agree with you, I have updated the webrev as you
On 2018/10/11 11:38 AM, Igor Ignatyev wrote:
> b/c this will make test library modularization somewhat
> troublesome, also I ain't sure if ModuleTargetHelper really needs to
> be placed into the top-level library regardless of its dependency on
> non-public API. "promoting" test library class to the top-level
> library comes w/ increased maintenance costs, the parent task
> explains that in more details.
>  https://bugs.openjdk.java.net/browse/JDK-8211358
>  https://bugs.openjdk.java.net/browse/JDK-8211290
> -- Igor
>> On Oct 10, 2018, at 8:26 PM, Hamlin Li <huaming.li at oracle.com
>> <mailto:huaming.li at oracle.com>> wrote:
>> Hi Igor,
>> Would you please clarify your concern further? I mean why
>> ModuleTargetHelper can be put to top level when it use non-public
>> APIs e.g. jdk.internal.module.*?
>> Thank you
>> On 2018/10/11 11:08 AM, Igor Ignatyev wrote:
>>> Hi Hamlin,
>>> as ModuleTargetHelper uses non-public API, I'd prefer not to have in
>>> a common test library, and 8211976 suggests moving it closer to
>>> tests. could you please explain why you decided to put it into the
>>> library instead?
>>> -- Igor
>>> ----- Original Message -----
>>> From: huaming.li at oracle.com <mailto:huaming.li at oracle.com>
>>> To: core-libs-dev at openjdk.java.net
>>> <mailto:core-libs-dev at openjdk.java.net>
>>> Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada
>>> Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary
>>> Would you please review the following patch?
>>> webrev: http://cr.openjdk.java.net/~mli/8186610/
>>> Thank you
More information about the core-libs-dev