Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Alan Bateman



On 01/04/2016 06:27, Sundararajan Athijegannathan wrote:

That is true of shell scripts too. i.e., existing code generates shell
scripts on Windows too  (although those shell scripts seem to run fine
under Cygwin).

Do you think we should filter out? Cross-platform image generation scenario?

As I recall, the .sh is generated on Windows for those that might run it 
from Cygwin so I think okay to leave that. The main thing is only 
generate the .bat on Windows.


I think we can rid of the !Files.exists test for both the shell and .bat 
case.


-Alan.


Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Mandy Chung
I think we should generate .bat on windows and shell scripts on other 
platforms.  Generating two scripts are confusing.

Mandy

> On Mar 31, 2016, at 10:27 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> That is true of shell scripts too. i.e., existing code generates shell
> scripts on Windows too  (although those shell scripts seem to run fine
> under Cygwin).
> 
> Do you think we should filter out? Cross-platform image generation scenario?
> 
> -Sundar
> 
> On 4/1/2016 10:54 AM, Mandy Chung wrote:
>>> On Mar 31, 2016, at 9:20 PM, Sundararajan Athijegannathan 
>>>  wrote:
>>> 
>>> Please review the updated webrev @
>>> http://cr.openjdk.java.net/~sundar/8136645/webrev.02/
>> 
>> This version still generates .bat for all platforms as opposed to generate 
>> it for windows only.
>> 
>> Mandy
> 



Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Sundararajan Athijegannathan
That is true of shell scripts too. i.e., existing code generates shell
scripts on Windows too  (although those shell scripts seem to run fine
under Cygwin).

Do you think we should filter out? Cross-platform image generation scenario?

-Sundar

On 4/1/2016 10:54 AM, Mandy Chung wrote:
>> On Mar 31, 2016, at 9:20 PM, Sundararajan Athijegannathan 
>>  wrote:
>>
>> Please review the updated webrev @
>> http://cr.openjdk.java.net/~sundar/8136645/webrev.02/
>
> This version still generates .bat for all platforms as opposed to generate it 
> for windows only.
>
> Mandy



Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Mandy Chung

> On Mar 31, 2016, at 9:20 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review the updated webrev @
> http://cr.openjdk.java.net/~sundar/8136645/webrev.02/


This version still generates .bat for all platforms as opposed to generate it 
for windows only.

Mandy

Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Sundararajan Athijegannathan
Please review the updated webrev @
http://cr.openjdk.java.net/~sundar/8136645/webrev.02/

* Changed "\n" to "\r\n"
* Removed POSIX/bits change code

Thanks,
-Sundar

On 4/1/2016 8:22 AM, Sundararajan Athijegannathan wrote:
> Hi,
>
> Comments below..
>
> On 4/1/2016 3:03 AM, Dmitry Samersoff wrote:
>> Sundararajan,
>>
>> Occasionally put my nose in. Just $0.2 ...
>>
>> 1. Do we really need separate .append("\n")? Also Windows convention is
>> "\r\n"
> I think so. Perhaps System.getProperty("line.separator") could be used.
> I'll fix it.
>
> Didn't realize it because cygwin is my development shell and did just
> "cat" on the generated file to view it :) Thanks!
>
>> 2. Is it possible to name a module using other languages (e.g. Russian
>> or Japanese). Is StandardCharsets.ISO_8859_1 appropriate in this case?
> Hmm.. This part remains the same as in Unix shell script generation
> (just above the newly added code).  Not sure if that is practically a
> big issue...
>
>> 3. Is PosixFileAttributeView.class appropriate here? If yes - please add
>> a comment, because name is misleading.
> Changing executable bits on? I'll add comment.
>
> Thanks,
> -Sundar
>
>> -Dmitry
>>
>> On 2016-03-31 20:38, Sundararajan Athijegannathan wrote:
>>> Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for
>>> https://bugs.openjdk.java.net/browse/JDK-8136645
>>>
>>> Thanks,
>>> -Sundar
>>>



Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Sundararajan Athijegannathan
Hi,

Comments below..

On 4/1/2016 3:03 AM, Dmitry Samersoff wrote:
> Sundararajan,
>
> Occasionally put my nose in. Just $0.2 ...
>
> 1. Do we really need separate .append("\n")? Also Windows convention is
> "\r\n"

I think so. Perhaps System.getProperty("line.separator") could be used.
I'll fix it.

Didn't realize it because cygwin is my development shell and did just
"cat" on the generated file to view it :) Thanks!

> 2. Is it possible to name a module using other languages (e.g. Russian
> or Japanese). Is StandardCharsets.ISO_8859_1 appropriate in this case?

Hmm.. This part remains the same as in Unix shell script generation
(just above the newly added code).  Not sure if that is practically a
big issue...

> 3. Is PosixFileAttributeView.class appropriate here? If yes - please add
> a comment, because name is misleading.

Changing executable bits on? I'll add comment.

Thanks,
-Sundar

> -Dmitry
>
> On 2016-03-31 20:38, Sundararajan Athijegannathan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for
>> https://bugs.openjdk.java.net/browse/JDK-8136645
>>
>> Thanks,
>> -Sundar
>>
>



hg: jigsaw/jake/jdk: 3 new changesets

2016-03-31 Thread mandy . chung
Changeset: 20ec0c69d3e2
Author:mchung
Date:  2016-03-31 11:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/20ec0c69d3e2

8153125: rmic from bootcycle build should launch with -m 
jdk.rmic/sun.rmi.rmic.Main
Reviewed-by: alanb, erikj

! make/rmic/RmicCommon.gmk

Changeset: 8e865b6d3ead
Author:mchung
Date:  2016-03-31 11:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e865b6d3ead

8153211: Convert build tool to use the new -XaddExports syntax in bootcycle 
build
Reviewed-by: alanb

! make/gendata/GendataBreakIterator.gmk

Changeset: ac512b5fa6d5
Author:mchung
Date:  2016-03-31 14:11 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ac512b5fa6d5

8153217: javafx modules are not included in the jre
Reviewed-by: alanb

! make/gensrc/GensrcModuleLoaderMap.gmk



hg: jigsaw/jake: 2 new changesets

