Review Request: JDK-8161121: VM::isSystemDomainLoader should consider platform class loader

[Mandy Chung]

With deprivileging, several modules of the runtime are mow defined to 
the platform class loader.  VM::isSystemDomainLoader is extended to
detect if the given class loader is boot loader or platform loader.

Webrev: 
  http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8161121/webrev.00/index.html

thanks
Mandy

Re: RFR: JDK-8185464: Link issues in java.xml module

[Jonathan Gibbons]

On 07/27/2017 04:58 PM, huizhe wang wrote:

Looks good to me too.

A side issue, the 'fixedNav' block is preventing the browser from 
showing the exact content of an inner anchor, the Nav section covers 
that much of content as its height. If I click on the link to 
CatalogFeatures.html#PREFER for example, I'd get to see DEFER.


Best,
Joe 


I noticed the fixedNav issue when checking this out yesterday, and I 
already filed


8185368: Navbar causes confusing behavior when navigating to a link
https://bugs.openjdk.java.net/browse/JDK-8185368

-- Jon

Re: RFR: JDK-8185464: Link issues in java.xml module

[huizhe wang]

Looks good to me too.

A side issue, the 'fixedNav' block is preventing the browser from 
showing the exact content of an inner anchor, the Nav section covers 
that much of content as its height. If I click on the link to 
CatalogFeatures.html#PREFER for example, I'd get to see DEFER.


Best,
Joe

On 7/27/2017 2:12 PM, Lance Andersen wrote:

On Jul 27, 2017, at 5:10 PM, Jonathan Gibbons  
wrote:

Lance,

It is intentional that the Author designation has disappeared from the 
javax.xml.datatype package summary.

I was just about to send another email, as I realized that we were not using 
-author after I hit send.

Thanks for the follow up :-)

Best
Lance

The following lines

  154  * 
  155  * Author mailto:jeff.sut...@sun.com; 
>Jeff Suttor
were normalized to
  152  * @author mailto:jeff.sut...@sun.com; 
>Jeff Suttor
and since we do not use the -author option when generating the main API doc 
bundle, the author information is not produced in the output. This is the same 
for all other uses of @author in our source code doc comments.  Here is the 
relevant extract from the command-line help:

Provided by the Standard doclet:
 -author   Include @author paragraphs


You can see the differences in the generated output for JDK 9:
http://download.java.net/java/jdk9/docs/api/javax/xml/datatype/package-summary.html 



Author Jeff Suttor 
See W3C XML Schema 1.0 Part 2, Section 3.2.7-14 

See XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration 

See XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration 

Since 1.5
Since:
1.5

(note the non-standard Author and See entries, and the double "Since" info)

and proposed, after the patch,
http://cr.openjdk.java.net/~jjg/8185464/api.00/javax/xml/datatype/package-summary.html
 


Since:
1.5
See Also:
W3C XML Schema 1.0 Part 2, Section 3.2.7-14 , 
XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration 
, XQuery 1.0 and XPath 2.0 Data 
Model, xdt:yearMonthDuration 
-- Jon



On 07/27/2017 01:49 PM, Lance Andersen wrote:

Hi Jon,

Overall it looks good.  Maybe it is my browser, but I do not see the Author tag 
in the DataType package summary though it is there in JDK 8 and looks like it 
should still display unless I am missing something…

Best
Lance

On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons > wrote:

Continuing the documentation cleanup:

Please review the following simple changes to the API documentation for the 
java.xml module,
to address issues with links in these files.

Some missing ids have been declared as appropriate.

The issue with a mailto: link in the public API to an obsolete address has been 
side-stepped
by converting a number of explicit Author and See constructs to the equivalent 
@author and @see
tags. Since we don't publish authors in the generated documentation, that 
addresses the
appearance of the bad mailto: link.  I'll leave it to someone else to take on 
the general task of
cleaning up the many references to obsolete @sun.com  email 
addresses in the source code.

JBS: https://bugs.openjdk.java.net/browse/JDK-8185464 

Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ 

API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html 


-- Jon



 
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 




  
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

[Stuart Marks]

Hi Ivan,

I think this is an interesting avenue to explore adding to the platform. The 
idea of sorting this way is pretty subtle and it seems to come up frequently, so 
it seems valuable. There are some issues that warrant further discussion, 
though. Briefly:


1. Should this be in the JDK?
2. What do other platforms do?
3. Does it have the right semantics?

Discussion follows.


--


1. Should this be in the JDK?

