From pardeep.k.sharma at oracle.com  Wed Aug  3 06:10:30 2016
From: pardeep.k.sharma at oracle.com (Pardeep Sharma)
Date: Tue, 2 Aug 2016 23:10:30 -0700 (PDT)
Subject: javac tool documentation: Xdoclint
Message-ID: <7ed59ba1-db03-415b-b3c7-e5bc8541de4e@default>

Team,

 

Need help with confirming few options with Xdoclint as part of the improvement in javac documentation and help.

Is there a way to confirm the default access level for -Xdoclint in javac for JDk 8 and 9?

 

When we run javac -X (9ea), get this:

---------------------------

$ javac -X

    -Xdoclint                  Enable recommended checks for problems in javadoc coments

  -Xdoclint:(all|none|[-]<group>)[/<access>]

        Enable or disable specific checks for problems in javadoc comments,

        where <group> is one of accessibility, html, missing, reference, or synta,

        and <access> is one of public, protected, package, or private.

  -Xdoclint/package:([-]<packages>)

        Enable or disable checks in specific packages. <packages> is a comma sepaated

        list of package specifiers. Package specifier is either a qualified name f a package

        or a package name prefix followed by .*, which expands to all sub-package of

        the given package. Prefix the package specifier with - to disable checks or

        the specified packages.

Note: Apart from corrections in few spellings (coments, separated, f) in the above output, it may be nice to know,

- What are the 'recommended' checks?

- Even though the variable access seems optional, it may help if such options are made clear in the help output or in the documentation.

 

This has come as a suggestion in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8073216"JDK-8073216 .

" in the description of "-Xdoclint:[-]group [/access]", the default access level must be specified (for Java 1.8.0_31, the default is private)"

Existing doc url: 

http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html 

 

Thank You,

Pardeep

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160802/137074c5/attachment-0001.html>

From mandy.chung at oracle.com  Fri Aug  5 20:11:28 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 5 Aug 2016 13:11:28 -0700
Subject: Review request 8136930: Simplify use of module-system options by
	custom launchers
Message-ID: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>

This patch renames the module-system options to GNU-style as specified
in JEP 293 [1] (see below for the new proposed option names).  This
addresses the problems discussed in [2] that the launcher will pass 
the module-system options down to the VM in the form of <option>=<value>.
This provides a consistent way to configure the module system and
simplify use of module-system options by custom launcher.  This patch
also updates several JDK tools including jlink, jmod, jimage, jar,
javac, javap, javadoc, javah, jdeps such that the GNU-style 
module-system options are consistent across all tools.

Webrev:
 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/

Harold has posted a separate code review for the hotspot change [3].
webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
includes the changes in langtools repo (this may be convenient for
those who wants to review langtools change only).

Note that existing -cp and -classpath have no change and continue to
be supported.  New long form option `--class-path` and `--help` are 
added to java, javac, and other tools where applicable.

For transition, all old options except -listmods continue to be 
supported by the java launcher, javac, javadoc, javap, javah.  
I propose to remove the old options in two weeks after this patch
is promoted (i.e. two promoted builds to go through the transition).

Mandy