2016-03-31 Thread mandy . chung
Changeset: fb3b49e0593e
Author:mchung
Date:  2016-03-31 18:15 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/fb3b49e0593e

Use jtreg 4.2 nightly

! common/conf/jib-profiles.js

Changeset: 97b420bd2845
Author:mchung
Date:  2016-03-31 14:11 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/97b420bd2845

8153217: javafx modules are not included in the jre
Reviewed-by: alanb

! make/Images.gmk
! make/common/Modules.gmk



hg: jigsaw/jake/nashorn: 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build

2016-03-31 Thread mandy . chung
Changeset: 38fb8799f2c1
Author:mchung
Date:  2016-03-31 11:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/38fb8799f2c1

8153211: Convert build tool to use the new -XaddExports syntax in bootcycle 
build
Reviewed-by: alanb

! make/BuildNashorn.gmk



Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

2016-03-31 Thread Mandy Chung

> On Mar 31, 2016, at 4:10 PM, Mandy Chung  wrote:
> 
> 
>> On Mar 30, 2016, at 9:17 AM, Claes Redestad  
>> wrote:
>> 
>> Hi Peter,
>> 
>> something like this, then:
>> 
>> http://cr.openjdk.java.net/~redestad/8152641/webrev.05/
>> 
> 
> BoundMethodHandle::generateConcreteBMHClassBytes
>   It only allows “LIJFD” characters.  But the default species types include 
> digit e.g. L3, L4, etc.  Do you see the warnings generated from 
> GenerateBMHClassesPlugin?

Ignore this comment - I meant to take it out but forgot.

Mandy

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

2016-03-31 Thread Mandy Chung

> On Mar 30, 2016, at 9:17 AM, Claes Redestad  wrote:
> 
> Hi Peter,
> 
> something like this, then:
> 
> http://cr.openjdk.java.net/~redestad/8152641/webrev.05/
> 

BoundMethodHandle::generateConcreteBMHClassBytes
   It only allows “LIJFD” characters.  But the default species types include 
digit e.g. L3, L4, etc.  Do you see the warnings generated from 
GenerateBMHClassesPlugin?

Nit: the method parameters are wrapped in the next line with 8-space 
indentation. It’d be better to follow the convention this source file uses.

GenerateBMHClassesPlugin::configure
   The plugin should validate of the input argument and throw an exception if 
it’s invalid.  The plugin API is still being revised and JDK-8152800 is related 
to the exception case.  The existing plugins throw PluginException.  
GenerateBMHClassesPlugin can do the same.

   Perhaps the expanded signatures should be stored after validation.

GenerateBMHClassesPlugin::generateConcreteClass
   It issues a warning if any exception thrown.  If the user specifies the 
types in the command line, they should specify the valid values (I would 
expect).  I prefer it to be an error and throw PluginException.

It may be time to rename this plugin to —-generate-jli-classes plugin, as John 
suggests.  A jlink plugin can define its sub options e.g. 
—-generate-jli-classes=bmh[:species=LL,LLL].

Can you add a test to sanity test if the classes are generated (both the 
default species types as well as specified in the input argument)?

Mandy

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

2016-03-31 Thread Mandy Chung

> On Mar 29, 2016, at 4:03 PM, Claes Redestad  wrote:
> 
> Mandy: I've not found any test (under jdk/test/tools/jlink or elsewhere) which
> has to be updated when adding a plugin like this.

jdk/test/tools/jlink/JLinkTest.java

This is the one I recalled.  This is in the core_tools or tier2 test group.  
The jlink tests are not run in the default test group.

Mandy

Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Dmitry Samersoff
Sundararajan,

Occasionally put my nose in. Just $0.2 ...

1. Do we really need separate .append("\n")? Also Windows convention is
"\r\n"

2. Is it possible to name a module using other languages (e.g. Russian
or Japanese). Is StandardCharsets.ISO_8859_1 appropriate in this case?

3. Is PosixFileAttributeView.class appropriate here? If yes - please add
a comment, because name is misleading.

-Dmitry

On 2016-03-31 20:38, Sundararajan Athijegannathan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8136645
> 
> Thanks,
> -Sundar
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Alan Bateman



On 31/03/2016 19:31, Sundararajan Athijegannathan wrote:

Please review updated webrev @
http://cr.openjdk.java.net/~sundar/8136645/webrev.01/

PS. Fixed "/" with "\" in "java" path. The generated batch file worked
in either case - but changing for consistency.


Does this generate the .bat on all platforms?

-Alan


Re: RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Sundararajan Athijegannathan
Please review updated webrev @
http://cr.openjdk.java.net/~sundar/8136645/webrev.01/

PS. Fixed "/" with "\" in "java" path. The generated batch file worked
in either case - but changing for consistency.

Thanks,
-Sundar

On 3/31/2016 11:08 PM, Sundararajan Athijegannathan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8136645
>
> Thanks,
> -Sundar



RFR 8136645: jlink tool should create windows os compatible launcher

2016-03-31 Thread Sundararajan Athijegannathan
Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8136645

Thanks,
-Sundar


Re: Review request 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build

2016-03-31 Thread Mandy Chung

> On Mar 31, 2016, at 10:06 AM, Alan Bateman  wrote:
> 
> 
> On 31/03/2016 17:56, Mandy Chung wrote:
>> A few build tools are using the old -XaddExports syntax that should switch 
>> to the new syntax:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153211/webrev.00/
>> 
>> Mandy
> This looks okay, are you planning to push these to jake or jdk9/dev?

jdk9/dev and then import to jigsaw/jake.  bootcycle build is broken in 
jigsaw/jake.

Mandy



Re: Review request 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build

2016-03-31 Thread Alan Bateman


On 31/03/2016 17:56, Mandy Chung wrote:

A few build tools are using the old -XaddExports syntax that should switch to 
the new syntax:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153211/webrev.00/

Mandy

This looks okay, are you planning to push these to jake or jdk9/dev?

-Alan


Review request 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build

2016-03-31 Thread Mandy Chung
A few build tools are using the old -XaddExports syntax that should switch to 
the new syntax:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153211/webrev.00/

Mandy