I think a case for it can be made. It does appear in other platforms (see below) 
and there are also several third party implementations available in a variety of 
environments. So people do have a need for this feature. It's also complicated 
enough to have generated lots of discussions and articles on the topic. The 
questions are whether this can be specified sufficiently clearly, and whether it 
provides value for the use cases for which it's intended. It's not obvious 
whether this is true, but I believe a case can and should be made.



2. What do other platforms do?

It was a bit difficult to find information about this, since it doesn't seem to 
have a well established name. Words like "natural", "logical", "alphanum", and 
"mixed" tend to be used. I eventually found these:


Windows XP StrCmpLogicalW [1]:

Compares two Unicode strings. Digits in the strings are considered as
numerical content rather than text. This test is not case-sensitive.

Windows 7 CompareStringEx SORT_DIGITSASNUMBERS [2]

Treat digits as numbers during sorting, for example, sort "2" before "10".

(Note: this API takes a locale parameter.)

Macintosh Mac NSString localizedStandardCompare [3]

This method should be used whenever file names or other strings are
presented in lists and tables where Finder-like sorting is appropriate.
The exact sorting behavior of this method is different under different
locales and may be changed in future releases. This method uses the
current locale.

(Note: I observe that the Mac Finder sorting is case insensitive.)

Swift String.localizedStandardCompare [4]

Compares strings as sorted by the Finder.

There are also third party, open source implementations available for a variety 
of platforms. These aren't too hard to find; this Coding Horror article [5] has 
a discussion of the issues and links to several implementations. Of particular 
note is the short Python implementation embedded in the article.


There is also the Node package javascript-natural-sort [6] which is one of 
several (of course) similar packages on NPM. This one seems popular, with more 
than 200,000 downloads in the past month.


Finally, there is mention of "numericOrdering" in this Unicode TR [7] but it 
seems fairly non-specific, and I don't know how it applies. The point here is 
that the Unicode community is aware of this kind of ordering, and various 
libraries that implement Unicode collation, such as ICU [8], might have 
implementations that can provide guidance.



3. Does it have the right semantics?

I think you can see from the above survey that there is no standard, and 
different implementations are all over the map, and most if not all are 
completely ill-specified. But what is useful about the survey is that it shows 
what people are actually using, and that there are things that many of them have 
in common. Two items jump out at me:


 - case-insensitive comparison (sometimes optional)
 - locale-specific collation

The obvious (but simplistic) thing to do is to provide variations of this API 
that can use String.CASE_INSENSITIVE_ORDER. Note however that its doc 
specifically states that it provides "unsatisfactory ordering for certain 
locales" and directs the reader to the Collator class, which does take locale 
into account.


Now, I'm sensitive about making this more complicated than necessary. But the 
point of "logical" comparator is to provide something that makes sense to humans 
looking at the result, which implies that locale-specific collation needs to be 
applied, as well as case insensitivity (which itself is locale-specific). So I 
think consideration of those is indeed necessary.


I don't know what the API should look like. The java.text.Collator class 
implements Comparator. This suggests the possibility of an API that allows a 
"downstream" comparator to be specified, to which ordering of certain 
subsequences can be delegated.


s'marks



[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/bb759947(v=vs.85).aspx

[2] 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761(v=vs.85).aspx

[3] 
https://developer.apple.com/documentation/foundation/nsstring/1409742-localizedstandardcompare?language=objc


[4] 
https://developer.apple.com/documentation/swift/string/1408384-localizedstandardcompare


[5] https://blog.codinghorror.com/sorting-for-humans-natural-sort-order/

[6] https://www.npmjs.com/package/javascript-natural-sort

[7] http://unicode.org/reports/tr35/tr35-collation.html#Setting_Options

[8] 

Re: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570

[Martin Buchholz]

Some ancient history: I wrote those ProcessBuilder tests back in 2005 and
tripped over the changes to NLSPATH and XFILESEARCHPATH.  I filed a bug
back then, but it did not get fixed.  I rediscovered those changes a decade
later when putenv/getenv was found to be the root cause of SIGSEGV in real
world usage.

I had forgotten about my workarounds in the ProcessBuilder test;
rediscovered by recursive grep, which is still my workhorse code
understanding tool.


On Thu, Jul 27, 2017 at 7:13 AM, Philip Race  wrote:

> Ok by me too ... it would not have crossed my mind to look at
> ProcessBuilder
> but I suppose it was trying to support the now deleted behaviours.
>
> -phil.
>
>
> On 7/27/17, 6:29 AM, Alan Bateman wrote:
>
>>
>>
>> On 26/07/2017 22:20, Martin Buchholz wrote:
>>
>>> 1. JDK-8185365 
>>>
>>> Tidy up leftover dead code after JDK-8136570
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/
>>>
>> This looks okay to me.
>>
>> -Alan
>>
>

Re: RFR: JDK-8185464: Link issues in java.xml module

[Lance Andersen]

> On Jul 27, 2017, at 5:10 PM, Jonathan Gibbons  
> wrote:
> 
> Lance,
> 
> It is intentional that the Author designation has disappeared from the 
> javax.xml.datatype package summary. 

I was just about to send another email, as I realized that we were not using 
-author after I hit send.

Thanks for the follow up :-)