[1] http://openjdk.java.net/jeps/293
[2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html

Existing Options                    New Options

-addmods                            --add-modules
-classpath | -cp | --classpath      -classpath | -cp | --class-path
-limitmods                          --limit-modules
-listmods                           --list-modules
-m                                  --module | -m
-modulepath | -mp | --modulepath    --module-path | -p
-modulesourcepath                   --module-source-path
--plugin-module-path                (no change)
-processormodulepath                --processor-module-path
-upgrademodulepath                  --upgrade-module-path
-XaddExports                        --add-exports
-XaddReads                          --add-reads
-Xpatch                             --patch-module
-bootclasspath                      --boot-class-path | -bootclasspath
-processorpath                      --processor-path  | -processor-path
-sourcepath                         --source-path | -sourcepath
-system                             --system
-release                            --release

From jan.lahoda at oracle.com  Tue Aug  9 13:12:10 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 9 Aug 2016 15:12:10 +0200
Subject: Review request 8136930: Simplify use of module-system options by
	custom launchers
In-Reply-To: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
Message-ID: <57A9D6AA.6030109@oracle.com>

I took a pass through langtools changes. Overall seems OK to me. Some 
minor comments:
-src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java: 
commented-out code in hasArg(). (Some more in Option.ArgKind, but that 
seems mostly OK.)
-src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties: 
the help is not listing --class-path, while it does list --source-path, 
and some other help texts list --class-path - is that intentional?
-test/jdk/javadoc/tool/6964914/TestStdDoclet.java (and some other 
tests): the references to jdk.launcher.patch.* where there probably to 
support standalone testing; I note that standalone testing is probably 
not going to work anymore for these tests.

Jan

On 5.8.2016 22:11, Mandy Chung wrote:
> This patch renames the module-system options to GNU-style as specified
> in JEP 293 [1] (see below for the new proposed option names).  This
> addresses the problems discussed in [2] that the launcher will pass
> the module-system options down to the VM in the form of <option>=<value>.
> This provides a consistent way to configure the module system and
> simplify use of module-system options by custom launcher.  This patch
> also updates several JDK tools including jlink, jmod, jimage, jar,
> javac, javap, javadoc, javah, jdeps such that the GNU-style
> module-system options are consistent across all tools.
>
> Webrev:
>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
>
> Harold has posted a separate code review for the hotspot change [3].
> webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
> includes the changes in langtools repo (this may be convenient for
> those who wants to review langtools change only).
>
> Note that existing -cp and -classpath have no change and continue to
> be supported.  New long form option `--class-path` and `--help` are
> added to java, javac, and other tools where applicable.
>
> For transition, all old options except -listmods continue to be
> supported by the java launcher, javac, javadoc, javap, javah.
> I propose to remove the old options in two weeks after this patch
> is promoted (i.e. two promoted builds to go through the transition).
>
> Mandy
>
> [1] http://openjdk.java.net/jeps/293
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
>
> Existing Options                    New Options
>
> -addmods                            --add-modules
> -classpath | -cp | --classpath      -classpath | -cp | --class-path
> -limitmods                          --limit-modules
> -listmods                           --list-modules
> -m                                  --module | -m
> -modulepath | -mp | --modulepath    --module-path | -p
> -modulesourcepath                   --module-source-path
> --plugin-module-path                (no change)
> -processormodulepath                --processor-module-path
> -upgrademodulepath                  --upgrade-module-path
> -XaddExports                        --add-exports
> -XaddReads                          --add-reads
> -Xpatch                             --patch-module
> -bootclasspath                      --boot-class-path | -bootclasspath
> -processorpath                      --processor-path  | -processor-path
> -sourcepath                         --source-path | -sourcepath
> -system                             --system
> -release                            --release
>

From kumar.x.srinivasan at oracle.com  Tue Aug  9 15:19:54 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 09 Aug 2016 08:19:54 -0700
Subject: Review request 8136930: Simplify use of module-system options
	by custom launchers
In-Reply-To: <57A9D6AA.6030109@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
	<57A9D6AA.6030109@oracle.com>
Message-ID: <57A9F49A.3020903@oracle.com>


On 8/9/2016 6:12 AM, Jan Lahoda wrote:
> I took a pass through langtools changes. Overall seems OK to me. Some 
> minor comments:
> -src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java: 
> commented-out code in hasArg(). (Some more in Option.ArgKind, but that 
> seems mostly OK.)
> -src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties: 
> the help is not listing --class-path, while it does list 
> --source-path, and some other help texts list --class-path - is that 
> intentional?
> -test/jdk/javadoc/tool/6964914/TestStdDoclet.java (and some other 
> tests): the references to jdk.launcher.patch.* where there probably to 
> support standalone testing; I note that standalone testing is probably 
> not going to work anymore for these tests.

Generally looks good, I also noticed the above, specifically --class-path ?

Kumar

>
> Jan
>
> On 5.8.2016 22:11, Mandy Chung wrote:
>> This patch renames the module-system options to GNU-style as specified
>> in JEP 293 [1] (see below for the new proposed option names). This
>> addresses the problems discussed in [2] that the launcher will pass
>> the module-system options down to the VM in the form of 
>> <option>=<value>.
>> This provides a consistent way to configure the module system and
>> simplify use of module-system options by custom launcher.  This patch
>> also updates several JDK tools including jlink, jmod, jimage, jar,
>> javac, javap, javadoc, javah, jdeps such that the GNU-style
>> module-system options are consistent across all tools.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
>>
>> Harold has posted a separate code review for the hotspot change [3].
>> webrev.00 includes changes in all repos except hotspot. 
>> webrev-langtools.00
>> includes the changes in langtools repo (this may be convenient for
>> those who wants to review langtools change only).
>>
>> Note that existing -cp and -classpath have no change and continue to
>> be supported.  New long form option `--class-path` and `--help` are
>> added to java, javac, and other tools where applicable.
>>
>> For transition, all old options except -listmods continue to be
>> supported by the java launcher, javac, javadoc, javap, javah.
>> I propose to remove the old options in two weeks after this patch
>> is promoted (i.e. two promoted builds to go through the transition).
>>
>> Mandy
>>
>> [1] http://openjdk.java.net/jeps/293
>> [2] 
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
>> [3] 
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
>>
>> Existing Options                    New Options
>>
>> -addmods                            --add-modules
>> -classpath | -cp | --classpath      -classpath | -cp | --class-path
>> -limitmods                          --limit-modules
>> -listmods                           --list-modules
>> -m                                  --module | -m
>> -modulepath | -mp | --modulepath    --module-path | -p
>> -modulesourcepath                   --module-source-path
>> --plugin-module-path                (no change)
>> -processormodulepath                --processor-module-path
>> -upgrademodulepath                  --upgrade-module-path
>> -XaddExports                        --add-exports
>> -XaddReads                          --add-reads
>> -Xpatch                             --patch-module
>> -bootclasspath                      --boot-class-path | -bootclasspath
>> -processorpath                      --processor-path  | -processor-path
>> -sourcepath                         --source-path | -sourcepath
>> -system                             --system
>> -release                            --release
>>


From jonathan.gibbons at oracle.com  Tue Aug  9 15:25:03 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 09 Aug 2016 08:25:03 -0700
Subject: Review request 8136930: Simplify use of module-system options
	by custom launchers
In-Reply-To: <57A9D6AA.6030109@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
	<57A9D6AA.6030109@oracle.com>
Message-ID: <57A9F5CF.2020105@oracle.com>

On 08/09/2016 06:12 AM, Jan Lahoda wrote:
> I took a pass through langtools changes. Overall seems OK to me. Some 
> minor comments:
> -src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java: 
> commented-out code in hasArg(). (Some more in Option.ArgKind, but that 
> seems mostly OK.)
> -src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties: 
> the help is not listing --class-path, while it does list 
> --source-path, and some other help texts list --class-path - is that 
> intentional?

Good catch, and no, not intentional.  However, the intent was to clean 
up javadoc option handling after the patch for new module-related 
options for javadoc arives.

> -test/jdk/javadoc/tool/6964914/TestStdDoclet.java (and some other 
> tests): the references to jdk.launcher.patch.* where there probably to 
> support standalone testing; I note that standalone testing is probably 
> not going to work anymore for these tests.

These will need to go at some point.  The tools currently support both 
old and new option forms, and there will need to be a follow up patch to 
clean up remaining use of all old-style options, and system properties, 
once the transition period is over.

>
> Jan
>
> On 5.8.2016 22:11, Mandy Chung wrote:
>> This patch renames the module-system options to GNU-style as specified
>> in JEP 293 [1] (see below for the new proposed option names). This
>> addresses the problems discussed in [2] that the launcher will pass
>> the module-system options down to the VM in the form of 
>> <option>=<value>.
>> This provides a consistent way to configure the module system and
>> simplify use of module-system options by custom launcher.  This patch
>> also updates several JDK tools including jlink, jmod, jimage, jar,
>> javac, javap, javadoc, javah, jdeps such that the GNU-style
>> module-system options are consistent across all tools.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
>>
>> Harold has posted a separate code review for the hotspot change [3].
>> webrev.00 includes changes in all repos except hotspot. 
>> webrev-langtools.00
>> includes the changes in langtools repo (this may be convenient for
>> those who wants to review langtools change only).
>>
>> Note that existing -cp and -classpath have no change and continue to
>> be supported.  New long form option `--class-path` and `--help` are
>> added to java, javac, and other tools where applicable.
>>
>> For transition, all old options except -listmods continue to be
>> supported by the java launcher, javac, javadoc, javap, javah.
>> I propose to remove the old options in two weeks after this patch
>> is promoted (i.e. two promoted builds to go through the transition).
>>
>> Mandy
>>
>> [1] http://openjdk.java.net/jeps/293
>> [2] 
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
>> [3] 
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
>>
>> Existing Options                    New Options
>>
>> -addmods                            --add-modules
>> -classpath | -cp | --classpath      -classpath | -cp | --class-path
>> -limitmods                          --limit-modules
>> -listmods                           --list-modules
>> -m                                  --module | -m
>> -modulepath | -mp | --modulepath    --module-path | -p
>> -modulesourcepath                   --module-source-path
>> --plugin-module-path                (no change)
>> -processormodulepath                --processor-module-path
>> -upgrademodulepath                  --upgrade-module-path
>> -XaddExports                        --add-exports
>> -XaddReads                          --add-reads
>> -Xpatch                             --patch-module
>> -bootclasspath                      --boot-class-path | -bootclasspath
>> -processorpath                      --processor-path  | -processor-path
>> -sourcepath                         --source-path | -sourcepath
>> -system                             --system
>> -release                            --release
>>


From alexandre.iline at oracle.com  Thu Aug 11 14:47:12 2016
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Thu, 11 Aug 2016 07:47:12 -0700
Subject: Review request 8136930: Simplify use of module-system options by
	custom launchers
In-Reply-To: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
Message-ID: <80E0D931-6342-4BA2-B0FE-F162A46D6117@oracle.com>

Hi, Mandy.

Could you help to identify what tests in the JTreg suite(s) require more work to switch to the new options?

Or the other way around: which tests have been fixed with this commit?

Thank you.


> On Aug 5, 2016, at 1:11 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> This patch renames the module-system options to GNU-style as specified
> in JEP 293 [1] (see below for the new proposed option names).  This
> addresses the problems discussed in [2] that the launcher will pass 
> the module-system options down to the VM in the form of <option>=<value>.
> This provides a consistent way to configure the module system and
> simplify use of module-system options by custom launcher.  This patch
> also updates several JDK tools including jlink, jmod, jimage, jar,
> javac, javap, javadoc, javah, jdeps such that the GNU-style 
> module-system options are consistent across all tools.
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
> 
> Harold has posted a separate code review for the hotspot change [3].
> webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
> includes the changes in langtools repo (this may be convenient for
> those who wants to review langtools change only).
> 
> Note that existing -cp and -classpath have no change and continue to
> be supported.  New long form option `--class-path` and `--help` are 
> added to java, javac, and other tools where applicable.
> 
> For transition, all old options except -listmods continue to be 
> supported by the java launcher, javac, javadoc, javap, javah.  
> I propose to remove the old options in two weeks after this patch
> is promoted (i.e. two promoted builds to go through the transition).
> 
> Mandy
> 
> [1] http://openjdk.java.net/jeps/293
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
> 
> Existing Options                    New Options
> 
> -addmods                            --add-modules
> -classpath | -cp | --classpath      -classpath | -cp | --class-path
> -limitmods                          --limit-modules
> -listmods                           --list-modules
> -m                                  --module | -m
> -modulepath | -mp | --modulepath    --module-path | -p
> -modulesourcepath                   --module-source-path
> --plugin-module-path                (no change)
> -processormodulepath                --processor-module-path
> -upgrademodulepath                  --upgrade-module-path
> -XaddExports                        --add-exports
> -XaddReads                          --add-reads
> -Xpatch                             --patch-module
> -bootclasspath                      --boot-class-path | -bootclasspath
> -processorpath                      --processor-path  | -processor-path
> -sourcepath                         --source-path | -sourcepath
> -system                             --system
> -release                            --release


From mandy.chung at oracle.com  Thu Aug 11 14:57:40 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 Aug 2016 07:57:40 -0700
Subject: Review request 8136930: Simplify use of module-system options by
	custom launchers
In-Reply-To: <80E0D931-6342-4BA2-B0FE-F162A46D6117@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
	<80E0D931-6342-4BA2-B0FE-F162A46D6117@oracle.com>
Message-ID: <B61E51FD-38C3-4189-A4CD-FF5C31512033@oracle.com>

Tests in jdk, hotspot, langtools, jaxp and nashorn repos have been converted to use the new options when this fix was pushed.

Any test changes in jdk9/client or jdk9/hs that are not yet in jdk9/dev would require changes.

Mandy

> On Aug 11, 2016, at 7:47 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> Hi, Mandy.
> 
> Could you help to identify what tests in the JTreg suite(s) require more work to switch to the new options?
> 
> Or the other way around: which tests have been fixed with this commit?
> 
> Thank you.
> 
> 
>> On Aug 5, 2016, at 1:11 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> This patch renames the module-system options to GNU-style as specified
>> in JEP 293 [1] (see below for the new proposed option names).  This
>> addresses the problems discussed in [2] that the launcher will pass 
>> the module-system options down to the VM in the form of <option>=<value>.
>> This provides a consistent way to configure the module system and
>> simplify use of module-system options by custom launcher.  This patch
>> also updates several JDK tools including jlink, jmod, jimage, jar,
>> javac, javap, javadoc, javah, jdeps such that the GNU-style 
>> module-system options are consistent across all tools.
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
>> 
>> Harold has posted a separate code review for the hotspot change [3].
>> webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
>> includes the changes in langtools repo (this may be convenient for
>> those who wants to review langtools change only).
>> 
>> Note that existing -cp and -classpath have no change and continue to
>> be supported.  New long form option `--class-path` and `--help` are 
>> added to java, javac, and other tools where applicable.
>> 
>> For transition, all old options except -listmods continue to be 
>> supported by the java launcher, javac, javadoc, javap, javah.  
>> I propose to remove the old options in two weeks after this patch
>> is promoted (i.e. two promoted builds to go through the transition).
>> 
>> Mandy
>> 
>> [1] http://openjdk.java.net/jeps/293
>> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
>> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
>> 
>> Existing Options                    New Options
>> 
>> -addmods                            --add-modules
>> -classpath | -cp | --classpath      -classpath | -cp | --class-path
>> -limitmods                          --limit-modules
>> -listmods                           --list-modules
>> -m                                  --module | -m
>> -modulepath | -mp | --modulepath    --module-path | -p
>> -modulesourcepath                   --module-source-path
>> --plugin-module-path                (no change)
>> -processormodulepath                --processor-module-path
>> -upgrademodulepath                  --upgrade-module-path
>> -XaddExports                        --add-exports
>> -XaddReads                          --add-reads
>> -Xpatch                             --patch-module
>> -bootclasspath                      --boot-class-path | -bootclasspath
>> -processorpath                      --processor-path  | -processor-path
>> -sourcepath                         --source-path | -sourcepath
>> -system                             --system
>> -release                            --release
> 


From alexandre.iline at oracle.com  Thu Aug 11 16:16:19 2016
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Thu, 11 Aug 2016 09:16:19 -0700
Subject: Review request 8136930: Simplify use of module-system options by
	custom launchers
In-Reply-To: <B61E51FD-38C3-4189-A4CD-FF5C31512033@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
	<80E0D931-6342-4BA2-B0FE-F162A46D6117@oracle.com>
	<B61E51FD-38C3-4189-A4CD-FF5C31512033@oracle.com>
Message-ID: <A42B9597-1065-42FE-A59C-8559AED6E69E@oracle.com>


> On Aug 11, 2016, at 7:57 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Tests in jdk, hotspot, langtools, jaxp and nashorn repos have been converted to use the new options when this fix was pushed.
> 
> Any test changes in jdk9/client or jdk9/hs that are not yet in jdk9/dev would require changes.

Just to be absolutely clear, you have scanned the source files for appearances of the options which are to go away, correct? You have searched java and shell files, I assume.

I hope it covers all the cases. If there is anything else we should be able to quickly identify it after running the tests.

Shura


> 
> Mandy
> 
>> On Aug 11, 2016, at 7:47 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>> 
>> Hi, Mandy.
>> 
>> Could you help to identify what tests in the JTreg suite(s) require more work to switch to the new options?
>> 
>> Or the other way around: which tests have been fixed with this commit?
>> 
>> Thank you.
>> 
>> 
>>> On Aug 5, 2016, at 1:11 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 
>>> This patch renames the module-system options to GNU-style as specified
>>> in JEP 293 [1] (see below for the new proposed option names).  This
>>> addresses the problems discussed in [2] that the launcher will pass 
>>> the module-system options down to the VM in the form of <option>=<value>.
>>> This provides a consistent way to configure the module system and
>>> simplify use of module-system options by custom launcher.  This patch
>>> also updates several JDK tools including jlink, jmod, jimage, jar,
>>> javac, javap, javadoc, javah, jdeps such that the GNU-style 
>>> module-system options are consistent across all tools.
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
>>> 
>>> Harold has posted a separate code review for the hotspot change [3].
>>> webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
>>> includes the changes in langtools repo (this may be convenient for
>>> those who wants to review langtools change only).
>>> 
>>> Note that existing -cp and -classpath have no change and continue to
>>> be supported.  New long form option `--class-path` and `--help` are 
>>> added to java, javac, and other tools where applicable.
>>> 
>>> For transition, all old options except -listmods continue to be 
>>> supported by the java launcher, javac, javadoc, javap, javah.  
>>> I propose to remove the old options in two weeks after this patch
>>> is promoted (i.e. two promoted builds to go through the transition).
>>> 
>>> Mandy
>>> 
>>> [1] http://openjdk.java.net/jeps/293
>>> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
>>> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
>>> 
>>> Existing Options                    New Options
>>> 
>>> -addmods                            --add-modules
>>> -classpath | -cp | --classpath      -classpath | -cp | --class-path
>>> -limitmods                          --limit-modules
>>> -listmods                           --list-modules
>>> -m                                  --module | -m
>>> -modulepath | -mp | --modulepath    --module-path | -p
>>> -modulesourcepath                   --module-source-path
>>> --plugin-module-path                (no change)
>>> -processormodulepath                --processor-module-path
>>> -upgrademodulepath                  --upgrade-module-path
>>> -XaddExports                        --add-exports
>>> -XaddReads                          --add-reads
>>> -Xpatch                             --patch-module
>>> -bootclasspath                      --boot-class-path | -bootclasspath
>>> -processorpath                      --processor-path  | -processor-path
>>> -sourcepath                         --source-path | -sourcepath
>>> -system                             --system
>>> -release                            --release
>> 
> 


From jonathan.gibbons at oracle.com  Thu Aug 11 20:06:32 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 Aug 2016 13:06:32 -0700
Subject: Review request 8136930: Simplify use of module-system options
	by custom launchers
In-Reply-To: <A42B9597-1065-42FE-A59C-8559AED6E69E@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>	<80E0D931-6342-4BA2-B0FE-F162A46D6117@oracle.com>	<B61E51FD-38C3-4189-A4CD-FF5C31512033@oracle.com>
	<A42B9597-1065-42FE-A59C-8559AED6E69E@oracle.com>
Message-ID: <57ACDAC8.4070906@oracle.com>

Shura,

Such is the nature of things, I would expect there are some instances of 
the old style options inbound from separate changesets under development 
or in review. I would expect that we will do a separate additional pass 
over tests before we remove support for the old style options.

-- Jon

On 08/11/2016 09:16 AM, Alexandre (Shura) Iline wrote:
>> On Aug 11, 2016, at 7:57 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>
>> Tests in jdk, hotspot, langtools, jaxp and nashorn repos have been converted to use the new options when this fix was pushed.
>>
>> Any test changes in jdk9/client or jdk9/hs that are not yet in jdk9/dev would require changes.
> Just to be absolutely clear, you have scanned the source files for appearances of the options which are to go away, correct? You have searched java and shell files, I assume.
>
> I hope it covers all the cases. If there is anything else we should be able to quickly identify it after running the tests.
>
> Shura
>
>
>> Mandy
>>
>>> On Aug 11, 2016, at 7:47 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>>
>>> Hi, Mandy.
>>>
>>> Could you help to identify what tests in the JTreg suite(s) require more work to switch to the new options?
>>>
>>> Or the other way around: which tests have been fixed with this commit?
>>>
>>> Thank you.
>>>
>>>
>>>> On Aug 5, 2016, at 1:11 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>
>>>> This patch renames the module-system options to GNU-style as specified
>>>> in JEP 293 [1] (see below for the new proposed option names).  This
>>>> addresses the problems discussed in [2] that the launcher will pass
>>>> the module-system options down to the VM in the form of <option>=<value>.
>>>> This provides a consistent way to configure the module system and
>>>> simplify use of module-system options by custom launcher.  This patch
>>>> also updates several JDK tools including jlink, jmod, jimage, jar,
>>>> javac, javap, javadoc, javah, jdeps such that the GNU-style
>>>> module-system options are consistent across all tools.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
>>>>
>>>> Harold has posted a separate code review for the hotspot change [3].
>>>> webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
>>>> includes the changes in langtools repo (this may be convenient for
>>>> those who wants to review langtools change only).
>>>>
>>>> Note that existing -cp and -classpath have no change and continue to
>>>> be supported.  New long form option `--class-path` and `--help` are
>>>> added to java, javac, and other tools where applicable.
>>>>
>>>> For transition, all old options except -listmods continue to be
>>>> supported by the java launcher, javac, javadoc, javap, javah.
>>>> I propose to remove the old options in two weeks after this patch
>>>> is promoted (i.e. two promoted builds to go through the transition).
>>>>
>>>> Mandy
>>>>
>>>> [1] http://openjdk.java.net/jeps/293
>>>> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
>>>> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
>>>>
>>>> Existing Options                    New Options
>>>>
>>>> -addmods                            --add-modules
>>>> -classpath | -cp | --classpath      -classpath | -cp | --class-path
>>>> -limitmods                          --limit-modules
>>>> -listmods                           --list-modules
>>>> -m                                  --module | -m
>>>> -modulepath | -mp | --modulepath    --module-path | -p
>>>> -modulesourcepath                   --module-source-path
>>>> --plugin-module-path                (no change)
>>>> -processormodulepath                --processor-module-path
>>>> -upgrademodulepath                  --upgrade-module-path
>>>> -XaddExports                        --add-exports
>>>> -XaddReads                          --add-reads
>>>> -Xpatch                             --patch-module
>>>> -bootclasspath                      --boot-class-path | -bootclasspath
>>>> -processorpath                      --processor-path  | -processor-path
>>>> -sourcepath                         --source-path | -sourcepath
>>>> -system                             --system
>>>> -release                            --release


From alexandre.iline at oracle.com  Thu Aug 11 20:41:58 2016
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Thu, 11 Aug 2016 13:41:58 -0700
Subject: Review request 8136930: Simplify use of module-system options by
	custom launchers
In-Reply-To: <57ACDAC8.4070906@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
	<80E0D931-6342-4BA2-B0FE-F162A46D6117@oracle.com>
	<B61E51FD-38C3-4189-A4CD-FF5C31512033@oracle.com>
	<A42B9597-1065-42FE-A59C-8559AED6E69E@oracle.com>
	<57ACDAC8.4070906@oracle.com>
Message-ID: <67AE498B-835E-445E-A570-E441F62A0088@oracle.com>


> On Aug 11, 2016, at 1:06 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Shura,
> 
> Such is the nature of things, I would expect there are some instances of the old style options inbound from separate changesets under development or in review. I would expect that we will do a separate additional pass over tests before we remove support for the old style options.

Of course.

And also, to be completely sure that the tests using new options everywhere, a test run needs to be performed for all tests and failures need to be looked on. Which we will do once the promotion build is out.

Shura

> 
> -- Jon
> 
> On 08/11/2016 09:16 AM, Alexandre (Shura) Iline wrote:
>>> On Aug 11, 2016, at 7:57 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 
>>> Tests in jdk, hotspot, langtools, jaxp and nashorn repos have been converted to use the new options when this fix was pushed.
>>> 
>>> Any test changes in jdk9/client or jdk9/hs that are not yet in jdk9/dev would require changes.
>> Just to be absolutely clear, you have scanned the source files for appearances of the options which are to go away, correct? You have searched java and shell files, I assume.
>> 
>> I hope it covers all the cases. If there is anything else we should be able to quickly identify it after running the tests.
>> 
>> Shura
>> 
>> 
>>> Mandy
>>> 
>>>> On Aug 11, 2016, at 7:47 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>>> 
>>>> Hi, Mandy.
>>>> 
>>>> Could you help to identify what tests in the JTreg suite(s) require more work to switch to the new options?
>>>> 
>>>> Or the other way around: which tests have been fixed with this commit?
>>>> 
>>>> Thank you.
>>>> 
>>>> 
>>>>> On Aug 5, 2016, at 1:11 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>> 
>>>>> This patch renames the module-system options to GNU-style as specified
>>>>> in JEP 293 [1] (see below for the new proposed option names).  This
>>>>> addresses the problems discussed in [2] that the launcher will pass
>>>>> the module-system options down to the VM in the form of <option>=<value>.
>>>>> This provides a consistent way to configure the module system and
>>>>> simplify use of module-system options by custom launcher.  This patch
>>>>> also updates several JDK tools including jlink, jmod, jimage, jar,
>>>>> javac, javap, javadoc, javah, jdeps such that the GNU-style
>>>>> module-system options are consistent across all tools.
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/
>>>>> 
>>>>> Harold has posted a separate code review for the hotspot change [3].
>>>>> webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
>>>>> includes the changes in langtools repo (this may be convenient for
>>>>> those who wants to review langtools change only).
>>>>> 
>>>>> Note that existing -cp and -classpath have no change and continue to
>>>>> be supported.  New long form option `--class-path` and `--help` are
>>>>> added to java, javac, and other tools where applicable.
>>>>> 
>>>>> For transition, all old options except -listmods continue to be
>>>>> supported by the java launcher, javac, javadoc, javap, javah.
>>>>> I propose to remove the old options in two weeks after this patch
>>>>> is promoted (i.e. two promoted builds to go through the transition).
>>>>> 
>>>>> Mandy
>>>>> 
>>>>> [1] http://openjdk.java.net/jeps/293
>>>>> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
>>>>> [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html
>>>>> 
>>>>> Existing Options                    New Options
>>>>> 
>>>>> -addmods                            --add-modules
>>>>> -classpath | -cp | --classpath      -classpath | -cp | --class-path
>>>>> -limitmods                          --limit-modules
>>>>> -listmods                           --list-modules
>>>>> -m                                  --module | -m
>>>>> -modulepath | -mp | --modulepath    --module-path | -p
>>>>> -modulesourcepath                   --module-source-path
>>>>> --plugin-module-path                (no change)
>>>>> -processormodulepath                --processor-module-path
>>>>> -upgrademodulepath                  --upgrade-module-path
>>>>> -XaddExports                        --add-exports
>>>>> -XaddReads                          --add-reads
>>>>> -Xpatch                             --patch-module
>>>>> -bootclasspath                      --boot-class-path | -bootclasspath
>>>>> -processorpath                      --processor-path  | -processor-path
>>>>> -sourcepath                         --source-path | -sourcepath
>>>>> -system                             --system
>>>>> -release                            --release
> 


From mandy.chung at oracle.com  Thu Aug 11 20:59:07 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 Aug 2016 13:59:07 -0700
Subject: Review request 8136930: Simplify use of module-system options by
	custom launchers
In-Reply-To: <67AE498B-835E-445E-A570-E441F62A0088@oracle.com>
References: <FB9415D6-2396-4D9D-A44C-7FB1E56B1862@oracle.com>
	<80E0D931-6342-4BA2-B0FE-F162A46D6117@oracle.com>
	<B61E51FD-38C3-4189-A4CD-FF5C31512033@oracle.com>
	<A42B9597-1065-42FE-A59C-8559AED6E69E@oracle.com>
	<57ACDAC8.4070906@oracle.com>
	<67AE498B-835E-445E-A570-E441F62A0088@oracle.com>
Message-ID: <3C35829F-A02C-4043-91BF-BADD28DBD111@oracle.com>


> On Aug 11, 2016, at 1:41 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> 
>> On Aug 11, 2016, at 1:06 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>> 
>> Shura,
>> 
>> Such is the nature of things, I would expect there are some instances of the old style options inbound from separate changesets under development or in review. I would expect that we will do a separate additional pass over tests before we remove support for the old style options.
> 
> Of course.
> 
> And also, to be completely sure that the tests using new options everywhere, a test run needs to be performed for all tests and failures need to be looked on. Which we will do once the promotion build is out.
> 

That?d be good.  I expect that will happen during one of those testing cycle.  This will ensure that the tests are correctly updated. We have verified the pit and hotspot tests.
 
Note that the old options continue to work.  Testing won?t find any tests needed to be converted to use new options, if that?s what you intend to find.


>> 
>> On 08/11/2016 09:16 AM, Alexandre (Shura) Iline wrote:
>>>> On Aug 11, 2016, at 7:57 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>> 
>>>> Tests in jdk, hotspot, langtools, jaxp and nashorn repos have been converted to use the new options when this fix was pushed.
>>>> 
>>>> Any test changes in jdk9/client or jdk9/hs that are not yet in jdk9/dev would require changes.
>>> Just to be absolutely clear, you have scanned the source files for appearances of the options which are to go away, correct? You have searched java and shell files, I assume.
>>> 

the entire source tree which has makefiles, native source file, etc.  Not only java and shell tests.

>>> I hope it covers all the cases. If there is anything else we should be able to quickly identify it after running the tests.

Only when the old options are removed.

Mandy

From alexandre.iline at oracle.com  Fri Aug 12 22:58:01 2016
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Fri, 12 Aug 2016 15:58:01 -0700
Subject: RFR: JDK-8163991: Fix license and copyright headers under
	test/jdk/javadoc/ and test/tools/javac/
In-Reply-To: <F4C0009F-D501-4CEA-A45E-267B9EBBDB03@oracle.com>
References: <F4C0009F-D501-4CEA-A45E-267B9EBBDB03@oracle.com>
Message-ID: <12169548-CEB4-4684-82F3-1FFF1F9EEFFE@oracle.com>

That looks ok, Sandeep.

Thanks.

Shura

> On Aug 12, 2016, at 3:55 PM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
> 
> Hello,
> 
> Please review the patch below which fixes copyright in test files for javadoc and javac
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163991
> Webrev: http://cr.openjdk.java.net/~shurailine/8163991/webrev.00/langtools.patch
> 
> Thanks,
> Sandeep


From Chris.Greenaway at softwareag.com  Tue Aug 16 09:21:42 2016
From: Chris.Greenaway at softwareag.com (Greenaway, Chris)
Date: Tue, 16 Aug 2016 09:21:42 +0000
Subject: Lambda return types and overloaded methods
Message-ID: <B396BF84AB575D46A32CF8A460F1030638C625@HQMBX4.eur.ad.sag>

There seems to be a problem with matching the return type of a lambda to the type required by an overloaded method when the lambda parameter isn't explicitly typed.

For example, the code below has compilation failures on the lines that are marked with "// Error". All other lines are acceptable.

There also seems to be an issue with method references when there are multiple methods with the same name but different arity - see the line marked "// Error 8".

            Chris Greenaway.


import java.util.function.Function;
import java.util.function.Predicate;

public class LambdaOverloading {
    public static void main(String[] args) {
        LambdaPredicate predicate = new LambdaPredicate();
        predicate.run((String s) -> s.startsWith("X"));
        predicate.run((String s) -> s.isEmpty());
        predicate.run((String s) -> true);
        predicate.run(s -> s.startsWith("X"));
        predicate.run(s -> s.isEmpty());
        predicate.run(s -> true);
        predicate.run(String::isEmpty);

        LambdaFunction function = new LambdaFunction();
        function.run((String s) -> s.substring(1));
        function.run((String s) -> s.trim());
        function.run((String s) -> s.toUpperCase());
        function.run((String s) -> "");
        function.run(s -> s.substring(1));
        function.run(s -> s.trim());
        function.run(s -> s.toUpperCase());
        function.run(s -> "");
        function.run(String::trim);
        function.run(String::toUpperCase);

        LambdaOverloaded overloaded = new LambdaOverloaded();
        overloaded.run((String s) -> s.startsWith("X"));
        overloaded.run((String s) -> s.substring(1));
        overloaded.run((String s) -> s.isEmpty());
        overloaded.run((String s) -> s.trim());
        overloaded.run((String s) -> s.toUpperCase());
        overloaded.run((String s) -> true);
        overloaded.run((String s) -> "");
        overloaded.run(s -> s.startsWith("X"));                     // Error 1
        overloaded.run(s -> s.substring(1));                        // Error 2
        overloaded.run(s -> s.isEmpty());                           // Error 3
        overloaded.run(s -> s.trim());                              // Error 4
        overloaded.run(s -> s.toUpperCase());                       // Error 5
        overloaded.run(s -> true);                                  // Error 6
        overloaded.run(s -> "");                                    // Error 7
        overloaded.run(String::isEmpty);
        overloaded.run(String::trim);
        overloaded.run(String::toUpperCase);                        // Error 8
    }

    private static class LambdaPredicate {
        public boolean run(Predicate<String> predicate) {
            return predicate.test("test");
        }
    }

    private static class LambdaFunction {
        public String run(Function<String, String> function) {
            return function.apply("test");
        }
    }

    private static class LambdaOverloaded {
        public boolean run(Predicate<String> predicate) {
            return predicate.test("test");
        }

        public String run(Function<String, String> function) {
            return function.apply("test");
        }
    }
}
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160816/70b305b0/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Tue Aug 16 10:17:40 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 Aug 2016 11:17:40 +0100
Subject: Lambda return types and overloaded methods
In-Reply-To: <B396BF84AB575D46A32CF8A460F1030638C625@HQMBX4.eur.ad.sag>
References: <B396BF84AB575D46A32CF8A460F1030638C625@HQMBX4.eur.ad.sag>
Message-ID: <a5fae9ef-6433-7e21-507b-319aa9525157@oracle.com>

Hi Chris,

what you are observing is by design - to keep things tractable, we 
deliberately decided to keep overload resolution a function of the 
argument expressions, and to only look at the return types after 
inference. In fact, javac won't even look at the body of a lambda, or a 
method reference or conditionals if such expressions are considered 
_not_ pertinent to applicability (see JLS section 15.12.2.2 for a formal 
definition). In short, an argument expression is pertinent to 
applicability unless it is an implicit lambda (a lambda w/o explicit 
parameter types) or an inexact method reference (a method reference 
matching multiple overloads) - or a conditional whose either 
sub-expression is one of those.

So, when you have argument expressions that are not pertinent to 
applicability, your only hope against ambiguity error is the loose 
applicability check described in JLS 15.12.2.1 - potential 
compatibility. This is a much looser check which simply validates that 
the lambda (or method reference) has an arity that is compatible with 
that of the target functional interface (for method reference we also 
look at void vs. value compatibility).

Sp, all your implicit lambda cases are ambiguous, because your targets 
are Predicate<String> and Function<String, String> - i.e. both are 
functional types accepting a String (arity 1). Given we are not allowed 
to look at the lambda body at this stage (the lambda is not pertinent to 
applicability), we have to give up.

In the case of the method references, you have that both String::isEmpty 
and String::trim are _exact_ method references - they are unambiguous, 
so the return types of such methods can indeed be used to disambiguate. 
The same cannot be said for String::toUpperCase which has two matches - 
so both Predicate<String> and Function<String, String> are potentially 
compatible with String::toUpperCase (given that one of the overloads for 
String::toUpperCase matches the arity of the function types) - but the 
method reference expression is then discarded from further checking 
because it is an inexact method reference, so the return type cannot be 
looked at.

If this behavior seems too strict, please keep in mind that these rules 
have been discussed extensively at the various lambda EG meetings; at 
some point we had a more powerful overload resolution algorithm - but 
there was an unanimous consensus to back out from it because its 
behavior was very hard to explain to users (the compiler would 
speculatively check a lambda body against each overloaded method, and 
discard those not compatible - this leads to a combinatorial explosion 
of checks in nested cases - and is generally an hard-to-follow process 
for a non-stack based human ;-)).

I concede that, in these particular cases, the behavior of pertinent to 
applicability/potential compatibility is a little phony - in the case of 
lambda, all overloads accept a functional interface which dictate a 
String parameter - so, there seems to be no ambiguity as to how the 
lambda body should be interpreted. A similar consideration holds for the 
method reference case where, after all, both overloaded toUpperCase 
methods return String, so why not using that information to prune the 
space of applicable methods (since Predicate<String> clearly does not 
return a String) ? While these might all be good incremental 
improvements over what we have, I must stress that this is not the 
language we have today.

Cheers
Maurizio

(*) this is not totally correct - in fact return types are also used for 
disambuguation when multiple methods are applicable - but for that to 
apply the lambda/method reference must be pertinent to applicability - 
i.e. an explicit lambda, or an exact method reference.


On 16/08/16 10:21, Greenaway, Chris wrote:
>
> There seems to be a problem with matching the return type of a lambda 
> to the type required by an overloaded method when the lambda parameter 
> isn't explicitly typed.
>
> For example, the code below has compilation failures on the lines that 
> are marked with "// Error". All other lines are acceptable.
>
> There also seems to be an issue with method references when there are 
> multiple methods with the same name but different arity - see the line 
> marked "// Error 8".
>
> Chris Greenaway.
>
> import java.util.function.Function;
>
> import java.util.function.Predicate;
>
> public class LambdaOverloading {
>
>     public static void main(String[] args) {
>
> LambdaPredicate predicate = new LambdaPredicate();
>
> predicate.run((String s) -> s.startsWith("X"));
>
> predicate.run((String s) -> s.isEmpty());
>
> predicate.run((String s) -> true);
>
> predicate.run(s -> s.startsWith("X"));
>
> predicate.run(s -> s.isEmpty());
>
> predicate.run(s -> true);
>
> predicate.run(String::isEmpty);
>
> LambdaFunction function = new LambdaFunction();
>
> function.run((String s) -> s.substring(1));
>
> function.run((String s) -> s.trim());
>
> function.run((String s) -> s.toUpperCase());
>
> function.run((String s) -> "");
>
> function.run(s -> s.substring(1));
>
> function.run(s -> s.trim());
>
> function.run(s -> s.toUpperCase());
>
> function.run(s -> "");
>
> function.run(String::trim);
>
> function.run(String::toUpperCase);
>
> LambdaOverloaded overloaded = new LambdaOverloaded();
>
> overloaded.run((String s) -> s.startsWith("X"));
>
> overloaded.run((String s) -> s.substring(1));
>
> overloaded.run((String s) -> s.isEmpty());
>
> overloaded.run((String s) -> s.trim());
>
> overloaded.run((String s) -> s.toUpperCase());
>
> overloaded.run((String s) -> true);
>
> overloaded.run((String s) -> "");
>
> overloaded.run(s -> s.startsWith("X"));                     // Error 1
>
> overloaded.run(s -> s.substring(1));                        // Error 2
>
> overloaded.run(s -> s.isEmpty());                           // Error 3
>
> overloaded.run(s -> s.trim());                              // Error 4
>
> overloaded.run(s -> s.toUpperCase());                       // Error 5
>
> overloaded.run(s -> true);                                  // Error 6
>
> overloaded.run(s -> "");                                    // Error 7
>
> overloaded.run(String::isEmpty);
>
> overloaded.run(String::trim);
>
> overloaded.run(String::toUpperCase); // Error 8
>
>     }
>
>     private static class LambdaPredicate {
>
>         public boolean run(Predicate<String> predicate) {
>
> return predicate.test("test");
>
>         }
>
>     }
>
>     private static class LambdaFunction {
>
>         public String run(Function<String, String> function) {
>
> return function.apply("test");
>
>         }
>
>     }
>
>     private static class LambdaOverloaded {
>
>         public boolean run(Predicate<String> predicate) {
>
> return predicate.test("test");
>
>         }
>
>         public String run(Function<String, String> function) {
>
> return function.apply("test");
>
>         }
>
>     }
>
> }
>
> This communication contains information which is confidential and may 
> also be privileged. It is for the exclusive use of the intended 
> recipient(s). If you are not the intended recipient(s), please note 
> that any distribution, copying, or use of this communication or the 
> information in it, is strictly prohibited. If you have received this 
> communication in error please notify us by e-mail and then delete the 
> e-mail and any copies of it.
> Software AG (UK) Limited Registered in England & Wales 1310740 - 
> /*http://www.softwareag.com/uk* /
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160816/090abb6e/attachment-0001.html>

From Chris.Greenaway at softwareag.com  Tue Aug 16 12:38:21 2016
From: Chris.Greenaway at softwareag.com (Greenaway, Chris)
Date: Tue, 16 Aug 2016 12:38:21 +0000
Subject: Lambda return types and overloaded methods
In-Reply-To: <a5fae9ef-6433-7e21-507b-319aa9525157@oracle.com>
References: <B396BF84AB575D46A32CF8A460F1030638C625@HQMBX4.eur.ad.sag>
	<a5fae9ef-6433-7e21-507b-319aa9525157@oracle.com>
Message-ID: <B396BF84AB575D46A32CF8A460F1030638C682@HQMBX4.eur.ad.sag>

That doesn't seem to fit with the discussion on this JDK bug: https://bugs.openjdk.java.net/browse/JDK-8029718 which has been fixed. In particular, there's a link to a discussion on this mailing list ( http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011394.html ) where various members express the opinion that the compiler should consider more than just arity.

An important consideration seems to be 15.27.3 of the JLS. Paraphrasing, it says that a lambda with implicitly typed parameters is only compatible with a functional interface if the lambda body results in a value compatible with the functional interface's result type. The definition of potentially compatible in 15.12.2.1 specifically references this.

            Chris.



From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
Sent: 16 August 2016 11:18
To: Greenaway, Chris; compiler-dev at openjdk.java.net
Subject: Re: Lambda return types and overloaded methods


Hi Chris,

what you are observing is by design - to keep things tractable, we deliberately decided to keep overload resolution a function of the argument expressions, and to only look at the return types after inference. In fact, javac won't even look at the body of a lambda, or a method reference or conditionals if such expressions are considered _not_ pertinent to applicability (see JLS section 15.12.2.2 for a formal definition). In short, an argument expression is pertinent to applicability unless it is an implicit lambda (a lambda w/o explicit parameter types) or an inexact method reference (a method reference matching multiple overloads) - or a conditional whose either sub-expression is one of those.

So, when you have argument expressions that are not pertinent to applicability, your only hope against ambiguity error is the loose applicability check described in JLS 15.12.2.1 - potential compatibility. This is a much looser check which simply validates that the lambda (or method reference) has an arity that is compatible with that of the target functional interface (for method reference we also look at void vs. value compatibility).

Sp, all your implicit lambda cases are ambiguous, because your targets are Predicate<String> and Function<String, String> - i.e. both are functional types accepting a String (arity 1). Given we are not allowed to look at the lambda body at this stage (the lambda is not pertinent to applicability), we have to give up.

In the case of the method references, you have that both String::isEmpty and String::trim are _exact_ method references - they are unambiguous, so the return types of such methods can indeed be used to disambiguate. The same cannot be said for String::toUpperCase which has two matches - so both Predicate<String> and Function<String, String> are potentially compatible with String::toUpperCase (given that one of the overloads for String::toUpperCase matches the arity of the function types) - but the method reference expression is then discarded from further checking because it is an inexact method reference, so the return type cannot be looked at.

If this behavior seems too strict, please keep in mind that these rules have been discussed extensively at the various lambda EG meetings; at some point we had a more powerful overload resolution algorithm - but there was an unanimous consensus to back out from it because its behavior was very hard to explain to users (the compiler would speculatively check a lambda body against each overloaded method, and discard those not compatible - this leads to a combinatorial explosion of checks in nested cases - and is generally an hard-to-follow process for a non-stack based human ;-)).

I concede that, in these particular cases, the behavior of pertinent to applicability/potential compatibility is a little phony - in the case of lambda, all overloads accept a functional interface which dictate a String parameter - so, there seems to be no ambiguity as to how the lambda body should be interpreted. A similar consideration holds for the method reference case where, after all, both overloaded toUpperCase methods return String, so why not using that information to prune the space of applicable methods (since Predicate<String> clearly does not return a String) ? While these might all be good incremental improvements over what we have, I must stress that this is not the language we have today.

Cheers
Maurizio

(*) this is not totally correct - in fact return types are also used for disambuguation when multiple methods are applicable - but for that to apply the lambda/method reference must be pertinent to applicability - i.e. an explicit lambda, or an exact method reference.

On 16/08/16 10:21, Greenaway, Chris wrote:
There seems to be a problem with matching the return type of a lambda to the type required by an overloaded method when the lambda parameter isn't explicitly typed.

For example, the code below has compilation failures on the lines that are marked with "// Error". All other lines are acceptable.

There also seems to be an issue with method references when there are multiple methods with the same name but different arity - see the line marked "// Error 8".

            Chris Greenaway.


import java.util.function.Function;
import java.util.function.Predicate;

public class LambdaOverloading {
    public static void main(String[] args) {
        LambdaPredicate predicate = new LambdaPredicate();
        predicate.run((String s) -> s.startsWith("X"));
        predicate.run((String s) -> s.isEmpty());
        predicate.run((String s) -> true);
        predicate.run(s -> s.startsWith("X"));
        predicate.run(s -> s.isEmpty());
        predicate.run(s -> true);
        predicate.run(String::isEmpty);

        LambdaFunction function = new LambdaFunction();
        function.run((String s) -> s.substring(1));
        function.run((String s) -> s.trim());
        function.run((String s) -> s.toUpperCase());
        function.run((String s) -> "");
        function.run(s -> s.substring(1));
        function.run(s -> s.trim());
        function.run(s -> s.toUpperCase());
        function.run(s -> "");
        function.run(String::trim);
        function.run(String::toUpperCase);

        LambdaOverloaded overloaded = new LambdaOverloaded();
        overloaded.run((String s) -> s.startsWith("X"));
        overloaded.run((String s) -> s.substring(1));
        overloaded.run((String s) -> s.isEmpty());
        overloaded.run((String s) -> s.trim());
        overloaded.run((String s) -> s.toUpperCase());
        overloaded.run((String s) -> true);
        overloaded.run((String s) -> "");
        overloaded.run(s -> s.startsWith("X"));                     // Error 1
        overloaded.run(s -> s.substring(1));                        // Error 2
        overloaded.run(s -> s.isEmpty());                           // Error 3
        overloaded.run(s -> s.trim());                              // Error 4
        overloaded.run(s -> s.toUpperCase());                       // Error 5
        overloaded.run(s -> true);                                  // Error 6
        overloaded.run(s -> "");                                    // Error 7
        overloaded.run(String::isEmpty);
        overloaded.run(String::trim);
        overloaded.run(String::toUpperCase);                        // Error 8
    }

    private static class LambdaPredicate {
        public boolean run(Predicate<String> predicate) {
            return predicate.test("test");
        }
    }

    private static class LambdaFunction {
        public String run(Function<String, String> function) {
            return function.apply("test");
        }
    }

    private static class LambdaOverloaded {
        public boolean run(Predicate<String> predicate) {
            return predicate.test("test");
        }

        public String run(Function<String, String> function) {
            return function.apply("test");
        }
    }
}
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk


This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160816/b0b7eb60/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Tue Aug 16 12:49:06 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 Aug 2016 13:49:06 +0100
Subject: Lambda return types and overloaded methods
In-Reply-To: <B396BF84AB575D46A32CF8A460F1030638C682@HQMBX4.eur.ad.sag>
References: <B396BF84AB575D46A32CF8A460F1030638C625@HQMBX4.eur.ad.sag>
	<a5fae9ef-6433-7e21-507b-319aa9525157@oracle.com>
	<B396BF84AB575D46A32CF8A460F1030638C682@HQMBX4.eur.ad.sag>
Message-ID: <dc30069a-6b61-b37c-497b-cc11f5dcc671@oracle.com>



On 16/08/16 13:38, Greenaway, Chris wrote:
>
> That doesn?t seem to fit with the discussion on this JDK bug: 
> https://bugs.openjdk.java.net/browse/JDK-8029718 which has been fixed. 
> In particular, there?s a link to a discussion on this mailing list ( 
> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011394.html 
> ) where various members express the opinion that the compiler should 
> consider more than just arity.
>
The bug (and the discussion) you refer to consider the case of value vs. 
void compatible lambda. I.e. if a lambda does not return, that 
information is enough to rule out a functional interface with non-void 
return type.
In your case the lambda is returning something, and both functional 
interfaces also return something. So that doesn't apply.
>
> An important consideration seems to be 15.27.3 of the JLS. 
> Paraphrasing, it says that a lambda with implicitly typed parameters 
> is only compatible with a functional interface if the lambda body 
> results in a value compatible with the functional interface?s result 
> type. The definition of potentially compatible in 15.12.2.1 
> specifically references this.
>
I don't see references from 15.12.2.1 to 15.27.3. I see however 
references to 15.27.2 - when the potentially compatible definition takes 
into account as whether the lambda is void- or value- compatible.

Maurizio
>
> Chris.
>
> *From:*Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> *Sent:* 16 August 2016 11:18
> *To:* Greenaway, Chris; compiler-dev at openjdk.java.net
> *Subject:* Re: Lambda return types and overloaded methods
>
> Hi Chris,
>
> what you are observing is by design - to keep things tractable, we 
> deliberately decided to keep overload resolution a function of the 
> argument expressions, and to only look at the return types after 
> inference. In fact, javac won't even look at the body of a lambda, or 
> a method reference or conditionals if such expressions are considered 
> _not_ pertinent to applicability (see JLS section 15.12.2.2 for a 
> formal definition). In short, an argument expression is pertinent to 
> applicability unless it is an implicit lambda (a lambda w/o explicit 
> parameter types) or an inexact method reference (a method reference 
> matching multiple overloads) - or a conditional whose either 
> sub-expression is one of those.
>
> So, when you have argument expressions that are not pertinent to 
> applicability, your only hope against ambiguity error is the loose 
> applicability check described in JLS 15.12.2.1 - potential 
> compatibility. This is a much looser check which simply validates that 
> the lambda (or method reference) has an arity that is compatible with 
> that of the target functional interface (for method reference we also 
> look at void vs. value compatibility).
>
> Sp, all your implicit lambda cases are ambiguous, because your targets 
> are Predicate<String> and Function<String, String> - i.e. both are 
> functional types accepting a String (arity 1). Given we are not 
> allowed to look at the lambda body at this stage (the lambda is not 
> pertinent to applicability), we have to give up.
>
> In the case of the method references, you have that both 
> String::isEmpty and String::trim are _exact_ method references - they 
> are unambiguous, so the return types of such methods can indeed be 
> used to disambiguate. The same cannot be said for String::toUpperCase 
> which has two matches - so both Predicate<String> and Function<String, 
> String> are potentially compatible with String::toUpperCase (given 
> that one of the overloads for String::toUpperCase matches the arity of 
> the function types) - but the method reference expression is then 
> discarded from further checking because it is an inexact method 
> reference, so the return type cannot be looked at.
>
> If this behavior seems too strict, please keep in mind that these 
> rules have been discussed extensively at the various lambda EG 
> meetings; at some point we had a more powerful overload resolution 
> algorithm - but there was an unanimous consensus to back out from it 
> because its behavior was very hard to explain to users (the compiler 
> would speculatively check a lambda body against each overloaded 
> method, and discard those not compatible - this leads to a 
> combinatorial explosion of checks in nested cases - and is generally 
> an hard-to-follow process for a non-stack based human ;-)).
>
> I concede that, in these particular cases, the behavior of pertinent 
> to applicability/potential compatibility is a little phony - in the 
> case of lambda, all overloads accept a functional interface which 
> dictate a String parameter - so, there seems to be no ambiguity as to 
> how the lambda body should be interpreted. A similar consideration 
> holds for the method reference case where, after all, both overloaded 
> toUpperCase methods return String, so why not using that information 
> to prune the space of applicable methods (since Predicate<String> 
> clearly does not return a String) ? While these might all be good 
> incremental improvements over what we have, I must stress that this is 
> not the language we have today.
>
> Cheers
> Maurizio
>
> (*) this is not totally correct - in fact return types are also used 
> for disambuguation when multiple methods are applicable - but for that 
> to apply the lambda/method reference must be pertinent to 
> applicability - i.e. an explicit lambda, or an exact method reference.
>
> On 16/08/16 10:21, Greenaway, Chris wrote:
>
>     There seems to be a problem with matching the return type of a
>     lambda to the type required by an overloaded method when the
>     lambda parameter isn't explicitly typed.
>
>     For example, the code below has compilation failures on the lines
>     that are marked with "// Error". All other lines are acceptable.
>
>     There also seems to be an issue with method references when there
>     are multiple methods with the same name but different arity - see
>     the line marked "// Error 8".
>
>     Chris Greenaway.
>
>     import java.util.function.Function;
>
>     import java.util.function.Predicate;
>
>     public class LambdaOverloading {
>
>     public static void main(String[] args) {
>
>     LambdaPredicate predicate = new LambdaPredicate();
>
>     predicate.run((String s) -> s.startsWith("X"));
>
>     predicate.run((String s) -> s.isEmpty());
>
>     predicate.run((String s) -> true);
>
>     predicate.run(s -> s.startsWith("X"));
>
>     predicate.run(s -> s.isEmpty());
>
>     predicate.run(s -> true);
>
>     predicate.run(String::isEmpty);
>
>     LambdaFunction function = new LambdaFunction();
>
>     function.run((String s) -> s.substring(1));
>
>     function.run((String s) -> s.trim());
>
>     function.run((String s) -> s.toUpperCase());
>
>     function.run((String s) -> "");
>
>     function.run(s -> s.substring(1));
>
>     function.run(s -> s.trim());
>
>     function.run(s -> s.toUpperCase());
>
>     function.run(s -> "");
>
>     function.run(String::trim);
>
>     function.run(String::toUpperCase);
>
>     LambdaOverloaded overloaded = new LambdaOverloaded();
>
>     overloaded.run((String s) -> s.startsWith("X"));
>
>     overloaded.run((String s) -> s.substring(1));
>
>     overloaded.run((String s) -> s.isEmpty());
>
>     overloaded.run((String s) -> s.trim());
>
>     overloaded.run((String s) -> s.toUpperCase());
>
>     overloaded.run((String s) -> true);
>
>     overloaded.run((String s) -> "");
>
>     overloaded.run(s -> s.startsWith("X"));                     // Error 1
>
>     overloaded.run(s -> s.substring(1));                        // Error 2
>
>     overloaded.run(s -> s.isEmpty());                           // Error 3
>
>     overloaded.run(s -> s.trim());                              // Error 4
>
>     overloaded.run(s -> s.toUpperCase());                       // Error 5
>
>     overloaded.run(s -> true);                                  // Error 6
>
>     overloaded.run(s -> "");                                    // Error 7
>
>     overloaded.run(String::isEmpty);
>
>     overloaded.run(String::trim);
>
>     overloaded.run(String::toUpperCase); // Error 8
>
>         }
>
>     private static class LambdaPredicate {
>
>     public boolean run(Predicate<String> predicate) {
>
>     return predicate.test("test");
>
>             }
>
>         }
>
>     private static class LambdaFunction {
>
>     public String run(Function<String, String> function) {
>
>     return function.apply("test");
>
>             }
>
>         }
>
>     private static class LambdaOverloaded {
>
>     public boolean run(Predicate<String> predicate) {
>
>     return predicate.test("test");
>
>             }
>
>     public String run(Function<String, String> function) {
>
>     return function.apply("test");
>
>             }
>
>         }
>
>     }
>
>     This communication contains information which is confidential and
>     may also be privileged. It is for the exclusive use of the
>     intended recipient(s). If you are not the intended recipient(s),
>     please note that any distribution, copying, or use of this
>     communication or the information in it, is strictly prohibited. If
>     you have received this communication in error please notify us by
>     e-mail and then delete the e-mail and any copies of it.
>
>     Software AG (UK) Limited Registered in England & Wales 1310740 -
>     */http://www.softwareag.com/uk/*//
>
> This communication contains information which is confidential and may 
> also be privileged. It is for the exclusive use of the intended 
> recipient(s). If you are not the intended recipient(s), please note 
> that any distribution, copying, or use of this communication or the 
> information in it, is strictly prohibited. If you have received this 
> communication in error please notify us by e-mail and then delete the 
> e-mail and any copies of it.
> Software AG (UK) Limited Registered in England & Wales 1310740 - 
> /*http://www.softwareag.com/uk* /
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160816/01041010/attachment-0001.html>

From Chris.Greenaway at softwareag.com  Tue Aug 16 13:58:55 2016
From: Chris.Greenaway at softwareag.com (Greenaway, Chris)
Date: Tue, 16 Aug 2016 13:58:55 +0000
Subject: Lambda return types and overloaded methods
In-Reply-To: <dc30069a-6b61-b37c-497b-cc11f5dcc671@oracle.com>
References: <B396BF84AB575D46A32CF8A460F1030638C625@HQMBX4.eur.ad.sag>
	<a5fae9ef-6433-7e21-507b-319aa9525157@oracle.com>
	<B396BF84AB575D46A32CF8A460F1030638C682@HQMBX4.eur.ad.sag>
	<dc30069a-6b61-b37c-497b-cc11f5dcc671@oracle.com>
Message-ID: <B396BF84AB575D46A32CF8A460F1030638C708@HQMBX4.eur.ad.sag>

I agree with you. After following your highlighting of those pieces of 15.12.2.1, I can see why the examples I gave do not compile.

However, there seems to be a conflict between 15.12.2.1 and 15.27.3.

In 15.27.3, it says that a "lambda expression is compatible in an ... invocation context ... with a target type T if T is a functional interface type and the expression is congruent ..." with T, in the case under discussion.

The definition of congruent specifies that where the function type's result is non-void, that the lambda must return a type compatible with the function type's result.

Additionally, it feels inconsistent / unintuitive that "(String s) -> s.trim()" is fine, but "s -> s.trim()" is not.

            Chris.


From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
Sent: 16 August 2016 13:49
To: Greenaway, Chris; compiler-dev at openjdk.java.net
Subject: Re: Lambda return types and overloaded methods




On 16/08/16 13:38, Greenaway, Chris wrote:
That doesn't seem to fit with the discussion on this JDK bug: https://bugs.openjdk.java.net/browse/JDK-8029718 which has been fixed. In particular, there's a link to a discussion on this mailing list ( http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011394.html ) where various members express the opinion that the compiler should consider more than just arity.
The bug (and the discussion) you refer to consider the case of value vs. void compatible lambda. I.e. if a lambda does not return, that information is enough to rule out a functional interface with non-void return type.
In your case the lambda is returning something, and both functional interfaces also return something. So that doesn't apply.


An important consideration seems to be 15.27.3 of the JLS. Paraphrasing, it says that a lambda with implicitly typed parameters is only compatible with a functional interface if the lambda body results in a value compatible with the functional interface's result type. The definition of potentially compatible in 15.12.2.1 specifically references this.
I don't see references from 15.12.2.1 to 15.27.3. I see however references to 15.27.2 - when the potentially compatible definition takes into account as whether the lambda is void- or value- compatible.

Maurizio


            Chris.



From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
Sent: 16 August 2016 11:18
To: Greenaway, Chris; compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>
Subject: Re: Lambda return types and overloaded methods


Hi Chris,

what you are observing is by design - to keep things tractable, we deliberately decided to keep overload resolution a function of the argument expressions, and to only look at the return types after inference. In fact, javac won't even look at the body of a lambda, or a method reference or conditionals if such expressions are considered _not_ pertinent to applicability (see JLS section 15.12.2.2 for a formal definition). In short, an argument expression is pertinent to applicability unless it is an implicit lambda (a lambda w/o explicit parameter types) or an inexact method reference (a method reference matching multiple overloads) - or a conditional whose either sub-expression is one of those.

So, when you have argument expressions that are not pertinent to applicability, your only hope against ambiguity error is the loose applicability check described in JLS 15.12.2.1 - potential compatibility. This is a much looser check which simply validates that the lambda (or method reference) has an arity that is compatible with that of the target functional interface (for method reference we also look at void vs. value compatibility).

Sp, all your implicit lambda cases are ambiguous, because your targets are Predicate<String> and Function<String, String> - i.e. both are functional types accepting a String (arity 1). Given we are not allowed to look at the lambda body at this stage (the lambda is not pertinent to applicability), we have to give up.

In the case of the method references, you have that both String::isEmpty and String::trim are _exact_ method references - they are unambiguous, so the return types of such methods can indeed be used to disambiguate. The same cannot be said for String::toUpperCase which has two matches - so both Predicate<String> and Function<String, String> are potentially compatible with String::toUpperCase (given that one of the overloads for String::toUpperCase matches the arity of the function types) - but the method reference expression is then discarded from further checking because it is an inexact method reference, so the return type cannot be looked at.

If this behavior seems too strict, please keep in mind that these rules have been discussed extensively at the various lambda EG meetings; at some point we had a more powerful overload resolution algorithm - but there was an unanimous consensus to back out from it because its behavior was very hard to explain to users (the compiler would speculatively check a lambda body against each overloaded method, and discard those not compatible - this leads to a combinatorial explosion of checks in nested cases - and is generally an hard-to-follow process for a non-stack based human ;-)).

I concede that, in these particular cases, the behavior of pertinent to applicability/potential compatibility is a little phony - in the case of lambda, all overloads accept a functional interface which dictate a String parameter - so, there seems to be no ambiguity as to how the lambda body should be interpreted. A similar consideration holds for the method reference case where, after all, both overloaded toUpperCase methods return String, so why not using that information to prune the space of applicable methods (since Predicate<String> clearly does not return a String) ? While these might all be good incremental improvements over what we have, I must stress that this is not the language we have today.

Cheers
Maurizio

(*) this is not totally correct - in fact return types are also used for disambuguation when multiple methods are applicable - but for that to apply the lambda/method reference must be pertinent to applicability - i.e. an explicit lambda, or an exact method reference.

On 16/08/16 10:21, Greenaway, Chris wrote:
There seems to be a problem with matching the return type of a lambda to the type required by an overloaded method when the lambda parameter isn't explicitly typed.

For example, the code below has compilation failures on the lines that are marked with "// Error". All other lines are acceptable.

There also seems to be an issue with method references when there are multiple methods with the same name but different arity - see the line marked "// Error 8".

            Chris Greenaway.


import java.util.function.Function;
import java.util.function.Predicate;

public class LambdaOverloading {
    public static void main(String[] args) {
        LambdaPredicate predicate = new LambdaPredicate();
        predicate.run((String s) -> s.startsWith("X"));
        predicate.run((String s) -> s.isEmpty());
        predicate.run((String s) -> true);
        predicate.run(s -> s.startsWith("X"));
        predicate.run(s -> s.isEmpty());
        predicate.run(s -> true);
        predicate.run(String::isEmpty);

        LambdaFunction function = new LambdaFunction();
        function.run((String s) -> s.substring(1));
        function.run((String s) -> s.trim());
        function.run((String s) -> s.toUpperCase());
        function.run((String s) -> "");
        function.run(s -> s.substring(1));
        function.run(s -> s.trim());
        function.run(s -> s.toUpperCase());
        function.run(s -> "");
        function.run(String::trim);
        function.run(String::toUpperCase);

        LambdaOverloaded overloaded = new LambdaOverloaded();
        overloaded.run((String s) -> s.startsWith("X"));
        overloaded.run((String s) -> s.substring(1));
        overloaded.run((String s) -> s.isEmpty());
        overloaded.run((String s) -> s.trim());
        overloaded.run((String s) -> s.toUpperCase());
        overloaded.run((String s) -> true);
        overloaded.run((String s) -> "");
        overloaded.run(s -> s.startsWith("X"));                     // Error 1
        overloaded.run(s -> s.substring(1));                        // Error 2
        overloaded.run(s -> s.isEmpty());                           // Error 3
        overloaded.run(s -> s.trim());                              // Error 4
        overloaded.run(s -> s.toUpperCase());                       // Error 5
        overloaded.run(s -> true);                                  // Error 6
        overloaded.run(s -> "");                                    // Error 7
        overloaded.run(String::isEmpty);
        overloaded.run(String::trim);
        overloaded.run(String::toUpperCase);                        // Error 8
    }

    private static class LambdaPredicate {
        public boolean run(Predicate<String> predicate) {
            return predicate.test("test");
        }
    }

    private static class LambdaFunction {
        public String run(Function<String, String> function) {
            return function.apply("test");
        }
    }

    private static class LambdaOverloaded {
        public boolean run(Predicate<String> predicate) {
            return predicate.test("test");
        }

        public String run(Function<String, String> function) {
            return function.apply("test");
        }
    }
}
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk


This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk


This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160816/5d4d6544/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Tue Aug 16 16:41:59 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 Aug 2016 17:41:59 +0100
Subject: Lambda return types and overloaded methods
In-Reply-To: <B396BF84AB575D46A32CF8A460F1030638C708@HQMBX4.eur.ad.sag>
References: <B396BF84AB575D46A32CF8A460F1030638C625@HQMBX4.eur.ad.sag>
	<a5fae9ef-6433-7e21-507b-319aa9525157@oracle.com>
	<B396BF84AB575D46A32CF8A460F1030638C682@HQMBX4.eur.ad.sag>
	<dc30069a-6b61-b37c-497b-cc11f5dcc671@oracle.com>
	<B396BF84AB575D46A32CF8A460F1030638C708@HQMBX4.eur.ad.sag>
Message-ID: <5a759c1b-7950-9447-3bff-ec028fe9055a@oracle.com>



On 16/08/16 14:58, Greenaway, Chris wrote:
>
> I agree with you. After following your highlighting of those pieces of 
> 15.12.2.1, I can see why the examples I gave do not compile.
>
> However, there seems to be a conflict between 15.12.2.1 and 15.27.3.
>
> In 15.27.3, it says that a ?lambda expression is compatible in an ? 
> invocation context ? with a target type T if T is a functional 
> interface type and the expression is congruent ?? with T, in the case 
> under discussion.
>
I think (the spec gurus will correct me if I'm wrong) that 15.27.3 only 
happens when you look inside the body of a lambda (*). Whether you are 
allowed or not to look inside the body is dictated by 15.12.2.1.

(*) is not even that simple, as 15.27.3 is used only when the target 
type of a lambda is 'ground' i.e. w/o inference variables - if it has 
inference variables slight variation of 15.27.3 is used, namely 18.2.1.

Maurizio
>
> The definition of congruent specifies that where the function type?s 
> result is non-void, that the lambda must return a type compatible with 
> the function type?s result.
>
> Additionally, it feels inconsistent / unintuitive that ?(String s) -> 
> s.trim()? is fine, but ?s -> s.trim()? is not.
>
> Chris.
>
> *From:*Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> *Sent:* 16 August 2016 13:49
> *To:* Greenaway, Chris; compiler-dev at openjdk.java.net
> *Subject:* Re: Lambda return types and overloaded methods
>
> On 16/08/16 13:38, Greenaway, Chris wrote:
>
>     That doesn?t seem to fit with the discussion on this JDK bug:
>     https://bugs.openjdk.java.net/browse/JDK-8029718 which has been
>     fixed. In particular, there?s a link to a discussion on this
>     mailing list (
>     http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011394.html
>     ) where various members express the opinion that the compiler
>     should consider more than just arity.
>
> The bug (and the discussion) you refer to consider the case of value 
> vs. void compatible lambda. I.e. if a lambda does not return, that 
> information is enough to rule out a functional interface with non-void 
> return type.
> In your case the lambda is returning something, and both functional 
> interfaces also return something. So that doesn't apply.
>
> An important consideration seems to be 15.27.3 of the JLS. 
> Paraphrasing, it says that a lambda with implicitly typed parameters 
> is only compatible with a functional interface if the lambda body 
> results in a value compatible with the functional interface?s result 
> type. The definition of potentially compatible in 15.12.2.1 
> specifically references this.
>
> I don't see references from 15.12.2.1 to 15.27.3. I see however 
> references to 15.27.2 - when the potentially compatible definition 
> takes into account as whether the lambda is void- or value- compatible.
>
> Maurizio
>
> Chris.
>
> *From:*Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> *Sent:* 16 August 2016 11:18
> *To:* Greenaway, Chris; compiler-dev at openjdk.java.net 
> <mailto:compiler-dev at openjdk.java.net>
> *Subject:* Re: Lambda return types and overloaded methods
>
> Hi Chris,
>
> what you are observing is by design - to keep things tractable, we 
> deliberately decided to keep overload resolution a function of the 
> argument expressions, and to only look at the return types after 
> inference. In fact, javac won't even look at the body of a lambda, or 
> a method reference or conditionals if such expressions are considered 
> _not_ pertinent to applicability (see JLS section 15.12.2.2 for a 
> formal definition). In short, an argument expression is pertinent to 
> applicability unless it is an implicit lambda (a lambda w/o explicit 
> parameter types) or an inexact method reference (a method reference 
> matching multiple overloads) - or a conditional whose either 
> sub-expression is one of those.
>
> So, when you have argument expressions that are not pertinent to 
> applicability, your only hope against ambiguity error is the loose 
> applicability check described in JLS 15.12.2.1 - potential 
> compatibility. This is a much looser check which simply validates that 
> the lambda (or method reference) has an arity that is compatible with 
> that of the target functional interface (for method reference we also 
> look at void vs. value compatibility).
>
> Sp, all your implicit lambda cases are ambiguous, because your targets 
> are Predicate<String> and Function<String, String> - i.e. both are 
> functional types accepting a String (arity 1). Given we are not 
> allowed to look at the lambda body at this stage (the lambda is not 
> pertinent to applicability), we have to give up.
>
> In the case of the method references, you have that both 
> String::isEmpty and String::trim are _exact_ method references - they 
> are unambiguous, so the return types of such methods can indeed be 
> used to disambiguate. The same cannot be said for String::toUpperCase 
> which has two matches - so both Predicate<String> and Function<String, 
> String> are potentially compatible with String::toUpperCase (given 
> that one of the overloads for String::toUpperCase matches the arity of 
> the function types) - but the method reference expression is then 
> discarded from further checking because it is an inexact method 
> reference, so the return type cannot be looked at.
>
> If this behavior seems too strict, please keep in mind that these 
> rules have been discussed extensively at the various lambda EG 
> meetings; at some point we had a more powerful overload resolution 
> algorithm - but there was an unanimous consensus to back out from it 
> because its behavior was very hard to explain to users (the compiler 
> would speculatively check a lambda body against each overloaded 
> method, and discard those not compatible - this leads to a 
> combinatorial explosion of checks in nested cases - and is generally 
> an hard-to-follow process for a non-stack based human ;-)).
>
> I concede that, in these particular cases, the behavior of pertinent 
> to applicability/potential compatibility is a little phony - in the 
> case of lambda, all overloads accept a functional interface which 
> dictate a String parameter - so, there seems to be no ambiguity as to 
> how the lambda body should be interpreted. A similar consideration 
> holds for the method reference case where, after all, both overloaded 
> toUpperCase methods return String, so why not using that information 
> to prune the space of applicable methods (since Predicate<String> 
> clearly does not return a String) ? While these might all be good 
> incremental improvements over what we have, I must stress that this is 
> not the language we have today.
>
> Cheers
> Maurizio
>
> (*) this is not totally correct - in fact return types are also used 
> for disambuguation when multiple methods are applicable - but for that 
> to apply the lambda/method reference must be pertinent to 
> applicability - i.e. an explicit lambda, or an exact method reference.
>
> On 16/08/16 10:21, Greenaway, Chris wrote:
>
>     There seems to be a problem with matching the return type of a
>     lambda to the type required by an overloaded method when the
>     lambda parameter isn't explicitly typed.
>
>     For example, the code below has compilation failures on the lines
>     that are marked with "// Error". All other lines are acceptable.
>
>     There also seems to be an issue with method references when there
>     are multiple methods with the same name but different arity - see
>     the line marked "// Error 8".
>
>                 Chris Greenaway.
>
>     import java.util.function.Function;
>
>     import java.util.function.Predicate;
>
>     public class LambdaOverloading {
>
>         public static void main(String[] args) {
>
>             LambdaPredicate predicate = new LambdaPredicate();
>
>             predicate.run((String s) -> s.startsWith("X"));
>
>             predicate.run((String s) -> s.isEmpty());
>
>             predicate.run((String s) -> true);
>
>             predicate.run(s -> s.startsWith("X"));
>
>             predicate.run(s -> s.isEmpty());
>
>             predicate.run(s -> true);
>
>             predicate.run(String::isEmpty);
>
>             LambdaFunction function = new LambdaFunction();
>
>             function.run((String s) -> s.substring(1));
>
>             function.run((String s) -> s.trim());
>
>             function.run((String s) -> s.toUpperCase());
>
>             function.run((String s) -> "");
>
>             function.run(s -> s.substring(1));
>
>             function.run(s -> s.trim());
>
>             function.run(s -> s.toUpperCase());
>
>             function.run(s -> "");
>
>             function.run(String::trim);
>
>             function.run(String::toUpperCase);
>
>             LambdaOverloaded overloaded = new LambdaOverloaded();
>
>             overloaded.run((String s) -> s.startsWith("X"));
>
>             overloaded.run((String s) -> s.substring(1));
>
>             overloaded.run((String s) -> s.isEmpty());
>
>             overloaded.run((String s) -> s.trim());
>
>             overloaded.run((String s) -> s.toUpperCase());
>
>             overloaded.run((String s) -> true);
>
>             overloaded.run((String s) -> "");
>
>             overloaded.run(s ->
>     s.startsWith("X"));                     // Error 1
>
>             overloaded.run(s ->
>     s.substring(1));                        // Error 2
>
>             overloaded.run(s ->
>     s.isEmpty());                           // Error 3
>
>             overloaded.run(s ->
>     s.trim());                              // Error 4
>
>             overloaded.run(s ->
>     s.toUpperCase());                       // Error 5
>
>             overloaded.run(s ->
>     true);                                  // Error 6
>
>             overloaded.run(s ->
>     "");                                    // Error 7
>
>             overloaded.run(String::isEmpty);
>
>             overloaded.run(String::trim);
>
>     overloaded.run(String::toUpperCase); // Error 8
>
>         }
>
>         private static class LambdaPredicate {
>
>             public boolean run(Predicate<String> predicate) {
>
>                 return predicate.test("test");
>
>             }
>
>         }
>
>         private static class LambdaFunction {
>
>             public String run(Function<String, String> function) {
>
>                 return function.apply("test");
>
>             }
>
>         }
>
>         private static class LambdaOverloaded {
>
>             public boolean run(Predicate<String> predicate) {
>
>                 return predicate.test("test");
>
>             }
>
>             public String run(Function<String, String> function) {
>
>                 return function.apply("test");
>
>             }
>
>         }
>
>     }
>
>     This communication contains information which is confidential and
>     may also be privileged. It is for the exclusive use of the
>     intended recipient(s). If you are not the intended recipient(s),
>     please note that any distribution, copying, or use of this
>     communication or the information in it, is strictly prohibited. If
>     you have received this communication in error please notify us by
>     e-mail and then delete the e-mail and any copies of it.
>
>     Software AG (UK) Limited Registered in England & Wales 1310740 -
>     */http://www.softwareag.com/uk/*//
>
> This communication contains information which is confidential and may 
> also be privileged. It is for the exclusive use of the intended 
> recipient(s). If you are not the intended recipient(s), please note 
> that any distribution, copying, or use of this communication or the 
> information in it, is strictly prohibited. If you have received this 
> communication in error please notify us by e-mail and then delete the 
> e-mail and any copies of it.
>
> Software AG (UK) Limited Registered in England & Wales 1310740 - 
> */http://www.softwareag.com/uk/*//
>
> This communication contains information which is confidential and may 
> also be privileged. It is for the exclusive use of the intended 
> recipient(s). If you are not the intended recipient(s), please note 
> that any distribution, copying, or use of this communication or the 
> information in it, is strictly prohibited. If you have received this 
> communication in error please notify us by e-mail and then delete the 
> e-mail and any copies of it.
> Software AG (UK) Limited Registered in England & Wales 1310740 - 
> /*http://www.softwareag.com/uk* /
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160816/3857ee18/attachment-0001.html>

From sandeep.konchady at oracle.com  Fri Aug 12 22:55:23 2016
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Fri, 12 Aug 2016 15:55:23 -0700
Subject: RFR: JDK-8163991: Fix license and copyright headers under
	test/jdk/javadoc/ and test/tools/javac/
Message-ID: <F4C0009F-D501-4CEA-A45E-267B9EBBDB03@oracle.com>

Hello,

Please review the patch below which fixes copyright in test files for javadoc and javac

Bug: https://bugs.openjdk.java.net/browse/JDK-8163991
Webrev: http://cr.openjdk.java.net/~shurailine/8163991/webrev.00/langtools.patch

Thanks,
Sandeep

From jonathan.gibbons at oracle.com  Thu Aug 18 20:57:12 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 18 Aug 2016 13:57:12 -0700
Subject: RFR: JDK-8163991: Fix license and copyright headers under
	test/jdk/javadoc/ and test/tools/javac/
In-Reply-To: <F4C0009F-D501-4CEA-A45E-267B9EBBDB03@oracle.com>
References: <F4C0009F-D501-4CEA-A45E-267B9EBBDB03@oracle.com>
Message-ID: <57B62128.3000402@oracle.com>

Looks OK to me.

-- Jon

On 08/12/2016 03:55 PM, Sandeep Konchady wrote:
> Hello,
>
> Please review the patch below which fixes copyright in test files for javadoc and javac
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163991
> Webrev: http://cr.openjdk.java.net/~shurailine/8163991/webrev.00/langtools.patch
>
> Thanks,
> Sandeep


From iris.clark at oracle.com  Thu Aug 18 21:16:35 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 18 Aug 2016 14:16:35 -0700 (PDT)
Subject: RFR: JDK-8163991: Fix license and copyright headers under
	test/jdk/javadoc/ and test/tools/javac/
In-Reply-To: <F4C0009F-D501-4CEA-A45E-267B9EBBDB03@oracle.com>
References: <F4C0009F-D501-4CEA-A45E-267B9EBBDB03@oracle.com>
Message-ID: <dcc560c9-c8f5-4cc7-b4a4-ce969aea3a11@default>

Hi, Sandeep.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8163991
> Webrev: http://cr.openjdk.java.net/~shurailine/8163991/webrev.00/langtools.patch

These changes all look reasonable to me.

Thanks,
Iris

From jan.lahoda at oracle.com  Mon Aug 22 12:42:46 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 22 Aug 2016 14:42:46 +0200
Subject: RFR 8164550: tools/javac/modules/InheritRuntimeEnvironmentTest.java
	fails on Windows after JDK-8153391
Message-ID: <57BAF346.3040909@oracle.com>

Hi,

The fix for JDK-8153391 broke the 
tools/javac/modules/InheritRuntimeEnvironmentTest.java on Windows. I 
think that is because the test was changed to use:
-classpath ""
and that this is not working well on Windows. I propose to use classpath 
consisting on a single empty directory, see the webrev.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8164550
Webrev:
http://cr.openjdk.java.net/~jlahoda/8164550/webrev.00/

Does this look sensible?

Thanks,
     Jan

From maurizio.cimadamore at oracle.com  Mon Aug 22 13:14:04 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 22 Aug 2016 14:14:04 +0100
Subject: RFR 8164550:
	tools/javac/modules/InheritRuntimeEnvironmentTest.java fails on Windows
	after JDK-8153391
In-Reply-To: <57BAF346.3040909@oracle.com>
References: <57BAF346.3040909@oracle.com>
Message-ID: <8bf97622-58ad-2e66-1bc6-5192ebee3bba@oracle.com>

Looks good.

Maurizio


On 22/08/16 13:42, Jan Lahoda wrote:
> Hi,
>
> The fix for JDK-8153391 broke the 
> tools/javac/modules/InheritRuntimeEnvironmentTest.java on Windows. I 
> think that is because the test was changed to use:
> -classpath ""
> and that this is not working well on Windows. I propose to use 
> classpath consisting on a single empty directory, see the webrev.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8164550
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8164550/webrev.00/
>
> Does this look sensible?
>
> Thanks,
>     Jan


From jan.lahoda at oracle.com  Mon Aug 22 13:19:21 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 22 Aug 2016 15:19:21 +0200
Subject: RFR 8164550:
	tools/javac/modules/InheritRuntimeEnvironmentTest.java fails on Windows
	after JDK-8153391
In-Reply-To: <8bf97622-58ad-2e66-1bc6-5192ebee3bba@oracle.com>
References: <57BAF346.3040909@oracle.com>
	<8bf97622-58ad-2e66-1bc6-5192ebee3bba@oracle.com>
Message-ID: <57BAFBD9.2010100@oracle.com>

Pushed. Thanks for quick review!

Jan

On 22.8.2016 15:14, Maurizio Cimadamore wrote:
> Looks good.
>
> Maurizio
>
>
> On 22/08/16 13:42, Jan Lahoda wrote:
>> Hi,
>>
>> The fix for JDK-8153391 broke the
>> tools/javac/modules/InheritRuntimeEnvironmentTest.java on Windows. I
>> think that is because the test was changed to use:
>> -classpath ""
>> and that this is not working well on Windows. I propose to use
>> classpath consisting on a single empty directory, see the webrev.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8164550
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8164550/webrev.00/
>>
>> Does this look sensible?
>>
>> Thanks,
>>     Jan
>

From jan.lahoda at oracle.com  Fri Aug 26 12:00:24 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 26 Aug 2016 14:00:24 +0200
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
Message-ID: <57C02F58.7080307@oracle.com>

Hi,

The RunCodingRules test is broken after 871b60b0c091, and has been 
disabled. My proposal to fix this is to disable the DefinedByAnalyzer 
for classes from the jdk.jdeps module. This module is not AFAIK 
implementing the APIs, and so is not a primary target of the 
analyzer/@DefinedBy annotation. One notable alternative would be to 
disable the crules completely for jdk.jdeps, but I opted rather for a 
more limited change. (Another alternative would be to add the @DefinedBy 
annotations to classes jdk.jdeps, but that does not seem quite right to me.)

Bug:
https://bugs.openjdk.java.net/browse/JDK-8164836
Webrev:
http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/

Jan

From stuart.marks at oracle.com  Fri Aug 26 15:36:04 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 26 Aug 2016 08:36:04 -0700
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
In-Reply-To: <57C02F58.7080307@oracle.com>
References: <57C02F58.7080307@oracle.com>
Message-ID: <eab56566-d297-c1eb-d64c-bf3f9e285c94@oracle.com>

Hi Jan,

Thanks for picking this up.

As you point out, the API usage in jdeprscan, and its containing module 
jdk.jdeps, really isn't the target of @DefinedBy. It's "implementing" the APIs, 
but for the purpose of getting callbacks from the annotation processing 
framework, not for the purpose of providing an implementation of the API to the 
general public. In that sense @DefinedBy doesn't really apply, so it makes sense 
to adjust the DefinedByAnalyzer to be more specific in what it's checking.

But does special-casing jdk.jdeps make sense? Or should there be some kind of 
finer-grained logic to determine when @DefinedBy should and shouldn't apply? I 
wouldn't be surprised if there are other usages of @DefinedBy outside of 
jdk.jdeps that are in a similar situation. See jdk.jshell for instance.

I've prepared a patch -- not yet posted anywhere -- that simply adds the right 
@DefinedBy annotations in jdeprscan. This is simple enough to do, even though it 
might not be the right thing.



s'marks




On 8/26/16 5:00 AM, Jan Lahoda wrote:
> Hi,
>
> The RunCodingRules test is broken after 871b60b0c091, and has been disabled. My
> proposal to fix this is to disable the DefinedByAnalyzer for classes from the
> jdk.jdeps module. This module is not AFAIK implementing the APIs, and so is not
> a primary target of the analyzer/@DefinedBy annotation. One notable alternative
> would be to disable the crules completely for jdk.jdeps, but I opted rather for
> a more limited change. (Another alternative would be to add the @DefinedBy
> annotations to classes jdk.jdeps, but that does not seem quite right to me.)
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8164836
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>
> Jan

From jonathan.gibbons at oracle.com  Fri Aug 26 19:02:46 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 26 Aug 2016 12:02:46 -0700
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
In-Reply-To: <eab56566-d297-c1eb-d64c-bf3f9e285c94@oracle.com>
References: <57C02F58.7080307@oracle.com>
	<eab56566-d297-c1eb-d64c-bf3f9e285c94@oracle.com>
Message-ID: <57C09256.8000401@oracle.com>

Arguably, we should only check @DefinedBy in java.compiler and 
jdk.compiler modules.

-- Jon

On 08/26/2016 08:36 AM, Stuart Marks wrote:
> Hi Jan,
>
> Thanks for picking this up.
>
> As you point out, the API usage in jdeprscan, and its containing 
> module jdk.jdeps, really isn't the target of @DefinedBy. It's 
> "implementing" the APIs, but for the purpose of getting callbacks from 
> the annotation processing framework, not for the purpose of providing 
> an implementation of the API to the general public. In that sense 
> @DefinedBy doesn't really apply, so it makes sense to adjust the 
> DefinedByAnalyzer to be more specific in what it's checking.
>
> But does special-casing jdk.jdeps make sense? Or should there be some 
> kind of finer-grained logic to determine when @DefinedBy should and 
> shouldn't apply? I wouldn't be surprised if there are other usages of 
> @DefinedBy outside of jdk.jdeps that are in a similar situation. See 
> jdk.jshell for instance.
>
> I've prepared a patch -- not yet posted anywhere -- that simply adds 
> the right @DefinedBy annotations in jdeprscan. This is simple enough 
> to do, even though it might not be the right thing.
>
>
>
> s'marks
>
>
>
>
> On 8/26/16 5:00 AM, Jan Lahoda wrote:
>> Hi,
>>
>> The RunCodingRules test is broken after 871b60b0c091, and has been 
>> disabled. My
>> proposal to fix this is to disable the DefinedByAnalyzer for classes 
>> from the
>> jdk.jdeps module. This module is not AFAIK implementing the APIs, and 
>> so is not
>> a primary target of the analyzer/@DefinedBy annotation. One notable 
>> alternative
>> would be to disable the crules completely for jdk.jdeps, but I opted 
>> rather for
>> a more limited change. (Another alternative would be to add the 
>> @DefinedBy
>> annotations to classes jdk.jdeps, but that does not seem quite right 
>> to me.)
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8164836
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>>
>> Jan


From stuart.marks at oracle.com  Fri Aug 26 19:52:25 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 26 Aug 2016 12:52:25 -0700
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
In-Reply-To: <57C09256.8000401@oracle.com>
References: <57C02F58.7080307@oracle.com>
	<eab56566-d297-c1eb-d64c-bf3f9e285c94@oracle.com>
	<57C09256.8000401@oracle.com>
Message-ID: <394d6c1f-c618-73c4-1391-35b280edb52a@oracle.com>

Seems sensible to me, though I'm distant enough from this that I'll let you guys 
work out the exact rules.

If the scope of DefinedByAnalzyer gets reduced, then maybe the uses of 
@DefinedBy outside of that scope should be removed.

s'marks

On 8/26/16 12:02 PM, Jonathan Gibbons wrote:
> Arguably, we should only check @DefinedBy in java.compiler and jdk.compiler
> modules.
>
> -- Jon
>
> On 08/26/2016 08:36 AM, Stuart Marks wrote:
>> Hi Jan,
>>
>> Thanks for picking this up.
>>
>> As you point out, the API usage in jdeprscan, and its containing module
>> jdk.jdeps, really isn't the target of @DefinedBy. It's "implementing" the
>> APIs, but for the purpose of getting callbacks from the annotation processing
>> framework, not for the purpose of providing an implementation of the API to
>> the general public. In that sense @DefinedBy doesn't really apply, so it makes
>> sense to adjust the DefinedByAnalyzer to be more specific in what it's checking.
>>
>> But does special-casing jdk.jdeps make sense? Or should there be some kind of
>> finer-grained logic to determine when @DefinedBy should and shouldn't apply? I
>> wouldn't be surprised if there are other usages of @DefinedBy outside of
>> jdk.jdeps that are in a similar situation. See jdk.jshell for instance.
>>
>> I've prepared a patch -- not yet posted anywhere -- that simply adds the right
>> @DefinedBy annotations in jdeprscan. This is simple enough to do, even though
>> it might not be the right thing.
>>
>>
>>
>> s'marks
>>
>>
>>
>>
>> On 8/26/16 5:00 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> The RunCodingRules test is broken after 871b60b0c091, and has been disabled. My
>>> proposal to fix this is to disable the DefinedByAnalyzer for classes from the
>>> jdk.jdeps module. This module is not AFAIK implementing the APIs, and so is not
>>> a primary target of the analyzer/@DefinedBy annotation. One notable alternative
>>> would be to disable the crules completely for jdk.jdeps, but I opted rather for
>>> a more limited change. (Another alternative would be to add the @DefinedBy
>>> annotations to classes jdk.jdeps, but that does not seem quite right to me.)
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8164836
>>> Webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>>>
>>> Jan
>

From kumar.x.srinivasan at oracle.com  Fri Aug 26 19:53:09 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 26 Aug 2016 12:53:09 -0700
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
In-Reply-To: <57C02F58.7080307@oracle.com>
References: <57C02F58.7080307@oracle.com>
Message-ID: <57C09E25.5040903@oracle.com>

Hi Jan,

We should also excluded jdk.javadoc from this check, I don't see the
value of the @DefinedBy for this.

Thanks
Kumar

On 8/26/2016 5:00 AM, Jan Lahoda wrote:
> Hi,
>
> The RunCodingRules test is broken after 871b60b0c091, and has been 
> disabled. My proposal to fix this is to disable the DefinedByAnalyzer 
> for classes from the jdk.jdeps module. This module is not AFAIK 
> implementing the APIs, and so is not a primary target of the 
> analyzer/@DefinedBy annotation. One notable alternative would be to 
> disable the crules completely for jdk.jdeps, but I opted rather for a 
> more limited change. (Another alternative would be to add the 
> @DefinedBy annotations to classes jdk.jdeps, but that does not seem 
> quite right to me.)
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8164836
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>
> Jan


From jonathan.gibbons at oracle.com  Fri Aug 26 22:26:12 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 26 Aug 2016 15:26:12 -0700
Subject: RFR: 8164887: update tests to remove use of old-style options
Message-ID: <57C0C204.5010102@oracle.com>

Please review this simple changeset to update some remaining uses of the 
old forms of some of the new module options, before we remove support 
for those old forms.

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

From mandy.chung at oracle.com  Fri Aug 26 22:37:07 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 Aug 2016 15:37:07 -0700
Subject: RFR: 8164887: update tests to remove use of old-style options
In-Reply-To: <57C0C204.5010102@oracle.com>
References: <57C0C204.5010102@oracle.com>
Message-ID: <EF0FEF9A-B04D-409B-9B62-A272FF35198D@oracle.com>


> On Aug 26, 2016, at 3:26 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review this simple changeset to update some remaining uses of the old forms of some of the new module options, before we remove support for those old forms.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8164887
> Webrev: http://cr.openjdk.java.net/~jjg/8164887/webrev.00

Looks good.

Mandy

From stuart.marks at oracle.com  Fri Aug 26 23:45:13 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 26 Aug 2016 16:45:13 -0700
Subject: RFR(xs): 8164837 fix jdeprscan TestLoad and TestScan failures on
	Windows
Message-ID: <5b5d0793-6ccb-ca95-561b-3ee0e879eaad@oracle.com>

Hi all,

Please review this small fix for a couple jdeprscan tests and to remove them 
from the problem list. Basically the problem was using '/' instead of 
File.separatorChar.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8164837

Webrev:

     http://cr.openjdk.java.net/~smarks/reviews/8164837/webrev.0/

Thanks,

s'marks

From joe.darcy at oracle.com  Fri Aug 26 23:59:28 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 26 Aug 2016 16:59:28 -0700
Subject: RFR(xs): 8164837 fix jdeprscan TestLoad and TestScan failures on
	Windows
In-Reply-To: <5b5d0793-6ccb-ca95-561b-3ee0e879eaad@oracle.com>
References: <5b5d0793-6ccb-ca95-561b-3ee0e879eaad@oracle.com>
Message-ID: <d1ca03cb-036f-02d8-8886-224cf94d28c6@oracle.com>

Looks good Stuart; thanks,

-Joe


On 8/26/2016 4:45 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this small fix for a couple jdeprscan tests and to 
> remove them from the problem list. Basically the problem was using '/' 
> instead of File.separatorChar.
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8164837
>
> Webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8164837/webrev.0/
>
> Thanks,
>
> s'marks


From stuart.marks at oracle.com  Sat Aug 27 00:13:31 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 26 Aug 2016 17:13:31 -0700
Subject: RFR(xs): 8164837 fix jdeprscan TestLoad and TestScan failures on
	Windows
In-Reply-To: <d1ca03cb-036f-02d8-8886-224cf94d28c6@oracle.com>
References: <5b5d0793-6ccb-ca95-561b-3ee0e879eaad@oracle.com>
	<d1ca03cb-036f-02d8-8886-224cf94d28c6@oracle.com>
Message-ID: <a7e1996b-fc00-97cd-1f3e-b5c364295ae7@oracle.com>

Thanks for reviewing, Joe.

I think I'll wait until Monday morning to push this one. :-)

s'marks

On 8/26/16 4:59 PM, joe darcy wrote:
> Looks good Stuart; thanks,
>
> -Joe
>
>
> On 8/26/2016 4:45 PM, Stuart Marks wrote:
>> Hi all,
>>
>> Please review this small fix for a couple jdeprscan tests and to remove them
>> from the problem list. Basically the problem was using '/' instead of
>> File.separatorChar.
>>
>> Bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8164837
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~smarks/reviews/8164837/webrev.0/
>>
>> Thanks,
>>
>> s'marks
>

From jan.lahoda at oracle.com  Sun Aug 28 20:31:12 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 28 Aug 2016 22:31:12 +0200
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
In-Reply-To: <57C09256.8000401@oracle.com>
References: <57C02F58.7080307@oracle.com>
	<eab56566-d297-c1eb-d64c-bf3f9e285c94@oracle.com>
	<57C09256.8000401@oracle.com>
Message-ID: <57C34A10.4080800@oracle.com>

On 26.8.2016 21:02, Jonathan Gibbons wrote:
> Arguably, we should only check @DefinedBy in java.compiler and
> jdk.compiler modules.

Updated version of the patch where the DefinedByAnalyzer only checks the 
java.compiler and jdk.compiler modules, and the @DefinedBy annotation is 
removed from the other modules is here:
http://cr.openjdk.java.net/~jlahoda/8164836/webrev.01/

Jan

>
> -- Jon
>
> On 08/26/2016 08:36 AM, Stuart Marks wrote:
>> Hi Jan,
>>
>> Thanks for picking this up.
>>
>> As you point out, the API usage in jdeprscan, and its containing
>> module jdk.jdeps, really isn't the target of @DefinedBy. It's
>> "implementing" the APIs, but for the purpose of getting callbacks from
>> the annotation processing framework, not for the purpose of providing
>> an implementation of the API to the general public. In that sense
>> @DefinedBy doesn't really apply, so it makes sense to adjust the
>> DefinedByAnalyzer to be more specific in what it's checking.
>>
>> But does special-casing jdk.jdeps make sense? Or should there be some
>> kind of finer-grained logic to determine when @DefinedBy should and
>> shouldn't apply? I wouldn't be surprised if there are other usages of
>> @DefinedBy outside of jdk.jdeps that are in a similar situation. See
>> jdk.jshell for instance.
>>
>> I've prepared a patch -- not yet posted anywhere -- that simply adds
>> the right @DefinedBy annotations in jdeprscan. This is simple enough
>> to do, even though it might not be the right thing.
>>
>>
>>
>> s'marks
>>
>>
>>
>>
>> On 8/26/16 5:00 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> The RunCodingRules test is broken after 871b60b0c091, and has been
>>> disabled. My
>>> proposal to fix this is to disable the DefinedByAnalyzer for classes
>>> from the
>>> jdk.jdeps module. This module is not AFAIK implementing the APIs, and
>>> so is not
>>> a primary target of the analyzer/@DefinedBy annotation. One notable
>>> alternative
>>> would be to disable the crules completely for jdk.jdeps, but I opted
>>> rather for
>>> a more limited change. (Another alternative would be to add the
>>> @DefinedBy
>>> annotations to classes jdk.jdeps, but that does not seem quite right
>>> to me.)
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8164836
>>> Webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>>>
>>> Jan
>

From jonathan.gibbons at oracle.com  Mon Aug 29 15:37:06 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 29 Aug 2016 08:37:06 -0700
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
In-Reply-To: <57C34A10.4080800@oracle.com>
References: <57C02F58.7080307@oracle.com>
	<eab56566-d297-c1eb-d64c-bf3f9e285c94@oracle.com>
	<57C09256.8000401@oracle.com> <57C34A10.4080800@oracle.com>
Message-ID: <57C456A2.9000404@oracle.com>

Looks OK to me.

-- Jon

On 08/28/2016 01:31 PM, Jan Lahoda wrote:
> On 26.8.2016 21:02, Jonathan Gibbons wrote:
>> Arguably, we should only check @DefinedBy in java.compiler and
>> jdk.compiler modules.
>
> Updated version of the patch where the DefinedByAnalyzer only checks 
> the java.compiler and jdk.compiler modules, and the @DefinedBy 
> annotation is removed from the other modules is here:
> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.01/
>
> Jan
>
>>
>> -- Jon
>>
>> On 08/26/2016 08:36 AM, Stuart Marks wrote:
>>> Hi Jan,
>>>
>>> Thanks for picking this up.
>>>
>>> As you point out, the API usage in jdeprscan, and its containing
>>> module jdk.jdeps, really isn't the target of @DefinedBy. It's
>>> "implementing" the APIs, but for the purpose of getting callbacks from
>>> the annotation processing framework, not for the purpose of providing
>>> an implementation of the API to the general public. In that sense
>>> @DefinedBy doesn't really apply, so it makes sense to adjust the
>>> DefinedByAnalyzer to be more specific in what it's checking.
>>>
>>> But does special-casing jdk.jdeps make sense? Or should there be some
>>> kind of finer-grained logic to determine when @DefinedBy should and
>>> shouldn't apply? I wouldn't be surprised if there are other usages of
>>> @DefinedBy outside of jdk.jdeps that are in a similar situation. See
>>> jdk.jshell for instance.
>>>
>>> I've prepared a patch -- not yet posted anywhere -- that simply adds
>>> the right @DefinedBy annotations in jdeprscan. This is simple enough
>>> to do, even though it might not be the right thing.
>>>
>>>
>>>
>>> s'marks
>>>
>>>
>>>
>>>
>>> On 8/26/16 5:00 AM, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> The RunCodingRules test is broken after 871b60b0c091, and has been
>>>> disabled. My
>>>> proposal to fix this is to disable the DefinedByAnalyzer for classes
>>>> from the
>>>> jdk.jdeps module. This module is not AFAIK implementing the APIs, and
>>>> so is not
>>>> a primary target of the analyzer/@DefinedBy annotation. One notable
>>>> alternative
>>>> would be to disable the crules completely for jdk.jdeps, but I opted
>>>> rather for
>>>> a more limited change. (Another alternative would be to add the
>>>> @DefinedBy
>>>> annotations to classes jdk.jdeps, but that does not seem quite right
>>>> to me.)
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8164836
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>>>>
>>>> Jan
>>


From kumar.x.srinivasan at oracle.com  Mon Aug 29 17:35:14 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 29 Aug 2016 10:35:14 -0700
Subject: RFR JDK-8164836: fix jdeprscan violations of
	tools/all/RunCodingRules.java
In-Reply-To: <57C456A2.9000404@oracle.com>
References: <57C02F58.7080307@oracle.com>
	<eab56566-d297-c1eb-d64c-bf3f9e285c94@oracle.com>
	<57C09256.8000401@oracle.com> <57C34A10.4080800@oracle.com>
	<57C456A2.9000404@oracle.com>
Message-ID: <57C47252.7020201@oracle.com>


+1, and thank you so much Jan for taking care of javadoc.

Kumar

> Looks OK to me.
>
> -- Jon
>
> On 08/28/2016 01:31 PM, Jan Lahoda wrote:
>> On 26.8.2016 21:02, Jonathan Gibbons wrote:
>>> Arguably, we should only check @DefinedBy in java.compiler and
>>> jdk.compiler modules.
>>
>> Updated version of the patch where the DefinedByAnalyzer only checks 
>> the java.compiler and jdk.compiler modules, and the @DefinedBy 
>> annotation is removed from the other modules is here:
>> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.01/
>>
>> Jan
>>
>>>
>>> -- Jon
>>>
>>> On 08/26/2016 08:36 AM, Stuart Marks wrote:
>>>> Hi Jan,
>>>>
>>>> Thanks for picking this up.
>>>>
>>>> As you point out, the API usage in jdeprscan, and its containing
>>>> module jdk.jdeps, really isn't the target of @DefinedBy. It's
>>>> "implementing" the APIs, but for the purpose of getting callbacks from
>>>> the annotation processing framework, not for the purpose of providing
>>>> an implementation of the API to the general public. In that sense
>>>> @DefinedBy doesn't really apply, so it makes sense to adjust the
>>>> DefinedByAnalyzer to be more specific in what it's checking.
>>>>
>>>> But does special-casing jdk.jdeps make sense? Or should there be some
>>>> kind of finer-grained logic to determine when @DefinedBy should and
>>>> shouldn't apply? I wouldn't be surprised if there are other usages of
>>>> @DefinedBy outside of jdk.jdeps that are in a similar situation. See
>>>> jdk.jshell for instance.
>>>>
>>>> I've prepared a patch -- not yet posted anywhere -- that simply adds
>>>> the right @DefinedBy annotations in jdeprscan. This is simple enough
>>>> to do, even though it might not be the right thing.
>>>>
>>>>
>>>>
>>>> s'marks
>>>>
>>>>
>>>>
>>>>
>>>> On 8/26/16 5:00 AM, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> The RunCodingRules test is broken after 871b60b0c091, and has been
>>>>> disabled. My
>>>>> proposal to fix this is to disable the DefinedByAnalyzer for classes
>>>>> from the
>>>>> jdk.jdeps module. This module is not AFAIK implementing the APIs, and
>>>>> so is not
>>>>> a primary target of the analyzer/@DefinedBy annotation. One notable
>>>>> alternative
>>>>> would be to disable the crules completely for jdk.jdeps, but I opted
>>>>> rather for
>>>>> a more limited change. (Another alternative would be to add the
>>>>> @DefinedBy
>>>>> annotations to classes jdk.jdeps, but that does not seem quite right
>>>>> to me.)
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8164836
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>>>>>
>>>>> Jan
>>>
>


From mandy.chung at oracle.com  Wed Aug 31 02:41:19 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Aug 2016 19:41:19 -0700
Subject: Review Request: JDK-8165109: langtools/test switches to use new CLI
	options
Message-ID: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>

Some langtools tests are stil using -release and -mp that are removed in [1].

Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/

thanks
Mandy
[1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466

From jonathan.gibbons at oracle.com  Wed Aug 31 02:55:14 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 Aug 2016 19:55:14 -0700
Subject: Review Request: JDK-8165109:  langtools/test switches to use
	new CLI options
In-Reply-To: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
Message-ID: <57C64712.7020405@oracle.com>

Looks good to me.

- Jon

On 08/30/2016 07:41 PM, Mandy Chung wrote:
> Some langtools tests are stil using -release and -mp that are removed in [1].
>
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>
> thanks
> Mandy
> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466


From mandy.chung at oracle.com  Wed Aug 31 03:07:39 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Aug 2016 20:07:39 -0700
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
Message-ID: <5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>

Hi Amy,

Can you file a new JBS issue for CheckExamples.java test?  This probably would need Jon or Jan to help.

thanks
Mandy

> On Aug 30, 2016, at 7:57 PM, Amy Lu <amy.lu at oracle.com> wrote:
> 
> Hi, Mandy
> 
> Thank you for the quick fix!
> 
> I just noticed that this patch does not include the fix for test tools/javac/diags/CheckExamples.java, which starts failing after removal of old module-related options. Will it fix in another bugid?
> 
> Thanks,
> Amy
> 
> On 8/31/16 10:41 AM, Mandy Chung wrote:
>> Some langtools tests are stil using -release and -mp that are removed in [1].
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>> 
>> thanks
>> Mandy
>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466
> 


From amy.lu at oracle.com  Wed Aug 31 02:57:28 2016
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 31 Aug 2016 10:57:28 +0800
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
Message-ID: <1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>

Hi, Mandy

Thank you for the quick fix!

I just noticed that this patch does not include the fix for test 
tools/javac/diags/CheckExamples.java, which starts failing after removal 
of old module-related options. Will it fix in another bugid?

Thanks,
Amy

On 8/31/16 10:41 AM, Mandy Chung wrote:
> Some langtools tests are stil using -release and -mp that are removed in [1].
>
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>
> thanks
> Mandy
> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466


From amy.lu at oracle.com  Wed Aug 31 03:12:04 2016
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 31 Aug 2016 11:12:04 +0800
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
	<5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
Message-ID: <b34b8369-f78f-8639-27f0-3fff12a76ba8@oracle.com>


On 8/31/16 11:07 AM, Mandy Chung wrote:
> Hi Amy,
>
> Can you file a new JBS issue for CheckExamples.java test?  This probably would need Jon or Jan to help.
Sure !

/Amy

From jonathan.gibbons at oracle.com  Wed Aug 31 03:30:11 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 Aug 2016 20:30:11 -0700
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
	<5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
Message-ID: <57C64F43.3010501@oracle.com>

Fix is in the comments in the new bug.

-- Jon

On 08/30/2016 08:07 PM, Mandy Chung wrote:
> Hi Amy,
>
> Can you file a new JBS issue for CheckExamples.java test?  This probably would need Jon or Jan to help.
>
> thanks
> Mandy
>
>> On Aug 30, 2016, at 7:57 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> Hi, Mandy
>>
>> Thank you for the quick fix!
>>
>> I just noticed that this patch does not include the fix for test tools/javac/diags/CheckExamples.java, which starts failing after removal of old module-related options. Will it fix in another bugid?
>>
>> Thanks,
>> Amy
>>
>> On 8/31/16 10:41 AM, Mandy Chung wrote:
>>> Some langtools tests are stil using -release and -mp that are removed in [1].
>>>
>>> Webrev:
>>>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>>>
>>> thanks
>>> Mandy
>>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466


From mandy.chung at oracle.com  Wed Aug 31 03:31:16 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Aug 2016 20:31:16 -0700
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <57C64F43.3010501@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
	<5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
	<57C64F43.3010501@oracle.com>
Message-ID: <75A0C19B-FED0-4C9C-95D3-B63A66B9CF4A@oracle.com>

diff --git a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
--- a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
+++ b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
@@ -22,6 +22,6 @@
  */
 
 // key: compiler.err.processorpath.no.processormodulepath
-// options: -processormodulepath mods -processorpath mods
+// options: --processor-module-path mods -processorpath mods
 
 class ProcessorPathNoProcessorModulePath {}

> On Aug 30, 2016, at 8:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Fix is in the comments in the new bug.
> 
> -- Jon
> 
> On 08/30/2016 08:07 PM, Mandy Chung wrote:
>> Hi Amy,
>> 
>> Can you file a new JBS issue for CheckExamples.java test?  This probably would need Jon or Jan to help.
>> 
>> thanks
>> Mandy
>> 
>>> On Aug 30, 2016, at 7:57 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>> 
>>> Hi, Mandy
>>> 
>>> Thank you for the quick fix!
>>> 
>>> I just noticed that this patch does not include the fix for test tools/javac/diags/CheckExamples.java, which starts failing after removal of old module-related options. Will it fix in another bugid?
>>> 
>>> Thanks,
>>> Amy
>>> 
>>> On 8/31/16 10:41 AM, Mandy Chung wrote:
>>>> Some langtools tests are stil using -release and -mp that are removed in [1].
>>>> 
>>>> Webrev:
>>>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>>>> 
>>>> thanks
>>>> Mandy
>>>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466
> 


From amy.lu at oracle.com  Wed Aug 31 03:32:43 2016
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 31 Aug 2016 11:32:43 +0800
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <57C64F43.3010501@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
	<5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
	<57C64F43.3010501@oracle.com>
Message-ID: <1c393a5c-dd4d-dba3-e542-40b0c6090bbb@oracle.com>

On 8/31/16 11:30 AM, Jonathan Gibbons wrote:
> Fix is in the comments in the new bug.
Thank you Jon for the quick update!

Thanks,
Amy

>
> -- Jon
>
> On 08/30/2016 08:07 PM, Mandy Chung wrote:
>> Hi Amy,
>>
>> Can you file a new JBS issue for CheckExamples.java test?  This 
>> probably would need Jon or Jan to help.
>>
>> thanks
>> Mandy
>>
>>> On Aug 30, 2016, at 7:57 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>
>>> Hi, Mandy
>>>
>>> Thank you for the quick fix!
>>>
>>> I just noticed that this patch does not include the fix for test 
>>> tools/javac/diags/CheckExamples.java, which starts failing after 
>>> removal of old module-related options. Will it fix in another bugid?
>>>
>>> Thanks,
>>> Amy
>>>
>>> On 8/31/16 10:41 AM, Mandy Chung wrote:
>>>> Some langtools tests are stil using -release and -mp that are 
>>>> removed in [1].
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>>>>
>>>> thanks
>>>> Mandy
>>>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466
>


From amy.lu at oracle.com  Wed Aug 31 03:37:09 2016
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 31 Aug 2016 11:37:09 +0800
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <75A0C19B-FED0-4C9C-95D3-B63A66B9CF4A@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
	<5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
	<57C64F43.3010501@oracle.com>
	<75A0C19B-FED0-4C9C-95D3-B63A66B9CF4A@oracle.com>
Message-ID: <0730ec23-4109-c273-fc21-99ec3103cfcd@oracle.com>

Great, so the only one failure left got resolved now by the additional diff.

All looks fine.(though I'm not official reviewer)

Thank you for the quick fix!


Thanks,
Amy

On 8/31/16 11:31 AM, Mandy Chung wrote:
> diff --git a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
> --- a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
> +++ b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
> @@ -22,6 +22,6 @@
>    */
>   
>   // key: compiler.err.processorpath.no.processormodulepath
> -// options: -processormodulepath mods -processorpath mods
> +// options: --processor-module-path mods -processorpath mods
>   
>   class ProcessorPathNoProcessorModulePath {}
>
>> On Aug 30, 2016, at 8:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> Fix is in the comments in the new bug.
>>
>> -- Jon
>>
>> On 08/30/2016 08:07 PM, Mandy Chung wrote:
>>> Hi Amy,
>>>
>>> Can you file a new JBS issue for CheckExamples.java test?  This probably would need Jon or Jan to help.
>>>
>>> thanks
>>> Mandy
>>>
>>>> On Aug 30, 2016, at 7:57 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>>
>>>> Hi, Mandy
>>>>
>>>> Thank you for the quick fix!
>>>>
>>>> I just noticed that this patch does not include the fix for test tools/javac/diags/CheckExamples.java, which starts failing after removal of old module-related options. Will it fix in another bugid?
>>>>
>>>> Thanks,
>>>> Amy
>>>>
>>>> On 8/31/16 10:41 AM, Mandy Chung wrote:
>>>>> Some langtools tests are stil using -release and -mp that are removed in [1].
>>>>>
>>>>> Webrev:
>>>>>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>>>>>
>>>>> thanks
>>>>> Mandy
>>>>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466


From jonathan.gibbons at oracle.com  Wed Aug 31 03:37:06 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 Aug 2016 20:37:06 -0700
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <75A0C19B-FED0-4C9C-95D3-B63A66B9CF4A@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
	<5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
	<57C64F43.3010501@oracle.com>
	<75A0C19B-FED0-4C9C-95D3-B63A66B9CF4A@oracle.com>
Message-ID: <57C650E2.1060600@oracle.com>

Looks OK to me

-- Jon

On 08/30/2016 08:31 PM, Mandy Chung wrote:
> diff --git a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
> --- a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
> +++ b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
> @@ -22,6 +22,6 @@
>    */
>   
>   // key: compiler.err.processorpath.no.processormodulepath
> -// options: -processormodulepath mods -processorpath mods
> +// options: --processor-module-path mods -processorpath mods
>   
>   class ProcessorPathNoProcessorModulePath {}
>
>> On Aug 30, 2016, at 8:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> Fix is in the comments in the new bug.
>>
>> -- Jon
>>
>> On 08/30/2016 08:07 PM, Mandy Chung wrote:
>>> Hi Amy,
>>>
>>> Can you file a new JBS issue for CheckExamples.java test?  This probably would need Jon or Jan to help.
>>>
>>> thanks
>>> Mandy
>>>
>>>> On Aug 30, 2016, at 7:57 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>>
>>>> Hi, Mandy
>>>>
>>>> Thank you for the quick fix!
>>>>
>>>> I just noticed that this patch does not include the fix for test tools/javac/diags/CheckExamples.java, which starts failing after removal of old module-related options. Will it fix in another bugid?
>>>>
>>>> Thanks,
>>>> Amy
>>>>
>>>> On 8/31/16 10:41 AM, Mandy Chung wrote:
>>>>> Some langtools tests are stil using -release and -mp that are removed in [1].
>>>>>
>>>>> Webrev:
>>>>>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>>>>>
>>>>> thanks
>>>>> Mandy
>>>>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466


From mandy.chung at oracle.com  Wed Aug 31 03:42:01 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Aug 2016 20:42:01 -0700
Subject: Review Request: JDK-8165109: langtools/test switches to use new
	CLI options
In-Reply-To: <57C650E2.1060600@oracle.com>
References: <72C43386-22F1-43AA-BBF7-9E71944E8CBF@oracle.com>
	<1dd79276-e0ec-6aa1-4fd3-568f3d6dec61@oracle.com>
	<5702DDE2-0547-409B-97E4-85D087078D1F@oracle.com>
	<57C64F43.3010501@oracle.com>
	<75A0C19B-FED0-4C9C-95D3-B63A66B9CF4A@oracle.com>
	<57C650E2.1060600@oracle.com>
Message-ID: <F89096DA-52C1-4FB7-B82D-32B7245FD3A4@oracle.com>

Thanks Jon and Amy.  I?ll include that in the same changeset.

Mandy

> On Aug 30, 2016, at 8:37 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Looks OK to me
> 
> -- Jon
> 
> On 08/30/2016 08:31 PM, Mandy Chung wrote:
>> diff --git a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
>> --- a/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
>> +++ b/test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java
>> @@ -22,6 +22,6 @@
>>   */
>>    // key: compiler.err.processorpath.no.processormodulepath
>> -// options: -processormodulepath mods -processorpath mods
>> +// options: --processor-module-path mods -processorpath mods
>>    class ProcessorPathNoProcessorModulePath {}
>> 
>>> On Aug 30, 2016, at 8:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>> 
>>> Fix is in the comments in the new bug.
>>> 
>>> -- Jon
>>> 
>>> On 08/30/2016 08:07 PM, Mandy Chung wrote:
>>>> Hi Amy,
>>>> 
>>>> Can you file a new JBS issue for CheckExamples.java test?  This probably would need Jon or Jan to help.
>>>> 
>>>> thanks
>>>> Mandy
>>>> 
>>>>> On Aug 30, 2016, at 7:57 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>>> 
>>>>> Hi, Mandy
>>>>> 
>>>>> Thank you for the quick fix!
>>>>> 
>>>>> I just noticed that this patch does not include the fix for test tools/javac/diags/CheckExamples.java, which starts failing after removal of old module-related options. Will it fix in another bugid?
>>>>> 
>>>>> Thanks,
>>>>> Amy
>>>>> 
>>>>> On 8/31/16 10:41 AM, Mandy Chung wrote:
>>>>>> Some langtools tests are stil using -release and -mp that are removed in [1].
>>>>>> 
>>>>>> Webrev:
>>>>>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165109/webrev.00/
>>>>>> 
>>>>>> thanks
>>>>>> Mandy
>>>>>> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466
>