Re: javac accepts enums, annotations and final classes being referenced by 'uses' statement

2016-03-31 Thread Jonathan Gibbons

Georgiy,

Please file this as an issue against javac, and we'll take it from 
there.   The case of the final class has previously been considered and 
considered "silly but not wrong", but the other two have not been 
explicitly considered.


Alex has previously said in this forum that 'uses' and 'provides' are 
just a convenient front-end for the ServiceLoader API, so I would expect 
that to be taken into account when considering what should be accepted 
as legal here.


-- Jon

On 03/30/2016 04:18 AM, Georgiy Rakov wrote:

Hello,

currently JDK9b111 javac successfully compiles following code:

   a/module-info.java:
   module a {
uses pkg.FinalClassST;
uses pkg.EnumST;
uses pkg.AnnotationST;
   }

   a/pkg/AnnotationST.java:
   package pkg;
   public @interface AnnotationST{}

   a/pkg/EnumST.java:
   package pkg;
   public enum EnumST {A,B}

   a/pkg/FinalClassST.java:
   package pkg;
   public final class FinalClassST{}


Could you please tell if this is javac, spec or both issue that type 
being referenced by 'uses' statement is not checked at compile-time 
for ability to be a service interface.


The minimized testcase is attached; in order to run it please:
1. unzip attached archive on Windows machine;
2. rename test9\test_bat to test9\test.bat;
3. modify test.bat by changing JDK_HOME variable to point to your JDK 
installation;

4. run test.bat.

BTW: provided the type name references non existing type javac does 
produce compile error.


Thanks,
Georgiy.




hg: jigsaw/jake/hotspot: 73 new changesets

2016-03-31 Thread alan . bateman
Changeset: 4d4f3f5b215a
Author:erikj
Date:  2016-03-14 12:03 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4d4f3f5b215a

8151619: genSocketOptionRegistry.exe always relinked on Windows
Reviewed-by: tbell

! make/lib/Lib-jdk.hotspot.agent.gmk

Changeset: 2eca85c32025
Author:ppunegov
Date:  2016-03-01 20:17 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2eca85c32025

8148563: compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout
Summary: decrease amount of directives and threads
Reviewed-by: neliasso

! test/compiler/compilercontrol/jcmd/StressAddJcmdBase.java
! test/compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java
- test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java

Changeset: f9a45b25d9c9
Author:ppunegov
Date:  2016-03-03 16:54 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f9a45b25d9c9

Merge


Changeset: 6ff38c89f1f2
Author:mikael
Date:  2016-03-03 09:33 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ff38c89f1f2

8149159: Clean up Unsafe
Reviewed-by: jrose, kvn, stsmirno, chegar, aph, psandoz, redestad, twisti

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/unsafe.cpp
+ src/share/vm/prims/unsafe.hpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/shark/sharkBuilder.cpp
! test/compiler/intrinsics/IntrinsicDisabledTest.java

Changeset: d15b795cdf21
Author:shade
Date:  2016-03-03 22:17 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d15b795cdf21

8150669: C1 intrinsic for Class.isPrimitive
Reviewed-by: twisti, vlivanov, redestad

! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
+ test/compiler/intrinsics/class/TestClassIsPrimitive.java

Changeset: 6c9cc4c0b514
Author:shade
Date:  2016-03-03 23:57 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6c9cc4c0b514

8150465: Unsafe methods to produce uninitialized arrays
Reviewed-by: jrose, kvn, psandoz, aph, twisti, flar

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/library_call.cpp
+ test/compiler/intrinsics/unsafe/AllocateUninitializedArray.java

Changeset: a66bdd827fcb
Author:shade
Date:  2016-03-04 01:30 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a66bdd827fcb

8146801: Allocating short arrays of non-constant size is slow
Reviewed-by: kvn, twisti, vlivanov

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/globals_aarch64.hpp
! src/cpu/ppc/vm/globals_ppc.hpp
! src/cpu/ppc/vm/ppc.ad
! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 59829cb7ae2e
Author:vdeshpande
Date:  2016-03-03 22:02 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59829cb7ae2e

8150767: Enables SHA Extensions on x86
Summary: Add x86 intrinsics for SHA-1 and SHA-256.
Reviewed-by: kvn, twisti
Contributed-by: vivek.r.deshpa...@intel.com, shravya.rukmannag...@intel.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
+ src/cpu/x86/vm/macroAssembler_x86_sha.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86.cpp
! src/cpu/x86/vm/stubRoutines_x86.hpp
! src/cpu/x86/vm/vmStructs_x86.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java
! 
src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java
! 
src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/share/vm/jvmci/vmStructs_jvmci.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 0adf6c8c7223
Author:zmajo
Date:  2016-03-04 08:53 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0adf6c8c7223

8150839: Adjust the number of compiler threads for 32-bit platforms
Summary: Set the number of compiler threads to 3 on 32-bit platforms.
Reviewed-by: iveresov

! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp

Changeset: 4838927d2c74
Author:rraghavan
Date:  2016-03-04 01:18 -0800
URL:   http://hg.openjdk.java.net/jigsaw/j

hg: jigsaw/jake/nashorn: 14 new changesets

2016-03-31 Thread alan . bateman
Changeset: 15d52fdd9168
Author:attila
Date:  2016-03-15 16:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/15d52fdd9168

8150218: Autoconversion SAM adapters sometimes don't get privileges
Reviewed-by: mhaupt, sundar

! src/jdk.dynalink/share/classes/jdk/dynalink/CallSiteDescriptor.java
! src/jdk.dynalink/share/classes/jdk/dynalink/LinkerServicesImpl.java
+ src/jdk.dynalink/share/classes/jdk/dynalink/SecureLookupSupplier.java
! 
src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/ClassLinker.java
! 
src/jdk.dynalink/share/classes/jdk/dynalink/beans/LinkerServicesWithMissingMemberHandlerFactory.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/OverloadedMethod.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/SingleDynamicMethod.java
- src/jdk.dynalink/share/classes/jdk/dynalink/beans/messages.properties
! 
src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.dynalink/share/classes/jdk/dynalink/linker/LinkerServices.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptUtils.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJava.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
+ test/script/basic/JDK-8150218.js
+ test/src/jdk/dynalink/test/ArrayRunnableTest.java