Best
Lance
> The following lines
> 
>  154  * 
>  155  * Author mailto:jeff.sut...@sun.com; 
> >Jeff Suttor
> were normalized to
>  152  * @author mailto:jeff.sut...@sun.com; 
> >Jeff Suttor
> and since we do not use the -author option when generating the main API doc 
> bundle, the author information is not produced in the output. This is the 
> same for all other uses of @author in our source code doc comments.  Here is 
> the relevant extract from the command-line help:
> 
> Provided by the Standard doclet:
> -author   Include @author paragraphs
> 
> 
> You can see the differences in the generated output for JDK 9:
> http://download.java.net/java/jdk9/docs/api/javax/xml/datatype/package-summary.html
>  
> 
> 
> 
> Author Jeff Suttor 
> See W3C XML Schema 1.0 Part 2, Section 3.2.7-14 
> 
> See XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration 
> 
> See XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration 
> 
> Since 1.5
> Since:
> 1.5
> 
> (note the non-standard Author and See entries, and the double "Since" info)
> 
> and proposed, after the patch,
> http://cr.openjdk.java.net/~jjg/8185464/api.00/javax/xml/datatype/package-summary.html
>  
> 
> 
> Since:
> 1.5
> See Also:
> W3C XML Schema 1.0 Part 2, Section 3.2.7-14 
> , XQuery 1.0 and XPath 2.0 Data 
> Model, xdt:dayTimeDuration 
> , XQuery 1.0 and 
> XPath 2.0 Data Model, xdt:yearMonthDuration 
> 
> -- Jon
> 
> 
> 
> On 07/27/2017 01:49 PM, Lance Andersen wrote:
>> Hi Jon,
>> 
>> Overall it looks good.  Maybe it is my browser, but I do not see the Author 
>> tag in the DataType package summary though it is there in JDK 8 and looks 
>> like it should still display unless I am missing something…
>> 
>> Best
>> Lance
>>> On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons >> > wrote:
>>> 
>>> Continuing the documentation cleanup:
>>> 
>>> Please review the following simple changes to the API documentation for the 
>>> java.xml module,
>>> to address issues with links in these files.
>>> 
>>> Some missing ids have been declared as appropriate.
>>> 
>>> The issue with a mailto: link in the public API to an obsolete address has 
>>> been side-stepped
>>> by converting a number of explicit Author and See constructs to the 
>>> equivalent @author and @see
>>> tags. Since we don't publish authors in the generated documentation, that 
>>> addresses the
>>> appearance of the bad mailto: link.  I'll leave it to someone else to take 
>>> on the general task of
>>> cleaning up the many references to obsolete @sun.com  
>>> email addresses in the source code.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8185464 
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ 
>>> 
>>> API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html 
>>> 
>>> 
>>> -- Jon
>>> 
>>> 
>> 
>>  
>> 
>>   
>> 
>>  Lance Andersen| 
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> lance.ander...@oracle.com 
>> 
>> 
>> 
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: JDK-8185464: Link issues in java.xml module

[Jonathan Gibbons]

Lance,

It is intentional that the Author designation has disappeared from the 
javax.xml.datatype package summary.  The following lines


 154  * 
 155  * Author mailto:jeff.sut...@sun.com;>Jeff Suttor

were normalized to

 152  * @author mailto:jeff.sut...@sun.com;>Jeff Suttor

and since we do not use the -author option when generating the main API 
doc bundle, the author information is not produced in the output. This 
is the same for all other uses of @author in our source code doc 
comments.  Here is the relevant extract from the command-line help:


Provided by the Standard doclet:
-author   Include @author paragraphs


You can see the differences in the generated output for JDK 9:
http://download.java.net/java/jdk9/docs/api/javax/xml/datatype/package-summary.html


   

 * Author Jeff Suttor 
 * See W3C XML Schema 1.0 Part 2, Section 3.2.7-14
   
 * See XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration
   
 * See XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration
   
 * Since 1.5

   

   Since:
   1.5


