RE: RFR: 8078820: Test deploying a XML parser as a module

2016-04-20 Thread Frank Yuan
> -Original Message- > From: huizhe wang [mailto:huizhe.w...@oracle.com] > Sent: Wednesday, April 20, 2016 1:19 PM > Subject: Re: RFR: 8078820: Test deploying a XML parser as a module > > > On 4/19/2016 12:52 AM, Frank Yuan wrote: > > > >> -Original Message- > >> From: Alan Batema

Re: #ReflectiveAccessByInstrumentationAgents

2016-04-20 Thread Alan Bateman
On 19/04/2016 18:00, Andrew Dinn wrote: : I have been building and testing on JDK9 Byteman using the EA program releases and have not seen anything break so far. However, that may just be because i) Byteman and the Byteman tests are only using runtime classes from the java base module and ii) ap

Re: JMH and JDK9

2016-04-20 Thread Sanne Grinovero
On Tue, Apr 5, 2016 at 3:16 PM, Andrew Dinn wrote: > On 05/04/16 11:17, Alan Bateman wrote: > . . . >> We recently updated JEP 261 proposing that "java.se" be the only java.* >> root module that is resolved when compiling code in the unnamed module >> or at runtime when the main class is loaded

Root modules (was Re: JMH and JDK9)

2016-04-20 Thread Alan Bateman
(dropping hotspot-dev and change the subject line as this discussion thread has moved on) On 20/04/2016 13:28, Sanne Grinovero wrote: : Agreed: excellent idea! I'm eager to try it out so that we can resume testing of everything else too; I just tried my luck with build 9-ea+114 but it didn't

RE: JMH and JDK9

2016-04-20 Thread Stephen Felts
There was a bug that was just fixed yesterday such that the Java EE classes were not hidden. It should have been fixed in the last nightly 114 build. As long as the necessary Java EE API classes are on the classpath, no command line options are needed. If you have the Java EE JTA API jar in the

8154707: java/util/ServiceLoader/modules/BasicTest.java failing

2016-04-20 Thread Alan Bateman
The changes to for JDK-8077360 [1] broke one of our test so it's failing in jdk9/dev now. As it happens, the test isn't really that useful anyway because the code is exercised by many other tests. So I think we can just make is miscellaneous test for now and replace when we do the next phase

Re: 8154707: java/util/ServiceLoader/modules/BasicTest.java failing

2016-04-20 Thread Chris Hegarty
> On 20 Apr 2016, at 16:37, Alan Bateman wrote: > > > The changes to for JDK-8077360 [1] broke one of our test so it's failing in > jdk9/dev now. > > As it happens, the test isn't really that useful anyway because the code is > exercised by many other tests. So I think we can just make is mi

Re: RFR: 8078820: Test deploying a XML parser as a module

2016-04-20 Thread huizhe wang
On 4/20/2016 12:52 AM, Frank Yuan wrote: Thanks, pushed. I would like to update the test anytime for the related bug or new API(e.g. Alan mentioned JDK-8129104) when you need. Thanks! Will let you know when we make progress on this. -Joe Frank

error reading module path

2016-04-20 Thread Jim Laskey (Oracle)
Periodically, when doing an incremental build I run into the following; Error: error reading module path java.io.IOException: error reading module path at jdk.tools.jmod.JmodTask$JmodFileWriter.hashDependences(jdk.jlink/JmodTask.java:585) at jdk.tools.jmod.JmodTask$JmodFileWriter.writeModuleInfo

Re: [9] Review request: 8153872: Nashorn no longer needs access to com.sun.javafx.application

2016-04-20 Thread Mandy Chung
> On Apr 19, 2016, at 8:25 AM, Kevin Rushforth > wrote: > > Jim, > > Please review the following fix: > > https://bugs.openjdk.java.net/browse/JDK-8153872 > http://cr.openjdk.java.net/~kcr/8153872/webrev.00/ > > This is a simple backout of the earlier fix for JDK-8153754. +1 Glad that this