Changeset: b9bf01ca3ef3
Author:lana
Date:  2016-03-15 14:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b9bf01ca3ef3

Merge

- src/jdk.dynalink/share/classes/jdk/dynalink/beans/messages.properties

Changeset: 5f06791d7682
Author:hannesw
Date:  2016-03-21 11:50 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5f06791d7682

8151809: ES6 Map/Set insertion with existing keys changes iteration order
Reviewed-by: lagergren, mhaupt

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/LinkedMap.java
+ test/script/basic/es6/JDK-8151809.js

Changeset: 25b13597ea73
Author:sdama
Date:  2016-03-21 12:38 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/25b13597ea73

8147613: enable jjs tests on Windows
Reviewed-by: lagergren, mhaupt

! make/build.xml
! test/script/nosecurity/JDK-8144221.js
! test/script/nosecurity/JDK-8151291.js
+ test/script/nosecurity/JDK-util.js
! test/script/nosecurity/jjs-common.js
! test/script/nosecurity/jjs-option-cp.js
! test/script/nosecurity/jjs-option-define.js
! test/script/nosecurity/jjs-option-doe.js
! test/script/nosecurity/jjs-option-fv.js
! test/script/nosecurity/jjs-option-fx.js
! test/script/nosecurity/jjs-option-lang.js
! test/script/nosecurity/jjs-option-ot.js
! test/script/nosecurity/jjs-option-scripting.js
! test/script/nosecurity/jjs-option-strict.js
! test/script/nosecurity/jjs-option-version.js

Changeset: 50be58e74a21
Author:hannesw
Date:  2016-03-22 14:23 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/50be58e74a21

8151810: for-in iteration does not provide per-iteration scope
Reviewed-by: attila, lagergren

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FieldObjectCreator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Block.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ForNode.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java
+ test/script/basic/es6/JDK-8151810.js

Changeset: 1421c56b3947
Author:hannesw
Date:  2016-03-22 14:26 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1421c56b3947

8151811: Const declarations do not work in for..in loops
Reviewed-by: attila, lagergren

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/es6/JDK-8151811.js

Changeset: 703729e9c5dd
Author:chegar
Date:  2016-03-22 10:43 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/703729e9c5dd

Merge

! 
src/jdk.dynalink/s

hg: jigsaw/jake/jdk: 63 new changesets

2016-03-31 Thread alan . bateman
Changeset: 005df9abb92e
Author:darcy
Date:  2016-03-11 15:30 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/005df9abb92e

8151750: Mark ChangingInterests.java as intermittently failing
Reviewed-by: lancea

! test/java/nio/channels/Selector/ChangingInterests.java

Changeset: fe5de5d885bb
Author:asmotrak
Date:  2016-03-11 17:07 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fe5de5d885bb

8151734: Mark Unreachable.java and MaxRetries.java as intermittently failing
Reviewed-by: weijun

! test/sun/security/krb5/auto/MaxRetries.java
! test/sun/security/krb5/auto/Unreachable.java

Changeset: 25e8c082d7ef
Author:mhaupt
Date:  2016-03-13 20:26 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/25e8c082d7ef

8150782: findClass / accessClass throw unexpected exceptions
Reviewed-by: sundar

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+ test/java/lang/invoke/t8150782/TestAccessClass.java
+ test/java/lang/invoke/t8150782/TestCls.java
+ test/java/lang/invoke/t8150782/TestFindClass.java
+ test/java/lang/invoke/t8150782/TestLookup.java

Changeset: d14f551f4d52
Author:mhaupt
Date:  2016-03-14 08:10 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d14f551f4d52

8151778: TestLookup.java fails after push of JDK-8150782
Reviewed-by: darcy

! test/java/lang/invoke/t8150782/TestLookup.java

Changeset: 2f1011811248
Author:amlu
Date:  2016-03-14 19:46 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2f1011811248

8151798: Mark java/util/TimeZone/Bug6772689.java as intermittently failing and 
demote to tier2
Reviewed-by: lancea

! test/TEST.groups
! test/java/util/TimeZone/Bug6772689.java

Changeset: b0b9d09d7640
Author:rriggs
Date:  2016-03-12 00:58 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b0b9d09d7640

8151062: Unclosed parenthesis in java.util.EnumMap.clone() Javadoc
Reviewed-by: rriggs
Contributed-by: Abhijit Roy 

! src/java.base/share/classes/java/util/EnumMap.java

Changeset: 927f20de2cc1
Author:darcy
Date:  2016-03-14 10:48 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/927f20de2cc1

8151835: Mark SmallPrimeExponentP.java as intermittently failing
Reviewed-by: vinnie

! test/sun/security/mscapi/SmallPrimeExponentP.java

Changeset: 05a1166a8201
Author:mikael
Date:  2016-03-03 09:12 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/05a1166a8201

8149159: Clean up Unsafe
Reviewed-by: jrose, kvn, stsmirno, chegar, aph, psandoz, redestad, twisti

! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/sun/misc/Unsafe.java
+ test/jdk/internal/misc/Unsafe/CopyMemory.java
! test/jdk/internal/misc/Unsafe/CopySwap.java

Changeset: dfd2c514773c
Author:shade
Date:  2016-03-03 23:57 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dfd2c514773c

8150465: Unsafe methods to produce uninitialized arrays
Reviewed-by: jrose, kvn, psandoz, aph, twisti, flar

! src/java.base/share/classes/jdk/internal/misc/Unsafe.java

Changeset: 6c484053b208
Author:zmajo
Date:  2016-03-07 09:34 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c484053b208

Merge

- make/mapfiles/libjfr/mapfile-vers
- src/java.base/share/classes/sun/misc/Version.java.template
- src/java.base/share/native/libjava/Version.c
- test/java/lang/invoke/T8139885.java
- test/sun/misc/Version/Version.java

Changeset: 5365a0b7e83f
Author:amurillo
Date:  2016-03-10 16:08 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5365a0b7e83f

Merge


Changeset: 1640de0263f7
Author:amurillo
Date:  2016-03-14 14:28 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1640de0263f7