(note the non-standard Author and See entries, and the double "Since" info)

and proposed, after the patch,
http://cr.openjdk.java.net/~jjg/8185464/api.00/javax/xml/datatype/package-summary.html

   Since:
   1.5
   See Also:
   W3C XML Schema 1.0 Part 2, Section 3.2.7-14
   , XQuery 1.0 and
   XPath 2.0 Data Model, xdt:dayTimeDuration
   ,
   XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration
   


-- Jon



On 07/27/2017 01:49 PM, Lance Andersen wrote:

Hi Jon,

Overall it looks good.  Maybe it is my browser, but I do not see the 
Author tag in the DataType package summary though it is there in JDK 8 
and looks like it should still display unless I am missing something…


Best
Lance
On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons 
> wrote:


Continuing the documentation cleanup:

Please review the following simple changes to the API documentation 
for the java.xml module,

to address issues with links in these files.

Some missing ids have been declared as appropriate.

The issue with a mailto: link in the public API to an obsolete 
address has been side-stepped
by converting a number of explicit Author and See constructs to the 
equivalent @author and @see
tags. Since we don't publish authors in the generated documentation, 
that addresses the
appearance of the bad mailto: link.  I'll leave it to someone else to 
take on the general task of
cleaning up the many references to obsolete @sun.com  
email addresses in the source code.


JBS: https://bugs.openjdk.java.net/browse/JDK-8185464
Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ 

API: 
http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html 



-- Jon






Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: JDK-8185464: Link issues in java.xml module

[Lance Andersen]

Hi Jon,

Overall it looks good.  Maybe it is my browser, but I do not see the Author tag 
in the DataType package summary though it is there in JDK 8 and looks like it 
should still display unless I am missing something…

Best
Lance
> On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons  
> wrote:
> 
> Continuing the documentation cleanup:
> 
> Please review the following simple changes to the API documentation for the 
> java.xml module,
> to address issues with links in these files.
> 
> Some missing ids have been declared as appropriate.
> 
> The issue with a mailto: link in the public API to an obsolete address has 
> been side-stepped
> by converting a number of explicit Author and See constructs to the 
> equivalent @author and @see
> tags. Since we don't publish authors in the generated documentation, that 
> addresses the
> appearance of the bad mailto: link.  I'll leave it to someone else to take on 
> the general task of
> cleaning up the many references to obsolete @sun.com email addresses in the 
> source code.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8185464
> Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/
> API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html
> 
> -- Jon
> 
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

RFR: JDK-8185464: Link issues in java.xml module

[Jonathan Gibbons]

Continuing the documentation cleanup:

Please review the following simple changes to the API documentation for 
the java.xml module,

to address issues with links in these files.

Some missing ids have been declared as appropriate.

The issue with a mailto: link in the public API to an obsolete address 
has been side-stepped
by converting a number of explicit Author and See constructs to the 
equivalent @author and @see
tags. Since we don't publish authors in the generated documentation, 
that addresses the
appearance of the bad mailto: link.  I'll leave it to someone else to 
take on the general task of
cleaning up the many references to obsolete @sun.com email addresses in 
the source code.


JBS: https://bugs.openjdk.java.net/browse/JDK-8185464
Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/
API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html

-- Jon

Re: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570

[Philip Race]

Ok by me too ... it would not have crossed my mind to look at ProcessBuilder
but I suppose it was trying to support the now deleted behaviours.

-phil.

On 7/27/17, 6:29 AM, Alan Bateman wrote:



On 26/07/2017 22:20, Martin Buchholz wrote:

1. JDK-8185365 

Tidy up leftover dead code after JDK-8136570
http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/

This looks okay to me.

-Alan

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

[Alan Bateman]

On 27/07/2017 10:07, Jaroslav Tulach wrote:

:
Yes, it seems like a desirable goal to let Graal compiler work with just
java.base. Is there a description how to build JDK9/10 with just java.base
that I could follow and test against?
You can use jlink to create a run-time image that only contains 
java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base 
--output smalljre).






If it exposes a MBean, the dependency would be needed.

Isn't there a way to require an optional dependency? That would be sufficient -
as the classes in question are only loaded once java.management searches for
them. E.g. only when java.management is installed.
There is `requires static` but it would be a lot cleaner if the 
management support could be refactored into its own service provider 
module, meaning JVMCIMXBeans would be in its own module.


-Alan

Re: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570

[Alan Bateman]

On 26/07/2017 22:20, Martin Buchholz wrote:

1. JDK-8185365 