Merge


Changeset: dadd5fa365d5
Author:jjg
Date:  2016-03-14 16:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dadd5fa365d5

8151847: rmic should support v53 classfiles
Reviewed-by: alanb

! src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java

Changeset: dc4a7fcdd13d
Author:amlu
Date:  2016-03-15 12:38 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dc4a7fcdd13d

8151785: Doc typo in src/../java/util/stream/PipelineHelper.java
Summary: Change from "intoWrapped" to "copyInto".
Reviewed-by: rriggs
Contributed-by: Hamlin Li 

! src/java.base/share/classes/java/util/stream/PipelineHelper.java

Changeset: 668137d6d741
Author:ksrini
Date:  2016-03-01 12:33 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/668137d6d741

8147755: ASM should create correct constant tag for invokestatic on handle 
point to interface static method
Summary: updates asm to v5.1
Reviewed-by: forax

! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
! src/java.base/s

hg: jigsaw/jake/langtools: 16 new changesets

2016-03-31 Thread alan . bateman
Changeset: 4e6a73cb55da
Author:ksrini
Date:  2016-03-14 15:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4e6a73cb55da

8071982: Update tests for revamped Doclet API
8071984: Update test cases for repeating and type annotations output in javadoc
Reviewed-by: ksrini, bpatel
Contributed-by: oleg.barbas...@oracle.com

! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java
! test/jdk/javadoc/doclet/testClassCrossReferences/C.java
! test/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java
! test/jdk/javadoc/doclet/testClassCrossReferences/package-list
+ test/jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyAnnotation.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyClass.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyEnum.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyError.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyException.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyInterface.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyAnnotation.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyClass.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyEnum.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyError.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyException.java
+ test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyInterface.java
! test/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/jdk/javadoc/doclet/testDeprecatedDocs/pkg/TestAnnotationType.java
+ test/jdk/javadoc/doclet/testGroupOption/C.java
! test/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java
+ test/jdk/javadoc/doclet/testGroupOption/abc1/C.java
+ test/jdk/javadoc/doclet/testGroupOption/abc2/C.java
+ test/jdk/javadoc/doclet/testGroupOption/abc3/C.java
+ test/jdk/javadoc/doclet/testGroupOption/other/C.java
! test/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java
! test/jdk/javadoc/doclet/testIndex/TestIndex.java
! test/jdk/javadoc/doclet/testIndex/pkg/Coin.java
! test/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java
! test/jdk/javadoc/doclet/testLinkTaglet/checkPkg/B.java
! test/jdk/javadoc/doclet/testLinkTaglet/pkg/C.java
! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java
+ test/jdk/javadoc/doclet/testNavigation/overview.html
! test/jdk/javadoc/doclet/testOptions/TestOptions.java
+ test/jdk/javadoc/doclet/testOptions/custom-stylesheet.css
+ test/jdk/javadoc/doclet/testOptions/deprecated/Foo.java
+ test/jdk/javadoc/doclet/testOptions/help.html
+ test/jdk/javadoc/doclet/testOptions/linksource/AnnotationTypeField.java
+ test/jdk/javadoc/doclet/testOptions/linksource/Properties.java
+ test/jdk/javadoc/doclet/testOptions/linksource/SomeClass.java
+ test/jdk/javadoc/doclet/testOptions/linksource/SomeEnum.java
! test/jdk/javadoc/doclet/testSearch/TestSearch.java
! test/jdk/javadoc/doclet/testSearch/pkg/AnotherClass.java
! test/jdk/javadoc/doclet/testSearch/pkg/package-info.java
! test/jdk/javadoc/doclet/testSearch/pkgfx/C.java
+ test/jdk/javadoc/doclet/testSerializedForm/ExternalizedForm.java
+ test/jdk/javadoc/doclet/testSerializedForm/SerializedForm.java
! test/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java
! test/jdk/javadoc/doclet/testSimpleTag/C.java
! test/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java
! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java
+ test/jdk/javadoc/doclet/testTypeAnnotations/typeannos/RepeatedAnnotations.java
! test/jdk/javadoc/doclet/testUseOption/TestUseOption.java
! test/jdk/javadoc/doclet/testUseOption/pkg1/C1.java
! test/jdk/javadoc/doclet/testUseOption/pkg1/C9.java
+ test/jdk/javadoc/doclet/testUseOption/pkg1/SubInterface.java
+ test/jdk/javadoc/doclet/testUseOption/pkg1/UsedThrowable.java
+ test/jdk/javadoc/doclet/testUseOption/pkg3/C.java
! test/jdk/javadoc/tool/VerifyLocale.java

Changeset: 9f2ab5bb1942
Author:lana
Date:  2016-03-15 14:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f2ab5bb1942

Merge


Changeset: 5bacae82131e
Author:jjg
Date:  2016-03-17 12:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5bacae82131e

8152048: change langtools tests to use ProblemList instead of @ignore
Reviewed-by: darcy

! test/ProblemList.txt

Changeset: facb06a2e3d8
Author:alundblad
Date:  2016-03-22 11:48 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/facb06a2e3d8

8151379: Sjavac should not print connection attempts on info logging level
Summary: Changed logging level on some sjavac messages.
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/sjavac/JavacState.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java

Changeset: d52219fa3026
Author:che

hg: jigsaw/jake/jaxws: 2 new changesets

2016-03-31 Thread alan . bateman
Changeset: e980062475c1
Author:lana
Date:  2016-03-31 01:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e980062475c1

Added tag jdk-9+112 for changeset 21274e7937ba

! .hgtags

Changeset: 2e61d618c68c
Author:alanb
Date:  2016-03-31 13:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2e61d618c68c

Merge




hg: jigsaw/jake/corba: 2 new changesets

2016-03-31 Thread alan . bateman
Changeset: cc30faa2da49
Author:lana
Date:  2016-03-31 01:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/cc30faa2da49

Added tag jdk-9+112 for changeset 780d0620add3

! .hgtags

Changeset: de3dfa940914
Author:alanb
Date:  2016-03-31 13:44 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/de3dfa940914

Merge




hg: jigsaw/jake/jaxp: 3 new changesets

2016-03-31 Thread alan . bateman
Changeset: 36326537f929
Author:joehw
Date:  2016-03-24 15:34 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/36326537f929

8151154: IllegalArgumentException not thrown when wrong syntax value is set for 
javax.xml.catalog.files
Reviewed-by: lancea

! src/java.xml/share/classes/javax/xml/catalog/BaseEntry.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java
! src/java.xml/share/classes/javax/xml/catalog/Util.java
! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java

Changeset: 29f414d284e5
Author:lana
Date:  2016-03-31 01:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/29f414d284e5

Added tag jdk-9+112 for changeset 36326537f929

! .hgtags

Changeset: a7ada8afc4ba
Author:alanb
Date:  2016-03-31 13:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a7ada8afc4ba

Merge




hg: jigsaw/jake: 18 new changesets

2016-03-31 Thread alan . bateman
Changeset: 5d868c42d888
Author:erikj
Date:  2016-03-14 12:00 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/5d868c42d888

8151619: genSocketOptionRegistry.exe always relinked on Windows
Reviewed-by: tbell

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! make/common/NativeCompilation.gmk

Changeset: 231e382d724e
Author:erikj
Date:  2016-03-15 11:08 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/231e382d724e

8151726: Introduce a JPRT testset buildinfra
Reviewed-by: tbell, dholmes

! common/conf/jib-profiles.js
! make/jprt.properties

Changeset: 0c4c33965d4c
Author:lana
Date:  2016-03-15 14:48 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/0c4c33965d4c

Merge


Changeset: d28be9fe5ab8
Author:erikj
Date:  2016-03-16 13:36 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d28be9fe5ab8

8151800: Jib profile for open linux should produce compact profiles images by 
default
Reviewed-by: dholmes

! common/conf/jib-profiles.js

Changeset: 9d77f922d694
Author:andrew
Date:  2016-03-19 01:28 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/9d77f922d694

8151841: Build needs additional flags to compile with GCC 6
Summary: C++ standard needs to be explicitly set and some optimisations turned 
off to build on GCC 6
Reviewed-by: erikj, dholmes, kbarrett

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: ad7fd6bb92e0
Author:simonis
Date:  2016-03-03 16:20 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/ad7fd6bb92e0

8150646: Add support for blocking compiles though whitebox API
Reviewed-by: kvn, ppunegov, simonis, neliasso
Contributed-by: nils.elias...@oracle.com, volker.simo...@gmail.com

! test/lib/sun/hotspot/WhiteBox.java

Changeset: fa307bc0ed5a
Author:zmajo
Date:  2016-03-14 17:51 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/fa307bc0ed5a

Merge


Changeset: 55b962a5631b
Author:amurillo
Date:  2016-03-17 11:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/55b962a5631b

Merge


Changeset: 15d061ef8591
Author:amurillo
Date:  2016-03-21 20:19 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/15d061ef8591

Merge


Changeset: 905405fcc3b4
Author:erikj
Date:  2016-03-22 10:46 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/905405fcc3b4

8149545: Add zlib devel package to devkit sysroot on Linux
Reviewed-by: alanb

! make/devkit/Tools.gmk

Changeset: 00ff6af007c0
Author:chegar
Date:  2016-03-22 10:44 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/00ff6af007c0

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/conf/jib-profiles.js
- make/CheckModules.gmk
- make/GenerateModuleDeps.gmk
! make/common/NativeCompilation.gmk
- modules.xml

Changeset: f7b181bd0dc2
Author:chegar
Date:  2016-03-22 17:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f7b181bd0dc2

Merge

! test/lib/sun/hotspot/WhiteBox.java

Changeset: e850a15d3ac6
Author:mchung
Date:  2016-03-23 09:20 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e850a15d3ac6

8152197: Single place to specify module-specific information for images build
Reviewed-by: alanb, erikj

! make/Images.gmk
! make/common/Modules.gmk

Changeset: 6da9e0c79eac
Author:lana
Date:  2016-03-23 21:44 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/6da9e0c79eac

Merge


Changeset: b23dfa43c0c3
Author:mchung
Date:  2016-03-24 13:45 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b23dfa43c0c3

8152697: JVMCI tests fail with UnsatisfiedLinkError as jdk.vm.ci not defined by 
boot loader
Reviewed-by: alanb

! make/common/Modules.gmk

Changeset: 03543a758cd5
Author:sherman
Date:  2016-03-25 10:55 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/03543a758cd5

8031767: Support system or alternative implementations of zlib
Reviewed-by: alanb, erikj

! common/autoconf/generated-configure.sh
! common/autoconf/lib-bundled.m4
! common/conf/jib-profiles.js

Changeset: 6c5a63c5e7a4
Author:lana
Date:  2016-03-31 01:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/6c5a63c5e7a4

Added tag jdk-9+112 for changeset 03543a758cd5

! .hgtags

Changeset: 6921d7a584ae
Author:alanb
Date:  2016-03-31 13:55 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/6921d7a584ae

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/conf/jib-profiles.js
! make/Images.gmk
! make/common/Modules.gmk
! make/common/NativeCompilation.gmk
! make/jprt.properties
! test/lib/sun/hotspot/WhiteBox.java



Re: modulepath and classpath mixture

2016-03-31 Thread Russell Gold
Hi Paul,

No, it does not make sense, if you are writing unit tests. Unit tests often 
access classes and methods that general uses of the module should not. On the 
other hand, it could make perfect sense to run the code as a module in a 
functional test. Functional/integration/acceptance tests should only access 
what users of the module can access, and don’t need to be in the same packages 
as the code, since the users of that code aren’t.

Regards,
Russ