Tidy up leftover dead code after JDK-8136570
http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/

This looks okay to me.

-Alan

Re: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570

[Roger Riggs]

Look fine Martin.

Roger

On 7/26/2017 5:20 PM, Martin Buchholz wrote:

1. JDK-8185365 

Tidy up leftover dead code after JDK-8136570
http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

[Chris Hegarty]

> On 26 Jul 2017, at 21:22, Andrey Nazarov  wrote:
> 
> Hi,
> 
> Please review this simple documentation patch
> 
> diff -r a133a7d1007b test/lib/jdk/test/lib/util/FileUtils.java
> --- a/test/lib/jdk/test/lib/util/FileUtils.java   Tue Jul 25 17:04:46 
> 2017 -0700
> +++ b/test/lib/jdk/test/lib/util/FileUtils.java   Wed Jul 26 13:20:44 
> 2017 -0700
> @@ -98,6 +98,7 @@
> while (true) {
> try {
> Files.delete(path);
> +// Checks for absence of the file. Semantics of 
> Files.exists() is not the same.
> while (!Files.notExists(path)) {
> times++;
> if (times > MAX_RETRY_DELETE_TIMES) {

Thank you. Reviewed.

-Chris.

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

[Jaroslav Tulach]

Thanks for your review Mandy.


>> Mandy Chung : 25.07.17 @ 11:39 <<
> > On Jul 25, 2017, at 1:33 AM, Doug Simon  wrote:
> >> On 25 Jul 2017, at 01:37, Mandy Chung  wrote:
> >> 
> >> Vladimir,
> >> 
> >> I believe you don’t want to add the dependency from JVMCI to
> >> java.management.  Otherwise, JVMCI can’t run with only java.base.> 
> > The dependency is unfortunate. Can you suggest how JVMCI platform beans
> > could participate in platform bean registration without the dependency?

Yes, it seems like a desirable goal to let Graal compiler work with just 
java.base. Is there a description how to build JDK9/10 with just java.base 
that I could follow and test against?

> If it exposes a MBean, the dependency would be needed.

Isn't there a way to require an optional dependency? That would be sufficient - 
as the classes in question are only loaded once java.management searches for 
them. E.g. only when java.management is installed.

> One consideration might be to separate the JVMCI MBean provider in its own
> module so that it’s registered only when such module is resolved in the
> module graph.  This way JVMCI can work even if java.management is not
> present.

Yes, I can create something like jdk.internal.vm.ci.management and move the 
JVMCIMXBeans.java (to be renamed to JVMCIMBeans.java per Vladimir's 
suggestion, if I remember correctly) there. This module would have dependency 
on jdk.internal.vm.ci and java.management and bridge them together.

How do I make sure this module is enabled when possible? Or is that automatic?

> >> Is the MBean in jdk.internal.vm.compiler or in Lab’s Graal compiler?
> > 
> > Anything in Lab’s Graal compiler is destined for JDK Graal so the
> > distinction is only temporary at best.
> Good to know.

The bean is in there and implements DynamicMBean interface. E.g. this part of 
Graal compiler module has to have dependency on java.management - that means 
to make that dependency optional or split the module in two, I assume.


> 
> >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/src/jdk/vm/ci/ser
> >> vices/internal/JVMCIMXBeans.java - I suspect this file meant to be in
> >> src/jdk.internal.vm.ci/share/classes/src/jdk.internal.vm.ci/share/classe
> >> s/jdk/vm/ci/services/internal/JVMCIMXBeans.java> 
> > Not sure I follow - there is currently no such directory
> > src/jdk.internal.vm.ci/share/classes/src
> Typo - it’s an existing directory:
> 
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/servic
> es/internal

The location is probably not correct. I am even surprised the code builds fine. 
Thanks for catching this.

-jt
 
> >>> On Jul 12, 2017, at 2:20 PM, Vladimir Kozlov
> >>>  wrote:
> >>> 
> >>> https://bugs.openjdk.java.net/browse/JDK-8182701
> >>> webrev:
> >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/
> >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/
> >>> 
> >>> Contributed by Jaroslav Tulach.
> >>> 
> >>> JDK itself contains quite a lot of platform MBeans which get registered
> >>> "on demand". Graal compiler (jdk.internal.vm.compiler) provides its own
> >>> MBean(s) - however currently there is no way to register it "on
> >>> demand". JDK9 already contains support for collecting platform MBeans
> >>> from various modules. We just need to expose Graal MBean through JVMCI.
> >>> 
> >>> Thanks,
> >>> Vladimir