> On Mar 30, 2016, at 3:13 PM, Paul Benedict  wrote:
> 
> Russell, you ask a good question. If an artifact is meant to be a module, 
> wouldn't it make sense for it to run as a module during testing too? Those 
> boundaries should be activated like they are in production to get good 
> confidence in the code. Those are my two cents. I'd like to hear opposing 
> opinions though why the boundaries shouldn't be there.
> 
> Cheers,
> Paul
> 
> On Wed, Mar 30, 2016 at 2:07 PM, Russell Gold  > wrote:
> Hi Paul,
> 
> Why would you put your main code on the module path during a unit test?  It 
> seems to me that unit tests are explicitly about making sure that the code 
> works, not the packaging. So you put both main and test code on the 
> classpath, and there is no problem. The unit test can be done before the main 
> code is packaged into a module.
> 
> - Russ
> 
>> On Mar 30, 2016, at 10:47 AM, Paul Benedict > > wrote:
>> 
>> Russell, if you have a module with package X and a classpath jar with 
>> package X, the module can't see package X from the classpath. 
>> 
>> In the last several posts, there's been discussion on putting tests on the 
>> classpath; keeping the "main" code in the module. So given what I stated 
>> above, that's what I've been referring to.
>> 
>> Cheers,
>> Paul
>> 
>> On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold > > wrote:
>> Hi Paul,
>> 
>> Could you explain? What kind of code do you mean cannot access it? And what 
>> do you mean by “a split package situation”?
>> 
>> From a conversation I had with Alan, earlier in this thread:
>> 
>> 
>>> On Mar 23, 2016, at 11:42 AM, Alan Bateman >> > wrote:
>>> 
>>> On 23/03/2016 14:15, Russell Gold wrote:
 Here are my assumptions, which you can correct.
 
 1. A jar or classes directory placed on a class path are treated as part 
 of the unnamed module
>>> Yes
>> 
>> 
>> So if the tests and main code are both in directories, which they have been 
>> up to now in Maven, why would there be a problem? Both would be in the 
>> unnamed module and able to access one another.
>> 
>> - Russ
>> 
>>> On Mar 29, 2016, at 10:47 PM, Paul Benedict >> > wrote:
>>> 
>>> Russell, when you drop a jar on the classpath, module code will not be able 
>>> to access it in a split package situation. That's the big barrier here. 
>>> Maven test projects are typically written with the same package shared with 
>>> the "main" code. 
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold >> > wrote:
>>> Hi Stephen,
>>> 
>>> Why do you need any kind of friend access?
>>> 
>>> It seems to me that this is making things harder than they need to be. The 
>>> tests can simply run with the production code on the class path, and then 
>>> there are no module issues at all.
>>> 
>>> I think a larger problem is that you can do what I just said with the jars, 
>>> even a jar which has been designated as a module by virtue of having a 
>>> module-info.class in it. That means that, when users are up taking jars, 
>>> they are not prevented from accessing module internals. They can put the 
>>> jars on the module path, of course, but they can still use them on the 
>>> class path!
>>> 
>>> - Russ
>>> 
>>> >
>>> > On 28 March 2016 at 11:13, Remi Forax >> > > wrote:
>>> >> Hi Stephen, Hi all,
>>> >> I think that delivering tests as a separated module is a bad idea.
>>> >>
>>> >> I see that from the point of a developer, seeing the code and the test 
>>> >> as different modules can be attractive because everything seems to be 
>>> >> put at the right place but there is a big drawback. Because modules are 
>>> >> reified at runtime, it means that the runtime environment of the tests 
>>> >> will be different from the production environment.
>>> >
>>> > This last sentence doesn't make sense to me - tests are not run in a
>>> > production environment.
>>> >
>>> > Tests have all the qualities of modules - code, dependencies,
>>> > compilation phase, deployment. The only special part is the need for
>>> > special "friend-like" access, which Jigsaw already has for other cases
>>> > (the export...to clause).
>>> >
>>> > Put simply, I consider that module =
>>> > deployment-artifact-with-dependencies. With that mental model, putting
>>> > tests inside the module is just not acceptable, because 

Re: Unexpected ClassnotFoundException on reflective Class#getMethod

2016-03-31 Thread Alan Bateman

On 31/03/2016 11:20, Sanne Grinovero wrote:

Thanks Alex,
that clarifies a lot, I was just about to try with a different dependency.

So this is not a reflection bug, but I'm just realising now that has
quite significant impact on JavaEE:
the Synchronization type is defined as public API of the specification [1].

Changing the JavaEE API isn't going to be very popular, so I guess the
expectation is for
containers to regularly override the modules?
This won't affect just the regular EE application servers, as these
APIs are often used also
in standalone JavaSE applications, as many components of the JavaEE spec can
be run in "standalone" or "embedded" modes.

For example Hibernate will now have to require the application launcher to apply
customizations to the JVM boot parameters, and probably so any other JPA
implementation.

1 - http://docs.oracle.com/javaee/7/api/javax/transaction/Synchronization.html

Java EE implementations have always upgraded/replaced a number of APIs 
that are "shared" with Java SE. The JSR-250 defined "Common Annotations" 
is another example where Java SE defines a subset of the API and Java EE 
implementations need the deploy with the full API.  So there isn't 
anything forcing anyone to change APIs, this is really just about how to 
compile or run with the Java EE versions of these components.


With JDK 8 and older then the only supported way of upgrading these 
components was the Endorsed Standards Override Mechanism. It turns out 
that this wasn't widely used and instead app servers and others have 
been putting JAR files on the class path with these components. 
Incredibly this worked even though it wasn't actually overriding the 
classes in the Java SE defined subset.


Moving to modules means that EE servers will need to deploy with the EE 
versions of these modules. Adding the class path isn't going to work 
because the module system will prohibit splitting packages between 
modules and the class path. The way to do this is, as Alex mentioned, is 
the upgrade module path.


Patching will work too, at least to get something going. In this case 
you can patch the java.transaction module with:


   -Xpatch:java.transaction=transaction-api_1.2.jar

There aren't any additional packages exported in the EE version so 
-XaddExports isn't neded. The equivalent with the Common Annotations 
would need -XaddExports because the EE version has APIs in packages that 
Java SE does not define.


One final thing to mention is that there is a proposal in the works to 
not resolve the EE modules when compiling code in the unnamed module or 
running code where the initial class is on the class path. For existing 
deployments then it would looking like that the JDK doesn't have the EE 
modules. This isn't fully implemented in the current builds but it is a 
proposal that will make migration to JDK 9 much easier for many. For 
those using the EE components outside the context of an app server then 
it would mean using `-addmods java.se.ee` so that all of the EE modules 
are resolved. I'm sure there will be more on this topic soon.


-Alan










Re: Unexpected ClassnotFoundException on reflective Class#getMethod

2016-03-31 Thread Sanne Grinovero
Thanks Alex,
that clarifies a lot, I was just about to try with a different dependency.

So this is not a reflection bug, but I'm just realising now that has
quite significant impact on JavaEE:
the Synchronization type is defined as public API of the specification [1].

Changing the JavaEE API isn't going to be very popular, so I guess the
expectation is for
containers to regularly override the modules?
This won't affect just the regular EE application servers, as these
APIs are often used also
in standalone JavaSE applications, as many components of the JavaEE spec can
be run in "standalone" or "embedded" modes.

For example Hibernate will now have to require the application launcher to apply
customizations to the JVM boot parameters, and probably so any other JPA
implementation.

1 - http://docs.oracle.com/javaee/7/api/javax/transaction/Synchronization.html

Thanks,
Sanne

On Wed, Mar 30, 2016 at 11:07 PM, Alex Buckley  wrote:
> The JDK 9b111 runtime image includes the java.transaction module which
> exports the javax.transaction package. The application class loader will try
> to load javax.transaction.* types from there, not from a JAR on the
> classpath. As you probably guess, the JDK's java.transaction module does not
> contain the javax.transaction.Synchronization type.
>
> You can either supply an alternate java.transaction module to override the
> one in the JDK (-upgrademodulepath), or you can inject your additional
> classes directly into the module in the JDK (-Xpatch). Please see JEP 261.
>
> Alex
>
>
> On 3/30/2016 2:39 PM, Sanne Grinovero wrote:
>>
>> Hello all,
>> looks like I've found an issue on invoking Class#getMethod.
>>
>> This method is used by Maven when scanning the project's classpath to
>> identify JUnit tests - which it does by default on any Maven project -
>> so I'm afraid the impact could be quite large.
>>
>> I've been able to narrow it down to this small test which doesn't need
>> neither Maven nor JUnit, however to reproduce the issue the project
>> must have a dependency to some third party jar.
>> In this reproducer I'm using javax.transaction.Synchronization, a copy
>> can be obtained from:
>>   -
>> https://repository.jboss.org/nexus/service/local/repositories/central/content/org/jboss/spec/javax/transaction/jboss-transaction-api_1.2_spec/1.0.0.Final/jboss-transaction-api_1.2_spec-1.0.0.Final.jar
>>
>>
>>  Main.java 
>> public class Main {
>>
>> public static void main(String[] args) {
>> Class clazz = SecondClass.class;
>> try {
>> clazz.getMethod("notexisting", new Class[0]);
>> } catch (NoSuchMethodException e) {
>> e.printStackTrace();
>> }
>> System.out.println("All good");
>> }
>>
>> }
>>  SecondClass.java 
>> import javax.transaction.Synchronization;
>>
>> public class SecondClass {
>>
>> public void registerSynchronization(Synchronization synchronization) {
>> }
>>
>> }
>>  EOF 
>>
>>
>> On Java8 or Java9 build 9-ea+110 the output is, as expected:
>>
>>> java.lang.NoSuchMethodException: SecondClass.notexisting()
>>> at java.lang.Class.getMethod(Class.java:1786)
>>> at Main.main(Main.java:6)
>>> All good
>>
>>
>>
>> On Java9 build 9-ea+111 though I'll have this:
>>
>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>> javax/transaction/Synchronization
>>> at java.lang.Class.getDeclaredMethods0(java.base@9-ea/Native Method)
>>> at
>>> java.lang.Class.privateGetDeclaredMethods(java.base@9-ea/Class.java:2937)
>>> at
>>> java.lang.Class.privateGetMethodRecursive(java.base@9-ea/Class.java:3282)
>>> at java.lang.Class.getMethod0(java.base@9-ea/Class.java:3252)
>>> at java.lang.Class.getMethod(java.base@9-ea/Class.java:1961)
>>> at Main.main(Main.java:6)
>>> Caused by: java.lang.ClassNotFoundException:
>>> javax.transaction.Synchronization
>>> at
>>> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-ea/BuiltinClassLoader.java:368)
>>> at
>>> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-ea/ClassLoaders.java:185)
>>> at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
>>> ... 6 more
>>
>>
>> I hope I have sent this to the right mailing list.
>> I've reported the same issue on bugreport.java.com, but the only ID I
>> have about that report is the "Review ID": JI-9033943
>> The reproducer in this email is much better than in the other report,
>> I can't check what I sent but I believe I might have sent an outdated
>> version; apologies for any confusion.
>>
>> Thanks,
>> Sanne Grinovero
>>
>


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

2016-03-31 Thread Frank Yuan
Hi Alan, Joe, and All

I have produced a new webrev 
http://cr.openjdk.java.net/~fyuan/8078820/webrev.01/ based on your comments, 
there are 2 tests:
1. BasicModularXMLParserTest.java, which is same as the previous one, tests the 
customized xml provider modules in boot layer
2. LayerModularXMLParserTest.java, which is suggested by Alan, it tests the 
different combinations of providers, application and
layers.

Would you like to review it again? Thank you!

Best Regards
Frank

From: Alan Bateman [mailto:alan.bate...@oracle.com] 
Sent: Sunday, March 27, 2016 2:52 PM
To: huizhe wang ; Frank Yuan 
Subject: Re: RFR: 8078820: Test deploying a XML parser as a module


On 26/03/2016 22:07, huizhe wang wrote:

On 3/24/2016 2:51 AM, Frank Yuan wrote:
To Joe


Need I wait for org.xml.sax.helpers.XMLReaderFactory? or leave it till later?

Up to you. I don't know how urgent this task is.  The XMLReaderFactory might 
take a while to get fixed. We may go ahead with our own
plan to update it since I haven't heard from the SAX project yet. Even so, it 
still might take weeks.

But once it's in place, it will be exactly the same as other factories with 
regard to the way it works in modules.
We can always come back to the test once we have a solution for the SAX API.

So I suggest go ahead and work with Frank to get this test in. I think it 
should co-locate with the existing unit tests.

-Alan.