From jk at blackdown.de  Fri Nov  1 10:18:17 2013
From: jk at blackdown.de (=?utf-8?Q?J=C3=BCrgen_Kreileder?=)
Date: Fri, 01 Nov 2013 18:18:17 +0100
Subject: Building on Mavericks
In-Reply-To: <3BB79968-3B9A-47E3-81E9-3F28847D8AB3@gmail.com> (Sam Pullara's
	message of "Tue, 15 Oct 2013 10:56:18 -0700")
References: <3BB79968-3B9A-47E3-81E9-3F28847D8AB3@gmail.com>
Message-ID: <20131101171809.257403DC06A@smtp.blackdown.de>

Sam Pullara <spullara at gmail.com> writes:

> Anyone have this working? gcc42 barfs on some of the OSX .h files.

With the following two changesets I can build with "USE_CLANG=true make" using Xcode 5 on Mavericks.


     Juergen

# HG changeset patch
# User J?rgen Kreileder <jk at blackdown.de>
# Date 1383086029 -3600
# Node ID 5cf40fd518ba9df9ef1806e9c2d6ace3ebc5366c
# Parent  4f2011496393a26dcfd7b1f7787a3673ddd32599
Allow building with "USE_CLANG=true make" on OS X Mavericks with Xcode 5.0.1

diff --git a/common/autoconf/generated-configure.sh b/common/autoconf/generated-configure.sh
--- a/common/autoconf/generated-configure.sh
+++ b/common/autoconf/generated-configure.sh
@@ -3865,7 +3865,7 @@
 #CUSTOM_AUTOCONF_INCLUDE
 
 # Do not change or remove the following line, it is needed for consistency checks:
-DATE_WHEN_GENERATED=1382702260
+DATE_WHEN_GENERATED=1383085981
 
 ###############################################################################
 #
@@ -20069,11 +20069,15 @@
     # Check that this is likely to be GCC.
     $COMPILER --version 2>&1 | $GREP "Free Software Foundation" > /dev/null
     if test $? -ne 0; then
-      { $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler." >&5
+      COMPILER_VERSION_TEST=`$COMPILER --version 2>&1 | $HEAD -n 2 | $TAIL -n 1 `
+      $COMPILER --version 2>&1 | $GREP "Apple LLVM" > /dev/null
+      if test $? -ne 0; then
+        { $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler." >&5
 $as_echo "$as_me: The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler." >&6;}
-      { $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with --version was: \"$COMPILER_VERSION_TEST\"" >&5
+        { $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with --version was: \"$COMPILER_VERSION_TEST\"" >&5
 $as_echo "$as_me: The result from running with --version was: \"$COMPILER_VERSION_TEST\"" >&6;}
-      as_fn_error $? "GCC compiler is required. Try setting --with-tools-dir." "$LINENO" 5
+        as_fn_error $? "GCC compiler is required. Try setting --with-tools-dir." "$LINENO" 5
+      fi
     fi
 
     # First line typically looks something like:
@@ -21648,11 +21652,15 @@
     # Check that this is likely to be GCC.
     $COMPILER --version 2>&1 | $GREP "Free Software Foundation" > /dev/null
     if test $? -ne 0; then
-      { $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler." >&5
+      COMPILER_VERSION_TEST=`$COMPILER --version 2>&1 | $HEAD -n 2 | $TAIL -n 1 `
+      $COMPILER --version 2>&1 | $GREP "Apple LLVM" > /dev/null
+      if test $? -ne 0; then
+        { $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler." >&5
 $as_echo "$as_me: The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler." >&6;}
-      { $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with --version was: \"$COMPILER_VERSION_TEST\"" >&5
+        { $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with --version was: \"$COMPILER_VERSION_TEST\"" >&5
 $as_echo "$as_me: The result from running with --version was: \"$COMPILER_VERSION_TEST\"" >&6;}
-      as_fn_error $? "GCC compiler is required. Try setting --with-tools-dir." "$LINENO" 5
+        as_fn_error $? "GCC compiler is required. Try setting --with-tools-dir." "$LINENO" 5
+      fi
     fi
 
     # First line typically looks something like:
diff --git a/common/autoconf/toolchain.m4 b/common/autoconf/toolchain.m4
--- a/common/autoconf/toolchain.m4
+++ b/common/autoconf/toolchain.m4
@@ -65,9 +65,13 @@
     # Check that this is likely to be GCC.
     $COMPILER --version 2>&1 | $GREP "Free Software Foundation" > /dev/null
     if test $? -ne 0; then
-      AC_MSG_NOTICE([The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler.])
-      AC_MSG_NOTICE([The result from running with --version was: "$COMPILER_VERSION_TEST"])
-      AC_MSG_ERROR([GCC compiler is required. Try setting --with-tools-dir.])
+      COMPILER_VERSION_TEST=`$COMPILER --version 2>&1 | $HEAD -n 2 | $TAIL -n 1 `
+      $COMPILER --version 2>&1 | $GREP "Apple LLVM" > /dev/null
+      if test $? -ne 0; then
+        AC_MSG_NOTICE([The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required GCC compiler.])
+        AC_MSG_NOTICE([The result from running with --version was: "$COMPILER_VERSION_TEST"])
+        AC_MSG_ERROR([GCC compiler is required. Try setting --with-tools-dir.])
+      fi
     fi
 
     # First line typically looks something like:
=
# HG changeset patch
# User J?rgen Kreileder <jk at blackdown.de>
# Date 1383086084 -3600
# Node ID d02d1e0b9c8deeaa9e1bc59b723aef6de593e7fd
# Parent  7fd913010dbbf75260688fd2fa8964763fa49a09
Allow building with "USE_CLANG=true make" on OS X Mavericks with Xcode 5.0.1

diff --git a/make/bsd/makefiles/gcc.make b/make/bsd/makefiles/gcc.make
--- a/make/bsd/makefiles/gcc.make
+++ b/make/bsd/makefiles/gcc.make
@@ -325,6 +325,13 @@
   endif
 endif
 
+# Use libstdc++
+ifeq ($(USE_CLANG), true)
+  ifeq ($(shell expr $(CC_VER_MAJOR) \> 4), 1)
+    LFLAGS += -stdlib=libstdc++
+  endif
+endif
+
 # Flags for generating make dependency flags.
 DEPFLAGS = -MMD -MP -MF $(DEP_DIR)/$(@:%=%.d)
 ifeq ($(USE_CLANG),)
=


-- 
https://blackdown.de/

From Sebastian.Millies at softwareag.com  Fri Nov  1 11:01:56 2013
From: Sebastian.Millies at softwareag.com (Millies, Sebastian)
Date: Fri, 1 Nov 2013 18:01:56 +0000
Subject: Performance model of sorted() ?
Message-ID: <32F15738E8E5524DA4F01A0FA4A8E490C2FE29C1@HQMBX5.eur.ad.sag>

Hello there,

in a talk at JAX 2013 the processing model for sorting a stream with sorted() was described as follows.
I?d like to know if that presentation is really correct:

.parallelStream().statelessOps() // upstream slice
.sorted() // sorted slice
.statelessOps().terminal() // downstream slice

? stream is sliced
? resulting stream is buffered at the end of upstream slice (barrier)
? downstream slice is started after the upstream slice is finished
? sorted-slice is run by a single thread only

I wonder particularly about the statement saying that the sorting is done by a single thread, after all
there is parallel array sort etc. Can anyone clarify the performance model of sorted() ?

-- Sebastian


Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From brian.goetz at oracle.com  Fri Nov  1 11:18:19 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 01 Nov 2013 14:18:19 -0400
Subject: Performance model of sorted() ?
In-Reply-To: <32F15738E8E5524DA4F01A0FA4A8E490C2FE29C1@HQMBX5.eur.ad.sag>
References: <32F15738E8E5524DA4F01A0FA4A8E490C2FE29C1@HQMBX5.eur.ad.sag>
Message-ID: <5273F06B.3050404@oracle.com>

The "slicing" part is right, but the single-threaded assumption is wrong.

What happens is that the upstream stateless ops will be done in 
parallel, with the results being collected at the leaves of the 
computation tree, into a bunch of mini-buffers.  Now, each will be 
sorted (in parallel), and then we begin a parallel merge, collecting the 
results into an array.  Then the downstream stateless ops and the 
terminal op are run, in parallel.

So, no truly sequential steps imposed by the framework (though binary 
parallel merges are generally dominated by the last merge step.)

On 11/1/2013 2:01 PM, Millies, Sebastian wrote:
> Hello there,
>
> in a talk at JAX 2013 the processing model for sorting a stream with sorted() was described as follows.
> I?d like to know if that presentation is really correct:
>
> .parallelStream().statelessOps() // upstream slice
> .sorted() // sorted slice
> .statelessOps().terminal() // downstream slice
>
> ? stream is sliced
> ? resulting stream is buffered at the end of upstream slice (barrier)
> ? downstream slice is started after the upstream slice is finished
> ? sorted-slice is run by a single thread only
>
> I wonder particularly about the statement saying that the sorting is done by a single thread, after all
> there is parallel array sort etc. Can anyone clarify the performance model of sorted() ?
>
> -- Sebastian
>
>
> Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>
>

From vicente.romero at oracle.com  Fri Nov  1 13:54:40 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 01 Nov 2013 20:54:40 +0000
Subject: Ambiguity method error when one method can't be applicable
In-Reply-To: <04d901cec4e2$a8169bb0$f843d310$@Kozlova@jetbrains.com>
References: <04b901cec43e$6853c560$38fb5020$@Kozlova@jetbrains.com>
	<04d901cec4e2$a8169bb0$f843d310$@Kozlova@jetbrains.com>
Message-ID: <52741510.6050707@oracle.com>

Hi Anna,

Sorry for the late reply, I guess I lost the track of this issue.

The chageset you have mentioned implements a new approach to unstick 
lambda expressions which has been discussed a lot in this list.

Check for example [1] and other mails in the thread.

Thanks,

Vicente

[1] 
http://mail.openjdk.java.net/pipermail/lambda-dev/2013-August/010704.html

On 09/10/13 12:28, Anna Kozlova wrote:
> Hi,
>
> It looks like that the change which caused the problem is
> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4a6acc42c3a1. The
> test data e.g.
> http://hg.openjdk.java.net/lambda/lambda/langtools/file/4a6acc42c3a1/test/to
> ols/javac/lambda/TargetType02.java was changed exactly in a way I've
> described.
>
> The change itself is quite complicated and javac specific so I am not sure I
> understand how it is connected to the spec. Could you please help?
>
> Thank you
> Anna Kozlova
> JetBrains
> http://www.jetbrains.com
> "Develop with pleasure!"
>
>
>
> -----Original Message-----
> From: lambda-dev-bounces at openjdk.java.net
> [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Anna Kozlova
> Sent: Tuesday, October 08, 2013 5:53 PM
> To: lambda-dev at openjdk.java.net
> Subject: Ambiguity method error when one method can't be applicable
>
> Hi guys,
>
>   
>
> The following code does not compile with ambiguous method error:
>
>   
>
> class MyTest {
>
>   
>
>      interface I1 {
>
>          Foo<Number> m(String s);
>
>      }
>
>   
>
>      interface I2 {
>
>          Foo<Number> m(Integer i);
>
>      }
>
>   
>
>      static class Foo<T extends Number> {
>
>          Foo(T t) {
>
>              System.out.println(t);
>
>          }
>
>      }
>
>   
>
>      private static void m(I1 i) {}
>
>      private static void m(I2 i) {}
>
>   
>
>      public static void main(String[] args) {
>
>          m(Foo::new);
>
>      }
>
> }
>
>   
>
> Some time ago though there was no such an error.
>
>   
>
> Not sure that I understand why compiler can't resolve such an ambiguity for
> me. Could someone explain, please?
>
>   
>
> Thank you
> Anna Kozlova
> JetBrains
>   <http://www.intellij.com/> http://www.jetbrains.com "Develop with
> pleasure!"
>
>   
>
>
>
> !DSPAM:35,52542aaf317841350320123!
>
>


From vicente.romero at oracle.com  Fri Nov  1 14:25:29 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 01 Nov 2013 21:25:29 +0000
Subject: Open a bug for compiler crash
In-Reply-To: <c01817b1-56c4-4c63-aa69-dccf86f7cf69@default>
References: <c01817b1-56c4-4c63-aa69-dccf86f7cf69@default>
Message-ID: <52741C49.4050505@oracle.com>

Hi Tristan,

Thanks for the report, the bug has been fixed, see [1]

Vicente

[1] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/70a301b35e71

On 02/10/13 11:26, Tristan Yan wrote:
> https://bugs.openjdk.java.net/browse/JDK-8025816
>
> Thank you
>
>   
>
> Tristan Yan(Haibo Yan)
>
> Office : 8610-61066212
>
> Fax  : 8610-61065441
>
> Cell  : 86-18610696822
>
>   
>
> 2F, Building No. 24, Zhongguancun Software Park
>
> Haidian District HYPERLINK "http://people.us.oracle.com/pls/oracle/f?p=8000:6:396067987304343:::6:P6_CITY:Beijing"Beijing , 100193
>
> oracle
>
>   
>
>


From vicente.romero at oracle.com  Sat Nov  2 13:15:47 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Sat, 02 Nov 2013 20:15:47 +0000
Subject: Possible regression involving inferred generic types
In-Reply-To: <CAL4QsgsteUsUpXeZgou-mLfTpmeyRjh-Mgz4CzBaYqjsW2bRpA@mail.gmail.com>
References: <CAL4QsgsteUsUpXeZgou-mLfTpmeyRjh-Mgz4CzBaYqjsW2bRpA@mail.gmail.com>
Message-ID: <52755D73.4090702@oracle.com>

Hi,

Sorry for the late response.

Thanks for the report I will investigate this issue and if necessary 
file a bug in our bug DB.

Thanks,

Vicente

On 17/10/13 01:48, cushon wrote:
> Forwarded from compiler-dev at Alex Buckley's suggestion. Original thread:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2013-October/007726.html
>
>
> I found some cases where javac 8 behaviour diverges from javac 7, and I'm
> interested in knowing whether this is a bug or an intentional change.
>
> The following programs do not compile with the jdk8 javac. (I tried b111 and
> 954dd199d6ff). All of the programs compile with the jdk7 javac.
>
> -------------------------------------------------------------------------------
> import java.util.List;
>
> class ReproOne {
>
>    static class Baz<T> {
>      public static List<Baz<Object>> getElements(Baz<Object> transcoder) {
>        return null;
>      }
>    }
>
>    private static void bar(Baz arg) {
>      for (Baz element : Baz.getElements(arg)) {}
>    }
> }
> -------------------------------------------------------------------------------
> abstract class ReproTwo<T> {
>
>    class Bar<E> {}
>
>    T get(Bar<? extends T> arg1, Bar arg2) {
>      return circularGet(arg2, arg2);
>    }
>
>    abstract T circularGet(final Bar<? extends T> arg1, final Bar<?> arg2);
> }
> -------------------------------------------------------------------------------
> abstract class ReproThree<T, V> {
>
>    class Binding<E> {}
>    class ProviderBinding<E> extends Binding<E> {}
>
>    abstract V visitOther(Binding<? extends T> binding);
>
>    public V visitTwo(ProviderBinding<? extends T> providerBinding) {
>      return visitOther((Binding) providerBinding);
>    }
> }
> -------------------------------------------------------------------------------
>
> javac output:
>
> ReproOne.java:12: error: incompatible types: Object cannot be converted to
> Baz
>      for (Baz element : Baz.getElements(arg)) {}
>                                        ^
>
> ReproTwo.java:6: error: incompatible types: Object cannot be converted to T
>      return circularGet(arg2, arg2);
>                        ^
>    where T is a type-variable:
>      T extends Object declared in class ReproTwo
>
> ReproThree.java:10: error: incompatible types: Object cannot be converted
> to V
>      return visitOther((Binding) providerBinding);
>                       ^
>    where V is a type-variable:
>      V extends Object declared in class ReproThree
>


From paul.sandoz at oracle.com  Mon Nov  4 01:13:08 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 4 Nov 2013 10:13:08 +0100
Subject: Performance model of sorted() ?
In-Reply-To: <5273F06B.3050404@oracle.com>
References: <32F15738E8E5524DA4F01A0FA4A8E490C2FE29C1@HQMBX5.eur.ad.sag>
	<5273F06B.3050404@oracle.com>
Message-ID: <7F12E649-8019-40E7-AF76-448B9AAB535D@oracle.com>


On Nov 1, 2013, at 7:18 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> The "slicing" part is right, but the single-threaded assumption is wrong.
> 
> What happens is that the upstream stateless ops will be done in 
> parallel, with the results being collected at the leaves of the 
> computation tree, into a bunch of mini-buffers.  Now, each will be 
> sorted (in parallel), and then we begin a parallel merge, collecting the 
> results into an array.  Then the downstream stateless ops and the 
> terminal op are run, in parallel.
> 

That is what we wanted/planned to do :-) but for reasons of expediency we currently resort to collecting, in parallel, to an array and then using Arrays.parallelSort e.g. the equivalent of:

  Stream s = ...
  s = s.parallel();
  Object[] a = s.toArray();
  Arrays.parallelSort(a);
  s = Arrays.stream(a);

So there is some redundancy and Arrays.parallelSort will not go parallel if the size of the array is less than 2^13.

Unfortunately it will be tricky to share any code from Arrays.parallelSort, thus requiring duplication x 4 (for refs + primitives). (Arrays.parallelArray splits into quarters to ensure the final sort is in the main array but in our case i don't think we require that.)

For an optimal implementation that computation tree needs to consist of nodes that are F/J tasks (such that collection and merging can happen concurrently) and we need to support sized and non-sized pipelines slightly differently for the collection phase. Given that we can use Arrays.parallelArray code as a template i think most of the hard work is done.

Paul.

> So, no truly sequential steps imposed by the framework (though binary 
> parallel merges are generally dominated by the last merge step.)


From vicente.romero at oracle.com  Mon Nov  4 07:10:09 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 04 Nov 2013 15:10:09 +0000
Subject: Possible regression involving inferred generic types
In-Reply-To: <CAL4QsgsteUsUpXeZgou-mLfTpmeyRjh-Mgz4CzBaYqjsW2bRpA@mail.gmail.com>
References: <CAL4QsgsteUsUpXeZgou-mLfTpmeyRjh-Mgz4CzBaYqjsW2bRpA@mail.gmail.com>
Message-ID: <5277B8D1.9050108@oracle.com>

Hi Liam,

I have been investigating the issue you reported. The fix that changed 
javac's behavior is deep in current javac 8 repo, see [1], the original 
bug entry can be seen at [2].

 From my understanding of the spec and also based on Alex's answer at 
[3], I think that the fact that the code compiles in 7 is a bug and thus 
8 can be considered correct. For this reason I don't think that there is 
a compatibility issue here.

I have modified the code of ReproOne.java to:

--------------------------------------------------------------------------------
import java.util.List;

class ReproOne {

   static class Baz<T> {
     public static List<Baz<Object>> getElements(Baz<Object> transcoder) {
       return null;
     }
   }

   private static void bar(Baz arg) {
     Baz element = Baz.getElements(arg).get(0);
   }
}
-----------------------------------------------------------------------------------

Which probably shows more clearly the fact that after erasing the return 
value of getElements() to "java.util.List" the type of get(0) is Object 
and thus not assignable to a variable of type Baz.

Thanks,
Vicente.

[1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/48ee63caaa93
[2] https://bugs.openjdk.java.net/browse/JDK-7144506
[3] 
http://mail.openjdk.java.net/pipermail/compiler-dev/2013-October/007726.html

On 17/10/13 01:48, cushon wrote:
> Forwarded from compiler-dev at Alex Buckley's suggestion. Original thread:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2013-October/007726.html
>
>
> I found some cases where javac 8 behaviour diverges from javac 7, and I'm
> interested in knowing whether this is a bug or an intentional change.
>
> The following programs do not compile with the jdk8 javac. (I tried b111 and
> 954dd199d6ff). All of the programs compile with the jdk7 javac.
>
> -------------------------------------------------------------------------------
> import java.util.List;
>
> class ReproOne {
>
>    static class Baz<T> {
>      public static List<Baz<Object>> getElements(Baz<Object> transcoder) {
>        return null;
>      }
>    }
>
>    private static void bar(Baz arg) {
>      for (Baz element : Baz.getElements(arg)) {}
>    }
> }
> -------------------------------------------------------------------------------
> abstract class ReproTwo<T> {
>
>    class Bar<E> {}
>
>    T get(Bar<? extends T> arg1, Bar arg2) {
>      return circularGet(arg2, arg2);
>    }
>
>    abstract T circularGet(final Bar<? extends T> arg1, final Bar<?> arg2);
> }
> -------------------------------------------------------------------------------
> abstract class ReproThree<T, V> {
>
>    class Binding<E> {}
>    class ProviderBinding<E> extends Binding<E> {}
>
>    abstract V visitOther(Binding<? extends T> binding);
>
>    public V visitTwo(ProviderBinding<? extends T> providerBinding) {
>      return visitOther((Binding) providerBinding);
>    }
> }
> -------------------------------------------------------------------------------
>
> javac output:
>
> ReproOne.java:12: error: incompatible types: Object cannot be converted to
> Baz
>      for (Baz element : Baz.getElements(arg)) {}
>                                        ^
>
> ReproTwo.java:6: error: incompatible types: Object cannot be converted to T
>      return circularGet(arg2, arg2);
>                        ^
>    where T is a type-variable:
>      T extends Object declared in class ReproTwo
>
> ReproThree.java:10: error: incompatible types: Object cannot be converted
> to V
>      return visitOther((Binding) providerBinding);
>                       ^
>    where V is a type-variable:
>      V extends Object declared in class ReproThree
>


From henry.jen at oracle.com  Wed Nov  6 13:55:07 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 06 Nov 2013 21:55:07 +0000
Subject: hg: lambda/lambda: 6 new changesets
Message-ID: <20131106215507.DEC58623DC@hg.openjdk.java.net>

Changeset: b098ee22aa97
Author:    erikj
Date:      2013-10-24 10:43 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/b098ee22aa97

8009280: JCE jurisdiction policy files not copied into jdk/lib/security
Reviewed-by: tbell, ihse

! common/makefiles/JavaCompilation.gmk

Changeset: 3c48e11c3901
Author:    dholmes
Date:      2013-10-24 20:45 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/3c48e11c3901

8016096: [macosx] jawt_md.h shipped with jdk is outdated
Summary: Revised build system and added platform specific headers for Mac OS X
Reviewed-by: ihse, erikj
Contributed-by: david.dehaven at oracle.com

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

Changeset: 72ef61df77e5
Author:    ihse
Date:      2013-10-25 13:58 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/72ef61df77e5

8027300: configure should use LIBS instead of LDFLAGS when testing freetype
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4

Changeset: dfbc93f26f38
Author:    dcubed
Date:      2013-10-25 10:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/dfbc93f26f38

8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy
Summary: Fix whitespace/indent issues.
Reviewed-by: hseigel, coleenp, erikj, ihse

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/makefiles/NativeCompilation.gmk

Changeset: 4f2011496393
Author:    katleman
Date:      2013-10-28 16:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/4f2011496393

Merge


Changeset: bb31481efc2a
Author:    henryjen
Date:      2013-11-06 11:33 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/bb31481efc2a

Merge

- .jcheck/conf
! common/autoconf/generated-configure.sh
! common/makefiles/JavaCompilation.gmk


From henry.jen at oracle.com  Wed Nov  6 13:55:22 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 06 Nov 2013 21:55:22 +0000
Subject: hg: lambda/lambda/jaxp: 39 new changesets
Message-ID: <20131106215645.D60DD623DD@hg.openjdk.java.net>

Changeset: a4622ff1462b
Author:    cl
Date:      2013-10-10 10:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/a4622ff1462b

Added tag jdk8-b111 for changeset 17ee0d3e97fd

! .hgtags

Changeset: 84a2b2ee6fc6
Author:    aefimov
Date:      2013-10-01 17:14 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/84a2b2ee6fc6

8024707: TransformerException : item() return null with node list of length != 1
Reviewed-by: joehw, lancea

! src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java

Changeset: f031b2fe21cd
Author:    dfuchs
Date:      2013-10-04 19:15 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/f031b2fe21cd

8025745: Clarify API documentation of JAXP factories.
Summary: Clarifies usage of ServiceLoader in JAXP factories.
Reviewed-by: alanb, joehw, psandoz

! src/javax/xml/datatype/DatatypeFactory.java
! src/javax/xml/parsers/DocumentBuilderFactory.java
! src/javax/xml/parsers/SAXParserFactory.java
! src/javax/xml/stream/XMLEventFactory.java
! src/javax/xml/stream/XMLInputFactory.java
! src/javax/xml/stream/XMLOutputFactory.java
! src/javax/xml/transform/TransformerFactory.java
! src/javax/xml/validation/SchemaFactory.java
! src/javax/xml/xpath/XPathFactory.java

Changeset: dbecbb685503
Author:    mfang
Date:      2013-10-08 09:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/dbecbb685503

8025215: jdk8 l10n resource file translation update 4
Reviewed-by: joehw, yhuang

! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java
+ src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java

Changeset: 1c074a0c2b97
Author:    mfang
Date:      2013-10-08 09:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/1c074a0c2b97

Merge


Changeset: d69f4ac43d64
Author:    lana
Date:      2013-10-08 14:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/d69f4ac43d64

Merge


Changeset: cdc3577cba0b
Author:    lana
Date:      2013-10-11 00:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/cdc3577cba0b

Merge


Changeset: acae2e8a46df
Author:    ihse
Date:      2013-10-10 14:58 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/acae2e8a46df

8001931: The new build system whitespace cleanup
Reviewed-by: tbell, simonis, erikj

! makefiles/BuildJaxp.gmk
! makefiles/Makefile

Changeset: c1f9158fbb9c
Author:    katleman
Date:      2013-10-16 11:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/c1f9158fbb9c

Merge


Changeset: e85dd07c0eea
Author:    cl
Date:      2013-10-17 09:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/e85dd07c0eea

Added tag jdk8-b112 for changeset c1f9158fbb9c

! .hgtags

Changeset: b76629725522
Author:    joehw
Date:      2013-10-10 17:01 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/b76629725522

8003262: reverse translation required changes in xalan resource bundles
Reviewed-by: lancea, dfuchs

! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java

Changeset: 2107c9baa457
Author:    lana
Date:      2013-10-10 10:03 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/2107c9baa457

Merge


Changeset: cff4e3bf530a
Author:    lana
Date:      2013-10-10 20:57 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/cff4e3bf530a

Merge


Changeset: 46ccc5fbc523
Author:    lana
Date:      2013-10-10 21:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/46ccc5fbc523

Merge


Changeset: de8c803d4958
Author:    aefimov
Date:      2013-10-13 13:50 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/de8c803d4958

8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc
Reviewed-by: alanb, shade

! src/com/sun/org/apache/xpath/internal/XPathContext.java

Changeset: 4712979714d1
Author:    lana
Date:      2013-10-11 21:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/4712979714d1

Merge


Changeset: 91ae0f2045bc
Author:    lana
Date:      2013-10-14 09:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/91ae0f2045bc

Merge


Changeset: eb169222d3f2
Author:    joehw
Date:      2013-10-14 22:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/eb169222d3f2

8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression
Reviewed-by: lancea, alanb

! src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java

Changeset: ecb66dc473c1
Author:    joehw
Date:      2013-07-16 14:06 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/ecb66dc473c1

8012425: Transform TransformerFactory
Reviewed-by: alanb, dfuchs, mullan

! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java
! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java
! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java
! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java

Changeset: 7a2014318343
Author:    joehw
Date:      2013-07-17 09:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/7a2014318343

8017298: Better XML support
Reviewed-by: alanb, dfuchs, mullan, lancea

! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java
! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java
! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java
! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java
! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java
- src/com/sun/org/apache/xerces/internal/util/SecurityManager.java
! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java
+ src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java
! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
! src/com/sun/xml/internal/stream/Entity.java

Changeset: a59549c3ad60
Author:    dfuchs
Date:      2013-07-17 18:46 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/a59549c3ad60

8013502: Improve stream factories
Reviewed-by: joehw, mullan, lancea

! src/javax/xml/stream/FactoryFinder.java

Changeset: 4b0b2b5c4cc8
Author:    chegar
Date:      2013-07-22 14:02 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/4b0b2b5c4cc8

Merge


Changeset: 40b8abe19642
Author:    chegar
Date:      2013-07-29 14:07 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/40b8abe19642

Merge

! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java
! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java
! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java
! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java

Changeset: 720db2e27962
Author:    joehw
Date:      2013-07-31 00:37 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/720db2e27962

8014530: Better digital signature processing
Reviewed-by: alanb, dfuchs, mullan, lancea

! src/com/sun/org/apache/xalan/internal/XalanConstants.java
+ src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java
! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java
! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java
! src/com/sun/org/apache/xerces/internal/impl/Constants.java
! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java
! src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java
! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java
! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java
! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java
+ src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java
! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java
! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java
! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java

Changeset: cd9347628c7c
Author:    joehw
Date:      2013-07-31 10:54 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/cd9347628c7c

8021366: java_util/Properties/PropertiesWithOtherEncodings fails during 7u45 nightly testing
Reviewed-by: lancea, alanb, dfuchs, mullan

! src/com/sun/xml/internal/stream/Entity.java

Changeset: ecbddaa85462
Author:    chegar
Date:      2013-08-02 11:10 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/ecbddaa85462

Merge


Changeset: c5e80c1fa32f
Author:    chegar
Date:      2013-08-09 14:31 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/c5e80c1fa32f

Merge

! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java

Changeset: f952c33ebfdb
Author:    chegar
Date:      2013-08-15 21:33 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/f952c33ebfdb

Merge


Changeset: ce16a5aa1507
Author:    joehw
Date:      2013-08-20 09:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/ce16a5aa1507

8022682: Supporting XOM
Reviewed-by: alanb, chegar, lancea

! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java
! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java
! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java
! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java
! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java
+ src/com/sun/org/apache/xerces/internal/util/SecurityManager.java
! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java
! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java

Changeset: cc3b64366048
Author:    chegar
Date:      2013-08-23 22:12 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/cc3b64366048

Merge


Changeset: 2b77e12ff69d
Author:    chegar
Date:      2013-10-11 19:49 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/2b77e12ff69d

Merge

! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java
! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java
! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java

Changeset: 6f220761f643
Author:    chegar
Date:      2013-10-15 14:16 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/6f220761f643

Merge


Changeset: 0c3f951630fe
Author:    joehw
Date:      2013-10-17 11:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/0c3f951630fe

8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI
Reviewed-by: lancea

! src/com/sun/org/apache/xerces/internal/util/URI.java

Changeset: 951c1f7fdb10
Author:    joehw
Date:      2013-10-17 16:35 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/951c1f7fdb10

8016500: Unlocalized warnigs.
Reviewed-by: lancea

! src/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java
! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java
! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java

Changeset: 31c82bc71ae3
Author:    lana
Date:      2013-10-17 15:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/31c82bc71ae3

Merge


Changeset: 2f1e1e2c2242
Author:    lana
Date:      2013-10-17 17:48 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/2f1e1e2c2242

Merge


Changeset: 0046d2278204
Author:    tbell
Date:      2013-10-22 16:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/0046d2278204

8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung

! make/jprt.properties

Changeset: 1b1e12117fe2
Author:    cl
Date:      2013-10-24 09:10 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/1b1e12117fe2

Added tag jdk8-b113 for changeset 0046d2278204

! .hgtags

Changeset: 20b3439cf5e9
Author:    henryjen
Date:      2013-11-06 11:37 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/20b3439cf5e9

Merge

! .hgtags
- .jcheck/conf


From henry.jen at oracle.com  Wed Nov  6 13:57:19 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 06 Nov 2013 21:57:19 +0000
Subject: hg: lambda/lambda/jaxws: 28 new changesets
Message-ID: <20131106215820.4CFB1623DE@hg.openjdk.java.net>

Changeset: fc94ce4b899e
Author:    cl
Date:      2013-10-10 10:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/fc94ce4b899e

Added tag jdk8-b111 for changeset 32edc7a2c866

! .hgtags

Changeset: b0610cd08440
Author:    mkos
Date:      2013-10-04 16:21 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/b0610cd08440

8025054: Update JAX-WS RI integration to 2.2.9-b130926.1035
Reviewed-by: chegar

! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WscompileMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Options.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Encoder.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64EncoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/ByteArrayOutputStreamEx.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/NamespaceContextEx.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamWriterEx.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/binary/SchemaBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DDataPattern.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DPattern.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DXMLPrinter.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DataPatternBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/GrammarBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/AnyNameClass.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/NameClassBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/SimpleNameClass.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/compact/UCode_UCodeESC_CharStream.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/xml/SchemaParser.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/xml/sax/JAXPXMLReaderCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPort.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLService.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundFault.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundOperation.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundPortType.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLFault.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLInput.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLMessage.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLModel.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOperation.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOutput.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPart.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPort.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPortType.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLService.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/PortInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/Stub.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ExternalMetadataReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractExtensibleImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLModelImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLServiceImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsservletMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/PayloadQNameBasedOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MemberSubmissionAddressingWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java
! src/share/jaxws_classes/javax/annotation/PostConstruct.java
! src/share/jaxws_classes/javax/annotation/PreDestroy.java
! src/share/jaxws_classes/javax/xml/bind/JAXBException.java
! src/share/jaxws_classes/javax/xml/bind/Marshaller.java
! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html
! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java

Changeset: e56be3a2287a
Author:    coffeys
Date:      2013-10-05 08:56 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/e56be3a2287a

8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash
Reviewed-by: mkos, chegar

! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java

Changeset: 1d6c13d3b8de
Author:    lana
Date:      2013-10-08 14:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/1d6c13d3b8de

Merge


Changeset: 7c0a7937f6ef
Author:    lana
Date:      2013-10-11 00:07 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/7c0a7937f6ef

Merge


Changeset: 602fdd7bb765
Author:    ihse
Date:      2013-10-10 14:58 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/602fdd7bb765

8001931: The new build system whitespace cleanup
Reviewed-by: tbell, simonis, erikj

! makefiles/BuildJaxws.gmk
! makefiles/Makefile

Changeset: dbdd5c762509
Author:    katleman
Date:      2013-10-16 11:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/dbdd5c762509

Merge


Changeset: 9ca9735d9966
Author:    cl
Date:      2013-10-17 09:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/9ca9735d9966

Added tag jdk8-b112 for changeset dbdd5c762509

! .hgtags

Changeset: da77e343f458
Author:    lana
Date:      2013-10-10 10:03 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/da77e343f458

Merge


Changeset: 66a12ce67d3a
Author:    lana
Date:      2013-10-10 21:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/66a12ce67d3a

Merge


Changeset: 328b8b96773b
Author:    lana
Date:      2013-10-11 21:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/328b8b96773b

Merge


Changeset: 43240b8b995b
Author:    mkos
Date:      2013-08-01 16:09 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/43240b8b995b

8017505: Better Client Service
Reviewed-by: mullan, ahgross, mgrebac

! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/MethodUtil.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/PolicyUtils.java

Changeset: 358f32260d1f
Author:    chegar
Date:      2013-08-02 11:11 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/358f32260d1f

Merge


Changeset: 5212665bea32
Author:    chegar
Date:      2013-08-09 14:31 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/5212665bea32

Merge


Changeset: d9704ab517d5
Author:    chegar
Date:      2013-08-15 21:33 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/d9704ab517d5

Merge


Changeset: fca8869ccfd0
Author:    chegar
Date:      2013-08-23 22:12 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/fca8869ccfd0

Merge


Changeset: a6e2adde013e
Author:    chegar
Date:      2013-08-30 10:15 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/a6e2adde013e

Merge


Changeset: f6376ba97cea
Author:    chegar
Date:      2013-09-06 09:55 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/f6376ba97cea

Merge


Changeset: d3a65e8912c9
Author:    chegar
Date:      2013-09-14 20:43 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/d3a65e8912c9

Merge


Changeset: da8141b6e344
Author:    chegar
Date:      2013-10-03 19:18 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/da8141b6e344

Merge


Changeset: 2dc8ae7eb53b
Author:    chegar
Date:      2013-10-11 19:24 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/2dc8ae7eb53b

Merge


Changeset: 01facfebe17b
Author:    chegar
Date:      2013-10-15 13:46 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/01facfebe17b

Merge


Changeset: be7d1f874b96
Author:    lana
Date:      2013-10-17 16:12 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/be7d1f874b96

Merge


Changeset: 17f1b13cd401
Author:    simonis
Date:      2013-10-21 15:11 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/17f1b13cd401

8026874: During JAXWS build the newly built JAXP classes should be in the bootclasspath (not only in the classpath)
Reviewed-by: erikj

! makefiles/BuildJaxws.gmk

Changeset: f20820d1582f
Author:    katleman
Date:      2013-10-22 16:10 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/f20820d1582f

Merge


Changeset: 9261f342aa73
Author:    tbell
Date:      2013-10-22 16:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/9261f342aa73

8027039: [jprt] Remove 32-bit Solaris from jprt.properties files
Reviewed-by: mduigou, mchung

! make/jprt.properties

Changeset: 9ad289610fc6
Author:    cl
Date:      2013-10-24 09:10 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/9ad289610fc6

Added tag jdk8-b113 for changeset 9261f342aa73

! .hgtags

Changeset: 7fd1228fd1a0
Author:    henryjen
Date:      2013-11-06 11:37 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/7fd1228fd1a0

Merge

! .hgtags
- .jcheck/conf


From henry.jen at oracle.com  Wed Nov  6 14:05:42 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 06 Nov 2013 22:05:42 +0000
Subject: hg: lambda/lambda/jdk: 8 new changesets
Message-ID: <20131106220736.4034D623E0@hg.openjdk.java.net>

Changeset: 110c4fe4c354
Author:    erikj
Date:      2013-10-24 10:43 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/110c4fe4c354

8009280: JCE jurisdiction policy files not copied into jdk/lib/security
Reviewed-by: tbell, ihse

! makefiles/BuildJdk.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CreateJars.gmk
+ makefiles/CreateSecurityJars.gmk
! makefiles/SignJars.gmk

Changeset: f40f639e1f52
Author:    dholmes
Date:      2013-10-24 20:46 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f40f639e1f52

8016096: [macosx] jawt_md.h shipped with jdk is outdated
Summary: Revised build system and added platform specific headers for Mac OS X
Reviewed-by: anthony, art, ihse, erikj
Contributed-by: david.dehaven at oracle.com

! makefiles/CopyFiles.gmk
! makefiles/gensrc/GensrcX11Wrappers.gmk
+ src/macosx/javavm/export/jawt_md.h
+ src/macosx/javavm/export/jni_md.h
+ src/macosx/javavm/export/jvm_md.h
! src/macosx/native/sun/awt/AWTSurfaceLayers.h
! src/macosx/native/sun/awt/CMenuComponent.h
! src/macosx/native/sun/awt/jawt.m
! src/macosx/native/sun/font/CoreTextSupport.h
! src/share/javavm/export/jawt.h

Changeset: f3c95d961557
Author:    dholmes
Date:      2013-10-24 20:47 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f3c95d961557

8025673: [macosx] Disable X11 AWT toolkit
Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X
Reviewed-by: anthony, art, ihse, erikj
Contributed-by: david.dehaven at oracle.com

! makefiles/CompileJavaClasses.gmk
! makefiles/GenerateSources.gmk
! makefiles/Tools.gmk
! makefiles/lib/Awt2dLibraries.gmk
! src/share/native/java/lang/System.c
! src/share/native/java/lang/java_props.h
! src/solaris/native/java/lang/java_props_macosx.c
! src/solaris/native/java/lang/java_props_macosx.h
! src/solaris/native/java/lang/java_props_md.c
! src/solaris/native/sun/awt/fontpath.c
! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh

Changeset: 5813af4c02e4
Author:    dcubed
Date:      2013-10-25 10:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5813af4c02e4

8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy
Summary: Fix whitespace/indent issues.
Reviewed-by: hseigel, coleenp, erikj, ihse

! makefiles/Import.gmk

Changeset: 1628a137edca
Author:    katleman
Date:      2013-10-28 16:03 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1628a137edca

Merge


Changeset: f26a0c8071bd
Author:    erikj
Date:      2013-10-29 15:44 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f26a0c8071bd

8027298: broken link in jdk8b113 macosx binaries
Reviewed-by: dcubed, ihse

! makefiles/Import.gmk

Changeset: e0851e231bd6
Author:    henryjen
Date:      2013-11-06 11:34 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e0851e231bd6

Merge

- .jcheck/conf
! makefiles/CreateJars.gmk
! makefiles/CreateSecurityJars.gmk
! makefiles/lib/Awt2dLibraries.gmk
- src/share/classes/java/lang/invoke/MagicLambdaImpl.java
- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties
! src/share/native/java/lang/System.c
! src/solaris/native/java/lang/java_props_md.c
- test/java/net/NetworkInterface/MemLeakTest.java
- test/jdk/lambda/vm/DefaultMethodsTest.java
- test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
- test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh

Changeset: ed09558136be
Author:    rfield
Date:      2013-11-04 10:12 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ed09558136be

7194897: JSR 292: Cannot create more than 16 instances of an anonymous class
8027681: Lambda serialization fails once reflection proxy generation kicks in
Reviewed-by: ksrini, briangoetz, jfranck
Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com

! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java
+ test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java
+ test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java


From henry.jen at oracle.com  Wed Nov  6 14:25:27 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 06 Nov 2013 22:25:27 +0000
Subject: hg: lambda/lambda/hotspot: 67 new changesets
Message-ID: <20131106222745.0EDD2623E2@hg.openjdk.java.net>

Changeset: d6d8aeb2c2d4
Author:    amurillo
Date:      2013-10-19 08:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d6d8aeb2c2d4

8026928: new hotspot build - hs25-b56
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 384c92148c68
Author:    amurillo
Date:      2013-10-21 14:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/384c92148c68

8023496: [jprt] build and test solaris 64-bits only
Reviewed-by: tbell, jcoomes

! make/jprt.properties

Changeset: f9d4ed6c88dd
Author:    dholmes
Date:      2013-10-21 20:51 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f9d4ed6c88dd

8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles
Reviewed-by: sla, sspitsyn

! test/TEST.groups

Changeset: 8cd1abf3ecab
Author:    dholmes
Date:      2013-10-21 21:06 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8cd1abf3ecab

Merge

- src/share/vm/memory/metablock.cpp
- src/share/vm/memory/metablock.hpp
! test/TEST.groups
- test/compiler/8013496/Test8013496.sh
- test/gc/7168848/HumongousAlloc.java

Changeset: 2036c97e3af0
Author:    dholmes
Date:      2013-10-21 22:36 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2036c97e3af0

Merge


Changeset: 7fe6ef09d242
Author:    farvidsson
Date:      2013-10-16 09:20 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7fe6ef09d242

8025638: jmap returns 0 instead of 1 when it fails.
Summary: Re-factored some code handling return values and fails/errors during tool execution.
Reviewed-by: sla, kevinw
Contributed-by: fredrik.arvidsson at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java
! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java
! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java
! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java
! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java

Changeset: 042cf42c72bd
Author:    simonis
Date:      2013-10-16 15:06 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/042cf42c72bd

8026703: Wrongly placed <xsl:import> element in Event-Based JVM Tracing .xsl files
Reviewed-by: sla, kamg

! src/share/vm/trace/traceEventClasses.xsl
! src/share/vm/trace/traceEventIds.xsl
! src/share/vm/trace/traceTypes.xsl

Changeset: d248425bcfe8
Author:    hseigel
Date:      2013-10-16 14:32 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d248425bcfe8

8024804: Crash when InterfaceMethodref resolves to Object.registerNatives
Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods.
Reviewed-by: coleenp, hseigel
Contributed-by: lois.foltan at oracle.com

! src/share/vm/interpreter/linkResolver.cpp
+ test/runtime/8024804/RegisterNatives.java

Changeset: 9e0ef3f02648
Author:    hseigel
Date:      2013-10-16 15:26 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9e0ef3f02648

Merge


Changeset: 1bee3014cf2a
Author:    dsamersoff
Date:      2013-10-17 16:08 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1bee3014cf2a

8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file
Summary: Coredump store memsz elf field rounded up to page
Reviewed-by: dholmes, sla

! agent/src/os/linux/ps_core.c

Changeset: ffb471203842
Author:    erikj
Date:      2013-10-17 16:11 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ffb471203842

8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated.
Reviewed-by: dholmes, sla

! make/windows/makefiles/trace.make

Changeset: ad8e901ca2e1
Author:    sla
Date:      2013-10-17 12:15 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ad8e901ca2e1

Merge


Changeset: d2db09f281ca
Author:    dsamersoff
Date:      2013-10-17 16:45 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d2db09f281ca

8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data
Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime.  Serviceability agent support was updated for this data
Reviewed-by: coleenp, minqi, sla
Contributed-by: eric.mccorkle at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! src/share/vm/runtime/vmStructs.cpp

Changeset: b942ac65ac86
Author:    dsamersoff
Date:      2013-10-17 17:01 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b942ac65ac86

Merge


Changeset: d0453d2fd045
Author:    dsamersoff
Date:      2013-10-18 10:37 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d0453d2fd045

Merge


Changeset: ee99e1a7c5fb
Author:    ccheung
Date:      2013-10-18 19:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ee99e1a7c5fb

Merge

! src/share/vm/interpreter/linkResolver.cpp
- src/share/vm/memory/metablock.cpp
- src/share/vm/memory/metablock.hpp
! src/share/vm/runtime/vmStructs.cpp
- test/compiler/8013496/Test8013496.sh
- test/gc/7168848/HumongousAlloc.java

Changeset: 996d1f2f056f
Author:    dsamersoff
Date:      2013-10-19 21:29 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/996d1f2f056f

8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part)
Summary: Pass one more property from Agent to JdpController
Reviewed-by: jbachorik, sla

! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp

Changeset: 1327b7f85503
Author:    ccheung
Date:      2013-10-21 17:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1327b7f85503

Merge


Changeset: 662c154d2749
Author:    hseigel
Date:      2013-10-22 14:47 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/662c154d2749

8026394: Eclipse fails with JDK8 build 111
Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object.  With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE.
Reviewed-by: acorn, dholmes
Contributed-by: lois.foltan at oracle.com

! src/share/vm/interpreter/linkResolver.cpp
+ test/runtime/8026394/InterfaceObjectTest.java

Changeset: b8860472c377
Author:    iklam
Date:      2013-10-22 14:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b8860472c377

8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread
Summary: Revert changes in JDK-8008962
Reviewed-by: coleenp, sspitsyn

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvmtiEnv.cpp

Changeset: 28be4c586b70
Author:    iklam
Date:      2013-10-22 16:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/28be4c586b70

Merge


Changeset: a997d762fa20
Author:    hseigel
Date:      2013-10-22 15:54 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a997d762fa20

8026809: [TESTBUG] Create regression test for JDK-8026041
Summary: Created simple regression test for the bug
Reviewed-by: hseigel, lfoltan, zgu
Contributed-by: mikhailo.seledtsov at oracle.com

+ test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java

Changeset: c183576a2dd1
Author:    hseigel
Date:      2013-10-22 22:14 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c183576a2dd1

Merge


Changeset: b658cfe35857
Author:    farvidsson
Date:      2013-10-23 10:24 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b658cfe35857

8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value
Summary: Fixes a bug with vmArgs when using JDKToolLauncher
Reviewed-by: sla, dholmes

! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java

Changeset: b3a4d4279fa3
Author:    ccheung
Date:      2013-10-24 17:20 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b3a4d4279fa3

Merge


Changeset: 74e00b98d5dd
Author:    anoll
Date:      2013-10-17 19:47 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/74e00b98d5dd

8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation
Summary: Increase size for the template interpreter accordingly
Reviewed-by: kvn, twisti

! src/cpu/x86/vm/templateInterpreter_x86.hpp

Changeset: 1856ea98184a
Author:    adlertz
Date:      2013-10-18 10:50 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1856ea98184a

8022783: Nashorn test fails with: assert(!def_outside->member(r))
Summary: Enables private copies of inputs for recent spill copies as well
Reviewed-by: kvn, twisti

! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/reg_split.cpp

Changeset: e3b736cf4fa3
Author:    adlertz
Date:      2013-10-18 09:36 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e3b736cf4fa3

Merge


Changeset: 252d541466ea
Author:    morris
Date:      2013-10-18 12:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/252d541466ea

8008242: VerifyOops is broken on SPARC
Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp

Changeset: 3213ba4d3dff
Author:    roland
Date:      2013-10-19 12:16 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3213ba4d3dff

8024069: replace_in_map() should operate on parent maps
Summary: type information gets lost because replace_in_map() doesn't update parent maps
Reviewed-by: kvn, twisti

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/multnode.cpp
! src/share/vm/opto/multnode.hpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp

Changeset: 19c5a042b0b3
Author:    iignatyev
Date:      2013-10-19 21:54 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/19c5a042b0b3

8026414: [TESTBUG] Tests for Tiered/NonTiered levels
Reviewed-by: twisti, iveresov

+ test/compiler/tiered/CompLevelsTest.java
+ test/compiler/tiered/NonTieredLevelsTest.java
+ test/compiler/tiered/TieredLevelsTest.java

Changeset: 600c83f8e6a5
Author:    iignatyev
Date:      2013-10-19 21:54 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/600c83f8e6a5

8023318: compiler/whitebox tests timeout with enabled TieredCompilation
Reviewed-by: kvn, twisti

! test/compiler/whitebox/CompilerWhiteBoxTest.java

Changeset: e842cc2d2dfb
Author:    iveresov
Date:      2013-10-19 22:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e842cc2d2dfb

Merge


Changeset: 52575a17a36c
Author:    iignatyev
Date:      2013-10-21 09:21 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/52575a17a36c

8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions
Reviewed-by: twisti, iveresov

! test/compiler/print/PrintInlining.java

Changeset: 4748b3308cda
Author:    iveresov
Date:      2013-10-21 17:34 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4748b3308cda

Merge


Changeset: 5ccbab1c69f3
Author:    roland
Date:      2013-10-22 09:51 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5ccbab1c69f3

8026251: New type profiling points: parameters to methods
Summary: x86 interpreter and c1 type profiling for parameters on method entries
Reviewed-by: kvn, twisti

! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp
! src/cpu/x86/vm/globals_x86.hpp
+ src/cpu/x86/vm/interp_masm_x86.cpp
+ src/cpu/x86/vm/interp_masm_x86.hpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/register_definitions_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/templateTable.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp

Changeset: 435c7b4577cd
Author:    rbackman
Date:      2013-10-21 15:31 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/435c7b4577cd

8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here
Reviewed-by: iveresov, roland

! src/share/vm/opto/compile.cpp

Changeset: 36e17466dd39
Author:    rbackman
Date:      2013-10-22 14:02 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/36e17466dd39

Merge


Changeset: 8b4bbba322d3
Author:    anoll
Date:      2013-10-23 10:00 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8b4bbba322d3

8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified
Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper()
Reviewed-by: roland, iveresov

! src/share/vm/compiler/compileBroker.cpp

Changeset: b2ee5dc63353
Author:    roland
Date:      2013-10-23 12:40 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b2ee5dc63353

8024070: C2 needs some form of type speculation
Summary: record unused type profile information with type system, propagate and use it.
Reviewed-by: kvn, twisti

! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/arguments.cpp
+ test/compiler/types/TypeSpeculation.java

Changeset: 4c9115774c8e
Author:    adlertz
Date:      2013-10-23 10:44 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4c9115774c8e

8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL
Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor
Reviewed-by: roland, twisti

! src/share/vm/opto/reg_split.cpp

Changeset: 97d400662426
Author:    adlertz
Date:      2013-10-23 19:22 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/97d400662426

Merge


Changeset: 9acbfe04b5c3
Author:    iveresov
Date:      2013-10-23 11:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9acbfe04b5c3

8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64
Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator
Reviewed-by: twisti, jrose

! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LinearScan.cpp

Changeset: 1c90f0072f0d
Author:    twisti
Date:      2013-10-23 15:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1c90f0072f0d

8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Reviewed-by: iveresov, jrose

! src/share/vm/classfile/systemDictionary.cpp

Changeset: 3a04e444da6d
Author:    iveresov
Date:      2013-10-23 16:25 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3a04e444da6d

Merge


Changeset: 59e8ad757e19
Author:    rbackman
Date:      2013-10-18 10:41 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/59e8ad757e19

8026844: Various Math functions needs intrinsification
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/mathexactnode.cpp
! src/share/vm/opto/mathexactnode.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/vmStructs.cpp
+ test/compiler/intrinsics/mathexact/AddExactICondTest.java
+ test/compiler/intrinsics/mathexact/AddExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/AddExactILoadTest.java
+ test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java
+ test/compiler/intrinsics/mathexact/AddExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
+ test/compiler/intrinsics/mathexact/DecExactITest.java
+ test/compiler/intrinsics/mathexact/DecExactLTest.java
+ test/compiler/intrinsics/mathexact/IncExactITest.java
+ test/compiler/intrinsics/mathexact/IncExactLTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
+ test/compiler/intrinsics/mathexact/MulExactICondTest.java
+ test/compiler/intrinsics/mathexact/MulExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/MulExactILoadTest.java
+ test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java
+ test/compiler/intrinsics/mathexact/MulExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactILoadTest.java
+ test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java
+ test/compiler/intrinsics/mathexact/SubExactICondTest.java
+ test/compiler/intrinsics/mathexact/SubExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/SubExactILoadTest.java
+ test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java
+ test/compiler/intrinsics/mathexact/SubExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java
! test/compiler/intrinsics/mathexact/Verify.java

Changeset: 68f07c29521b
Author:    anoll
Date:      2013-10-15 08:38 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/68f07c29521b

8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice
Summary: Remove duplicate print
Reviewed-by: kvn, twisti

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

Changeset: d95eca175eff
Author:    sspitsyn
Date:      2013-10-23 20:15 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d95eca175eff

8023004: JSR 292: java.lang.RuntimeException: Original target method was called.
Reviewed-by: jrose

! src/share/vm/prims/methodHandles.cpp

Changeset: 0d1661d63d70
Author:    vlivanov
Date:      2013-10-23 20:20 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0d1661d63d70

8012941: JSR 292: too deep inlining might crash compiler because of stack overflow
Reviewed-by: kvn, twisti

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_globals.hpp

Changeset: f7d928a3181c
Author:    roland
Date:      2013-10-24 19:32 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f7d928a3181c

8026978: JSR292: fatal error: Type profiling not implemented on this platform
Summary: force TypeProfileLevel to 0 on non x86
Reviewed-by: twisti

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

Changeset: 395499125cb0
Author:    iveresov
Date:      2013-10-24 16:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/395499125cb0

Merge

- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 6b32b911d723
Author:    iveresov
Date:      2013-10-24 16:25 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6b32b911d723

Merge

! src/share/vm/runtime/vmStructs.cpp
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 1d1ea10fe09f
Author:    mgerdin
Date:      2013-10-15 13:56 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1d1ea10fe09f

8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it.
Summary: Chunk up the last piece of committed memory in a VSN when getting a new one.
Reviewed-by: stefank, jmasa

! src/share/vm/memory/metaspace.cpp
! src/share/vm/prims/jni.cpp

Changeset: 91a88c8450f4
Author:    mgerdin
Date:      2013-10-18 09:31 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/91a88c8450f4

8026698: Incorrect error handling in Metaspace::allocate
Reviewed-by: stefank, jwilhelm

! src/share/vm/memory/metaspace.cpp

Changeset: a1b05d4a6fd0
Author:    stefank
Date:      2013-10-21 09:34 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a1b05d4a6fd0

8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace
Reviewed-by: mgerdin, brutisso

+ test/gc/TestSystemGC.java

Changeset: 3dd24766da44
Author:    stefank
Date:      2013-10-21 01:04 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3dd24766da44

Merge


Changeset: 2fab5b7e6140
Author:    ehelin
Date:      2013-10-21 14:20 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2fab5b7e6140

8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops
Reviewed-by: coleenp, mgerdin, sspitsyn

! src/share/vm/prims/jvmtiImpl.cpp

Changeset: c7f403b05168
Author:    sjohanss
Date:      2013-10-22 11:50 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c7f403b05168

8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash
Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values.
Reviewed-by: stefank, ehelin

! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp

Changeset: 0823c8bac468
Author:    jcoomes
Date:      2013-10-22 12:03 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0823c8bac468

Merge


Changeset: 1b422ef5288a
Author:    tschatzl
Date:      2013-10-23 10:23 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1b422ef5288a

8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region
Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes.
Reviewed-by: iveresov, simonis, tschatzl
Contributed-by: Axel Siebenborn <axel.siebenborn at sap.com>

! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp

Changeset: 0dcdec729cda
Author:    jcoomes
Date:      2013-10-25 08:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0dcdec729cda

Merge


Changeset: 82a9cdbf683e
Author:    amurillo
Date:      2013-10-25 13:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/82a9cdbf683e

Merge

! src/share/vm/services/diagnosticCommand.cpp
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: bde83ddf920c
Author:    amurillo
Date:      2013-10-25 13:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bde83ddf920c

Added tag hs25-b56 for changeset 82a9cdbf683e

! .hgtags

Changeset: e006d2e25bc7
Author:    dholmes
Date:      2013-10-24 20:47 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e006d2e25bc7

8025673: [macosx] Disable X11 AWT toolkit
Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X
Reviewed-by: dholmes
Contributed-by: david.dehaven at oracle.com

! src/os/bsd/vm/os_bsd.cpp

Changeset: 913a35723a0a
Author:    katleman
Date:      2013-10-28 16:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/913a35723a0a

Merge


Changeset: 7fd913010dbb
Author:    katleman
Date:      2013-10-29 14:56 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7fd913010dbb

Merge


Changeset: d31bebcd5635
Author:    henryjen
Date:      2013-11-06 11:36 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d31bebcd5635

Merge

! .hgtags
- .jcheck/conf
! make/jprt.properties
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/globals.hpp


From henry.jen at oracle.com  Wed Nov  6 14:29:33 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 06 Nov 2013 22:29:33 +0000
Subject: hg: lambda/lambda/nashorn: 52 new changesets
Message-ID: <20131106223022.E00A6623E3@hg.openjdk.java.net>

Changeset: fc2b6885e60e
Author:    cl
Date:      2013-10-10 10:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/fc2b6885e60e

Added tag jdk8-b111 for changeset 75fd3486e584

! .hgtags

Changeset: 982dd6e1bf4f
Author:    lana
Date:      2013-09-27 18:38 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/982dd6e1bf4f

Merge


Changeset: 2016a6b9e1f3
Author:    hannesw
Date:      2013-09-27 16:59 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/2016a6b9e1f3

8025515: Performance issues with Source.getLine()
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/ir/LexicalContext.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/Source.java
+ test/script/basic/JDK-8025515.js

Changeset: 1809c9e97c71
Author:    hannesw
Date:      2013-09-27 17:00 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/1809c9e97c71

8025520: Array.prototype.slice should only copy defined elements
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8025520.js

Changeset: efc40aacaee4
Author:    hannesw
Date:      2013-09-30 15:54 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/efc40aacaee4

8025589: Array.prototype.shift should only copy defined elements in generic mode
Reviewed-by: sundar, attila

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8025589.js

Changeset: ad5f9ce2a95b
Author:    jlaskey
Date:      2013-09-30 10:24 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/ad5f9ce2a95b

Merge


Changeset: 787e36fdf69a
Author:    jlaskey
Date:      2013-09-30 12:06 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/787e36fdf69a

Merge


Changeset: 7272ec90f2c6
Author:    sundar
Date:      2013-09-30 21:33 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/7272ec90f2c6

8025629: load function should support a way to load scripts from classpath
Reviewed-by: lagergren, hannesw, attila

! make/build.xml
! src/jdk/nashorn/internal/runtime/Context.java
+ test/script/trusted/JDK-8025629.js
+ test/src/jdk/nashorn/internal/runtime/resources/load_test.js

Changeset: f5aefbe76cec
Author:    jlaskey
Date:      2013-09-30 18:09 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/f5aefbe76cec

8025689: fx:base.js classes not loading
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/resources/fx/base.js

Changeset: cd7fb58043cb
Author:    sundar
Date:      2013-10-01 14:38 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/cd7fb58043cb

8025488: Error.captureStackTrace should not format error stack
Reviewed-by: hannesw, attila

! src/jdk/nashorn/internal/objects/NativeError.java
+ test/script/basic/JDK-8025488.js
+ test/script/basic/JDK-8025488.js.EXPECTED

Changeset: 3470bc26128f
Author:    sundar
Date:      2013-10-04 16:21 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/3470bc26128f

8025771: Enhance Nashorn Contexts
Reviewed-by: jlaskey, hannesw

- make/java.security.override
! make/project.properties
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! test/script/basic/JDK-8023026.js
+ test/script/sandbox/arrayclass.js
+ test/script/sandbox/arrayclass.js.EXPECTED

Changeset: 6345d08fd5de
Author:    hannesw
Date:      2013-10-08 11:55 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/6345d08fd5de

8025213: Assignment marks variable as defined too early
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/nashorn/internal/codegen/Attr.java
+ test/script/basic/JDK-8025213.js
+ test/script/basic/JDK-8025213.js.EXPECTED

Changeset: 8c326f8c6799
Author:    sundar
Date:      2013-10-08 13:02 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/8c326f8c6799

8026033: Switch should load expression even when there are no cases in it
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8026033.js
+ test/script/basic/JDK-8026033.js.EXPECTED

Changeset: 025e2ff9e91b
Author:    hannesw
Date:      2013-10-08 13:11 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/025e2ff9e91b

8025965: Specialized functions with same weight replace each other in TreeSet
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/CompiledFunction.java

Changeset: 19dba6637f20
Author:    sundar
Date:      2013-10-08 14:57 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/19dba6637f20

8026039: future strict names are allowed as function name and argument name of a strict function
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/parser/AbstractParser.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/error/JDK-8026039.js
+ test/script/error/JDK-8026039.js.EXPECTED

Changeset: c9921761903b
Author:    hannesw
Date:      2013-10-08 15:53 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/c9921761903b

8026042: FoldConstants need to guard against ArrayLiteralNode
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
+ test/script/basic/JDK-8026042.js
+ test/script/basic/JDK-8026042.js.EXPECTED

Changeset: 346ba5b8a488
Author:    sundar
Date:      2013-10-08 16:46 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/346ba5b8a488

8026048: Function constructor should convert arguments to String before performing any syntax checks
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/objects/NativeFunction.java
+ test/script/basic/JDK-8026048.js

Changeset: 3551855c4f40
Author:    lana
Date:      2013-10-08 15:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/3551855c4f40

Merge

- make/java.security.override

Changeset: b48b719c5efc
Author:    lana
Date:      2013-10-11 03:09 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/b48b719c5efc

Merge

- make/java.security.override

Changeset: 45399f3ef717
Author:    ihse
Date:      2013-10-10 14:58 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/45399f3ef717

8001931: The new build system whitespace cleanup
Reviewed-by: tbell, simonis, erikj

! makefiles/BuildNashorn.gmk
! makefiles/Makefile

Changeset: 6a4fdb3bb4e3
Author:    katleman
Date:      2013-10-16 12:05 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/6a4fdb3bb4e3

Merge


Changeset: 103590fc1e0a
Author:    cl
Date:      2013-10-17 09:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/103590fc1e0a

Added tag jdk8-b112 for changeset 6a4fdb3bb4e3

! .hgtags

Changeset: 8d29733ad609
Author:    sundar
Date:      2013-10-09 10:47 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/8d29733ad609

8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8026112.js

Changeset: 1e03d7caa68b
Author:    sundar
Date:      2013-10-09 13:26 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/1e03d7caa68b

8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8026125.js

Changeset: ec3094d9d5d5
Author:    hannesw
Date:      2013-10-09 14:50 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/ec3094d9d5d5

8026008: Constant folding removes var statement
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/codegen/FoldConstants.java
+ test/script/basic/JDK-8026008.js
+ test/script/basic/JDK-8026008.js.EXPECTED

Changeset: 03a68e7ca1d5
Author:    lagergren
Date:      2013-10-09 17:53 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/03a68e7ca1d5

8026137: Fix Issues with Binary Evaluation Order
Reviewed-by: hannesw, jlaskey
Contributed-by: marcus.lagergren at oracle.com, attila.szegedi at oracle.com

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/BranchOptimizer.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/CompileUnit.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/WeighNodes.java
! src/jdk/nashorn/internal/codegen/types/BooleanType.java
! src/jdk/nashorn/internal/codegen/types/ObjectType.java
! src/jdk/nashorn/internal/codegen/types/Type.java
! src/jdk/nashorn/internal/ir/AccessNode.java
! src/jdk/nashorn/internal/ir/BaseNode.java
! src/jdk/nashorn/internal/ir/CallNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/IndexNode.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/ir/RuntimeNode.java
- src/jdk/nashorn/internal/ir/TypeOverride.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java
! src/jdk/nashorn/internal/parser/TokenType.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
+ test/script/basic/JDK-8026137.js
+ test/script/basic/JDK-8026137.js.EXPECTED

Changeset: 7cc5ff16380f
Author:    sundar
Date:      2013-10-10 11:48 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/7cc5ff16380f

8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases.
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/runtime/CodeInstaller.java
! src/jdk/nashorn/internal/runtime/Context.java
! test/script/assert.js
! test/script/basic/JDK-8019508.js
! test/script/basic/JDK-8019508.js.EXPECTED
! test/script/basic/JDK-8019553.js
! test/script/basic/JDK-8019553.js.EXPECTED
! test/script/basic/JDK-8019791.js
! test/script/basic/JDK-8019791.js.EXPECTED
! test/script/basic/JDK-8019805.js
! test/script/basic/JDK-8019805.js.EXPECTED
+ test/script/basic/JDK-8026167.js
! test/script/basic/NASHORN-100.js
! test/script/basic/NASHORN-100.js.EXPECTED
! test/script/basic/NASHORN-293.js
! test/script/basic/NASHORN-293.js.EXPECTED
! test/script/basic/NASHORN-40.js
! test/script/basic/NASHORN-40.js.EXPECTED
! test/script/basic/NASHORN-51.js
! test/script/basic/NASHORN-51.js.EXPECTED
! test/script/basic/NASHORN-98.js
! test/script/basic/NASHORN-98.js.EXPECTED
! test/script/basic/eval.js
! test/script/basic/eval.js.EXPECTED

Changeset: e60bbcf2f6b6
Author:    sundar
Date:      2013-10-10 13:17 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/e60bbcf2f6b6

8026248: importClass has to be a varargs function
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8026248.js
+ test/script/basic/JDK-8026248.js.EXPECTED

Changeset: f6263ae511c2
Author:    lana
Date:      2013-10-10 13:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/f6263ae511c2

Merge


Changeset: 34f7a699cdef
Author:    sundar
Date:      2013-10-10 14:43 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/34f7a699cdef

8026162: "this" in SAM adapter functions is wrong
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
+ test/script/basic/JDK-8026162.js

Changeset: ed3da7a574a0
Author:    lagergren
Date:      2013-10-10 16:16 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/ed3da7a574a0

8026250: Logging nullpointer bugfix and javadoc warnings
Reviewed-by: hannesw, jlaskey, sundar

! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeError.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/DebugLogger.java
! src/jdk/nashorn/internal/runtime/GlobalObject.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk/nashorn/internal/runtime/ScriptLoader.java
! src/jdk/nashorn/internal/runtime/WithObject.java

Changeset: a781ea074521
Author:    sundar
Date:      2013-10-10 21:43 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/a781ea074521

8026264: Getter, setter function name mangling issues
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
+ test/script/basic/JDK-8026264.js

Changeset: 375c2f2d41c8
Author:    sundar
Date:      2013-10-11 06:50 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/375c2f2d41c8

8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds
Reviewed-by: jlaskey

! test/script/basic/JDK-8025488.js

Changeset: 56be5161f0d2
Author:    sundar
Date:      2013-10-11 09:09 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/56be5161f0d2

Merge


Changeset: 1c154cee43d9
Author:    hannesw
Date:      2013-10-11 10:56 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/1c154cee43d9

8026292: Megamorphic setter fails with boolean value
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/codegen/MethodEmitter.java
+ test/script/basic/JDK-8026292.js

Changeset: fb091f9052a6
Author:    sundar
Date:      2013-10-11 11:15 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/fb091f9052a6

8026302: source representation of getter and setter methods is wrong
Reviewed-by: lagergren, hannesw, jlaskey

! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8026302.js
+ test/script/basic/JDK-8026302.js.EXPECTED
! test/script/basic/objects.js.EXPECTED

Changeset: 062579f50371
Author:    sundar
Date:      2013-10-11 14:11 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/062579f50371

8026317: $ in the function name results in wrong function being invoked
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/codegen/Namespace.java
+ test/script/basic/JDK-8026317.js
+ test/script/basic/JDK-8026317.js.EXPECTED

Changeset: b35d175207f6
Author:    sundar
Date:      2013-10-11 14:13 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/b35d175207f6

Merge


Changeset: 1b0a71a9920a
Author:    lana
Date:      2013-10-11 23:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/1b0a71a9920a

Merge


Changeset: 6cb4f20d971f
Author:    jlaskey
Date:      2013-10-11 14:54 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/6cb4f20d971f

8026309: latest runsunspider.js tests contains several bugs
Reviewed-by: sundar, lagergren
Contributed-by: james.laskey at oracle.com

! test/script/basic/runsunspider.js

Changeset: 8c617a092d68
Author:    hannesw
Date:      2013-10-14 11:45 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/8c617a092d68

8026016: too many relinks dominate avatar.js http benchmark
Reviewed-by: sundar, jlaskey, attila

! src/jdk/nashorn/internal/runtime/ScriptObject.java
+ test/script/basic/JDK-8026016.js
+ test/script/basic/JDK-8026016.js.EXPECTED

Changeset: d155c4a7703c
Author:    attila
Date:      2013-10-14 12:41 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/d155c4a7703c

8026113: Nashorn arrays should automatically convert to Java arrays
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
+ test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java

Changeset: 64e841576c68
Author:    attila
Date:      2013-10-15 15:57 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/64e841576c68

8026397: Fix ambiguity with array conversion, including passing JS NativeArrays in Java variable arity methods' vararg array position
Reviewed-by: jlaskey, sundar

! src/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk/internal/dynalink/support/Guards.java
! src/jdk/internal/dynalink/support/messages.properties
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java

Changeset: aa452eb4a5d0
Author:    hannesw
Date:      2013-10-15 17:37 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/aa452eb4a5d0

8026367: Add a sync keyword to mozilla_compat
Reviewed-by: sundar, attila, lagergren

! src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8026367.js
! test/script/sandbox/loadcompat.js

Changeset: b3ee112a328e
Author:    jlaskey
Date:      2013-10-15 13:14 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/b3ee112a328e

8026498: Revert: latest runsunspider.js tests contains several bugs
Reviewed-by: sundar, hannesw
Contributed-by: james.laskey at oracle.com

! test/script/basic/runsunspider.js

Changeset: 9a13e95cc40f
Author:    sundar
Date:      2013-10-15 22:13 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/9a13e95cc40f

Merge


Changeset: 1899da5c71d3
Author:    hannesw
Date:      2013-10-16 10:12 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/1899da5c71d3

8026692: eval() throws NullPointerException with --compile-only
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/Lower.java
+ test/script/basic/JDK-8026692.js

Changeset: 2d5f9f77c199
Author:    hannesw
Date:      2013-10-16 10:15 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/2d5f9f77c199

8026693: getType() called on DISCARD node
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/codegen/BranchOptimizer.java
+ test/script/basic/JDK-8026693.js

Changeset: adc5639fc4b9
Author:    sundar
Date:      2013-10-17 13:02 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/adc5639fc4b9

Merge


Changeset: 676cd7bf5e09
Author:    lana
Date:      2013-10-17 16:19 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/676cd7bf5e09

Merge


Changeset: 79f7b79bf97b
Author:    cl
Date:      2013-10-24 09:10 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/79f7b79bf97b

Added tag jdk8-b113 for changeset 676cd7bf5e09

! .hgtags

Changeset: 9bf2e9c6bd55
Author:    henryjen
Date:      2013-11-06 11:38 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/9bf2e9c6bd55

Merge

- .jcheck/conf


From henry.jen at oracle.com  Tue Nov 12 00:09:06 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:09:06 +0000
Subject: hg: lambda/lambda: 31 new changesets
Message-ID: <20131112080908.6695E62525@hg.openjdk.java.net>

Changeset: b65d48f6938a
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/b65d48f6938a

Added tag jdk8-b114 for changeset 4f2011496393

! .hgtags

Changeset: 3dc55f0c1b6f
Author:    jlaskey
Date:      2013-01-28 16:29 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/3dc55f0c1b6f

8006676: Integrate Nashorn into new build system
Reviewed-by: jlaskey
Contributed-by: james.laskey at oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/bin/compare.sh
! common/makefiles/Main.gmk
! common/makefiles/MakeBase.gmk
+ make/nashorn-rules.gmk
! make/scripts/hgforest.sh

Changeset: ecd447139a39
Author:    jlaskey
Date:      2013-02-04 17:30 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/ecd447139a39

Merge

! common/autoconf/generated-configure.sh

Changeset: 9ed388a04fa7
Author:    jlaskey
Date:      2013-02-06 13:37 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/9ed388a04fa7

8007666: nashorn missing from hgforest.sh
Reviewed-by: jlaskey
Contributed-by: james.laskey at oracle.com

! common/bin/hgforest.sh

Changeset: 8b19b55f695d
Author:    jlaskey
Date:      2013-02-18 19:01 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/8b19b55f695d

8008420: Fix Nashorn forest to build with NEWBUILD=false
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! Makefile
! make/nashorn-rules.gmk

Changeset: f9a1cb245484
Author:    jlaskey
Date:      2013-02-19 10:02 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/f9a1cb245484

8008446: Tweaks to make all NEWBUILD=false round 2
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! make/Defs-internal.gmk

Changeset: 887fde71977e
Author:    jlaskey
Date:      2013-02-21 15:25 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/887fde71977e

8008447: Tweaks to make all NEWBUILD=false round 3
Reviewed-by: jjh, sundar
Contributed-by: james.laskey at oracle.com

! make/jdk-rules.gmk
! make/sanity-rules.gmk

Changeset: e877cb3eb4d6
Author:    jlaskey
Date:      2013-02-22 13:09 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/e877cb3eb4d6

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 528a9984198f
Author:    jlaskey
Date:      2013-02-22 22:58 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/528a9984198f

8008774: nashorn missing from dependencies after merge with tl
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! common/makefiles/Main.gmk

Changeset: 13ddc5c3ebfc
Author:    jlaskey
Date:      2013-03-02 10:28 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/13ddc5c3ebfc

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk
! make/nashorn-rules.gmk

Changeset: 1d38d30196be
Author:    jlaskey
Date:      2013-03-08 14:44 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/1d38d30196be

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: b938d5ee29c3
Author:    jlaskey
Date:      2013-03-15 11:50 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/b938d5ee29c3

Merge


Changeset: fe5a388bf8fe
Author:    jlaskey
Date:      2013-03-26 09:13 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/fe5a388bf8fe

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 1378ccca1c79
Author:    jlaskey
Date:      2013-04-09 08:35 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/1378ccca1c79

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 8a7e97848471
Author:    jlaskey
Date:      2013-04-15 08:06 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/8a7e97848471

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 6316aefcf716
Author:    jlaskey
Date:      2013-04-17 08:47 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/6316aefcf716

Merge


Changeset: dd81e9b5fb38
Author:    jlaskey
Date:      2013-04-22 13:59 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/dd81e9b5fb38

Merge


Changeset: 431d16ddfcd9
Author:    jlaskey
Date:      2013-04-29 21:37 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/431d16ddfcd9

Merge


Changeset: 1fca390200c1
Author:    jlaskey
Date:      2013-05-14 09:04 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/1fca390200c1

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 67b5cbe55744
Author:    jlaskey
Date:      2013-05-23 09:48 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/67b5cbe55744

Merge


Changeset: de886178f8e6
Author:    jlaskey
Date:      2013-06-05 13:08 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/de886178f8e6

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: 520fd54a7c43
Author:    jlaskey
Date:      2013-07-16 09:08 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/520fd54a7c43

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 67dc3d7d5b5f
Author:    jlaskey
Date:      2013-07-24 08:23 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/67dc3d7d5b5f

Merge

! common/autoconf/generated-configure.sh

Changeset: 96f207364e46
Author:    jlaskey
Date:      2013-08-27 16:05 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/96f207364e46

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: ddf76977d04a
Author:    jlaskey
Date:      2013-09-13 10:14 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/ddf76977d04a

Merge

! common/autoconf/generated-configure.sh
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 8b92b08993a8
Author:    jlaskey
Date:      2013-09-30 10:23 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/8b92b08993a8

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: d832f6171acd
Author:    jlaskey
Date:      2013-10-29 11:48 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/d832f6171acd

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 067355edfbf8
Author:    vinnie
Date:      2013-10-30 17:31 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/067355edfbf8

8027567: JDK 8 build failure: the correct version of GNU make is being rejected
Reviewed-by: chegar, erikj

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh

Changeset: 37d2736caf46
Author:    lana
Date:      2013-10-30 13:41 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/37d2736caf46

Merge

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: 763ada2a1d8c
Author:    lana
Date:      2013-10-31 16:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/763ada2a1d8c

Merge


Changeset: c1c8b46008c1
Author:    henryjen
Date:      2013-11-11 23:14 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/rev/c1c8b46008c1

Merge

! .hgtags
- .jcheck/conf
! common/autoconf/generated-configure.sh
! common/bin/hgforest.sh
! common/makefiles/Main.gmk


From henry.jen at oracle.com  Tue Nov 12 00:09:44 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:09:44 +0000
Subject: hg: lambda/lambda/jaxws: 2 new changesets
Message-ID: <20131112080950.35F6162527@hg.openjdk.java.net>

Changeset: e126d8eca69b
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/e126d8eca69b

Added tag jdk8-b114 for changeset 9ad289610fc6

! .hgtags

Changeset: 747894ce3b42
Author:    henryjen
Date:      2013-11-11 23:15 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/747894ce3b42

Merge

! .hgtags
- .jcheck/conf


From henry.jen at oracle.com  Tue Nov 12 00:09:16 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:09:16 +0000
Subject: hg: lambda/lambda/jaxp: 7 new changesets
Message-ID: <20131112080932.E44D962526@hg.openjdk.java.net>

Changeset: d3b6da1b3e25
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/d3b6da1b3e25

Added tag jdk8-b114 for changeset 1b1e12117fe2

! .hgtags

Changeset: 390e94b9a852
Author:    joehw
Date:      2013-10-24 13:43 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/390e94b9a852

8004476: XSLT Extension Functions Don't Work in WebStart
Reviewed-by: dfuchs, lancea, alanb

! src/com/sun/org/apache/xalan/internal/XalanConstants.java
+ src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java
+ src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java
! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java
! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java
! src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Compile.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java
! src/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java
! src/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java
! src/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java

Changeset: 96562bf197f2
Author:    lana
Date:      2013-10-28 12:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/96562bf197f2

Merge


Changeset: 1af33ab1bc58
Author:    joehw
Date:      2013-10-29 14:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/1af33ab1bc58

8027484: Implementation error in SAX2DOM.java
Reviewed-by: alanb, lancea

! src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java

Changeset: 04778b00286a
Author:    joehw
Date:      2013-10-30 08:58 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/04778b00286a

8024378: StAX parser shall support JAXP properties
Reviewed-by: dfuchs, lancea

! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java

Changeset: f610fd46463e
Author:    lana
Date:      2013-10-31 16:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/f610fd46463e

Merge


Changeset: 1e7e1aab8067
Author:    henryjen
Date:      2013-11-11 23:15 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/1e7e1aab8067

Merge

! .hgtags
- .jcheck/conf


From henry.jen at oracle.com  Tue Nov 12 00:10:06 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:10:06 +0000
Subject: hg: lambda/lambda/nashorn: 30 new changesets
Message-ID: <20131112081037.B506662528@hg.openjdk.java.net>

Changeset: f109bb255b80
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/f109bb255b80

Added tag jdk8-b114 for changeset 79f7b79bf97b

! .hgtags

Changeset: b01a10c7c7c2
Author:    attila
Date:      2013-10-17 12:38 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/b01a10c7c7c2

8026161: Don't narrow floating-point literals in the lexer
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/parser/Lexer.java
! src/jdk/nashorn/internal/runtime/JSType.java
+ test/script/basic/JDK-8026161.js
+ test/script/basic/JDK-8026161.js.EXPECTED
! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java

Changeset: a2065f67857c
Author:    hannesw
Date:      2013-10-17 17:33 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/a2065f67857c

8026701: Array.prototype.splice is slow on dense arrays
Reviewed-by: lagergren, sundar, jlaskey

! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java
! test/examples/array-micro.js
+ test/script/basic/JDK-8026701.js
+ test/script/basic/JDK-8026701.js.EXPECTED

Changeset: 66d27c77b455
Author:    hannesw
Date:      2013-10-18 12:50 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/66d27c77b455

8026805: Array.prototype.length doesn't work as expected
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeJSAdapter.java
+ test/script/basic/JDK-8026805.js

Changeset: b5b4c98b072b
Author:    sundar
Date:      2013-10-18 18:26 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/b5b4c98b072b

Merge


Changeset: d8aa87d292eb
Author:    hannesw
Date:      2013-10-18 22:42 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/d8aa87d292eb

8026858: Array length does not handle defined properties correctly
Reviewed-by: jlaskey

! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
+ test/script/basic/JDK-8026858.js

Changeset: 612886fe324d
Author:    sundar
Date:      2013-10-21 10:09 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/612886fe324d

Merge


Changeset: f22742d5daa3
Author:    kshefov
Date:      2013-10-21 13:31 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/f22742d5daa3

8026871: NASHORN TEST: Enable possibility to test Nashorn use of JavaFX canvas.
Reviewed-by: jlaskey, sundar

! make/build.xml
! make/project.properties
+ test/script/jfx.js
+ test/script/jfx/flyingimage.js
+ test/script/jfx/flyingimage/flyingimage.png
+ test/script/jfx/flyingimage/golden/linux.png
+ test/script/jfx/flyingimage/golden/macosx.png
+ test/script/jfx/flyingimage/golden/windows.png
+ test/script/jfx/kaleidoscope.js
+ test/script/jfx/kaleidoscope/golden/linux.png
+ test/script/jfx/kaleidoscope/golden/macosx.png
+ test/script/jfx/kaleidoscope/golden/windows.png

Changeset: d8d5b7919c57
Author:    sundar
Date:      2013-10-22 14:27 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/d8d5b7919c57

8027016: Array.prototype.indexOf should return -1 when array is of length zero
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8027016.js

Changeset: 6d339d98074e
Author:    hannesw
Date:      2013-10-22 11:12 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/6d339d98074e

8027015: AutoCloseable no longer implements @FunctionalInterface
Reviewed-by: lagergren, sundar

! test/script/basic/NASHORN-397.js

Changeset: d24a4fabdce1
Author:    hannesw
Date:      2013-10-22 11:31 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/d24a4fabdce1

8026955: for-in should convert primitive values to object
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
+ test/script/basic/JDK-8026955.js
+ test/script/basic/JDK-8026955.js.EXPECTED

Changeset: 360761288b38
Author:    sundar
Date:      2013-10-22 17:38 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/360761288b38

8027024: String.prototype.charAt and charCodeAt do not evaluate 'self' and 'pos' arguments in right order
Reviewed-by: jlaskey, attila, lagergren

! src/jdk/nashorn/internal/objects/NativeString.java
! src/overview.html
+ test/script/basic/JDK-8027024.js
+ test/script/basic/JDK-8027024.js.EXPECTED

Changeset: d04028e6b624
Author:    sundar
Date:      2013-10-22 17:47 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/d04028e6b624

Merge


Changeset: 0ecbc0188b64
Author:    attila
Date:      2013-10-22 16:43 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/0ecbc0188b64

8027031: complete merging of loads and converts
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/codegen/BranchOptimizer.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java

Changeset: 6f19eb443a47
Author:    attila
Date:      2013-10-22 17:52 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/6f19eb443a47

8027037: Make ScriptObjectMirror conversions work for any JSObject
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java

Changeset: eae4e4c1f613
Author:    sundar
Date:      2013-10-22 22:04 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/eae4e4c1f613

8027020: [regression] java.lang.VerifyError: Bad type on operand stack
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/runtime/ScriptLoader.java

Changeset: 734f71f8a2c3
Author:    sundar
Date:      2013-10-22 22:12 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/734f71f8a2c3

Merge


Changeset: 5df55690fd5b
Author:    sundar
Date:      2013-10-23 17:30 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/5df55690fd5b

8027128: jdk.nashorn.api.scripting.JSObject should be an interface
Reviewed-by: hannesw, attila, jlaskey

+ src/jdk/nashorn/api/scripting/AbstractJSObject.java
! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! test/script/basic/JDK-8024847.js
! test/script/basic/JDK-8024847.js.EXPECTED
! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java
! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java

Changeset: f31ee3a2847d
Author:    sundar
Date:      2013-10-23 20:15 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/f31ee3a2847d

8027150: ScriptObjectListAdapter won't work as expected
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/runtime/ListAdapter.java
- src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java

Changeset: 640c1854f742
Author:    sundar
Date:      2013-10-23 20:21 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/640c1854f742

Merge

- src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java

Changeset: 767e85d2a1b3
Author:    lana
Date:      2013-10-28 12:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/767e85d2a1b3

Merge


Changeset: 7985ec3782b5
Author:    hannesw
Date:      2013-10-25 10:20 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/7985ec3782b5

8027042: Evaluation order for binary operators can be improved
Reviewed-by: lagergren, jlaskey, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/types/Type.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/Expression.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/ir/TernaryNode.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
+ test/script/basic/JDK-8027042.js
+ test/script/basic/JDK-8027042.js.EXPECTED

Changeset: 71cfb21c68dc
Author:    hannesw
Date:      2013-10-25 15:21 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/71cfb21c68dc

8027301: Optimizations for Function.prototype.apply
Reviewed-by: jlaskey

! src/jdk/nashorn/internal/runtime/CompiledFunctions.java
! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java

Changeset: 406f2b672937
Author:    jlaskey
Date:      2013-10-29 10:40 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/406f2b672937

Merge


Changeset: adab2c628923
Author:    jlaskey
Date:      2013-10-29 14:22 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/adab2c628923

8027447: The wrong string buffer is specified for stderr in $EXEC
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java

Changeset: 645197151cc3
Author:    jlaskey
Date:      2013-10-30 11:28 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/645197151cc3

8027532: nashorn should only use jdk8 apis in the compact1 profile
Reviewed-by: sundar, lagergren, hannesw
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java

Changeset: a002c1bb88f9
Author:    sundar
Date:      2013-10-30 20:09 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/a002c1bb88f9

8027562: eval should load second and subsequent arguments for side effect
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8027562.js
+ test/script/basic/JDK-8027562.js.EXPECTED

Changeset: 5ce78473d6c3
Author:    sundar
Date:      2013-10-31 12:50 +0530
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/5ce78473d6c3

Merge


Changeset: f0d3ac2474ee
Author:    lana
Date:      2013-10-31 16:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/f0d3ac2474ee

Merge

- src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java

Changeset: c52d26fd783a
Author:    henryjen
Date:      2013-11-11 23:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/nashorn/rev/c52d26fd783a

Merge

- .jcheck/conf


From henry.jen at oracle.com  Tue Nov 12 00:10:58 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:10:58 +0000
Subject: hg: lambda/lambda/corba: 3 new changesets
Message-ID: <20131112081101.5F32E62529@hg.openjdk.java.net>

Changeset: d425685e0b74
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/d425685e0b74

Added tag jdk8-b114 for changeset 0bbccf77c23e

! .hgtags

Changeset: 8d07115924b7
Author:    lana
Date:      2013-10-31 16:30 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/8d07115924b7

Merge


Changeset: 09289077333f
Author:    henryjen
Date:      2013-11-11 23:15 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/corba/rev/09289077333f

Merge

! .hgtags
- .jcheck/conf


From henry.jen at oracle.com  Tue Nov 12 00:11:15 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:11:15 +0000
Subject: hg: lambda/lambda/hotspot: 38 new changesets
Message-ID: <20131112081235.A06AC6252A@hg.openjdk.java.net>

Changeset: ddc3758f68db
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ddc3758f68db

Added tag jdk8-b114 for changeset 7fd913010dbb

! .hgtags

Changeset: ea1b8c643fc8
Author:    lana
Date:      2013-10-30 13:43 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ea1b8c643fc8

Merge

- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 205834867346
Author:    lana
Date:      2013-10-31 16:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/205834867346

Merge


Changeset: f94a9f0746d8
Author:    amurillo
Date:      2013-10-25 13:43 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f94a9f0746d8

8027173: new hotspot build - hs25-b57
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: e64f1fe9756b
Author:    farvidsson
Date:      2013-10-24 10:02 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e64f1fe9756b

8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes
Summary: Rewrite of the getLoadedClasses() method implementation to include anonymous classes.
Reviewed-by: coleenp, sspitsyn

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/prims/jvmtiGetLoadedClasses.cpp

Changeset: d70a665e25d7
Author:    iklam
Date:      2013-10-24 22:19 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d70a665e25d7

8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size
Summary: Use hard-coded DEFAULT_MAIN_THREAD_STACK_PAGES = 2048 for 10.9
Reviewed-by: dcubed, iveresov
Contributed-by: gerard.ziemski at oracle.com

! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp

Changeset: e4f478e7781b
Author:    jbachorik
Date:      2013-10-25 09:07 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e4f478e7781b

8027294: Prepare hotspot for non TOD based uptime counter
Summary: Use HR timer when available for os::elapsed_counter() on linux/bsd. Add a new counter for the JVM uptime.
Reviewed-by: dholmes, sla

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/share/vm/services/jmm.h
! src/share/vm/services/management.cpp

Changeset: a6177f601c64
Author:    hseigel
Date:      2013-10-25 11:05 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a6177f601c64

8026822: metaspace/flags/maxMetaspaceSize throws OOM of unexpected type.java.lang.OutOfMemoryError: Compressed class space
Summary: Incorporate chunk size when seeing if OutOfMemoryError was caused by Metaspace or Compressed class space.
Reviewed-by: stefank, coleenp

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp

Changeset: 634715d59d9e
Author:    hseigel
Date:      2013-10-25 11:13 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/634715d59d9e

Merge


Changeset: 209aa13ab8c0
Author:    coleenp
Date:      2013-10-25 15:19 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/209aa13ab8c0

8024927: Nashorn performance regression with CompressedOops
Summary: Allocate compressed class space at end of Java heap.  For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops
Reviewed-by: stefank, hseigel, goetz

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/runtime/CompressedOops/CompressedClassPointers.java

Changeset: b4aa8fc5d0d5
Author:    ccheung
Date:      2013-10-25 22:06 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b4aa8fc5d0d5

Merge

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/share/vm/memory/metaspace.cpp
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 1a04de1aaedb
Author:    dsamersoff
Date:      2013-10-28 21:41 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1a04de1aaedb

8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot
Summary: Fixed two compilation-breaking nits
Reviewed-by: sla, dholmes

! agent/src/os/bsd/ps_proc.c

Changeset: 85730a185147
Author:    ccheung
Date:      2013-10-30 14:02 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/85730a185147

Merge


Changeset: 292050e5d5ea
Author:    dholmes
Date:      2013-10-24 00:33 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/292050e5d5ea

8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build
Reviewed-by: coleenp, twisti

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/runtime/thread.cpp

Changeset: 066778844ed9
Author:    jprovino
Date:      2013-10-27 14:11 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/066778844ed9

Merge


Changeset: f2f9139ccde9
Author:    jprovino
Date:      2013-10-30 16:06 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f2f9139ccde9

Merge


Changeset: a007575ea726
Author:    vladidan
Date:      2013-10-30 16:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a007575ea726

Merge


Changeset: 3b3133d93fb6
Author:    brutisso
Date:      2013-10-28 13:27 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3b3133d93fb6

8027132: Print deprecation warning message for the flags controlling the CMS foreground collector
Reviewed-by: stefank, ehelin, ysr, tschatzl

! src/share/vm/runtime/arguments.cpp
+ test/gc/startup_warnings/TestCMSForegroundFlags.java

Changeset: 6d965678f21e
Author:    ehelin
Date:      2013-10-31 21:20 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6d965678f21e

Merge


Changeset: bd3237e0e18d
Author:    twisti
Date:      2013-10-24 16:23 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bd3237e0e18d

8026328: Setting a breakpoint on invokedynamic crashes the JVM
Reviewed-by: jrose, roland

! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/globals_zero.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/cppInterpreter.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/handles.cpp

Changeset: cbe8ba0fb8fc
Author:    twisti
Date:      2013-10-24 16:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cbe8ba0fb8fc

Merge

- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: f01788f13696
Author:    adlertz
Date:      2013-10-25 10:13 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f01788f13696

8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc
Summary: Remove input to junk phi if they also become dead during post_allocate_copy_removal
Reviewed-by: roland

! src/share/vm/opto/postaloc.cpp

Changeset: 7ae254fd0b3c
Author:    adlertz
Date:      2013-10-25 12:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7ae254fd0b3c

Merge


Changeset: 6c2f07d1495f
Author:    roland
Date:      2013-10-28 09:58 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6c2f07d1495f

8027140: Assertion in compiler when running bigapps/Kitchensink/stability
Summary: filter() code for TypeKlassPtr not moved when permgen removal was introduced
Reviewed-by: twisti, iveresov

! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp

Changeset: bfdb530cdffa
Author:    roland
Date:      2013-10-28 12:21 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bfdb530cdffa

Merge


Changeset: a196f1aaec86
Author:    anoll
Date:      2013-10-25 22:57 +0200
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a196f1aaec86

8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers)
Summary: Exit compiler threads early during startup so that wrong error message is not printed
Reviewed-by: iveresov, twisti

! src/share/vm/compiler/compileBroker.cpp
+ test/compiler/startup/StartupOutput.java

Changeset: 8c16f426dbb2
Author:    iveresov
Date:      2013-10-28 15:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8c16f426dbb2

Merge


Changeset: fc1632f5021a
Author:    iveresov
Date:      2013-10-28 17:32 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fc1632f5021a

Merge


Changeset: a57a165b8296
Author:    rbackman
Date:      2013-10-28 08:34 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a57a165b8296

8027353: Exact intrinsics: assert(n != NULL) failed: must not be null
Reviewed-by: kvn, roland

! src/share/vm/opto/library_call.cpp
! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java
! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java

Changeset: 60a32bb8ff99
Author:    rbackman
Date:      2013-10-30 13:14 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/60a32bb8ff99

8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1
Reviewed-by: duke

! src/share/vm/opto/loopTransform.cpp
+ test/compiler/intrinsics/mathexact/NestedMathExactTest.java

Changeset: 4d3575d37a07
Author:    iveresov
Date:      2013-10-30 22:55 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4d3575d37a07

8026735: Stream tests throw java.lang.IncompatibleClassChangeError
Summary: Put a band-aid to disable CHA-based inlining for interfaces with default methods in C1
Reviewed-by: kvn, twisti

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciInstanceKlass.hpp
+ test/compiler/inlining/InlineDefaultMethod.java

Changeset: 946a8294ab15
Author:    iveresov
Date:      2013-10-31 04:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/946a8294ab15

8024919: G1: SPECjbb2013 crashes due to a broken object reference
Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic
Reviewed-by: kvn, roland

! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp

Changeset: 2dcd0bd2920d
Author:    iveresov
Date:      2013-10-31 14:54 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2dcd0bd2920d

Merge


Changeset: 0836a3c28c6a
Author:    iveresov
Date:      2013-10-31 15:04 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0836a3c28c6a

Merge


Changeset: 3b32d287da89
Author:    amurillo
Date:      2013-11-01 08:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3b32d287da89

Merge

! src/os/bsd/vm/os_bsd.cpp

Changeset: afd012c940e4
Author:    amurillo
Date:      2013-11-01 08:26 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/afd012c940e4

Added tag hs25-b57 for changeset 3b32d287da89

! .hgtags

Changeset: 9ebaac78a8a0
Author:    amurillo
Date:      2013-11-05 14:06 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9ebaac78a8a0

Merge


Changeset: fc7177e457bf
Author:    henryjen
Date:      2013-11-11 23:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fc7177e457bf

Merge

! .hgtags
- .jcheck/conf
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/method.cpp


From henry.jen at oracle.com  Tue Nov 12 00:13:04 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:13:04 +0000
Subject: hg: lambda/lambda/langtools: 6 new changesets
Message-ID: <20131112081329.082EF6252B@hg.openjdk.java.net>

Changeset: fea486d30d41
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/fea486d30d41

Added tag jdk8-b114 for changeset 850d2602ae98

! .hgtags

Changeset: aa91bc6e8480
Author:    mchung
Date:      2013-10-30 08:35 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/aa91bc6e8480

8027481: jdeps to handle classes with the same package name and correct profile for javax.crypto.*
Reviewed-by: alanb, dfuchs

! src/share/classes/com/sun/tools/jdeps/Analyzer.java
! src/share/classes/com/sun/tools/jdeps/Archive.java
! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/share/classes/com/sun/tools/jdeps/Profile.java
! test/tools/jdeps/Basic.java
! test/tools/jdeps/Test.java
+ test/tools/jdeps/javax/activity/NotCompactProfile.java
+ test/tools/jdeps/p/Bar.java

Changeset: 537fa895fd74
Author:    vromero
Date:      2013-10-30 18:09 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/537fa895fd74

8027327: jar files related to test test/tools/javac/ExtDirs/ExtDirTest.java should be removed from the repo
Reviewed-by: ksrini

! test/tools/javac/ExtDirs/ExtDirTest.java
- test/tools/javac/ExtDirs/ext1/pkg1.jar
- test/tools/javac/ExtDirs/ext2/pkg2.jar
- test/tools/javac/ExtDirs/ext3/pkg1.jar
- test/tools/javac/ExtDirs/ext3/pkg2.jar

Changeset: 62a67e0875ff
Author:    briangoetz
Date:      2013-10-30 14:12 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/62a67e0875ff

8024930: Re-enable disabled bridging tests
Reviewed-by: psandoz, rfield

! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

Changeset: 6b4d6205366c
Author:    lana
Date:      2013-10-31 16:46 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6b4d6205366c

Merge

- test/tools/javac/ExtDirs/ext1/pkg1.jar
- test/tools/javac/ExtDirs/ext2/pkg2.jar
- test/tools/javac/ExtDirs/ext3/pkg1.jar
- test/tools/javac/ExtDirs/ext3/pkg2.jar
- test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: 097bc67c0099
Author:    henryjen
Date:      2013-11-11 23:16 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/097bc67c0099

Merge

! .hgtags
- .jcheck/conf
- test/tools/javac/Diagnostics/compressed/T8012003c.java
- test/tools/javac/Diagnostics/compressed/T8012003c.out
- test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java
- test/tools/javac/defaultMethods/separate/Separate.java
- test/tools/javac/diags/examples/BadArgTypesInLambda.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java


From henry.jen at oracle.com  Tue Nov 12 00:14:06 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 12 Nov 2013 08:14:06 +0000
Subject: hg: lambda/lambda/jdk: 126 new changesets
Message-ID: <20131112083919.659396252E@hg.openjdk.java.net>

Changeset: 62982664dc72
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/62982664dc72

Added tag jdk8-b114 for changeset f26a0c8071bd

! .hgtags

Changeset: 180c05796c45
Author:    bae
Date:      2013-10-10 18:59 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/180c05796c45

7058618: PNG parser bugs found via zzuf fuzzing
Reviewed-by: prr, vadim

! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java

Changeset: 0c2ba6a67b0d
Author:    morris
Date:      2013-10-11 12:40 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0c2ba6a67b0d

7195597: ThreadStateTest gets different results with -Xcomp
Reviewed-by: kvn

! test/java/lang/Thread/ThreadStateTest.java

Changeset: 124bffc749ea
Author:    lana
Date:      2013-10-12 14:14 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/124bffc749ea

Merge

- src/macosx/classes/sun/lwawt/SelectionClearListener.java
- src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java
- src/share/classes/java/lang/invoke/InvokeGeneric.java
- src/share/classes/java/time/chrono/ChronoDateImpl.java
- test/com/sun/jdi/Solaris32AndSolaris64Test.sh
- test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so
- test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so
- test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
- test/java/util/regex/PatternTest.java

Changeset: 7ed340e7d894
Author:    bae
Date:      2013-10-14 15:32 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ed340e7d894

7058602: BMP parser bugs found via zzuf fuzzing
Reviewed-by: prr, vadim

! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
! src/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
! src/share/classes/java/awt/image/ComponentSampleModel.java

Changeset: cb9fa40f73f7
Author:    bae
Date:      2013-10-14 15:49 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb9fa40f73f7

7058607: GIF parser bugs found via zzuf fuzzing
Reviewed-by: prr, vadim

! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java

Changeset: 478f7a9b3b12
Author:    bae
Date:      2013-10-14 16:00 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/478f7a9b3b12

7058611: JPG parser bugs found via zzuf fuzzing
Reviewed-by: prr, vadim

! src/share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java

Changeset: b164c8eb1295
Author:    jgodinez
Date:      2013-10-14 09:15 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b164c8eb1295

8022536: closed/javax/print/TextFlavorTest.java fails
Reviewed-by: prr, jchen

! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
! test/java/awt/print/PrinterJob/PrintLatinCJKTest.java
+ test/javax/print/TextFlavorTest.java

Changeset: 8a59181b3c6d
Author:    vadim
Date:      2013-10-15 08:39 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8a59181b3c6d

8023590: REGRESSION: large count of graphics artifacts with Java 8 on Windows 8 on Intel HD card.
Reviewed-by: prr, bae

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: 0df5cda89a50
Author:    jchen
Date:      2013-10-15 14:16 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0df5cda89a50

8025429: [parfait] warnings from b107 for sun.java2d.cmm: JNI exception pending
Reviewed-by: prr, bae

! src/share/native/sun/java2d/cmm/lcms/LCMS.c

Changeset: c9c945cea665
Author:    jgodinez
Date:      2013-10-15 14:24 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c9c945cea665

8015586: [macosx] Test closed/java/awt/print/PrinterJob/PrintToDir.java fails on MacOSX
Reviewed-by: prr, jchen

! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java
! src/share/classes/sun/print/RasterPrinterJob.java
+ test/java/awt/print/PrinterJob/PrintToDir.java

Changeset: 070e8ec9d82c
Author:    bae
Date:      2013-10-16 17:13 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/070e8ec9d82c

8026702: Fix for 8025429 breaks jdk build on windows
Reviewed-by: serb

! src/share/native/sun/java2d/cmm/lcms/LCMS.c

Changeset: 73d212a3b2eb
Author:    jchen
Date:      2013-10-16 14:00 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/73d212a3b2eb

8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test
Reviewed-by: prr, vadim, serb

! src/share/native/sun/java2d/opengl/OGLBlitLoops.c

Changeset: bcf8e9a59968
Author:    jgodinez
Date:      2013-10-18 15:30 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bcf8e9a59968

8025988: [macosx] Attribute settings don't work for JobAttributes range
8025990: [macosx] Attribute settings don't work for JobAttributes setOrientationRequested, setMedia
Reviewed-by: prr, jchen

! src/macosx/native/sun/awt/CPrinterJob.m
! src/share/classes/sun/print/RasterPrinterJob.java
! src/windows/classes/sun/awt/windows/WPrinterJob.java
! test/java/awt/PrintJob/SaveDialogTitleTest.java

Changeset: 2a3e21fe9d0d
Author:    jgodinez
Date:      2013-10-21 13:18 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a3e21fe9d0d

8026951: Fix for 8025988 breaks jdk build on windows
Reviewed-by: prr, jchen

! src/share/classes/sun/print/RasterPrinterJob.java

Changeset: 923f39485651
Author:    bae
Date:      2013-10-22 13:28 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/923f39485651

8026780: Crash on PPC and PPC v2 for Java_awt test suit
Reviewed-by: prr, jchen

! src/share/native/sun/java2d/cmm/lcms/LCMS.c

Changeset: 739ed3f0e796
Author:    ceisserer
Date:      2013-10-22 13:47 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/739ed3f0e796

8023483: sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java failed with jdk8 on linux platforms
Reviewed-by: prr, bae

! src/solaris/classes/sun/java2d/xr/XRBackend.java
! src/solaris/classes/sun/java2d/xr/XRBackendNative.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/classes/sun/java2d/xr/XRPaints.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
+ test/java/awt/GradientPaint/GradientTransformTest.java
+ test/java/awt/GradientPaint/LinearColorSpaceGradientTest.java
! test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java

Changeset: c55a8480cc27
Author:    ceisserer
Date:      2013-10-22 15:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c55a8480cc27

8023098: XRender : AlphaComposite test results are incorrect.
Reviewed-by: prr, bae

! src/solaris/classes/sun/java2d/xr/MaskTileManager.java
! src/solaris/classes/sun/java2d/xr/XRColor.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/classes/sun/java2d/xr/XRDrawImage.java
! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java
+ src/solaris/classes/sun/java2d/xr/XRSolidSrcPict.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/classes/sun/java2d/xr/XRUtils.java

Changeset: aca4a67e560d
Author:    vadim
Date:      2013-10-23 08:56 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/aca4a67e560d

8001173: [findbugs] Evaluate FindBug output for sun.font.CompositeFont, sun.font.CompositeFontDescriptor
Reviewed-by: prr, bae

! src/share/classes/sun/font/StandardTextSource.java
! src/share/classes/sun/font/TextLabelFactory.java
! src/solaris/classes/sun/font/FontConfigManager.java

Changeset: 92af0666c168
Author:    prr
Date:      2013-10-23 08:46 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/92af0666c168

8027169: Xrender: Cleaner version of the fix for 7159455 Nimbus scrollbar glitch
Reviewed-by: prr, bae

! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java

Changeset: d27525c346fa
Author:    lana
Date:      2013-10-24 21:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d27525c346fa

Merge

- make/sun/awt/FILES_c_macosx.gmk
- make/sun/awt/FILES_export_macosx.gmk
- makefiles/GendataBreakIterator.gmk
- makefiles/GendataFontConfig.gmk
- makefiles/GendataHtml32dtd.gmk
- makefiles/GendataTZDB.gmk
- makefiles/GendataTimeZone.gmk
- makefiles/GenerateJavaSources.gmk
- makefiles/GensrcBuffer.gmk
- makefiles/GensrcCLDR.gmk
- makefiles/GensrcCharacterData.gmk
- makefiles/GensrcCharsetCoder.gmk
- makefiles/GensrcCharsetMapping.gmk
- makefiles/GensrcExceptions.gmk
- makefiles/GensrcIcons.gmk
- makefiles/GensrcJDWP.gmk
- makefiles/GensrcJObjC.gmk
- makefiles/GensrcLocaleDataMetaInfo.gmk
- makefiles/GensrcMisc.gmk
- makefiles/GensrcProperties.gmk
- makefiles/GensrcSwing.gmk
- makefiles/GensrcX11Wrappers.gmk
- src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java
- src/macosx/native/com/apple/resources/MacOSXResourceBundle.m
- src/share/classes/com/sun/jdi/connect/package.html
- src/share/classes/com/sun/jdi/connect/spi/package.html
- src/share/classes/com/sun/jdi/event/package.html
- src/share/classes/com/sun/jdi/package.html
- src/share/classes/com/sun/jdi/request/package.html
- src/share/classes/com/sun/management/package.html
- src/share/classes/com/sun/tools/attach/package.html
- src/share/classes/com/sun/tools/attach/spi/package.html
- src/share/classes/com/sun/tools/jconsole/package.html
- src/share/classes/java/net/HttpURLPermission.java
- src/solaris/doc/sun/man/man1/ja/javaws.1
- src/solaris/doc/sun/man/man1/javaws.1
- test/com/oracle/security/ucrypto/TestAES.java
- test/com/oracle/security/ucrypto/TestDigest.java
- test/com/oracle/security/ucrypto/TestRSA.java
- test/com/oracle/security/ucrypto/UcryptoTest.java
- test/java/net/HttpURLPermission/HttpURLPermissionTest.java
- test/java/net/HttpURLPermission/URLTest.java
- test/java/net/HttpURLPermission/policy.1
- test/java/net/HttpURLPermission/policy.2
- test/java/net/HttpURLPermission/policy.3

Changeset: 3371047f56f3
Author:    lana
Date:      2013-10-31 15:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3371047f56f3

Merge


Changeset: 2e59014ef38f
Author:    alexsch
Date:      2013-10-09 13:40 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2e59014ef38f

8025649: need test to cover JDK-8000423
Reviewed-by: anthony, serb
Contributed-by: Alexander Stepanov <alexander.v.stepanov at oracle.com>

+ test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html
+ test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.java

Changeset: 84c766f6796b
Author:    bagiras
Date:      2013-10-09 14:12 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/84c766f6796b

8016356: Any swing frame resizes ugly.
Reviewed-by: art, anthony

! src/windows/native/sun/windows/awt_Window.cpp

Changeset: 929dc0915f8c
Author:    anthony
Date:      2013-10-09 15:34 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/929dc0915f8c

7159266: [macosx] ApplicationDelegate should not be set in the headless mode
Summary: Don't install ApplicationDelegate in headless mode
Reviewed-by: art, serb

! src/macosx/native/sun/awt/awt.m

Changeset: 976e5f580124
Author:    leonidr
Date:      2013-10-09 20:59 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/976e5f580124

8019623: Lack of synchronization in AppContext.getAppContext()
Reviewed-by: anthony, art

! src/share/classes/sun/awt/AppContext.java
+ test/sun/awt/AppContext/MultiThread/MultiThreadTest.java

Changeset: fba62451d705
Author:    leonidr
Date:      2013-10-09 21:15 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fba62451d705

8016551: JMenuItem in WindowsLookAndFeel can't paint default icons
Reviewed-by: alexsch, serb

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java
+ test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java

Changeset: cea6ca16142e
Author:    cl
Date:      2013-10-09 14:32 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cea6ca16142e

8026021: more fix of javadoc errors and warnings reported by doclint, see the description
Reviewed-by: anthony, serb

! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/LinearGradientPaint.java
! src/share/classes/java/awt/RadialGradientPaint.java
! src/share/classes/java/awt/font/LineBreakMeasurer.java
! src/share/classes/java/awt/font/MultipleMaster.java
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/im/InputContext.java
! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/StyleConstants.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java

Changeset: 81ea6299230a
Author:    serb
Date:      2013-10-10 02:35 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/81ea6299230a

7058662: AiffFileReader throws java.lang.ArithmeticException: division by zero when frame size is zero
7058666: Unexpected exception in AU parser code
7058672: Unexpected exceptions and freezes in WAV parser code
Reviewed-by: prr

! src/share/classes/com/sun/media/sound/AiffFileReader.java
! src/share/classes/com/sun/media/sound/AuFileReader.java
! src/share/classes/com/sun/media/sound/WaveFileReader.java
+ test/javax/sound/sampled/FileReader/ReadersExceptions.java

Changeset: 857d6f78f241
Author:    pchelko
Date:      2013-10-10 11:40 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/857d6f78f241

8025588: [macosx] Frozen AppKit thread in 7u40
Reviewed-by: anthony, art, serb

! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/event/InvocationEvent.java
! src/share/classes/sun/awt/AWTAccessor.java

Changeset: 31a156bae7cb
Author:    pchelko
Date:      2013-10-10 19:27 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/31a156bae7cb

8024864: [macosx] Problems with rendering of controls
Reviewed-by: serb, leonidr

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
+ test/java/awt/Paint/bug8024864.java

Changeset: de36486eadd2
Author:    pchelko
Date:      2013-10-11 11:48 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/de36486eadd2

8026143: [macosx] Maximized state could be inconsistent between peer and frame
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m
+ test/java/awt/Frame/MaximizedByPlatform/MaximizedByPlatform.java

Changeset: d96f9a8cf89a
Author:    kshefov
Date:      2013-10-11 15:39 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d96f9a8cf89a

7124338: [macosx] Selection lost if a selected item removed from a java.awt.List
Reviewed-by: serb, anthony

+ test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.html
+ test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java

Changeset: 2e04843f1c1d
Author:    art
Date:      2013-10-11 16:44 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2e04843f1c1d

8022185: Fix Raw and unchecked warnings in classes belonging to java.awt.datatransfer
Reviewed-by: art, pchelko
Contributed-by: Srikalyan Chandrashekar <srikalyan.chandrashekar at oracle.com>

! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java

Changeset: 2f7f6995fa64
Author:    pchelko
Date:      2013-10-11 17:57 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2f7f6995fa64

8026262: NPE in SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of #JDK-8024987
Reviewed-by: art, serb

! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java

Changeset: af273c9b564a
Author:    pchelko
Date:      2013-10-11 18:04 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/af273c9b564a

8024329: [macosx] JRadioButtonMenuItem behaves like a checkbox when using the ScreenMenuBar
Reviewed-by: anthony, serb

! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java

Changeset: f65895a2959e
Author:    lana
Date:      2013-10-11 14:19 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f65895a2959e

Merge

- src/share/classes/java/lang/invoke/InvokeGeneric.java
- src/share/classes/java/time/chrono/ChronoDateImpl.java
- test/com/sun/jdi/Solaris32AndSolaris64Test.sh
- test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so
- test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so
- test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
- test/java/util/regex/PatternTest.java

Changeset: d874963706dc
Author:    yan
Date:      2013-10-14 11:47 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d874963706dc

8025824: [cleanup] Fix tidy errors and warnings in preformatted HTML files related to 2d/awt/swing
Reviewed-by: anthony, alexsch

! src/macosx/classes/com/apple/eawt/event/package.html
! src/macosx/classes/com/apple/eawt/package.html
! src/share/classes/java/awt/color/package.html
! src/share/classes/java/awt/datatransfer/package.html
! src/share/classes/java/awt/dnd/package.html
! src/share/classes/java/awt/doc-files/AWTThreadIssues.html
! src/share/classes/java/awt/doc-files/DesktopProperties.html
! src/share/classes/java/awt/doc-files/FocusSpec.html
! src/share/classes/java/awt/doc-files/Modality.html
! src/share/classes/java/awt/event/package.html
! src/share/classes/java/awt/font/package.html
! src/share/classes/java/awt/geom/package.html
! src/share/classes/java/awt/image/package.html
! src/share/classes/java/awt/image/renderable/package.html
! src/share/classes/java/awt/package.html
! src/share/classes/java/awt/print/package.html
! src/share/classes/javax/print/attribute/package.html
! src/share/classes/javax/print/attribute/standard/package.html
! src/share/classes/javax/print/event/package.html
! src/share/classes/javax/print/package.html
! src/share/classes/javax/swing/border/package.html
! src/share/classes/javax/swing/colorchooser/package.html
! src/share/classes/javax/swing/event/package.html
! src/share/classes/javax/swing/filechooser/package.html
! src/share/classes/javax/swing/plaf/basic/package.html
! src/share/classes/javax/swing/plaf/metal/package.html
! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html
! src/share/classes/javax/swing/plaf/multi/package.html
! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html
! src/share/classes/javax/swing/plaf/nimbus/package.html
! src/share/classes/javax/swing/plaf/package.html
! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html
! src/share/classes/javax/swing/plaf/synth/package.html
! src/share/classes/javax/swing/table/package.html
! src/share/classes/javax/swing/text/html/package.html
! src/share/classes/javax/swing/text/html/parser/package.html
! src/share/classes/javax/swing/text/package.html
! src/share/classes/javax/swing/text/rtf/package.html
! src/share/classes/javax/swing/tree/package.html
! src/share/classes/javax/swing/undo/package.html

Changeset: 69a17384fe22
Author:    malenkov
Date:      2013-10-14 13:22 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/69a17384fe22

7165112: Incomprehensible garbage in doc for RootPaneContainer
Reviewed-by: alexsch

! src/share/classes/javax/swing/JApplet.java
! src/share/classes/javax/swing/JDialog.java
! src/share/classes/javax/swing/JFrame.java
! src/share/classes/javax/swing/JInternalFrame.java
! src/share/classes/javax/swing/JWindow.java
! src/share/classes/javax/swing/RootPaneContainer.java

Changeset: 9f49b055e983
Author:    malenkov
Date:      2013-10-14 13:59 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9f49b055e983

7016396: (spec) JCK test mentioned in 6735293 is still failing
Reviewed-by: alexsch

! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
! src/share/classes/javax/swing/text/AsyncBoxView.java
! src/share/classes/javax/swing/text/CompositeView.java
! src/share/classes/javax/swing/text/GlyphView.java
! src/share/classes/javax/swing/text/View.java

Changeset: 54a6e22b749c
Author:    malenkov
Date:      2013-10-14 14:13 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/54a6e22b749c

7035495: javax.swing.ImageIcon spec should  be clarified
Reviewed-by: alexsch

! src/share/classes/javax/swing/ImageIcon.java

Changeset: 5e0ed469c36a
Author:    alexsch
Date:      2013-10-14 18:19 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5e0ed469c36a

8005391: Floating behavior of HTMLEditorKit parser
Reviewed-by: malenkov, leonidr
Contributed-by: Alexander Shusherov <alexander.shusherov at oracle.com>

! src/share/classes/javax/swing/text/SimpleAttributeSet.java
+ test/javax/swing/text/html/8005391/bug8005391.java

Changeset: 24fd0716d8d6
Author:    alexsch
Date:      2013-10-14 18:52 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/24fd0716d8d6

8020708: NLS mnemonics missing in SwingSet2/JInternalFrame demo
Reviewed-by: malenkov, leonidr

! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java
+ test/javax/swing/JInternalFrame/8020708/bug8020708.java

Changeset: 9546631f14ca
Author:    serb
Date:      2013-10-14 20:11 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9546631f14ca

8019591: JCK: testICSEthrowing_fullScreen fails: no ICSE thrown
Reviewed-by: art, anthony

! src/share/classes/java/awt/GraphicsDevice.java
+ test/java/awt/Window/WindowGCInFullScreen/WindowGCInFullScreen.java

Changeset: f9548641d699
Author:    serb
Date:      2013-10-15 20:37 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f9548641d699

7059886: 6 JCK manual awt/Desktop tests fail with GTKLookAndFeel - GTK intialization issue
Reviewed-by: anthony, art
Contributed-by: alexander.zvegintsev at oracle.com

+ src/solaris/classes/sun/misc/GThreadHelper.java
! src/solaris/native/sun/awt/awt_UNIXToolkit.c
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/xawt/awt_Desktop.c

Changeset: 89546b9be510
Author:    serb
Date:      2013-10-15 20:40 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/89546b9be510

8025225: Window.setAlwaysOnTop documentation should be updated
Reviewed-by: anthony, art
Contributed-by: alexander.zvegintsev at oracle.com

! src/share/classes/java/awt/Window.java

Changeset: 229b10e97bd2
Author:    bagiras
Date:      2013-10-16 19:02 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/229b10e97bd2

2228674: Fix failed for CR 7162144
Reviewed-by: art, anthony

! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/EventQueue.java

Changeset: 70242d821c66
Author:    serb
Date:      2013-10-17 20:54 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/70242d821c66

8022657: Add FunctionalInterface annotation to awt interfaces
Reviewed-by: anthony, art

! src/share/classes/java/awt/KeyEventDispatcher.java
! src/share/classes/java/awt/KeyEventPostProcessor.java

Changeset: 3c2d4569a6a3
Author:    serb
Date:      2013-10-17 21:22 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3c2d4569a6a3

8026356: [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main
Reviewed-by: anthony, art

! src/share/classes/java/awt/Component.java

Changeset: 5334c651c7ba
Author:    yan
Date:      2013-10-18 15:15 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5334c651c7ba

7002846: Fix for 6989505 may be incomplete
Reviewed-by: anthony, art
Contributed-by: Andrei Eremeev <andrei.eremeev at oracle.com>

! src/windows/classes/sun/awt/windows/WRobotPeer.java
! src/windows/native/sun/windows/awt_Robot.cpp
! src/windows/native/sun/windows/awt_Robot.h

Changeset: 84ae644933b6
Author:    serb
Date:      2013-10-18 20:35 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/84ae644933b6

8026476: Choice does not get mouse events if it does not have enough place for popup menu
Reviewed-by: anthony, serb
Contributed-by: alexander.zvegintsev at oracle.com

! src/solaris/classes/sun/awt/X11/XChoicePeer.java

Changeset: d72ca6dac444
Author:    leonidr
Date:      2013-10-22 16:45 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d72ca6dac444

8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS"
Reviewed-by: anthony, serb

! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
+ test/java/awt/event/KeyEvent/8020209/bug8020209.java
! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

Changeset: 4ad826a08e6f
Author:    serb
Date:      2013-10-23 16:24 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4ad826a08e6f

8020851: java.awt.event.WindowEvent spec should state that WINDOW_CLOSED event may not be delivered under certain circumstances
Reviewed-by: anthony, art

! src/share/classes/java/awt/event/WindowEvent.java

Changeset: cd2e3c63ee42
Author:    serb
Date:      2013-10-24 14:32 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cd2e3c63ee42

7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError
Reviewed-by: anthony, art

! src/solaris/classes/sun/awt/X11/XButtonPeer.java
! src/solaris/classes/sun/awt/X11/XCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XContentWindow.java
! src/solaris/classes/sun/awt/X11/XLabelPeer.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Paint/ButtonRepaint.java
+ test/java/awt/Paint/CheckboxRepaint.java
+ test/java/awt/Paint/ExposeOnEDT.java
+ test/java/awt/Paint/LabelRepaint.java
+ test/java/awt/Paint/ListRepaint.java

Changeset: 7c84aff91033
Author:    pchelko
Date:      2013-10-24 19:23 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7c84aff91033

8027030: AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64)
Reviewed-by: anthony, serb

! src/share/classes/sun/awt/datatransfer/DataTransferer.java

Changeset: c561db53a24c
Author:    pchelko
Date:      2013-10-24 19:50 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c561db53a24c

8027025: [macosx] getLocationOnScreen returns 0 if parent invisible
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
+ test/java/awt/Window/8027025/Test8027025.java

Changeset: 6fe5443c3dde
Author:    alitvinov
Date:      2013-10-25 13:41 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6fe5443c3dde

8027066: XMLDecoder in java 7 cannot properly deserialize object arrays
Reviewed-by: alexsch, malenkov
Contributed-by: anton.nashatyrev at oracle.com

! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java
+ test/java/beans/XMLEncoder/Test8027066.java

Changeset: 75ae2a980db5
Author:    malenkov
Date:      2013-10-25 16:42 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/75ae2a980db5

8026705: [TEST_BUG] java/beans/Introspector/TestTypeResolver.java failed
Reviewed-by: art, jfranck

! test/java/beans/Introspector/TestTypeResolver.java

Changeset: dab1d3798016
Author:    serb
Date:      2013-10-25 19:51 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dab1d3798016

7172770: Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported"
Reviewed-by: anthony, art

! src/share/classes/java/awt/Toolkit.java

Changeset: 162c57b874d4
Author:    lana
Date:      2013-10-25 10:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/162c57b874d4

Merge

- make/sun/awt/FILES_c_macosx.gmk
- make/sun/awt/FILES_export_macosx.gmk
- makefiles/GendataBreakIterator.gmk
- makefiles/GendataFontConfig.gmk
- makefiles/GendataHtml32dtd.gmk
- makefiles/GendataTZDB.gmk
- makefiles/GendataTimeZone.gmk
- makefiles/GenerateJavaSources.gmk
- makefiles/GensrcBuffer.gmk
- makefiles/GensrcCLDR.gmk
- makefiles/GensrcCharacterData.gmk
- makefiles/GensrcCharsetCoder.gmk
- makefiles/GensrcCharsetMapping.gmk
- makefiles/GensrcExceptions.gmk
- makefiles/GensrcIcons.gmk
- makefiles/GensrcJDWP.gmk
- makefiles/GensrcJObjC.gmk
- makefiles/GensrcLocaleDataMetaInfo.gmk
- makefiles/GensrcMisc.gmk
- makefiles/GensrcProperties.gmk
- makefiles/GensrcSwing.gmk
- makefiles/GensrcX11Wrappers.gmk
- src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java
- src/macosx/native/com/apple/resources/MacOSXResourceBundle.m
- src/share/classes/com/sun/jdi/connect/package.html
- src/share/classes/com/sun/jdi/connect/spi/package.html
- src/share/classes/com/sun/jdi/event/package.html
- src/share/classes/com/sun/jdi/package.html
- src/share/classes/com/sun/jdi/request/package.html
- src/share/classes/com/sun/management/package.html
- src/share/classes/com/sun/tools/attach/package.html
- src/share/classes/com/sun/tools/attach/spi/package.html
- src/share/classes/com/sun/tools/jconsole/package.html
! src/share/classes/java/awt/datatransfer/DataFlavor.java
- src/share/classes/java/net/HttpURLPermission.java
! src/share/classes/sun/awt/AppContext.java
- src/solaris/doc/sun/man/man1/ja/javaws.1
- src/solaris/doc/sun/man/man1/javaws.1
- test/com/oracle/security/ucrypto/TestAES.java
- test/com/oracle/security/ucrypto/TestDigest.java
- test/com/oracle/security/ucrypto/TestRSA.java
- test/com/oracle/security/ucrypto/UcryptoTest.java
- test/java/net/HttpURLPermission/HttpURLPermissionTest.java
- test/java/net/HttpURLPermission/URLTest.java
- test/java/net/HttpURLPermission/policy.1
- test/java/net/HttpURLPermission/policy.2
- test/java/net/HttpURLPermission/policy.3

Changeset: 55cab2211ae9
Author:    ant
Date:      2013-10-29 16:35 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/55cab2211ae9

8027157: [SwingNode] needs explicit expose for JWindow
Reviewed-by: art, anthony

! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: bedc29a6d074
Author:    malenkov
Date:      2013-10-29 17:01 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bedc29a6d074

8022746: List of spelling errors in API doc
Reviewed-by: alexsch, smarks

! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m
! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/macosx/classes/com/apple/laf/AquaMenuPainter.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTreeUI.java
! src/macosx/classes/java/net/DefaultInterface.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/macosx/classes/sun/font/CFontManager.java
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/CTextPipe.m
! src/share/back/commonRef.c
! src/share/back/eventFilter.c
! src/share/back/util.c
! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java
! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java
! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java
! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java
! src/share/classes/com/sun/beans/decoder/CharElementHandler.java
! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java
! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java
! src/share/classes/com/sun/beans/decoder/ElementHandler.java
! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java
! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java
! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java
! src/share/classes/com/sun/beans/decoder/IntElementHandler.java
! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java
! src/share/classes/com/sun/beans/decoder/LongElementHandler.java
! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java
! src/share/classes/com/sun/beans/decoder/NewElementHandler.java
! src/share/classes/com/sun/beans/decoder/NullElementHandler.java
! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java
! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java
! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java
! src/share/classes/com/sun/beans/decoder/StringElementHandler.java
! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java
! src/share/classes/com/sun/beans/decoder/VarElementHandler.java
! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java
! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/com/sun/jdi/connect/ListeningConnector.java
! src/share/classes/com/sun/jdi/connect/spi/TransportService.java
! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java
! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/Filter.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/com/sun/jndi/ldap/LdapName.java
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java
! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java
! src/share/classes/com/sun/media/sound/DirectAudioDevice.java
! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
! src/share/classes/com/sun/net/httpserver/Headers.java
! src/share/classes/com/sun/net/httpserver/HttpExchange.java
! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java
! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java
! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/package.html
! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java
! src/share/classes/com/sun/tools/hat/resources/hat.js
! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java
! src/share/classes/com/sun/tools/jdi/ThreadListener.java
! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/share/classes/java/awt/AWTEventMulticaster.java
! src/share/classes/java/awt/AlphaComposite.java
! src/share/classes/java/awt/BasicStroke.java
! src/share/classes/java/awt/BorderLayout.java
! src/share/classes/java/awt/CheckboxMenuItem.java
! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/Event.java
! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/Graphics.java
! src/share/classes/java/awt/Graphics2D.java
! src/share/classes/java/awt/GraphicsEnvironment.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/MediaTracker.java
! src/share/classes/java/awt/MenuComponent.java
! src/share/classes/java/awt/MultipleGradientPaintContext.java
! src/share/classes/java/awt/Polygon.java
! src/share/classes/java/awt/PopupMenu.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/ScrollPane.java
! src/share/classes/java/awt/ScrollPaneAdjustable.java
! src/share/classes/java/awt/Shape.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/datatransfer/FlavorMap.java
! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java
! src/share/classes/java/awt/dnd/DragGestureListener.java
! src/share/classes/java/awt/dnd/DragGestureRecognizer.java
! src/share/classes/java/awt/dnd/DragSourceContext.java
! src/share/classes/java/awt/dnd/DragSourceEvent.java
! src/share/classes/java/awt/dnd/DropTarget.java
! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java
! src/share/classes/java/awt/event/ActionEvent.java
! src/share/classes/java/awt/event/KeyEvent.java
! src/share/classes/java/awt/font/FontRenderContext.java
! src/share/classes/java/awt/font/GlyphMetrics.java
! src/share/classes/java/awt/font/GlyphVector.java
! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/java/awt/font/TextLayout.java
! src/share/classes/java/awt/font/TransformAttribute.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/geom/Line2D.java
! src/share/classes/java/awt/geom/Path2D.java
! src/share/classes/java/awt/geom/QuadCurve2D.java
! src/share/classes/java/awt/im/InputMethodRequests.java
! src/share/classes/java/awt/image/BandedSampleModel.java
! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ComponentColorModel.java
! src/share/classes/java/awt/image/ComponentSampleModel.java
! src/share/classes/java/awt/image/ImageConsumer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java
! src/share/classes/java/awt/image/renderable/RenderableImage.java
! src/share/classes/java/awt/image/renderable/RenderableImageOp.java
! src/share/classes/java/beans/AppletInitializer.java
! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/EventHandler.java
! src/share/classes/java/beans/MethodDescriptor.java
! src/share/classes/java/beans/PropertyDescriptor.java
! src/share/classes/java/beans/PropertyEditorSupport.java
! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java
! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java
! src/share/classes/java/beans/beancontext/BeanContextSupport.java
! src/share/classes/java/io/File.java
! src/share/classes/java/io/ObjectStreamConstants.java
! src/share/classes/java/io/PrintStream.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/management/CompilationMXBean.java
! src/share/classes/java/lang/management/MemoryPoolMXBean.java
! src/share/classes/java/lang/management/ThreadInfo.java
! src/share/classes/java/lang/management/ThreadMXBean.java
! src/share/classes/java/net/Authenticator.java
! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/net/CookieStore.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/classes/java/net/InterfaceAddress.java
! src/share/classes/java/net/JarURLConnection.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/StandardSocketOptions.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/MembershipKey.java
! src/share/classes/java/nio/channels/package-info.java
! src/share/classes/java/nio/charset/Charset.java
! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java
! src/share/classes/java/rmi/MarshalledObject.java
! src/share/classes/java/security/AccessControlException.java
! src/share/classes/java/security/DigestOutputStream.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/ProtectionDomain.java
! src/share/classes/java/security/Security.java
! src/share/classes/java/security/UnresolvedPermission.java
! src/share/classes/java/security/cert/CertificateRevokedException.java
! src/share/classes/java/security/spec/ECFieldF2m.java
! src/share/classes/java/sql/Array.java
! src/share/classes/java/sql/BatchUpdateException.java
! src/share/classes/java/sql/Blob.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Clob.java
! src/share/classes/java/sql/Connection.java
! src/share/classes/java/sql/DataTruncation.java
! src/share/classes/java/sql/DatabaseMetaData.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/sql/DriverPropertyInfo.java
! src/share/classes/java/sql/PreparedStatement.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLException.java
! src/share/classes/java/sql/SQLFeatureNotSupportedException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLNonTransientException.java
! src/share/classes/java/sql/SQLRecoverableException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTimeoutException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java
! src/share/classes/java/sql/SQLTransientException.java
! src/share/classes/java/sql/SQLWarning.java
! src/share/classes/java/sql/SQLXML.java
! src/share/classes/java/sql/Statement.java
! src/share/classes/java/sql/Struct.java
! src/share/classes/java/sql/package.html
! src/share/classes/java/text/BreakIterator.java
! src/share/classes/java/text/ChoiceFormat.java
! src/share/classes/java/text/DigitList.java
! src/share/classes/java/text/FieldPosition.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/RuleBasedCollator.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/zone/ZoneRules.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/MissingFormatWidthException.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ExecutorCompletionService.java
! src/share/classes/java/util/jar/Manifest.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/javax/accessibility/AccessibleContext.java
! src/share/classes/javax/accessibility/AccessibleText.java
! src/share/classes/javax/crypto/NullCipher.java
! src/share/classes/javax/crypto/NullCipherSpi.java
! src/share/classes/javax/imageio/IIOParam.java
! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/event/IIOReadProgressListener.java
! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java
! src/share/classes/javax/imageio/event/IIOReadWarningListener.java
! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java
! src/share/classes/javax/imageio/metadata/IIOMetadata.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/management/relation/RelationService.java
! src/share/classes/javax/management/relation/RelationServiceMBean.java
! src/share/classes/javax/management/remote/rmi/package.html
! src/share/classes/javax/naming/Binding.java
! src/share/classes/javax/naming/InsufficientResourcesException.java
! src/share/classes/javax/naming/ldap/LdapName.java
! src/share/classes/javax/naming/ldap/Rdn.java
! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java
! src/share/classes/javax/net/ssl/SSLSocket.java
! src/share/classes/javax/print/CancelablePrintJob.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/DocPrintJob.java
! src/share/classes/javax/print/MultiDoc.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/attribute/standard/MediaTray.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java
! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java
! src/share/classes/javax/print/package.html
! src/share/classes/javax/script/AbstractScriptEngine.java
! src/share/classes/javax/script/CompiledScript.java
! src/share/classes/javax/script/Invocable.java
! src/share/classes/javax/script/ScriptEngine.java
! src/share/classes/javax/script/ScriptEngineFactory.java
! src/share/classes/javax/security/sasl/RealmChoiceCallback.java
! src/share/classes/javax/security/sasl/Sasl.java
! src/share/classes/javax/security/sasl/SaslClient.java
! src/share/classes/javax/security/sasl/SaslException.java
! src/share/classes/javax/smartcardio/CardChannel.java
! src/share/classes/javax/smartcardio/CardTerminal.java
! src/share/classes/javax/sound/midi/MidiDevice.java
! src/share/classes/javax/sound/midi/MidiMessage.java
! src/share/classes/javax/sound/midi/MidiSystem.java
! src/share/classes/javax/sound/midi/ShortMessage.java
! src/share/classes/javax/sound/midi/Soundbank.java
! src/share/classes/javax/sound/midi/Synthesizer.java
! src/share/classes/javax/sound/sampled/AudioFormat.java
! src/share/classes/javax/sound/sampled/AudioSystem.java
! src/share/classes/javax/sound/sampled/ReverbType.java
! src/share/classes/javax/sql/PooledConnection.java
! src/share/classes/javax/sql/RowSet.java
! src/share/classes/javax/sql/StatementEvent.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
! src/share/classes/javax/sql/rowset/JoinRowSet.java
! src/share/classes/javax/sql/rowset/Joinable.java
! src/share/classes/javax/sql/rowset/Predicate.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncResolver.java
! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java
! src/share/classes/javax/sql/rowset/spi/XmlReader.java
! src/share/classes/javax/sql/rowset/spi/XmlWriter.java
! src/share/classes/javax/swing/AbstractButton.java
! src/share/classes/javax/swing/BoxLayout.java
! src/share/classes/javax/swing/DefaultListSelectionModel.java
! src/share/classes/javax/swing/DefaultRowSorter.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/JApplet.java
! src/share/classes/javax/swing/JComboBox.java
! src/share/classes/javax/swing/JComponent.java
! src/share/classes/javax/swing/JDialog.java
! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/JFormattedTextField.java
! src/share/classes/javax/swing/JFrame.java
! src/share/classes/javax/swing/JInternalFrame.java
! src/share/classes/javax/swing/JLabel.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/JMenu.java
! src/share/classes/javax/swing/JPasswordField.java
! src/share/classes/javax/swing/JPopupMenu.java
! src/share/classes/javax/swing/JRootPane.java
! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/JSpinner.java
! src/share/classes/javax/swing/JSplitPane.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/JViewport.java
! src/share/classes/javax/swing/JWindow.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/ProgressMonitor.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/javax/swing/ScrollPaneConstants.java
! src/share/classes/javax/swing/SpinnerDateModel.java
! src/share/classes/javax/swing/SpinnerModel.java
! src/share/classes/javax/swing/SpinnerNumberModel.java
! src/share/classes/javax/swing/SpringLayout.java
! src/share/classes/javax/swing/SwingUtilities.java
! src/share/classes/javax/swing/ToolTipManager.java
! src/share/classes/javax/swing/TransferHandler.java
! src/share/classes/javax/swing/UIManager.java
! src/share/classes/javax/swing/border/TitledBorder.java
! src/share/classes/javax/swing/event/DocumentEvent.java
! src/share/classes/javax/swing/event/HyperlinkEvent.java
! src/share/classes/javax/swing/event/TableModelEvent.java
! src/share/classes/javax/swing/event/TreeModelEvent.java
! src/share/classes/javax/swing/filechooser/FileSystemView.java
! src/share/classes/javax/swing/plaf/ComboBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicBorders.java
! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java
! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java
! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java
! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java
! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java
! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/share/classes/javax/swing/table/DefaultTableColumnModel.java
! src/share/classes/javax/swing/table/JTableHeader.java
! src/share/classes/javax/swing/table/TableColumn.java
! src/share/classes/javax/swing/table/TableColumnModel.java
! src/share/classes/javax/swing/text/AbstractDocument.java
! src/share/classes/javax/swing/text/AbstractWriter.java
! src/share/classes/javax/swing/text/AsyncBoxView.java
! src/share/classes/javax/swing/text/BoxView.java
! src/share/classes/javax/swing/text/DefaultFormatter.java
! src/share/classes/javax/swing/text/DefaultHighlighter.java
! src/share/classes/javax/swing/text/DefaultStyledDocument.java
! src/share/classes/javax/swing/text/Document.java
! src/share/classes/javax/swing/text/DocumentFilter.java
! src/share/classes/javax/swing/text/ElementIterator.java
! src/share/classes/javax/swing/text/FlowView.java
! src/share/classes/javax/swing/text/GapContent.java
! src/share/classes/javax/swing/text/GapVector.java
! src/share/classes/javax/swing/text/InternationalFormatter.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/NumberFormatter.java
! src/share/classes/javax/swing/text/ParagraphView.java
! src/share/classes/javax/swing/text/StyleConstants.java
! src/share/classes/javax/swing/text/StyleContext.java
! src/share/classes/javax/swing/text/TableView.java
! src/share/classes/javax/swing/text/View.java
! src/share/classes/javax/swing/text/WrappedPlainView.java
! src/share/classes/javax/swing/text/ZoneView.java
! src/share/classes/javax/swing/text/html/AccessibleHTML.java
! src/share/classes/javax/swing/text/html/BlockView.java
! src/share/classes/javax/swing/text/html/CSS.java
! src/share/classes/javax/swing/text/html/CSSParser.java
! src/share/classes/javax/swing/text/html/FormSubmitEvent.java
! src/share/classes/javax/swing/text/html/FormView.java
! src/share/classes/javax/swing/text/html/FrameSetView.java
! src/share/classes/javax/swing/text/html/HTML.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java
! src/share/classes/javax/swing/text/html/HTMLWriter.java
! src/share/classes/javax/swing/text/html/OptionListModel.java
! src/share/classes/javax/swing/text/html/ParagraphView.java
! src/share/classes/javax/swing/text/html/StyleSheet.java
! src/share/classes/javax/swing/text/html/TableView.java
! src/share/classes/javax/swing/text/html/parser/ContentModel.java
! src/share/classes/javax/swing/text/html/parser/DocumentParser.java
! src/share/classes/javax/swing/text/html/parser/Element.java
! src/share/classes/javax/swing/text/html/parser/Parser.java
! src/share/classes/javax/swing/tree/AbstractLayoutCache.java
! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java
! src/share/classes/javax/swing/tree/DefaultTreeModel.java
! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java
! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
! src/share/classes/javax/swing/tree/TreeModel.java
! src/share/classes/javax/swing/tree/TreeSelectionModel.java
! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java
! src/share/classes/javax/xml/crypto/KeySelector.java
! src/share/classes/javax/xml/crypto/MarshalException.java
! src/share/classes/javax/xml/crypto/dsig/TransformException.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java
! src/share/classes/jdi-overview.html
! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java
! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java
! src/share/classes/jdk/internal/util/xml/XMLStreamException.java
! src/share/classes/jdk/internal/util/xml/impl/Parser.java
! src/share/classes/org/ietf/jgss/GSSContext.java
! src/share/classes/org/ietf/jgss/GSSCredential.java
! src/share/classes/org/ietf/jgss/GSSException.java
! src/share/classes/org/ietf/jgss/GSSManager.java
! src/share/classes/org/ietf/jgss/GSSName.java
! src/share/classes/org/ietf/jgss/package.html
! src/share/classes/sun/applet/AppletSecurity.java
! src/share/classes/sun/awt/FontConfiguration.java
! src/share/classes/sun/awt/GlobalCursorManager.java
! src/share/classes/sun/awt/shell/ShellFolderManager.java
! src/share/classes/sun/dc/DuctusRenderingEngine.java
! src/share/classes/sun/font/ExtendedTextSourceLabel.java
! src/share/classes/sun/font/FileFontStrike.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/FontRunIterator.java
! src/share/classes/sun/font/LayoutPathImpl.java
! src/share/classes/sun/font/ScriptRun.java
! src/share/classes/sun/font/StrikeCache.java
! src/share/classes/sun/font/SunFontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/share/classes/sun/font/Type1Font.java
! src/share/classes/sun/java2d/SurfaceDataProxy.java
! src/share/classes/sun/java2d/loops/ProcessPath.java
! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java
! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/RenderingEngine.java
! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java
! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java
! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java
! src/share/classes/sun/management/counter/perf/InstrumentationException.java
! src/share/classes/sun/management/counter/perf/PerfDataType.java
! src/share/classes/sun/misc/CRC16.java
! src/share/classes/sun/misc/CharacterDecoder.java
! src/share/classes/sun/misc/PerformanceLogger.java
! src/share/classes/sun/net/NetworkClient.java
! src/share/classes/sun/net/TelnetOutputStream.java
! src/share/classes/sun/net/ftp/FtpClient.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/idn/StringPrep.java
! src/share/classes/sun/net/smtp/SmtpProtocolException.java
! src/share/classes/sun/net/www/http/ChunkedInputStream.java
! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/http/PosterOutputStream.java
! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java
! src/share/classes/sun/print/PSPathGraphics.java
! src/share/classes/sun/print/PSPrinterJob.java
! src/share/classes/sun/print/PathGraphics.java
! src/share/classes/sun/print/PrintJob2D.java
! src/share/classes/sun/print/RasterPrinterJob.java
! src/share/classes/sun/rmi/rmic/RemoteClass.java
! src/share/classes/sun/rmi/rmic/Util.java
! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java
! src/share/classes/sun/rmi/runtime/Log.java
! src/share/classes/sun/rmi/server/Activation.java
! src/share/classes/sun/rmi/transport/ObjectTable.java
! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java
! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java
! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java
! src/share/classes/sun/security/jca/GetInstance.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/share/classes/sun/security/jgss/krb5/MessageToken.java
! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java
! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/share/classes/sun/security/provider/DSA.java
! src/share/classes/sun/security/provider/certpath/AdjacencyList.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java
! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/RSASignature.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/security/x509/AlgIdDSA.java
! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java
! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java
! src/share/classes/sun/text/resources/th/CollationData_th.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jconsole/BorderedComponent.java
! src/share/classes/sun/tools/jconsole/inspector/XTextField.java
! src/share/classes/sun/tools/jinfo/JInfo.java
! src/share/classes/sun/tools/jmap/JMap.java
! src/share/classes/sun/tools/jstat/ColumnFormat.java
! src/share/classes/sun/tools/jstat/resources/jstat_options
! src/share/classes/sun/tools/tree/ExprExpression.java
! src/share/classes/sun/tools/tree/FieldExpression.java
! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java
! src/share/classes/sun/util/logging/PlatformLogger.java
! src/share/demo/jfc/Font2DTest/FontPanel.java
! src/share/demo/jfc/TableExample/TableExample4.java
! src/share/demo/jvmti/hprof/debug_malloc.c
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! src/share/javavm/export/jvm.h
! src/share/native/com/sun/java/util/jar/pack/zip.cpp
! src/share/native/com/sun/media/sound/PlatformMidi.h
! src/share/native/common/jni_util.h
! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c
! src/share/native/java/util/zip/zip_util.c
! src/share/native/sun/awt/image/cvutils/img_dcm.h
! src/share/native/sun/awt/image/cvutils/img_replscale.h
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
! src/share/native/sun/awt/image/jpeg/jpegdecoder.c
! src/share/native/sun/awt/libpng/CHANGES
! src/share/native/sun/awt/libpng/png.h
! src/share/native/sun/awt/libpng/pngconf.h
! src/share/native/sun/awt/libpng/pngpriv.h
! src/share/native/sun/awt/libpng/pngrutil.c
! src/share/native/sun/font/layout/ArabicLayoutEngine.h
! src/share/native/sun/font/layout/IndicReordering.h
! src/share/native/sun/font/layout/KhmerReordering.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/TibetanReordering.cpp
! src/share/native/sun/java2d/cmm/lcms/cmsio0.c
! src/share/native/sun/java2d/cmm/lcms/cmslut.c
! src/share/native/sun/java2d/loops/ProcessPath.c
! src/share/native/sun/java2d/opengl/OGLTextRenderer.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c
! src/share/sample/jmx/jmx-scandir/index.html
! src/share/sample/nio/chatserver/ClientReader.java
! src/share/sample/scripting/scriptpad/src/resources/gui.js
! src/solaris/classes/java/net/DefaultInterface.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XChoicePeer.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java
! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java
! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11GraphicsConfig.java
! src/solaris/classes/sun/font/XMap.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
! src/solaris/classes/sun/nio/fs/SolarisWatchService.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/classes/sun/nio/fs/UnixUriUtils.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
! src/solaris/demo/jni/Poller/Poller.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/multiVis.c
! src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h
! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java
! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java
! src/windows/classes/java/net/DefaultInterface.java
! src/windows/classes/sun/awt/windows/WPathGraphics.java
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
! src/windows/classes/sun/nio/fs/WindowsPath.java
! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
! src/windows/native/java/io/canonicalize_md.c
! src/windows/native/java/net/DualStackPlainSocketImpl.c
! src/windows/native/java/net/icmp.h
! src/windows/native/sun/font/fontpath.c
! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp
! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp
! src/windows/native/sun/java2d/windows/GDIRenderer.cpp
! src/windows/native/sun/nio/ch/SocketChannelImpl.c
! src/windows/native/sun/security/krb5/NativeCreds.c
! src/windows/native/sun/windows/ThemeReader.cpp
! src/windows/native/sun/windows/awt_BitmapUtil.cpp
! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Dialog.h
! src/windows/native/sun/windows/awt_DnDDS.cpp
! src/windows/native/sun/windows/awt_Font.h
! src/windows/native/sun/windows/awt_InputTextInfor.cpp
! src/windows/native/sun/windows/awt_PrintJob.cpp
! src/windows/native/sun/windows/awt_TextComponent.cpp

Changeset: d4eb25382baf
Author:    malenkov
Date:      2013-10-29 19:01 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d4eb25382baf

8027442: JDK compilation fails on MacOS
Reviewed-by: alexsch, pchelko

! src/share/classes/java/awt/Component.java

Changeset: a2b42e558211
Author:    bagiras
Date:      2013-10-29 21:46 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a2b42e558211

8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine
Reviewed-by: anthony, pchelko

! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java

Changeset: db2838f25a85
Author:    pchelko
Date:      2013-10-30 12:00 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/db2838f25a85

8027152: Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112
Reviewed-by: art, serb

! src/share/classes/java/awt/Window.java
+ test/java/awt/Window/OwnedWindowsSerialization/OwnedWindowsSerialization.java

Changeset: 05f04b1c5bd0
Author:    leonidr
Date:      2013-10-30 20:54 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/05f04b1c5bd0

8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CWrapper.java
! src/macosx/native/sun/awt/AWTWindow.h
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CWrapper.m
+ test/java/awt/FullScreen/8013581/bug8013581.java

Changeset: 6f436140049d
Author:    lana
Date:      2013-10-31 16:22 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f436140049d

Merge

! src/share/classes/java/awt/image/ComponentSampleModel.java
! src/share/classes/sun/print/RasterPrinterJob.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java

Changeset: ecba02f6be31
Author:    sla
Date:      2013-10-29 08:10 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ecba02f6be31

8027371: Add JDI tests for breakpointing and stepping in lambda code
Reviewed-by: mchung, sspitsyn

+ test/com/sun/jdi/LambdaBreakpointTest.java
+ test/com/sun/jdi/LambdaStepTest.java

Changeset: d34c5e860d5f
Author:    aefimov
Date:      2013-10-24 17:23 +0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d34c5e860d5f

8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing
Reviewed-by: okutsu, mfang, alanb

! test/ProblemList.txt
! test/sun/util/resources/TimeZone/Bug6317929.java

Changeset: a8bbd962f34a
Author:    jlaskey
Date:      2013-01-28 16:29 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a8bbd962f34a

8006676: Integrate Nashorn into new build system
Reviewed-by: jlaskey
Contributed-by: james.laskey at oracle.com

! THIRD_PARTY_README
! make/launchers/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
! test/tools/launcher/VersionCheck.java

Changeset: 41654275896d
Author:    jlaskey
Date:      2013-02-04 17:29 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/41654275896d

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java
! test/tools/launcher/VersionCheck.java

Changeset: a174944b0c00
Author:    jlaskey
Date:      2013-02-21 15:25 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a174944b0c00

8008447: Tweaks to make all NEWBUILD=false round 3
Reviewed-by: jjh, sundar
Contributed-by: james.laskey at oracle.com

! make/launchers/Makefile

Changeset: 25db7658a063
Author:    jlaskey
Date:      2013-02-22 10:23 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/25db7658a063

8008721: Tweaks to make all NEWBUILD=false round 4
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! make/launchers/Makefile

Changeset: ea22045ce09b
Author:    jlaskey
Date:      2013-02-22 14:05 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ea22045ce09b

Merge

! makefiles/CreateJars.gmk

Changeset: ff68fafd6302
Author:    jlaskey
Date:      2013-02-22 17:45 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ff68fafd6302

8008756: THIRD_PARTY_README contains Unicode
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! THIRD_PARTY_README

Changeset: ce82a0ee7735
Author:    jlaskey
Date:      2013-02-22 18:03 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ce82a0ee7735

8008757: NEWBUILD=true has separate launcher code for jjs
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! makefiles/CompileLaunchers.gmk

Changeset: 20a827b22a2e
Author:    jlaskey
Date:      2013-02-22 23:36 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/20a827b22a2e

8008775: Remove non-ascii from jdk/THIRD_PARTY_README
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! THIRD_PARTY_README

Changeset: 364e0871f7a3
Author:    jlaskey
Date:      2013-03-02 11:06 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/364e0871f7a3

Merge

! make/launchers/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
- test/javax/script/RhinoExceptionTest.java
! test/tools/launcher/VersionCheck.java

Changeset: 3565c755c49f
Author:    jlaskey
Date:      2013-03-15 11:51 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3565c755c49f

Merge

! makefiles/CreateJars.gmk

Changeset: 8c223a4f906a
Author:    jlaskey
Date:      2013-03-26 09:12 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8c223a4f906a

Merge

! makefiles/CreateJars.gmk

Changeset: efbbcd5848cf
Author:    jlaskey
Date:      2013-04-01 10:09 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/efbbcd5848cf

Merge


Changeset: 39ce82dad57d
Author:    jlaskey
Date:      2013-04-09 08:36 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/39ce82dad57d

Merge


Changeset: ff9683b6854c
Author:    jlaskey
Date:      2013-04-15 08:27 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ff9683b6854c

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk

Changeset: 1cdf20da340b
Author:    jlaskey
Date:      2013-04-17 08:47 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1cdf20da340b

Merge


Changeset: 72fa581a83a4
Author:    jlaskey
Date:      2013-04-22 14:00 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/72fa581a83a4

Merge


Changeset: ead9944bbb3b
Author:    jlaskey
Date:      2013-04-29 21:37 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ead9944bbb3b

Merge


Changeset: 5bde43b1e463
Author:    jlaskey
Date:      2013-05-14 09:04 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5bde43b1e463

Merge


Changeset: efd620f8963f
Author:    jlaskey
Date:      2013-05-23 09:48 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/efd620f8963f

Merge

! makefiles/CreateJars.gmk

Changeset: 193652dff077
Author:    jlaskey
Date:      2013-05-29 13:22 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/193652dff077

Merge


Changeset: 733713d7517c
Author:    jlaskey
Date:      2013-06-05 13:10 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/733713d7517c

Merge

! makefiles/CompileLaunchers.gmk

Changeset: 3b464e13a776
Author:    jlaskey
Date:      2013-07-16 09:09 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b464e13a776

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
! test/tools/launcher/VersionCheck.java

Changeset: c0a2094aaafd
Author:    jlaskey
Date:      2013-07-24 08:22 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c0a2094aaafd

Merge

- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html

Changeset: 528fc8f4281b
Author:    jlaskey
Date:      2013-08-27 16:06 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/528fc8f4281b

Merge

! makefiles/CompileLaunchers.gmk

Changeset: be6ca7197e0e
Author:    jlaskey
Date:      2013-09-13 10:15 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/be6ca7197e0e

Merge

! makefiles/CreateJars.gmk
- src/share/classes/java/util/stream/CloseableStream.java
- src/share/classes/java/util/stream/DelegatingStream.java
- test/java/util/Map/CheckRandomHashSeed.java
- test/java/util/Map/TreeBinSplitBackToEntries.java
- test/sun/tools/jconsole/ImmutableResourceTest.java
- test/sun/tools/jconsole/ImmutableResourceTest.sh

Changeset: 74b1eb493407
Author:    jlaskey
Date:      2013-09-30 10:24 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/74b1eb493407

Merge

! makefiles/CreateJars.gmk

Changeset: f5c9333b6129
Author:    jlaskey
Date:      2013-10-29 10:40 -0300
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f5c9333b6129

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
! test/tools/launcher/VersionCheck.java

Changeset: 121c34517841
Author:    chegar
Date:      2013-10-29 17:21 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/121c34517841

8027466: Revert jdk/THIRD_PARTY_README to known good version
Reviewed-by: alanb

! THIRD_PARTY_README

Changeset: 6fc2889fe7d0
Author:    mfang
Date:      2013-10-29 11:27 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6fc2889fe7d0

8026108: [it, ja, zh_CN] wrong translation in jar example.
Reviewed-by: okutsu, yhuang

! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties

Changeset: 0cc9bdb22911
Author:    mfang
Date:      2013-10-29 11:29 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0cc9bdb22911

8008437: [sv] over-translation in java command line outputs
Reviewed-by: okutsu, yhuang

! src/share/classes/sun/tools/jar/resources/jar_sv.properties

Changeset: 331d8ced56dc
Author:    mfang
Date:      2013-10-29 11:34 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/331d8ced56dc

8025646: [pt_BR] overtranslation of option in java command line output
Reviewed-by: naoto, yhuang

! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties

Changeset: a3ac9c0b19a9
Author:    jbachorik
Date:      2013-10-29 21:49 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a3ac9c0b19a9

8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926
Reviewed-by: alanb, egahlin

! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java

Changeset: 8cfc73ad9f31
Author:    mfang
Date:      2013-10-29 15:31 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8cfc73ad9f31

8008647: [es] minor cosmetic issues in translated java command line outputs
Reviewed-by: naoto

! src/share/classes/sun/tools/jar/resources/jar_es.properties

Changeset: 4071c853edff
Author:    mfang
Date:      2013-10-29 15:32 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4071c853edff

Merge


Changeset: bede752d1e3c
Author:    mfang
Date:      2013-10-29 16:59 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bede752d1e3c

8025521: [de] mnemonic conflict in FileChooser for GTK Style feel&look
Reviewed-by: naoto

! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties

Changeset: 5d1bda6c1fe3
Author:    jbachorik
Date:      2013-10-30 14:50 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5d1bda6c1fe3

8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector
Summary: Dynamically discover the first available port instead of hard-coding one
Reviewed-by: sla, chegar, dfuchs

! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java

Changeset: 9a5048dc7c0d
Author:    chegar
Date:      2013-10-30 14:41 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9a5048dc7c0d

8026880: NetworkInterface native initializing code should check fieldID values
Reviewed-by: alanb

! src/solaris/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.c

Changeset: b04b124418d8
Author:    ykantser
Date:      2013-10-30 13:44 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b04b124418d8

8022229: Intermittent test failures in sun/tools/jstatd
Reviewed-by: sla, egahlin, jbachorik, allwin

+ test/lib/testlibrary/jdk/testlibrary/Asserts.java
+ test/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java
+ test/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java
+ test/lib/testlibrary/jdk/testlibrary/Platform.java
+ test/lib/testlibrary/jdk/testlibrary/ProcessThread.java
+ test/lib/testlibrary/jdk/testlibrary/TestThread.java
+ test/lib/testlibrary/jdk/testlibrary/Utils.java
+ test/lib/testlibrary/jdk/testlibrary/XRun.java
+ test/sun/tools/jstatd/JstatGCUtilParser.java
+ test/sun/tools/jstatd/JstatdTest.java
+ test/sun/tools/jstatd/TestJstatdDefaults.java
+ test/sun/tools/jstatd/TestJstatdExternalRegistry.java
+ test/sun/tools/jstatd/TestJstatdPort.java
+ test/sun/tools/jstatd/TestJstatdPortAndServer.java
+ test/sun/tools/jstatd/TestJstatdServer.java
+ test/sun/tools/jstatd/TestJstatdUsage.java
- test/sun/tools/jstatd/jpsOutput1.awk
- test/sun/tools/jstatd/jstatGcutilOutput1.awk
- test/sun/tools/jstatd/jstatdDefaults.sh
- test/sun/tools/jstatd/jstatdExternalRegistry.sh
- test/sun/tools/jstatd/jstatdPort.sh
- test/sun/tools/jstatd/jstatdServerName.sh
- test/sun/tools/jstatd/jstatdUsage1.sh
- test/sun/tools/jstatd/usage.out

Changeset: 550244957351
Author:    mfang
Date:      2013-10-30 09:33 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/550244957351

6192407: s10_70, ko, s1/dvd, minor misspelling under "Select Software Localizations"
Reviewed-by: yhuang

! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: e45b48874ba9
Author:    mfang
Date:      2013-10-30 09:37 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e45b48874ba9

6931564: Incorrect display name of Locale for south africa
Reviewed-by: yhuang

! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: 2a714dabb624
Author:    jbachorik
Date:      2013-10-30 17:54 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a714dabb624

8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool
Reviewed-by: mchung, brutisso

! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java

Changeset: 7bc67bed3c14
Author:    michaelm
Date:      2013-10-30 18:37 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7bc67bed3c14

8027570: NullPointerException in URLPermission.hashCode()
Reviewed-by: chegar

! src/share/classes/java/net/URLPermission.java
! test/java/net/URLPermission/URLPermissionTest.java

Changeset: 281e26d7f325
Author:    michaelm
Date:      2013-10-30 18:38 +0000
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/281e26d7f325

Merge

- make/sun/awt/FILES_c_macosx.gmk
- make/sun/awt/FILES_export_macosx.gmk
- makefiles/GendataBreakIterator.gmk
- makefiles/GendataFontConfig.gmk
- makefiles/GendataHtml32dtd.gmk
- makefiles/GendataTZDB.gmk
- makefiles/GendataTimeZone.gmk
- makefiles/GenerateJavaSources.gmk
- makefiles/GensrcBuffer.gmk
- makefiles/GensrcCLDR.gmk
- makefiles/GensrcCharacterData.gmk
- makefiles/GensrcCharsetCoder.gmk
- makefiles/GensrcCharsetMapping.gmk
- makefiles/GensrcExceptions.gmk
- makefiles/GensrcIcons.gmk
- makefiles/GensrcJDWP.gmk
- makefiles/GensrcJObjC.gmk
- makefiles/GensrcLocaleDataMetaInfo.gmk
- makefiles/GensrcMisc.gmk
- makefiles/GensrcProperties.gmk
- makefiles/GensrcSwing.gmk
- makefiles/GensrcX11Wrappers.gmk
- src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java
- src/macosx/native/com/apple/resources/MacOSXResourceBundle.m
- src/share/classes/java/lang/invoke/MagicLambdaImpl.java
! src/share/classes/java/net/URLPermission.java
- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties
- src/solaris/doc/sun/man/man1/ja/javaws.1
- src/solaris/doc/sun/man/man1/javaws.1
- test/java/net/NetworkInterface/MemLeakTest.java
- test/jdk/lambda/vm/DefaultMethodsTest.java
- test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
- test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh
- test/sun/tools/jstatd/jpsOutput1.awk
- test/sun/tools/jstatd/jstatGcutilOutput1.awk
- test/sun/tools/jstatd/jstatdDefaults.sh
- test/sun/tools/jstatd/jstatdExternalRegistry.sh
- test/sun/tools/jstatd/jstatdPort.sh
- test/sun/tools/jstatd/jstatdServerName.sh
- test/sun/tools/jstatd/jstatdUsage1.sh
- test/sun/tools/jstatd/usage.out

Changeset: 348ffbd19feb
Author:    lana
Date:      2013-10-30 13:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/348ffbd19feb

Merge

! makefiles/CreateJars.gmk
+ makefiles/CreateSecurityJars.gmk

Changeset: ddb0b681654a
Author:    briangoetz
Date:      2013-10-29 12:31 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ddb0b681654a

8027318: Lambda Metafactory: generate serialization-hostile read/writeObject methods for non-serializable lambdas
Reviewed-by: rfield, psandoz

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java

Changeset: f731d096530f
Author:    wetmore
Date:      2013-10-30 16:49 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f731d096530f

8027526: CheckTipsAndVersions.java failing occasionally
Reviewed-by: mullan, mchung

! test/java/security/Signature/SignatureGetAlgorithm.java

Changeset: e8894e3224d9
Author:    darcy
Date:      2013-10-30 17:27 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e8894e3224d9

8005294: Consider default methods for additions to AnnotatedElement
Reviewed-by: jfranck, plevart, mchung, abuckley, sogoel

! src/share/classes/java/lang/reflect/AnnotatedElement.java
+ test/java/lang/reflect/AnnotatedElement/TestAnnotatedElementDefaults.java

Changeset: 0734e1584d9d
Author:    bpb
Date:      2013-10-30 17:45 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0734e1584d9d

6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers
8021203: BigInteger.doubleValue/floatValue returns 0.0 instead of Infinity
8021204: Constructor BigInteger(String val, int radix) doesn't detect overflow
8022780: Incorrect BigInteger division because of MutableBigInteger.bitLength() overflow
Summary: Prevent construction of overflowed BigIntegers.
Reviewed-by: bpb, darcy, psandoz
Contributed-by: Dmitry Nadezhin <dmitry.nadezhin at oracle.com>

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
+ test/java/math/BigInteger/BitLengthOverflow.java
+ test/java/math/BigInteger/DivisionOverflow.java
+ test/java/math/BigInteger/DoubleValueOverflow.java
! test/java/math/BigInteger/ExtremeShiftingTests.java
+ test/java/math/BigInteger/StringConstructorOverflow.java
+ test/java/math/BigInteger/SymmetricRangeTests.java

Changeset: 1ea1b24c1a04
Author:    smarks
Date:      2013-10-30 18:39 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1ea1b24c1a04

8023863: deprecate support for statically-generated stubs from RMI (JRMP)
4449028: exportObject() javadoc should specify behavior for null socket factories
Reviewed-by: dfuchs, darcy

! src/share/classes/java/rmi/server/RemoteStub.java
! src/share/classes/java/rmi/server/UnicastRemoteObject.java
! src/share/classes/java/rmi/server/package.html

Changeset: 18c111c17231
Author:    psandoz
Date:      2013-10-31 11:59 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/18c111c17231

8027316: Distinct operation on an unordered stream should not be a barrier
Reviewed-by: henryjen, mduigou, briangoetz

! src/share/classes/java/util/stream/DistinctOps.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java

Changeset: bb4b1e1e390d
Author:    jbachorik
Date:      2013-10-31 11:59 +0100
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bb4b1e1e390d

7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled
Summary: Make the test less stringent by not requiring the number of loaded classes to increase by a specific number
Reviewed-by: sla

! test/ProblemList.txt
! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java

Changeset: 82ee370c3d7e
Author:    briangoetz
Date:      2013-10-31 10:37 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/82ee370c3d7e

8024637: Lambda linkage performance - use reflection instead of ASM to manipulate parameter types
8023984: Lambda linkage performance - use a method ref to a static factory instead of a ctor ref
Reviewed-by: briangoetz, rfield
Contributed-by: sergey.kuksenko at oracle.com

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java

Changeset: 9732816c9d17
Author:    briangoetz
Date:      2013-10-29 12:45 -0400
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9732816c9d17

8024633: Lambda linkage performance - initialize generated class earlier
Reviewed-by: briangoetz, rfield
Contributed-by: sergey.kuksenko at oracle.com

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java

Changeset: e93de88661ab
Author:    dxu
Date:      2013-10-31 11:52 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e93de88661ab

8027155: test/java/io/File/NulFile.java failing when test run in othervm mode
Reviewed-by: mchung, alanb

! test/java/io/File/NulFile.java

Changeset: c4bbd5963f9c
Author:    joehw
Date:      2013-10-31 13:51 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c4bbd5963f9c

8024876: [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions
Reviewed-by: chegar

! test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java

Changeset: f82b730c798b
Author:    lana
Date:      2013-10-31 16:44 -0700
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f82b730c798b

Merge

- src/share/classes/java/lang/invoke/MagicLambdaImpl.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/javax/naming/ldap/Rdn.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/tools/jar/Main.java
- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties
! src/share/javavm/export/jvm.h
! src/share/native/com/sun/java/util/jar/pack/zip.cpp
! src/solaris/classes/sun/nio/fs/UnixPath.java
- test/java/net/NetworkInterface/MemLeakTest.java
- test/jdk/lambda/vm/DefaultMethodsTest.java
- test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
- test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh
- test/sun/tools/jstatd/jpsOutput1.awk
- test/sun/tools/jstatd/jstatGcutilOutput1.awk
- test/sun/tools/jstatd/jstatdDefaults.sh
- test/sun/tools/jstatd/jstatdExternalRegistry.sh
- test/sun/tools/jstatd/jstatdPort.sh
- test/sun/tools/jstatd/jstatdServerName.sh
- test/sun/tools/jstatd/jstatdUsage1.sh
- test/sun/tools/jstatd/usage.out

Changeset: 99dd9e50f37e
Author:    henryjen
Date:      2013-11-11 23:17 -0800
URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/99dd9e50f37e

Merge

! .hgtags
- .jcheck/conf
! makefiles/CreateJars.gmk
! makefiles/CreateSecurityJars.gmk
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/beans/EventHandler.java
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/java/util/stream/DistinctOps.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/javavm/export/jvm.h
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/windows/classes/sun/nio/fs/WindowsPath.java
! test/ProblemList.txt
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java


From forax at univ-mlv.fr  Wed Nov 13 01:37:58 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 13 Nov 2013 10:37:58 +0100
Subject: Local Functional Interfaces
In-Reply-To: <CAHaxNQwOGqFyoOaPGo6Z-_YOBP9DC8KQxDyoMur_QvVJzHwqcQ@mail.gmail.com>
References: <CAHaxNQwOGqFyoOaPGo6Z-_YOBP9DC8KQxDyoMur_QvVJzHwqcQ@mail.gmail.com>
Message-ID: <52834876.2050401@univ-mlv.fr>

Hi Olena,
interface local to method (like enum BTW) are not valid in Java,
so it's not really an issue related to lambdas but more an issue related 
to allowing local interface in method.

First, because the interface defined a static context, local interface 
can be only defined in a static method,
otherwise you can have an initializer or a default method in the 
interface that access to the field
of the enclosing class.

public class Snippet {
   static void myMethod() {
     interface Runner { public void run(); }
     Runner runner = () -> System.out.println("hello");
     runner.run();
   }
}

This seriously reduce the possible interesting use classes making a 
local interface not very useful.

cheers,
R?mi

On 09/23/2013 09:27 PM, Olena Syrota wrote:
> Dear lambda dev team,
>
> Recently I made experiments with lamdas and found exotic case.
> I was not able to declare local interface to make a "local" lambda-function.
>
> Why I needed this.
> Suppose I was to implement "local" lamdba-function to be used only couple
> of times inside my method.
> Compiler did not allowed me to place interface inside function.
> In my case it was interface Dropper to implement lambda-function that drops
> last element.
>
> void myMethod(...) {
>
> Interface Dropper { dropLastSymbolInChain (List<List<String>> chain);}
> Dropper d = x -> x.stream()
> .map(e->e.subList(0, e.size()-2))
> .collect(Collectors.toList());
>
> List<List<String>> chain1Dropped = d.dropLastSymbolInChain(chain1);
> List<List<String>> chain2Dropped = d.dropLastSymbolInChain(chain2);
> }
>
> I was forced to declare interface Dropper outside myMethod.
>
> Should the proposition on local interfaces be submitted to jep?
>
>
> Thank you.
> Olena
>


From akarnokd at gmail.com  Wed Nov 13 06:01:46 2013
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Wed, 13 Nov 2013 15:01:46 +0100
Subject: Ambiguous reference
Message-ID: <CAAWwtm-gAcFtL=yc2RBQ=n6hk+HuJSru7F2kNdAJifVbhs3Bpg@mail.gmail.com>

Hello,

I'm rewriting a library and run into a strange ambiguity error reported by
javac in JDK 8 b115, Windows 7 x86:

public class Bug<T> {
    public void forEach(Consumer<? super T> consumer) {
        // ...
    }
    public void forEach(BiConsumer<? super Integer, ? super T> consumer) {
        forEach((v) -> consumer.accept(1, v));
    }
    public void forEach(Predicate<? super T> stoppableConsumer) {
        // ...
    }
    public void forEach(BiPredicate<? super Integer, ? super T>
stoppableConsumer) {
        forEach(v -> stoppableConsumer.test(1, v));
    }
}

error: reference to forEach is ambiguous
        forEach((v) -> consumer.accept(1, v));
  both method forEach(Consumer<? super T>) in Bug and method
forEach(Predicate<? super T>) in Bug match
  where T is a type-variable:
    T extends Object declared in class Bug

error: reference to forEach is ambiguous
        forEach(v -> stoppableConsumer.test(1, v));
  both method forEach(Consumer<? super T>) in Bug and method
forEach(Predicate<? super T>) in Bug match
  where T is a type-variable:
    T extends Object declared in class Bug

I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
ambiguity in the editor, and the "highlight occurrences" correctly selects
the 3rd method when I select the forEach in the 4th method. However, the
clean and build fails with the errors above. I have to add explicit cast to
the problematic places.

So I'm a bit confused right now. Is it a bug with NetBeans' editor, with
javac or simply the artifact of how overload resolution works?
-- 
Best regards,
David Karnok

From ali.ebrahimi1781 at gmail.com  Wed Nov 13 06:29:46 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Wed, 13 Nov 2013 17:59:46 +0330
Subject: Local Functional Interfaces
In-Reply-To: <52834876.2050401@univ-mlv.fr>
References: <CAHaxNQwOGqFyoOaPGo6Z-_YOBP9DC8KQxDyoMur_QvVJzHwqcQ@mail.gmail.com>
	<52834876.2050401@univ-mlv.fr>
Message-ID: <CAA0cW5Ape=kUiJDfoE98kVfkjQUGnTTZj_ohPbHWcra8TqPoEg@mail.gmail.com>

In better words, interface declarations are implicitly static and you can
not have static declarations in local context (method body).


On Wed, Nov 13, 2013 at 1:07 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Olena,
> interface local to method (like enum BTW) are not valid in Java,
> so it's not really an issue related to lambdas but more an issue related
> to allowing local interface in method.
>
> First, because the interface defined a static context, local interface
> can be only defined in a static method,
> otherwise you can have an initializer or a default method in the
> interface that access to the field
> of the enclosing class.
>
> public class Snippet {
>    static void myMethod() {
>      interface Runner { public void run(); }
>      Runner runner = () -> System.out.println("hello");
>      runner.run();
>    }
> }
>
> This seriously reduce the possible interesting use classes making a
> local interface not very useful.
>
> cheers,
> R?mi
>
> On 09/23/2013 09:27 PM, Olena Syrota wrote:
> > Dear lambda dev team,
> >
> > Recently I made experiments with lamdas and found exotic case.
> > I was not able to declare local interface to make a "local"
> lambda-function.
> >
> > Why I needed this.
> > Suppose I was to implement "local" lamdba-function to be used only couple
> > of times inside my method.
> > Compiler did not allowed me to place interface inside function.
> > In my case it was interface Dropper to implement lambda-function that
> drops
> > last element.
> >
> > void myMethod(...) {
> >
> > Interface Dropper { dropLastSymbolInChain (List<List<String>> chain);}
> > Dropper d = x -> x.stream()
> > .map(e->e.subList(0, e.size()-2))
> > .collect(Collectors.toList());
> >
> > List<List<String>> chain1Dropped = d.dropLastSymbolInChain(chain1);
> > List<List<String>> chain2Dropped = d.dropLastSymbolInChain(chain2);
> > }
> >
> > I was forced to declare interface Dropper outside myMethod.
> >
> > Should the proposition on local interfaces be submitted to jep?
> >
> >
> > Thank you.
> > Olena
> >
>
>
>

From forax at univ-mlv.fr  Wed Nov 13 06:45:27 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 13 Nov 2013 15:45:27 +0100
Subject: Local Functional Interfaces
Message-ID: <96jv00sgi6un6mvtfld4ycrk.1384353927514@email.android.com>

I was trying to explain why :)

cheers,
R?mi

From my smartphone

-------- Message d'origine --------
De : Ali Ebrahimi <ali.ebrahimi1781 at gmail.com> 
Date : 13/11/2013  15:29  (GMT+01:00) 
A : Remi Forax <forax at univ-mlv.fr> 
Cc : lambda-dev <lambda-dev at openjdk.java.net> 
Objet : Re: Local Functional Interfaces 
 
In better words, interface declarations are implicitly static and you can not have static declarations in local context (method body).


On Wed, Nov 13, 2013 at 1:07 PM, Remi Forax <forax at univ-mlv.fr> wrote:
Hi Olena,
interface local to method (like enum BTW) are not valid in Java,
so it's not really an issue related to lambdas but more an issue related
to allowing local interface in method.

First, because the interface defined a static context, local interface
can be only defined in a static method,
otherwise you can have an initializer or a default method in the
interface that access to the field
of the enclosing class.

public class Snippet {
? ?static void myMethod() {
? ? ?interface Runner { public void run(); }
? ? ?Runner runner = () -> System.out.println("hello");
? ? ?runner.run();
? ?}
}

This seriously reduce the possible interesting use classes making a
local interface not very useful.

cheers,
R?mi

On 09/23/2013 09:27 PM, Olena Syrota wrote:
> Dear lambda dev team,
>
> Recently I made experiments with lamdas and found exotic case.
> I was not able to declare local interface to make a "local" lambda-function.
>
> Why I needed this.
> Suppose I was to implement "local" lamdba-function to be used only couple
> of times inside my method.
> Compiler did not allowed me to place interface inside function.
> In my case it was interface Dropper to implement lambda-function that drops
> last element.
>
> void myMethod(...) {
>
> Interface Dropper { dropLastSymbolInChain (List<List<String>> chain);}
> Dropper d = x -> x.stream()
> .map(e->e.subList(0, e.size()-2))
> .collect(Collectors.toList());
>
> List<List<String>> chain1Dropped = d.dropLastSymbolInChain(chain1);
> List<List<String>> chain2Dropped = d.dropLastSymbolInChain(chain2);
> }
>
> I was forced to declare interface Dropper outside myMethod.
>
> Should the proposition on local interfaces be submitted to jep?
>
>
> Thank you.
> Olena
>




From matthew at matthewadams.me  Wed Nov 13 08:49:52 2013
From: matthew at matthewadams.me (Matthew Adams)
Date: Wed, 13 Nov 2013 10:49:52 -0600
Subject: Stateless traits & default interface methods question
Message-ID: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>

_Note: This may be a FAQ.  RTFMs are fine._

I have a question about default interface methods, thinking in terms of
stateless traits.

Assume at time t0 I define an interface I with a given default method
implementation and class C implements I.  Later, at time t1, I modify the
implementations of I's default methods _without_ recompiling C.  The next
time that I execute a method on C that came from a default method on I, do
I get I's implementation as it was at t0 or t1?

In other words, are default method implementations woven into classes at
compile time, do classes delegate to the interface's default method
implementation at runtime, or is it via some other mechanism?

-matthew
-- 
mailto:matthew at matthewadams.me <matthew at matthewadams.me>
skype:matthewadams12
googletalk:matthew at matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

From Sebastian.Millies at softwareag.com  Wed Nov 13 09:14:02 2013
From: Sebastian.Millies at softwareag.com (Millies, Sebastian)
Date: Wed, 13 Nov 2013 17:14:02 +0000
Subject: Stateless traits & default interface methods question
In-Reply-To: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
References: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
Message-ID: <32F15738E8E5524DA4F01A0FA4A8E490C2FE5E87@HQMBX5.eur.ad.sag>

Hi Matthew,

I've just tested this, and you'll get the implementation at time t1, i. e. the implementation as it is at runtime.
However, I don't know by what mechanism.

-- Sebastian

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Matthew Adams
Sent: Wednesday, November 13, 2013 5:50 PM
To: lambda-dev at openjdk.java.net
Subject: Stateless traits & default interface methods question

_Note: This may be a FAQ.  RTFMs are fine._

I have a question about default interface methods, thinking in terms of stateless traits.

Assume at time t0 I define an interface I with a given default method implementation and class C implements I.  Later, at time t1, I modify the implementations of I's default methods _without_ recompiling C.  The next time that I execute a method on C that came from a default method on I, do I get I's implementation as it was at t0 or t1?

In other words, are default method implementations woven into classes at compile time, do classes delegate to the interface's default method implementation at runtime, or is it via some other mechanism?

-matthew
--
mailto:matthew at matthewadams.me <matthew at matthewadams.me>
skype:matthewadams12
googletalk:matthew at matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams


Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From kmcguigan at twitter.com  Wed Nov 13 09:14:52 2013
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Wed, 13 Nov 2013 09:14:52 -0800
Subject: Stateless traits & default interface methods question
In-Reply-To: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
References: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
Message-ID: <CADNkbOFerM+4c+wjjiUKBQEQp4mDC449qTZCsKo6UkGeMp==Qg@mail.gmail.com>

The decision is made a class load time, so you would get the t1
implementation (assume a VM restart happened in between and C was reloaded,
of course).

--
- Keith


On Wed, Nov 13, 2013 at 8:49 AM, Matthew Adams <matthew at matthewadams.me>wrote:

> _Note: This may be a FAQ.  RTFMs are fine._
>
> I have a question about default interface methods, thinking in terms of
> stateless traits.
>
> Assume at time t0 I define an interface I with a given default method
> implementation and class C implements I.  Later, at time t1, I modify the
> implementations of I's default methods _without_ recompiling C.  The next
> time that I execute a method on C that came from a default method on I, do
> I get I's implementation as it was at t0 or t1?
>
> In other words, are default method implementations woven into classes at
> compile time, do classes delegate to the interface's default method
> implementation at runtime, or is it via some other mechanism?
>
> -matthew
> --
> mailto:matthew at matthewadams.me <matthew at matthewadams.me>
> skype:matthewadams12
> googletalk:matthew at matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>
>

From zhong.j.yu at gmail.com  Wed Nov 13 10:59:11 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 13 Nov 2013 12:59:11 -0600
Subject: Ambiguous reference
In-Reply-To: <CAAWwtm-gAcFtL=yc2RBQ=n6hk+HuJSru7F2kNdAJifVbhs3Bpg@mail.gmail.com>
References: <CAAWwtm-gAcFtL=yc2RBQ=n6hk+HuJSru7F2kNdAJifVbhs3Bpg@mail.gmail.com>
Message-ID: <CACuKZqHFmgoAEwqVoT2UvKwD_V=7VCu2R-pjvwH+0O7msv9sjg@mail.gmail.com>

Here's my understanding how the process works.

When javac sees

    forEach( v->... )

two pieces of information of the implicit lambda are used to prune
overloading methods:
1. the arity. therefore BiConsumer/BiPredicate are excluded
2. whether the lambda body returns void or a real type.

If the lambda body is a block, it's quite clear whether it's void or
not. It seems to me that this would work:

    public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
        forEach((v) -> { biConsumer.accept(1, v); });
    }
    public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
        forEach(v -> { return biPredicate.test(1, v); } );
    }

( ... But it fails in javac build 115. javac bug?)

If the lambda body is a "statement expression", like in your original example

    public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
        forEach((v) -> biConsumer.accept(1, v) );
    }
    public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
        forEach(v -> biPredicate.test(1, v) );
    }

It's unclear what the return type is, so javac cannot use the return
type to prune. Note that even though `biConsumer.accept(1, v)`
obviously returns void, javac does not know that, because the type of
`v` is not known yet. And even though `biPredicate.test(1, v)`
obviously returns boolean, it is compatible to a function type that
expects void return.

Now, for each invocation, we have two potentially applicable methods.

The next step tries to prune methods by checking argument types
against method parameter types. Unfortunately, implicit lambda
expressions are too vague, so they are simply ignored in this step.

Therefore both methods are considered applicable methods. The most
specific method is sought after. However neither method is more
specific than the other, therefore we see the error message of
ambiguity.

If you use explicit lambda expressions, javac is able to do more
pruning, so this works:

    public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
        forEach((T v) -> biConsumer.accept(1, v) );
    }
    public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
        forEach( (T v) -> biPredicate.test(1, v) );
    }

So if you have overloading methods like this

    public void forEach(Consumer<? super T> consumer) {
        // ...
    }
    public void forEach(Predicate<? super T> predicate) {
        // ...
    }

client code often cannot use implicit lambda expressions as arguments;
and experts have advised against this kind of overloading scheme (two
functional interfaces with the same arity)


Zhong Yu

On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
> Hello,
>
> I'm rewriting a library and run into a strange ambiguity error reported by
> javac in JDK 8 b115, Windows 7 x86:
>
> public class Bug<T> {
>     public void forEach(Consumer<? super T> consumer) {
>         // ...
>     }
>     public void forEach(BiConsumer<? super Integer, ? super T> consumer) {
>         forEach((v) -> consumer.accept(1, v));
>     }
>     public void forEach(Predicate<? super T> stoppableConsumer) {
>         // ...
>     }
>     public void forEach(BiPredicate<? super Integer, ? super T>
> stoppableConsumer) {
>         forEach(v -> stoppableConsumer.test(1, v));
>     }
> }
>
> error: reference to forEach is ambiguous
>         forEach((v) -> consumer.accept(1, v));
>   both method forEach(Consumer<? super T>) in Bug and method
> forEach(Predicate<? super T>) in Bug match
>   where T is a type-variable:
>     T extends Object declared in class Bug
>
> error: reference to forEach is ambiguous
>         forEach(v -> stoppableConsumer.test(1, v));
>   both method forEach(Consumer<? super T>) in Bug and method
> forEach(Predicate<? super T>) in Bug match
>   where T is a type-variable:
>     T extends Object declared in class Bug
>
> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
> ambiguity in the editor, and the "highlight occurrences" correctly selects
> the 3rd method when I select the forEach in the 4th method. However, the
> clean and build fails with the errors above. I have to add explicit cast to
> the problematic places.
>
> So I'm a bit confused right now. Is it a bug with NetBeans' editor, with
> javac or simply the artifact of how overload resolution works?
> --
> Best regards,
> David Karnok
>

From zhong.j.yu at gmail.com  Wed Nov 13 11:04:46 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 13 Nov 2013 13:04:46 -0600
Subject: Javac Bug?
Message-ID: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>

This program does not compile in javac8 build 115. I think it should
compile (but who knows really:)

public class Bug<T> {
    public void forEach(Consumer<? super T> consumer) {
        // ...
    }
    public void forEach(Predicate<? super T> predicate) {
        // ...
    }
    public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
        forEach((v) -> { biConsumer.accept(1, v); });
    }
    public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
        forEach(v -> { return biPredicate.test(1, v); } );
    }
}



On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> Here's my understanding how the process works.
>
> When javac sees
>
>     forEach( v->... )
>
> two pieces of information of the implicit lambda are used to prune
> overloading methods:
> 1. the arity. therefore BiConsumer/BiPredicate are excluded
> 2. whether the lambda body returns void or a real type.
>
> If the lambda body is a block, it's quite clear whether it's void or
> not. It seems to me that this would work:
>
>     public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>         forEach((v) -> { biConsumer.accept(1, v); });
>     }
>     public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>         forEach(v -> { return biPredicate.test(1, v); } );
>     }
>
> ( ... But it fails in javac build 115. javac bug?)
>
> If the lambda body is a "statement expression", like in your original example
>
>     public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>         forEach((v) -> biConsumer.accept(1, v) );
>     }
>     public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>         forEach(v -> biPredicate.test(1, v) );
>     }
>
> It's unclear what the return type is, so javac cannot use the return
> type to prune. Note that even though `biConsumer.accept(1, v)`
> obviously returns void, javac does not know that, because the type of
> `v` is not known yet. And even though `biPredicate.test(1, v)`
> obviously returns boolean, it is compatible to a function type that
> expects void return.
>
> Now, for each invocation, we have two potentially applicable methods.
>
> The next step tries to prune methods by checking argument types
> against method parameter types. Unfortunately, implicit lambda
> expressions are too vague, so they are simply ignored in this step.
>
> Therefore both methods are considered applicable methods. The most
> specific method is sought after. However neither method is more
> specific than the other, therefore we see the error message of
> ambiguity.
>
> If you use explicit lambda expressions, javac is able to do more
> pruning, so this works:
>
>     public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>         forEach((T v) -> biConsumer.accept(1, v) );
>     }
>     public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>         forEach( (T v) -> biPredicate.test(1, v) );
>     }
>
> So if you have overloading methods like this
>
>     public void forEach(Consumer<? super T> consumer) {
>         // ...
>     }
>     public void forEach(Predicate<? super T> predicate) {
>         // ...
>     }
>
> client code often cannot use implicit lambda expressions as arguments;
> and experts have advised against this kind of overloading scheme (two
> functional interfaces with the same arity)
>
>
> Zhong Yu
>
> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
>> Hello,
>>
>> I'm rewriting a library and run into a strange ambiguity error reported by
>> javac in JDK 8 b115, Windows 7 x86:
>>
>> public class Bug<T> {
>>     public void forEach(Consumer<? super T> consumer) {
>>         // ...
>>     }
>>     public void forEach(BiConsumer<? super Integer, ? super T> consumer) {
>>         forEach((v) -> consumer.accept(1, v));
>>     }
>>     public void forEach(Predicate<? super T> stoppableConsumer) {
>>         // ...
>>     }
>>     public void forEach(BiPredicate<? super Integer, ? super T>
>> stoppableConsumer) {
>>         forEach(v -> stoppableConsumer.test(1, v));
>>     }
>> }
>>
>> error: reference to forEach is ambiguous
>>         forEach((v) -> consumer.accept(1, v));
>>   both method forEach(Consumer<? super T>) in Bug and method
>> forEach(Predicate<? super T>) in Bug match
>>   where T is a type-variable:
>>     T extends Object declared in class Bug
>>
>> error: reference to forEach is ambiguous
>>         forEach(v -> stoppableConsumer.test(1, v));
>>   both method forEach(Consumer<? super T>) in Bug and method
>> forEach(Predicate<? super T>) in Bug match
>>   where T is a type-variable:
>>     T extends Object declared in class Bug
>>
>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>> ambiguity in the editor, and the "highlight occurrences" correctly selects
>> the 3rd method when I select the forEach in the 4th method. However, the
>> clean and build fails with the errors above. I have to add explicit cast to
>> the problematic places.
>>
>> So I'm a bit confused right now. Is it a bug with NetBeans' editor, with
>> javac or simply the artifact of how overload resolution works?
>> --
>> Best regards,
>> David Karnok
>>

From zhong.j.yu at gmail.com  Wed Nov 13 11:14:37 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 13 Nov 2013 13:14:37 -0600
Subject: Ambiguous reference
In-Reply-To: <CACuKZqHFmgoAEwqVoT2UvKwD_V=7VCu2R-pjvwH+0O7msv9sjg@mail.gmail.com>
References: <CAAWwtm-gAcFtL=yc2RBQ=n6hk+HuJSru7F2kNdAJifVbhs3Bpg@mail.gmail.com>
	<CACuKZqHFmgoAEwqVoT2UvKwD_V=7VCu2R-pjvwH+0O7msv9sjg@mail.gmail.com>
Message-ID: <CACuKZqFZxo09dE9xR+oJfcnzsZeE_EUEJY_jA_uW4vLL8XrL+Q@mail.gmail.com>

One thing I find quite worrisome in the new overload resolution - In
Java7, applicable methods are "actually" applicable. The "choosing the
most specific method" step is guaranteed to chose an actually
applicable method.

In Java8, that's not the case in a lot of times. Applicable methods
may not be actually applicable, and the "most specific" step may
choose a method that fails to pass further compilation.

This can be quite confusing to the programmer:

case 1. javac reports ambiguity because two methods are applicable -
while it is very clear to the programmer that one of the method is not
actrually applicable.

case 2. javac chooses the most specific method, then finds that it is
not actually applicable, reports that arguments do not fit the
parameter types - while it seems very clear to the programmer that
this method should not be a candidate in the first place.


Zhong Yu

From zhong.j.yu at gmail.com  Wed Nov 13 12:03:20 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 13 Nov 2013 14:03:20 -0600
Subject: Stateless traits & default interface methods question
In-Reply-To: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
References: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
Message-ID: <CACuKZqGd_eKoWk2DKiA5atQTqHE=w88A+P_GdUWmPBrNcX4OHQ@mail.gmail.com>

I certainly hope it's the later - the interface and the class could be
distributed by different parties; changing an implementation detail on
the interface should not require recompiling all subclasses.

Zhong Yu

On Wed, Nov 13, 2013 at 10:49 AM, Matthew Adams <matthew at matthewadams.me> wrote:
> _Note: This may be a FAQ.  RTFMs are fine._
>
> I have a question about default interface methods, thinking in terms of
> stateless traits.
>
> Assume at time t0 I define an interface I with a given default method
> implementation and class C implements I.  Later, at time t1, I modify the
> implementations of I's default methods _without_ recompiling C.  The next
> time that I execute a method on C that came from a default method on I, do
> I get I's implementation as it was at t0 or t1?
>
> In other words, are default method implementations woven into classes at
> compile time, do classes delegate to the interface's default method
> implementation at runtime, or is it via some other mechanism?
>
> -matthew
> --
> mailto:matthew at matthewadams.me <matthew at matthewadams.me>
> skype:matthewadams12
> googletalk:matthew at matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

From pbenedict at apache.org  Wed Nov 13 17:43:45 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Wed, 13 Nov 2013 19:43:45 -0600
Subject: @Override and default methods
Message-ID: <CABLGb9yz=ijo-7Us=hd2PfgkUdMo3dRZzrqaA68oetQ8hGeWMw@mail.gmail.com>

I saw this email come through Apache and would like your opinions:

===
Hi,

during the vote for collections 4.0 we have discovered a problem wrt the
MultiMap interface in general and specifically the MultiKeyMap.

Java 8 introduces a new default method in the Map interface:

 boolean remove(Object key, Object value)

This clashes with the method in MultiMap:

 V remove(K key, V value)

and the remove methods for multiple keys in MultiKeyMap:

 V remove(K key1, K key2)

Just changing the return type does not solve the problem, as one can not
re-define a method in an interface without using the @Override
annotation, but this would only work when compiling with JDK 8 and fail
for other JDKs.
===

What is the correct course in such a situation?

-- 
Cheers,
Paul

From david.holmes at oracle.com  Wed Nov 13 19:21:10 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Nov 2013 19:21:10 -0800
Subject: Stateless traits & default interface methods question
In-Reply-To: <32F15738E8E5524DA4F01A0FA4A8E490C2FE5E87@HQMBX5.eur.ad.sag>
References: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
	<32F15738E8E5524DA4F01A0FA4A8E490C2FE5E87@HQMBX5.eur.ad.sag>
Message-ID: <528441A6.6080801@oracle.com>

On 13/11/2013 9:14 AM, Millies, Sebastian wrote:
> Hi Matthew,
>
> I've just tested this, and you'll get the implementation at time t1, i. e. the implementation as it is at runtime.
> However, I don't know by what mechanism.

The normal mechanism by which you get whatever bytecode is in the 
compiled interface's .class file when it is loaded at runtime. Logically 
the class delegates to the interface's default method implementation. 
Nothing special happens at Java source code compilation time.

David

> -- Sebastian
>
> -----Original Message-----
> From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Matthew Adams
> Sent: Wednesday, November 13, 2013 5:50 PM
> To: lambda-dev at openjdk.java.net
> Subject: Stateless traits & default interface methods question
>
> _Note: This may be a FAQ.  RTFMs are fine._
>
> I have a question about default interface methods, thinking in terms of stateless traits.
>
> Assume at time t0 I define an interface I with a given default method implementation and class C implements I.  Later, at time t1, I modify the implementations of I's default methods _without_ recompiling C.  The next time that I execute a method on C that came from a default method on I, do I get I's implementation as it was at t0 or t1?
>
> In other words, are default method implementations woven into classes at compile time, do classes delegate to the interface's default method implementation at runtime, or is it via some other mechanism?
>
> -matthew
> --
> mailto:matthew at matthewadams.me <matthew at matthewadams.me>
> skype:matthewadams12
> googletalk:matthew at matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>
>
> Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>
>

From peter.levart at gmail.com  Wed Nov 13 23:09:34 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 14 Nov 2013 08:09:34 +0100
Subject: Local Functional Interfaces
In-Reply-To: <CAA0cW5Ape=kUiJDfoE98kVfkjQUGnTTZj_ohPbHWcra8TqPoEg@mail.gmail.com>
References: <CAHaxNQwOGqFyoOaPGo6Z-_YOBP9DC8KQxDyoMur_QvVJzHwqcQ@mail.gmail.com>
	<52834876.2050401@univ-mlv.fr>
	<CAA0cW5Ape=kUiJDfoE98kVfkjQUGnTTZj_ohPbHWcra8TqPoEg@mail.gmail.com>
Message-ID: <5284772E.6030808@gmail.com>

On 11/13/2013 03:29 PM, Ali Ebrahimi wrote:
> In better words, interface declarations are implicitly static and you can
> not have static declarations in local context (method body).

Right, and this (currently) applies to static methods too. I.e. the 
following:

     static void staticMethod() {
         int x = 1;

         class LocalClass { // works!
             void m() {
                 System.out.println(x);
             }
         }

         interface LocalInterface { // 'interface' not allowed here
             default void m() {
                 System.out.println(x);
             }
         }
     }


...references to local variables from local classes are implemented as 
fields in local classes, where the values of local variables are 
captured - which implicitly requires state - and interfaces have no state...

But a hypothetical "static local" class or interface would be possible - 
with rules that prevent its methods from accessing local or instance 
variables/methods of enclosing scopes. There could even be a consistent 
syntax for such things:

     static void staticMethod() {
         int x = 1;

         static class LocalClass {
             void m() {
                 System.out.println(x); // can't access local var
             }
         }

         interface LocalInterface { // 'interface' is implicitly static
             default void m() {
                 System.out.println(x); // can't access local var
             }
         }
     }


Consistent in sense that Java already has a "static class" in the form 
of nested class - with rules that prevent its methods from accessing 
instance variables/methods of enclosing scopes...

All that is possible, but the question is whether it is desirable. Where 
would it be usable? Would you want to have a local interface with a name 
and particular signature in one method, and a local interface with same 
name and different signature in some other method of the same class? 
Would it discourage interface re-use? Java already has a "private 
interface" which prevents it's visibility outside the declaring class. 
This is, in my opinion, enough hiding for a feature that was meant to 
define a contract...

Regards, Peter

>
>
> On Wed, Nov 13, 2013 at 1:07 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hi Olena,
>> interface local to method (like enum BTW) are not valid in Java,
>> so it's not really an issue related to lambdas but more an issue related
>> to allowing local interface in method.
>>
>> First, because the interface defined a static context, local interface
>> can be only defined in a static method,
>> otherwise you can have an initializer or a default method in the
>> interface that access to the field
>> of the enclosing class.
>>
>> public class Snippet {
>>     static void myMethod() {
>>       interface Runner { public void run(); }
>>       Runner runner = () -> System.out.println("hello");
>>       runner.run();
>>     }
>> }
>>
>> This seriously reduce the possible interesting use classes making a
>> local interface not very useful.
>>
>> cheers,
>> R?mi
>>
>> On 09/23/2013 09:27 PM, Olena Syrota wrote:
>>> Dear lambda dev team,
>>>
>>> Recently I made experiments with lamdas and found exotic case.
>>> I was not able to declare local interface to make a "local"
>> lambda-function.
>>> Why I needed this.
>>> Suppose I was to implement "local" lamdba-function to be used only couple
>>> of times inside my method.
>>> Compiler did not allowed me to place interface inside function.
>>> In my case it was interface Dropper to implement lambda-function that
>> drops
>>> last element.
>>>
>>> void myMethod(...) {
>>>
>>> Interface Dropper { dropLastSymbolInChain (List<List<String>> chain);}
>>> Dropper d = x -> x.stream()
>>> .map(e->e.subList(0, e.size()-2))
>>> .collect(Collectors.toList());
>>>
>>> List<List<String>> chain1Dropped = d.dropLastSymbolInChain(chain1);
>>> List<List<String>> chain2Dropped = d.dropLastSymbolInChain(chain2);
>>> }
>>>
>>> I was forced to declare interface Dropper outside myMethod.
>>>
>>> Should the proposition on local interfaces be submitted to jep?
>>>
>>>
>>> Thank you.
>>> Olena
>>>
>>
>>


From vicente.romero at oracle.com  Fri Nov 15 05:54:49 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 15 Nov 2013 13:54:49 +0000
Subject: Ambiguous reference
In-Reply-To: <CACuKZqHFmgoAEwqVoT2UvKwD_V=7VCu2R-pjvwH+0O7msv9sjg@mail.gmail.com>
References: <CAAWwtm-gAcFtL=yc2RBQ=n6hk+HuJSru7F2kNdAJifVbhs3Bpg@mail.gmail.com>
	<CACuKZqHFmgoAEwqVoT2UvKwD_V=7VCu2R-pjvwH+0O7msv9sjg@mail.gmail.com>
Message-ID: <528627A9.1040908@oracle.com>

On 13/11/13 18:59, Zhong Yu wrote:
> Here's my understanding how the process works.
>
> When javac sees
>
>      forEach( v->... )
>
> two pieces of information of the implicit lambda are used to prune
> overloading methods:
> 1. the arity. therefore BiConsumer/BiPredicate are excluded
> 2. whether the lambda body returns void or a real type.
Hi,

Overloading methods are discriminated by arity, return types are 
considered in a later phase once you know what methods to consider. This 
was implemented for several reasons, simplification between them, but 
also has some drawbacks.

So in all cases the compiler output is correct.

Thanks,
Vicente

>
> If the lambda body is a block, it's quite clear whether it's void or
> not. It seems to me that this would work:
>
>      public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>          forEach((v) -> { biConsumer.accept(1, v); });
>      }
>      public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>          forEach(v -> { return biPredicate.test(1, v); } );
>      }
>
> ( ... But it fails in javac build 115. javac bug?)
>
> If the lambda body is a "statement expression", like in your original example
>
>      public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>          forEach((v) -> biConsumer.accept(1, v) );
>      }
>      public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>          forEach(v -> biPredicate.test(1, v) );
>      }
>
> It's unclear what the return type is, so javac cannot use the return
> type to prune. Note that even though `biConsumer.accept(1, v)`
> obviously returns void, javac does not know that, because the type of
> `v` is not known yet. And even though `biPredicate.test(1, v)`
> obviously returns boolean, it is compatible to a function type that
> expects void return.
>
> Now, for each invocation, we have two potentially applicable methods.
>
> The next step tries to prune methods by checking argument types
> against method parameter types. Unfortunately, implicit lambda
> expressions are too vague, so they are simply ignored in this step.
>
> Therefore both methods are considered applicable methods. The most
> specific method is sought after. However neither method is more
> specific than the other, therefore we see the error message of
> ambiguity.
>
> If you use explicit lambda expressions, javac is able to do more
> pruning, so this works:
>
>      public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>          forEach((T v) -> biConsumer.accept(1, v) );
>      }
>      public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>          forEach( (T v) -> biPredicate.test(1, v) );
>      }
>
> So if you have overloading methods like this
>
>      public void forEach(Consumer<? super T> consumer) {
>          // ...
>      }
>      public void forEach(Predicate<? super T> predicate) {
>          // ...
>      }
>
> client code often cannot use implicit lambda expressions as arguments;
> and experts have advised against this kind of overloading scheme (two
> functional interfaces with the same arity)
>
>
> Zhong Yu
>
> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
>> Hello,
>>
>> I'm rewriting a library and run into a strange ambiguity error reported by
>> javac in JDK 8 b115, Windows 7 x86:
>>
>> public class Bug<T> {
>>      public void forEach(Consumer<? super T> consumer) {
>>          // ...
>>      }
>>      public void forEach(BiConsumer<? super Integer, ? super T> consumer) {
>>          forEach((v) -> consumer.accept(1, v));
>>      }
>>      public void forEach(Predicate<? super T> stoppableConsumer) {
>>          // ...
>>      }
>>      public void forEach(BiPredicate<? super Integer, ? super T>
>> stoppableConsumer) {
>>          forEach(v -> stoppableConsumer.test(1, v));
>>      }
>> }
>>
>> error: reference to forEach is ambiguous
>>          forEach((v) -> consumer.accept(1, v));
>>    both method forEach(Consumer<? super T>) in Bug and method
>> forEach(Predicate<? super T>) in Bug match
>>    where T is a type-variable:
>>      T extends Object declared in class Bug
>>
>> error: reference to forEach is ambiguous
>>          forEach(v -> stoppableConsumer.test(1, v));
>>    both method forEach(Consumer<? super T>) in Bug and method
>> forEach(Predicate<? super T>) in Bug match
>>    where T is a type-variable:
>>      T extends Object declared in class Bug
>>
>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>> ambiguity in the editor, and the "highlight occurrences" correctly selects
>> the 3rd method when I select the forEach in the 4th method. However, the
>> clean and build fails with the errors above. I have to add explicit cast to
>> the problematic places.
>>
>> So I'm a bit confused right now. Is it a bug with NetBeans' editor, with
>> javac or simply the artifact of how overload resolution works?
>> --
>> Best regards,
>> David Karnok
>>


From vicente.romero at oracle.com  Fri Nov 15 05:57:31 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 15 Nov 2013 13:57:31 +0000
Subject: Javac Bug?
In-Reply-To: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
Message-ID: <5286284B.8080608@oracle.com>

On 13/11/13 19:04, Zhong Yu wrote:
> This program does not compile in javac8 build 115. I think it should
> compile (but who knows really:)
>
> public class Bug<T> {
>      public void forEach(Consumer<? super T> consumer) {
>          // ...
>      }
>      public void forEach(Predicate<? super T> predicate) {
>          // ...
>      }
>      public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>          forEach((v) -> { biConsumer.accept(1, v); });
>      }
>      public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>          forEach(v -> { return biPredicate.test(1, v); } );
>      }
> }
Hi Zhong Yu,

No the compiler is right functional descriptors of Consumer and 
Predicate have the same arity, so the compiler determines that there is 
an ambiguity error.

Thanks,
Vicente
>
>
>
> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>> Here's my understanding how the process works.
>>
>> When javac sees
>>
>>      forEach( v->... )
>>
>> two pieces of information of the implicit lambda are used to prune
>> overloading methods:
>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>> 2. whether the lambda body returns void or a real type.
>>
>> If the lambda body is a block, it's quite clear whether it's void or
>> not. It seems to me that this would work:
>>
>>      public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>>          forEach((v) -> { biConsumer.accept(1, v); });
>>      }
>>      public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>>          forEach(v -> { return biPredicate.test(1, v); } );
>>      }
>>
>> ( ... But it fails in javac build 115. javac bug?)
>>
>> If the lambda body is a "statement expression", like in your original example
>>
>>      public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>>          forEach((v) -> biConsumer.accept(1, v) );
>>      }
>>      public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>>          forEach(v -> biPredicate.test(1, v) );
>>      }
>>
>> It's unclear what the return type is, so javac cannot use the return
>> type to prune. Note that even though `biConsumer.accept(1, v)`
>> obviously returns void, javac does not know that, because the type of
>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>> obviously returns boolean, it is compatible to a function type that
>> expects void return.
>>
>> Now, for each invocation, we have two potentially applicable methods.
>>
>> The next step tries to prune methods by checking argument types
>> against method parameter types. Unfortunately, implicit lambda
>> expressions are too vague, so they are simply ignored in this step.
>>
>> Therefore both methods are considered applicable methods. The most
>> specific method is sought after. However neither method is more
>> specific than the other, therefore we see the error message of
>> ambiguity.
>>
>> If you use explicit lambda expressions, javac is able to do more
>> pruning, so this works:
>>
>>      public void forEach(BiConsumer<? super Integer, ? super T> biConsumer) {
>>          forEach((T v) -> biConsumer.accept(1, v) );
>>      }
>>      public void forEach(BiPredicate<? super Integer, ? super T> biPredicate) {
>>          forEach( (T v) -> biPredicate.test(1, v) );
>>      }
>>
>> So if you have overloading methods like this
>>
>>      public void forEach(Consumer<? super T> consumer) {
>>          // ...
>>      }
>>      public void forEach(Predicate<? super T> predicate) {
>>          // ...
>>      }
>>
>> client code often cannot use implicit lambda expressions as arguments;
>> and experts have advised against this kind of overloading scheme (two
>> functional interfaces with the same arity)
>>
>>
>> Zhong Yu
>>
>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
>>> Hello,
>>>
>>> I'm rewriting a library and run into a strange ambiguity error reported by
>>> javac in JDK 8 b115, Windows 7 x86:
>>>
>>> public class Bug<T> {
>>>      public void forEach(Consumer<? super T> consumer) {
>>>          // ...
>>>      }
>>>      public void forEach(BiConsumer<? super Integer, ? super T> consumer) {
>>>          forEach((v) -> consumer.accept(1, v));
>>>      }
>>>      public void forEach(Predicate<? super T> stoppableConsumer) {
>>>          // ...
>>>      }
>>>      public void forEach(BiPredicate<? super Integer, ? super T>
>>> stoppableConsumer) {
>>>          forEach(v -> stoppableConsumer.test(1, v));
>>>      }
>>> }
>>>
>>> error: reference to forEach is ambiguous
>>>          forEach((v) -> consumer.accept(1, v));
>>>    both method forEach(Consumer<? super T>) in Bug and method
>>> forEach(Predicate<? super T>) in Bug match
>>>    where T is a type-variable:
>>>      T extends Object declared in class Bug
>>>
>>> error: reference to forEach is ambiguous
>>>          forEach(v -> stoppableConsumer.test(1, v));
>>>    both method forEach(Consumer<? super T>) in Bug and method
>>> forEach(Predicate<? super T>) in Bug match
>>>    where T is a type-variable:
>>>      T extends Object declared in class Bug
>>>
>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>> ambiguity in the editor, and the "highlight occurrences" correctly selects
>>> the 3rd method when I select the forEach in the 4th method. However, the
>>> clean and build fails with the errors above. I have to add explicit cast to
>>> the problematic places.
>>>
>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor, with
>>> javac or simply the artifact of how overload resolution works?
>>> --
>>> Best regards,
>>> David Karnok
>>>


From vicente.romero at oracle.com  Fri Nov 15 06:04:22 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 15 Nov 2013 14:04:22 +0000
Subject: Ambiguous reference
In-Reply-To: <CACuKZqFZxo09dE9xR+oJfcnzsZeE_EUEJY_jA_uW4vLL8XrL+Q@mail.gmail.com>
References: <CAAWwtm-gAcFtL=yc2RBQ=n6hk+HuJSru7F2kNdAJifVbhs3Bpg@mail.gmail.com>	<CACuKZqHFmgoAEwqVoT2UvKwD_V=7VCu2R-pjvwH+0O7msv9sjg@mail.gmail.com>
	<CACuKZqFZxo09dE9xR+oJfcnzsZeE_EUEJY_jA_uW4vLL8XrL+Q@mail.gmail.com>
Message-ID: <528629E6.10505@oracle.com>

On 13/11/13 19:14, Zhong Yu wrote:
> One thing I find quite worrisome in the new overload resolution - In
> Java7, applicable methods are "actually" applicable. The "choosing the
> most specific method" step is guaranteed to chose an actually
> applicable method.
>
> In Java8, that's not the case in a lot of times. Applicable methods
> may not be actually applicable, and the "most specific" step may
> choose a method that fails to pass further compilation.
>
> This can be quite confusing to the programmer:
>
> case 1. javac reports ambiguity because two methods are applicable -
> while it is very clear to the programmer that one of the method is not
> actrually applicable.
>
> case 2. javac chooses the most specific method, then finds that it is
> not actually applicable, reports that arguments do not fit the
> parameter types - while it seems very clear to the programmer that
> this method should not be a candidate in the first place.
>
>
> Zhong Yu
>
Hi,

If you are referring to the specific case of lambdas what the compiler 
says is that both methods match, not that they are applicable. Probably 
the error message can be clearer.

Vicente

From akarnokd at gmail.com  Fri Nov 15 06:24:32 2013
From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=)
Date: Fri, 15 Nov 2013 15:24:32 +0100
Subject: Ambiguous reference
In-Reply-To: <528629E6.10505@oracle.com>
References: <CAAWwtm-gAcFtL=yc2RBQ=n6hk+HuJSru7F2kNdAJifVbhs3Bpg@mail.gmail.com>
	<CACuKZqHFmgoAEwqVoT2UvKwD_V=7VCu2R-pjvwH+0O7msv9sjg@mail.gmail.com>
	<CACuKZqFZxo09dE9xR+oJfcnzsZeE_EUEJY_jA_uW4vLL8XrL+Q@mail.gmail.com>
	<528629E6.10505@oracle.com>
Message-ID: <CAAWwtm9OkDxRZyrxPVnHYBXMDeQZmm=ct1HAfjex-=4R5ynFjA@mail.gmail.com>

Thanks for the explanations. I'll rename the problematic methods to avoid
the issue.


2013/11/15 Vicente-Arturo Romero-Zaldivar <vicente.romero at oracle.com>

> On 13/11/13 19:14, Zhong Yu wrote:
>
>> One thing I find quite worrisome in the new overload resolution - In
>> Java7, applicable methods are "actually" applicable. The "choosing the
>> most specific method" step is guaranteed to chose an actually
>> applicable method.
>>
>> In Java8, that's not the case in a lot of times. Applicable methods
>> may not be actually applicable, and the "most specific" step may
>> choose a method that fails to pass further compilation.
>>
>> This can be quite confusing to the programmer:
>>
>> case 1. javac reports ambiguity because two methods are applicable -
>> while it is very clear to the programmer that one of the method is not
>> actrually applicable.
>>
>> case 2. javac chooses the most specific method, then finds that it is
>> not actually applicable, reports that arguments do not fit the
>> parameter types - while it seems very clear to the programmer that
>> this method should not be a candidate in the first place.
>>
>>
>> Zhong Yu
>>
>>  Hi,
>
> If you are referring to the specific case of lambdas what the compiler
> says is that both methods match, not that they are applicable. Probably the
> error message can be clearer.
>
> Vicente
>



-- 
Best regards,
David Karnok

From zhong.j.yu at gmail.com  Fri Nov 15 06:51:38 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 15 Nov 2013 08:51:38 -0600
Subject: Javac Bug?
In-Reply-To: <5286284B.8080608@oracle.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
	<5286284B.8080608@oracle.com>
Message-ID: <CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>

The return type seems also play a role here, see
http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html

""
A lambda expression (15.27) is potentially compatible with a
functional interface type (9.8) if all of the following are true:

The arity of the targeted type's function type is the same as the
arity of the lambda expression.
If the targeted type's function type has a void return, then the
lambda body is either a statement expression (14.8) or a
void-compatible block (15.27.2).
If the targeted type's function type has a (non-void) return type,
then the lambda body is either an expression or a value-compatible
block (15.27.2).
""

Therefore, method
    public void forEach(Consumer<? super T> consumer)
is not potentially applicable to invocation
    forEach(v -> { return biPredicate.test(1, v); } );
because the function type of Consumer has a void return, yet the
lambda body is a value-compatible block.


On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
<vicente.romero at oracle.com> wrote:
> On 13/11/13 19:04, Zhong Yu wrote:
>>
>> This program does not compile in javac8 build 115. I think it should
>> compile (but who knows really:)
>>
>> public class Bug<T> {
>>      public void forEach(Consumer<? super T> consumer) {
>>          // ...
>>      }
>>      public void forEach(Predicate<? super T> predicate) {
>>          // ...
>>      }
>>      public void forEach(BiConsumer<? super Integer, ? super T>
>> biConsumer) {
>>          forEach((v) -> { biConsumer.accept(1, v); });
>>      }
>>      public void forEach(BiPredicate<? super Integer, ? super T>
>> biPredicate) {
>>          forEach(v -> { return biPredicate.test(1, v); } );
>>      }
>> }
>
> Hi Zhong Yu,
>
> No the compiler is right functional descriptors of Consumer and Predicate
> have the same arity, so the compiler determines that there is an ambiguity
> error.
>
> Thanks,
> Vicente
>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>
>>> Here's my understanding how the process works.
>>>
>>> When javac sees
>>>
>>>      forEach( v->... )
>>>
>>> two pieces of information of the implicit lambda are used to prune
>>> overloading methods:
>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>> 2. whether the lambda body returns void or a real type.
>>>
>>> If the lambda body is a block, it's quite clear whether it's void or
>>> not. It seems to me that this would work:
>>>
>>>      public void forEach(BiConsumer<? super Integer, ? super T>
>>> biConsumer) {
>>>          forEach((v) -> { biConsumer.accept(1, v); });
>>>      }
>>>      public void forEach(BiPredicate<? super Integer, ? super T>
>>> biPredicate) {
>>>          forEach(v -> { return biPredicate.test(1, v); } );
>>>      }
>>>
>>> ( ... But it fails in javac build 115. javac bug?)
>>>
>>> If the lambda body is a "statement expression", like in your original
>>> example
>>>
>>>      public void forEach(BiConsumer<? super Integer, ? super T>
>>> biConsumer) {
>>>          forEach((v) -> biConsumer.accept(1, v) );
>>>      }
>>>      public void forEach(BiPredicate<? super Integer, ? super T>
>>> biPredicate) {
>>>          forEach(v -> biPredicate.test(1, v) );
>>>      }
>>>
>>> It's unclear what the return type is, so javac cannot use the return
>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>> obviously returns void, javac does not know that, because the type of
>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>> obviously returns boolean, it is compatible to a function type that
>>> expects void return.
>>>
>>> Now, for each invocation, we have two potentially applicable methods.
>>>
>>> The next step tries to prune methods by checking argument types
>>> against method parameter types. Unfortunately, implicit lambda
>>> expressions are too vague, so they are simply ignored in this step.
>>>
>>> Therefore both methods are considered applicable methods. The most
>>> specific method is sought after. However neither method is more
>>> specific than the other, therefore we see the error message of
>>> ambiguity.
>>>
>>> If you use explicit lambda expressions, javac is able to do more
>>> pruning, so this works:
>>>
>>>      public void forEach(BiConsumer<? super Integer, ? super T>
>>> biConsumer) {
>>>          forEach((T v) -> biConsumer.accept(1, v) );
>>>      }
>>>      public void forEach(BiPredicate<? super Integer, ? super T>
>>> biPredicate) {
>>>          forEach( (T v) -> biPredicate.test(1, v) );
>>>      }
>>>
>>> So if you have overloading methods like this
>>>
>>>      public void forEach(Consumer<? super T> consumer) {
>>>          // ...
>>>      }
>>>      public void forEach(Predicate<? super T> predicate) {
>>>          // ...
>>>      }
>>>
>>> client code often cannot use implicit lambda expressions as arguments;
>>> and experts have advised against this kind of overloading scheme (two
>>> functional interfaces with the same arity)
>>>
>>>
>>> Zhong Yu
>>>
>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm rewriting a library and run into a strange ambiguity error reported
>>>> by
>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>
>>>> public class Bug<T> {
>>>>      public void forEach(Consumer<? super T> consumer) {
>>>>          // ...
>>>>      }
>>>>      public void forEach(BiConsumer<? super Integer, ? super T>
>>>> consumer) {
>>>>          forEach((v) -> consumer.accept(1, v));
>>>>      }
>>>>      public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>          // ...
>>>>      }
>>>>      public void forEach(BiPredicate<? super Integer, ? super T>
>>>> stoppableConsumer) {
>>>>          forEach(v -> stoppableConsumer.test(1, v));
>>>>      }
>>>> }
>>>>
>>>> error: reference to forEach is ambiguous
>>>>          forEach((v) -> consumer.accept(1, v));
>>>>    both method forEach(Consumer<? super T>) in Bug and method
>>>> forEach(Predicate<? super T>) in Bug match
>>>>    where T is a type-variable:
>>>>      T extends Object declared in class Bug
>>>>
>>>> error: reference to forEach is ambiguous
>>>>          forEach(v -> stoppableConsumer.test(1, v));
>>>>    both method forEach(Consumer<? super T>) in Bug and method
>>>> forEach(Predicate<? super T>) in Bug match
>>>>    where T is a type-variable:
>>>>      T extends Object declared in class Bug
>>>>
>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>> selects
>>>> the 3rd method when I select the forEach in the 4th method. However, the
>>>> clean and build fails with the errors above. I have to add explicit cast
>>>> to
>>>> the problematic places.
>>>>
>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor, with
>>>> javac or simply the artifact of how overload resolution works?
>>>> --
>>>> Best regards,
>>>> David Karnok
>>>>
>

From vicente.romero at oracle.com  Fri Nov 15 07:15:44 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 15 Nov 2013 15:15:44 +0000
Subject: Javac Bug?
In-Reply-To: <CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>	<5286284B.8080608@oracle.com>
	<CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
Message-ID: <52863AA0.1050206@oracle.com>

On 15/11/13 14:51, Zhong Yu wrote:
> The return type seems also play a role here, see
> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
>
> ""
> A lambda expression (15.27) is potentially compatible with a
> functional interface type (9.8) if all of the following are true:
>
> The arity of the targeted type's function type is the same as the
> arity of the lambda expression.
> If the targeted type's function type has a void return, then the
> lambda body is either a statement expression (14.8) or a
> void-compatible block (15.27.2).
> If the targeted type's function type has a (non-void) return type,
> then the lambda body is either an expression or a value-compatible
> block (15.27.2).
> ""
>
> Therefore, method
>      public void forEach(Consumer<? super T> consumer)
> is not potentially applicable to invocation
>      forEach(v -> { return biPredicate.test(1, v); } );
> because the function type of Consumer has a void return, yet the
> lambda body is a value-compatible block.

The compiler analyze lambda expressions in several phases:

first analysis is by arity, if there are two possible applicable methods 
by arity the compiler issues an error. If a method pass to the next 
phase, then the rest of the information is taken into account.

>
>
> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
> <vicente.romero at oracle.com> wrote:
>> On 13/11/13 19:04, Zhong Yu wrote:
>>> This program does not compile in javac8 build 115. I think it should
>>> compile (but who knows really:)
>>>
>>> public class Bug<T> {
>>>       public void forEach(Consumer<? super T> consumer) {
>>>           // ...
>>>       }
>>>       public void forEach(Predicate<? super T> predicate) {
>>>           // ...
>>>       }
>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>> biConsumer) {
>>>           forEach((v) -> { biConsumer.accept(1, v); });
>>>       }
>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>> biPredicate) {
>>>           forEach(v -> { return biPredicate.test(1, v); } );
>>>       }
>>> }
>> Hi Zhong Yu,
>>
>> No the compiler is right functional descriptors of Consumer and Predicate
>> have the same arity, so the compiler determines that there is an ambiguity
>> error.
>>
>> Thanks,
>> Vicente
>>
>>>
>>>
>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>> Here's my understanding how the process works.
>>>>
>>>> When javac sees
>>>>
>>>>       forEach( v->... )
>>>>
>>>> two pieces of information of the implicit lambda are used to prune
>>>> overloading methods:
>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>>> 2. whether the lambda body returns void or a real type.
>>>>
>>>> If the lambda body is a block, it's quite clear whether it's void or
>>>> not. It seems to me that this would work:
>>>>
>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>> biConsumer) {
>>>>           forEach((v) -> { biConsumer.accept(1, v); });
>>>>       }
>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>> biPredicate) {
>>>>           forEach(v -> { return biPredicate.test(1, v); } );
>>>>       }
>>>>
>>>> ( ... But it fails in javac build 115. javac bug?)
>>>>
>>>> If the lambda body is a "statement expression", like in your original
>>>> example
>>>>
>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>> biConsumer) {
>>>>           forEach((v) -> biConsumer.accept(1, v) );
>>>>       }
>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>> biPredicate) {
>>>>           forEach(v -> biPredicate.test(1, v) );
>>>>       }
>>>>
>>>> It's unclear what the return type is, so javac cannot use the return
>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>>> obviously returns void, javac does not know that, because the type of
>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>>> obviously returns boolean, it is compatible to a function type that
>>>> expects void return.
>>>>
>>>> Now, for each invocation, we have two potentially applicable methods.
>>>>
>>>> The next step tries to prune methods by checking argument types
>>>> against method parameter types. Unfortunately, implicit lambda
>>>> expressions are too vague, so they are simply ignored in this step.
>>>>
>>>> Therefore both methods are considered applicable methods. The most
>>>> specific method is sought after. However neither method is more
>>>> specific than the other, therefore we see the error message of
>>>> ambiguity.
>>>>
>>>> If you use explicit lambda expressions, javac is able to do more
>>>> pruning, so this works:
>>>>
>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>> biConsumer) {
>>>>           forEach((T v) -> biConsumer.accept(1, v) );
>>>>       }
>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>> biPredicate) {
>>>>           forEach( (T v) -> biPredicate.test(1, v) );
>>>>       }
>>>>
>>>> So if you have overloading methods like this
>>>>
>>>>       public void forEach(Consumer<? super T> consumer) {
>>>>           // ...
>>>>       }
>>>>       public void forEach(Predicate<? super T> predicate) {
>>>>           // ...
>>>>       }
>>>>
>>>> client code often cannot use implicit lambda expressions as arguments;
>>>> and experts have advised against this kind of overloading scheme (two
>>>> functional interfaces with the same arity)
>>>>
>>>>
>>>> Zhong Yu
>>>>
>>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I'm rewriting a library and run into a strange ambiguity error reported
>>>>> by
>>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>>
>>>>> public class Bug<T> {
>>>>>       public void forEach(Consumer<? super T> consumer) {
>>>>>           // ...
>>>>>       }
>>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>>> consumer) {
>>>>>           forEach((v) -> consumer.accept(1, v));
>>>>>       }
>>>>>       public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>>           // ...
>>>>>       }
>>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>>> stoppableConsumer) {
>>>>>           forEach(v -> stoppableConsumer.test(1, v));
>>>>>       }
>>>>> }
>>>>>
>>>>> error: reference to forEach is ambiguous
>>>>>           forEach((v) -> consumer.accept(1, v));
>>>>>     both method forEach(Consumer<? super T>) in Bug and method
>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>     where T is a type-variable:
>>>>>       T extends Object declared in class Bug
>>>>>
>>>>> error: reference to forEach is ambiguous
>>>>>           forEach(v -> stoppableConsumer.test(1, v));
>>>>>     both method forEach(Consumer<? super T>) in Bug and method
>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>     where T is a type-variable:
>>>>>       T extends Object declared in class Bug
>>>>>
>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>>> selects
>>>>> the 3rd method when I select the forEach in the 4th method. However, the
>>>>> clean and build fails with the errors above. I have to add explicit cast
>>>>> to
>>>>> the problematic places.
>>>>>
>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor, with
>>>>> javac or simply the artifact of how overload resolution works?
>>>>> --
>>>>> Best regards,
>>>>> David Karnok
>>>>>


From zhong.j.yu at gmail.com  Fri Nov 15 07:36:19 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 15 Nov 2013 09:36:19 -0600
Subject: Javac Bug?
In-Reply-To: <52863AA0.1050206@oracle.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
	<5286284B.8080608@oracle.com>
	<CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
	<52863AA0.1050206@oracle.com>
Message-ID: <CACuKZqFG09qUiysCFc9JaGsSCbdKRX2yqXf-CodWApo3jAvSaA@mail.gmail.com>

On Fri, Nov 15, 2013 at 9:15 AM, Vicente-Arturo Romero-Zaldivar
<vicente.romero at oracle.com> wrote:
> On 15/11/13 14:51, Zhong Yu wrote:
>>
>> The return type seems also play a role here, see
>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
>>
>> ""
>> A lambda expression (15.27) is potentially compatible with a
>> functional interface type (9.8) if all of the following are true:
>>
>> The arity of the targeted type's function type is the same as the
>> arity of the lambda expression.
>> If the targeted type's function type has a void return, then the
>> lambda body is either a statement expression (14.8) or a
>> void-compatible block (15.27.2).
>> If the targeted type's function type has a (non-void) return type,
>> then the lambda body is either an expression or a value-compatible
>> block (15.27.2).
>> ""
>>
>> Therefore, method
>>      public void forEach(Consumer<? super T> consumer)
>> is not potentially applicable to invocation
>>      forEach(v -> { return biPredicate.test(1, v); } );
>> because the function type of Consumer has a void return, yet the
>> lambda body is a value-compatible block.
>
>
> The compiler analyze lambda expressions in several phases:
>
> first analysis is by arity, if there are two possible applicable methods by
> arity the compiler issues an error. If a method pass to the next phase, then
> the rest of the information is taken into account.

But the spec text I quoted mentions both arity and return type in the
phase of identifying potentially applicable methods (15.12.2.1)


>
>
>>
>>
>> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
>> <vicente.romero at oracle.com> wrote:
>>>
>>> On 13/11/13 19:04, Zhong Yu wrote:
>>>>
>>>> This program does not compile in javac8 build 115. I think it should
>>>> compile (but who knows really:)
>>>>
>>>> public class Bug<T> {
>>>>       public void forEach(Consumer<? super T> consumer) {
>>>>           // ...
>>>>       }
>>>>       public void forEach(Predicate<? super T> predicate) {
>>>>           // ...
>>>>       }
>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>> biConsumer) {
>>>>           forEach((v) -> { biConsumer.accept(1, v); });
>>>>       }
>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>> biPredicate) {
>>>>           forEach(v -> { return biPredicate.test(1, v); } );
>>>>       }
>>>> }
>>>
>>> Hi Zhong Yu,
>>>
>>> No the compiler is right functional descriptors of Consumer and Predicate
>>> have the same arity, so the compiler determines that there is an
>>> ambiguity
>>> error.
>>>
>>> Thanks,
>>> Vicente
>>>
>>>>
>>>>
>>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>>>
>>>>> Here's my understanding how the process works.
>>>>>
>>>>> When javac sees
>>>>>
>>>>>       forEach( v->... )
>>>>>
>>>>> two pieces of information of the implicit lambda are used to prune
>>>>> overloading methods:
>>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>>>> 2. whether the lambda body returns void or a real type.
>>>>>
>>>>> If the lambda body is a block, it's quite clear whether it's void or
>>>>> not. It seems to me that this would work:
>>>>>
>>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>>> biConsumer) {
>>>>>           forEach((v) -> { biConsumer.accept(1, v); });
>>>>>       }
>>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>>> biPredicate) {
>>>>>           forEach(v -> { return biPredicate.test(1, v); } );
>>>>>       }
>>>>>
>>>>> ( ... But it fails in javac build 115. javac bug?)
>>>>>
>>>>> If the lambda body is a "statement expression", like in your original
>>>>> example
>>>>>
>>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>>> biConsumer) {
>>>>>           forEach((v) -> biConsumer.accept(1, v) );
>>>>>       }
>>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>>> biPredicate) {
>>>>>           forEach(v -> biPredicate.test(1, v) );
>>>>>       }
>>>>>
>>>>> It's unclear what the return type is, so javac cannot use the return
>>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>>>> obviously returns void, javac does not know that, because the type of
>>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>>>> obviously returns boolean, it is compatible to a function type that
>>>>> expects void return.
>>>>>
>>>>> Now, for each invocation, we have two potentially applicable methods.
>>>>>
>>>>> The next step tries to prune methods by checking argument types
>>>>> against method parameter types. Unfortunately, implicit lambda
>>>>> expressions are too vague, so they are simply ignored in this step.
>>>>>
>>>>> Therefore both methods are considered applicable methods. The most
>>>>> specific method is sought after. However neither method is more
>>>>> specific than the other, therefore we see the error message of
>>>>> ambiguity.
>>>>>
>>>>> If you use explicit lambda expressions, javac is able to do more
>>>>> pruning, so this works:
>>>>>
>>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>>> biConsumer) {
>>>>>           forEach((T v) -> biConsumer.accept(1, v) );
>>>>>       }
>>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>>> biPredicate) {
>>>>>           forEach( (T v) -> biPredicate.test(1, v) );
>>>>>       }
>>>>>
>>>>> So if you have overloading methods like this
>>>>>
>>>>>       public void forEach(Consumer<? super T> consumer) {
>>>>>           // ...
>>>>>       }
>>>>>       public void forEach(Predicate<? super T> predicate) {
>>>>>           // ...
>>>>>       }
>>>>>
>>>>> client code often cannot use implicit lambda expressions as arguments;
>>>>> and experts have advised against this kind of overloading scheme (two
>>>>> functional interfaces with the same arity)
>>>>>
>>>>>
>>>>> Zhong Yu
>>>>>
>>>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm rewriting a library and run into a strange ambiguity error
>>>>>> reported
>>>>>> by
>>>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>>>
>>>>>> public class Bug<T> {
>>>>>>       public void forEach(Consumer<? super T> consumer) {
>>>>>>           // ...
>>>>>>       }
>>>>>>       public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> consumer) {
>>>>>>           forEach((v) -> consumer.accept(1, v));
>>>>>>       }
>>>>>>       public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>>>           // ...
>>>>>>       }
>>>>>>       public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> stoppableConsumer) {
>>>>>>           forEach(v -> stoppableConsumer.test(1, v));
>>>>>>       }
>>>>>> }
>>>>>>
>>>>>> error: reference to forEach is ambiguous
>>>>>>           forEach((v) -> consumer.accept(1, v));
>>>>>>     both method forEach(Consumer<? super T>) in Bug and method
>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>     where T is a type-variable:
>>>>>>       T extends Object declared in class Bug
>>>>>>
>>>>>> error: reference to forEach is ambiguous
>>>>>>           forEach(v -> stoppableConsumer.test(1, v));
>>>>>>     both method forEach(Consumer<? super T>) in Bug and method
>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>     where T is a type-variable:
>>>>>>       T extends Object declared in class Bug
>>>>>>
>>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>>>> selects
>>>>>> the 3rd method when I select the forEach in the 4th method. However,
>>>>>> the
>>>>>> clean and build fails with the errors above. I have to add explicit
>>>>>> cast
>>>>>> to
>>>>>> the problematic places.
>>>>>>
>>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor,
>>>>>> with
>>>>>> javac or simply the artifact of how overload resolution works?
>>>>>> --
>>>>>> Best regards,
>>>>>> David Karnok
>>>>>>
>

From david.holmes at oracle.com  Fri Nov 15 09:25:08 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 16 Nov 2013 03:25:08 +1000
Subject: Javac Bug?
In-Reply-To: <CACuKZqFG09qUiysCFc9JaGsSCbdKRX2yqXf-CodWApo3jAvSaA@mail.gmail.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
	<5286284B.8080608@oracle.com>
	<CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
	<52863AA0.1050206@oracle.com>
	<CACuKZqFG09qUiysCFc9JaGsSCbdKRX2yqXf-CodWApo3jAvSaA@mail.gmail.com>
Message-ID: <528658F4.2080107@oracle.com>

On 16/11/2013 1:36 AM, Zhong Yu wrote:
> On Fri, Nov 15, 2013 at 9:15 AM, Vicente-Arturo Romero-Zaldivar
> <vicente.romero at oracle.com> wrote:
>> On 15/11/13 14:51, Zhong Yu wrote:
>>>
>>> The return type seems also play a role here, see
>>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
>>>
>>> ""
>>> A lambda expression (15.27) is potentially compatible with a
>>> functional interface type (9.8) if all of the following are true:
>>>
>>> The arity of the targeted type's function type is the same as the
>>> arity of the lambda expression.
>>> If the targeted type's function type has a void return, then the
>>> lambda body is either a statement expression (14.8) or a
>>> void-compatible block (15.27.2).
>>> If the targeted type's function type has a (non-void) return type,
>>> then the lambda body is either an expression or a value-compatible
>>> block (15.27.2).
>>> ""
>>>
>>> Therefore, method
>>>       public void forEach(Consumer<? super T> consumer)
>>> is not potentially applicable to invocation
>>>       forEach(v -> { return biPredicate.test(1, v); } );
>>> because the function type of Consumer has a void return, yet the
>>> lambda body is a value-compatible block.
>>
>>
>> The compiler analyze lambda expressions in several phases:
>>
>> first analysis is by arity, if there are two possible applicable methods by
>> arity the compiler issues an error. If a method pass to the next phase, then
>> the rest of the information is taken into account.
>
> But the spec text I quoted mentions both arity and return type in the
> phase of identifying potentially applicable methods (15.12.2.1)

I have to agree - the compiler needs to consider all of the conditions 
combined as is written in the spec. It should not declare ambiguity 
based on arity alone when the return type would have reduced things to a 
single applicable method.

David
-----

>
>>
>>
>>>
>>>
>>> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
>>> <vicente.romero at oracle.com> wrote:
>>>>
>>>> On 13/11/13 19:04, Zhong Yu wrote:
>>>>>
>>>>> This program does not compile in javac8 build 115. I think it should
>>>>> compile (but who knows really:)
>>>>>
>>>>> public class Bug<T> {
>>>>>        public void forEach(Consumer<? super T> consumer) {
>>>>>            // ...
>>>>>        }
>>>>>        public void forEach(Predicate<? super T> predicate) {
>>>>>            // ...
>>>>>        }
>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>> biConsumer) {
>>>>>            forEach((v) -> { biConsumer.accept(1, v); });
>>>>>        }
>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>> biPredicate) {
>>>>>            forEach(v -> { return biPredicate.test(1, v); } );
>>>>>        }
>>>>> }
>>>>
>>>> Hi Zhong Yu,
>>>>
>>>> No the compiler is right functional descriptors of Consumer and Predicate
>>>> have the same arity, so the compiler determines that there is an
>>>> ambiguity
>>>> error.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>>>>
>>>>>> Here's my understanding how the process works.
>>>>>>
>>>>>> When javac sees
>>>>>>
>>>>>>        forEach( v->... )
>>>>>>
>>>>>> two pieces of information of the implicit lambda are used to prune
>>>>>> overloading methods:
>>>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>>>>> 2. whether the lambda body returns void or a real type.
>>>>>>
>>>>>> If the lambda body is a block, it's quite clear whether it's void or
>>>>>> not. It seems to me that this would work:
>>>>>>
>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> biConsumer) {
>>>>>>            forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>        }
>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> biPredicate) {
>>>>>>            forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>        }
>>>>>>
>>>>>> ( ... But it fails in javac build 115. javac bug?)
>>>>>>
>>>>>> If the lambda body is a "statement expression", like in your original
>>>>>> example
>>>>>>
>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> biConsumer) {
>>>>>>            forEach((v) -> biConsumer.accept(1, v) );
>>>>>>        }
>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> biPredicate) {
>>>>>>            forEach(v -> biPredicate.test(1, v) );
>>>>>>        }
>>>>>>
>>>>>> It's unclear what the return type is, so javac cannot use the return
>>>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>>>>> obviously returns void, javac does not know that, because the type of
>>>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>>>>> obviously returns boolean, it is compatible to a function type that
>>>>>> expects void return.
>>>>>>
>>>>>> Now, for each invocation, we have two potentially applicable methods.
>>>>>>
>>>>>> The next step tries to prune methods by checking argument types
>>>>>> against method parameter types. Unfortunately, implicit lambda
>>>>>> expressions are too vague, so they are simply ignored in this step.
>>>>>>
>>>>>> Therefore both methods are considered applicable methods. The most
>>>>>> specific method is sought after. However neither method is more
>>>>>> specific than the other, therefore we see the error message of
>>>>>> ambiguity.
>>>>>>
>>>>>> If you use explicit lambda expressions, javac is able to do more
>>>>>> pruning, so this works:
>>>>>>
>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> biConsumer) {
>>>>>>            forEach((T v) -> biConsumer.accept(1, v) );
>>>>>>        }
>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> biPredicate) {
>>>>>>            forEach( (T v) -> biPredicate.test(1, v) );
>>>>>>        }
>>>>>>
>>>>>> So if you have overloading methods like this
>>>>>>
>>>>>>        public void forEach(Consumer<? super T> consumer) {
>>>>>>            // ...
>>>>>>        }
>>>>>>        public void forEach(Predicate<? super T> predicate) {
>>>>>>            // ...
>>>>>>        }
>>>>>>
>>>>>> client code often cannot use implicit lambda expressions as arguments;
>>>>>> and experts have advised against this kind of overloading scheme (two
>>>>>> functional interfaces with the same arity)
>>>>>>
>>>>>>
>>>>>> Zhong Yu
>>>>>>
>>>>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm rewriting a library and run into a strange ambiguity error
>>>>>>> reported
>>>>>>> by
>>>>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>>>>
>>>>>>> public class Bug<T> {
>>>>>>>        public void forEach(Consumer<? super T> consumer) {
>>>>>>>            // ...
>>>>>>>        }
>>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>> consumer) {
>>>>>>>            forEach((v) -> consumer.accept(1, v));
>>>>>>>        }
>>>>>>>        public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>>>>            // ...
>>>>>>>        }
>>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>> stoppableConsumer) {
>>>>>>>            forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>        }
>>>>>>> }
>>>>>>>
>>>>>>> error: reference to forEach is ambiguous
>>>>>>>            forEach((v) -> consumer.accept(1, v));
>>>>>>>      both method forEach(Consumer<? super T>) in Bug and method
>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>      where T is a type-variable:
>>>>>>>        T extends Object declared in class Bug
>>>>>>>
>>>>>>> error: reference to forEach is ambiguous
>>>>>>>            forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>      both method forEach(Consumer<? super T>) in Bug and method
>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>      where T is a type-variable:
>>>>>>>        T extends Object declared in class Bug
>>>>>>>
>>>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>>>>> selects
>>>>>>> the 3rd method when I select the forEach in the 4th method. However,
>>>>>>> the
>>>>>>> clean and build fails with the errors above. I have to add explicit
>>>>>>> cast
>>>>>>> to
>>>>>>> the problematic places.
>>>>>>>
>>>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor,
>>>>>>> with
>>>>>>> javac or simply the artifact of how overload resolution works?
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> David Karnok
>>>>>>>
>>
>

From ali.ebrahimi1781 at gmail.com  Fri Nov 15 09:57:36 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 15 Nov 2013 21:27:36 +0330
Subject: Javac Bug?
In-Reply-To: <528658F4.2080107@oracle.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
	<5286284B.8080608@oracle.com>
	<CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
	<52863AA0.1050206@oracle.com>
	<CACuKZqFG09qUiysCFc9JaGsSCbdKRX2yqXf-CodWApo3jAvSaA@mail.gmail.com>
	<528658F4.2080107@oracle.com>
Message-ID: <CAA0cW5CQKceq5covyo4F6pOAasXhLtVMYLOexBRnnk5_z7Ak9A@mail.gmail.com>

+1. I raised this issue multiple times in this list when Maurizio was in
oracle.


On Fri, Nov 15, 2013 at 8:55 PM, David Holmes <david.holmes at oracle.com>wrote:

> On 16/11/2013 1:36 AM, Zhong Yu wrote:
> > On Fri, Nov 15, 2013 at 9:15 AM, Vicente-Arturo Romero-Zaldivar
> > <vicente.romero at oracle.com> wrote:
> >> On 15/11/13 14:51, Zhong Yu wrote:
> >>>
> >>> The return type seems also play a role here, see
> >>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
> >>>
> >>> ""
> >>> A lambda expression (15.27) is potentially compatible with a
> >>> functional interface type (9.8) if all of the following are true:
> >>>
> >>> The arity of the targeted type's function type is the same as the
> >>> arity of the lambda expression.
> >>> If the targeted type's function type has a void return, then the
> >>> lambda body is either a statement expression (14.8) or a
> >>> void-compatible block (15.27.2).
> >>> If the targeted type's function type has a (non-void) return type,
> >>> then the lambda body is either an expression or a value-compatible
> >>> block (15.27.2).
> >>> ""
> >>>
> >>> Therefore, method
> >>>       public void forEach(Consumer<? super T> consumer)
> >>> is not potentially applicable to invocation
> >>>       forEach(v -> { return biPredicate.test(1, v); } );
> >>> because the function type of Consumer has a void return, yet the
> >>> lambda body is a value-compatible block.
> >>
> >>
> >> The compiler analyze lambda expressions in several phases:
> >>
> >> first analysis is by arity, if there are two possible applicable
> methods by
> >> arity the compiler issues an error. If a method pass to the next phase,
> then
> >> the rest of the information is taken into account.
> >
> > But the spec text I quoted mentions both arity and return type in the
> > phase of identifying potentially applicable methods (15.12.2.1)
>
> I have to agree - the compiler needs to consider all of the conditions
> combined as is written in the spec. It should not declare ambiguity
> based on arity alone when the return type would have reduced things to a
> single applicable method.
>
> David
> -----
>
> >
> >>
> >>
> >>>
> >>>
> >>> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
> >>> <vicente.romero at oracle.com> wrote:
> >>>>
> >>>> On 13/11/13 19:04, Zhong Yu wrote:
> >>>>>
> >>>>> This program does not compile in javac8 build 115. I think it should
> >>>>> compile (but who knows really:)
> >>>>>
> >>>>> public class Bug<T> {
> >>>>>        public void forEach(Consumer<? super T> consumer) {
> >>>>>            // ...
> >>>>>        }
> >>>>>        public void forEach(Predicate<? super T> predicate) {
> >>>>>            // ...
> >>>>>        }
> >>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
> >>>>> biConsumer) {
> >>>>>            forEach((v) -> { biConsumer.accept(1, v); });
> >>>>>        }
> >>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
> >>>>> biPredicate) {
> >>>>>            forEach(v -> { return biPredicate.test(1, v); } );
> >>>>>        }
> >>>>> }
> >>>>
> >>>> Hi Zhong Yu,
> >>>>
> >>>> No the compiler is right functional descriptors of Consumer and
> Predicate
> >>>> have the same arity, so the compiler determines that there is an
> >>>> ambiguity
> >>>> error.
> >>>>
> >>>> Thanks,
> >>>> Vicente
> >>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com>
> wrote:
> >>>>>>
> >>>>>> Here's my understanding how the process works.
> >>>>>>
> >>>>>> When javac sees
> >>>>>>
> >>>>>>        forEach( v->... )
> >>>>>>
> >>>>>> two pieces of information of the implicit lambda are used to prune
> >>>>>> overloading methods:
> >>>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
> >>>>>> 2. whether the lambda body returns void or a real type.
> >>>>>>
> >>>>>> If the lambda body is a block, it's quite clear whether it's void or
> >>>>>> not. It seems to me that this would work:
> >>>>>>
> >>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
> >>>>>> biConsumer) {
> >>>>>>            forEach((v) -> { biConsumer.accept(1, v); });
> >>>>>>        }
> >>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
> >>>>>> biPredicate) {
> >>>>>>            forEach(v -> { return biPredicate.test(1, v); } );
> >>>>>>        }
> >>>>>>
> >>>>>> ( ... But it fails in javac build 115. javac bug?)
> >>>>>>
> >>>>>> If the lambda body is a "statement expression", like in your
> original
> >>>>>> example
> >>>>>>
> >>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
> >>>>>> biConsumer) {
> >>>>>>            forEach((v) -> biConsumer.accept(1, v) );
> >>>>>>        }
> >>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
> >>>>>> biPredicate) {
> >>>>>>            forEach(v -> biPredicate.test(1, v) );
> >>>>>>        }
> >>>>>>
> >>>>>> It's unclear what the return type is, so javac cannot use the return
> >>>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
> >>>>>> obviously returns void, javac does not know that, because the type
> of
> >>>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
> >>>>>> obviously returns boolean, it is compatible to a function type that
> >>>>>> expects void return.
> >>>>>>
> >>>>>> Now, for each invocation, we have two potentially applicable
> methods.
> >>>>>>
> >>>>>> The next step tries to prune methods by checking argument types
> >>>>>> against method parameter types. Unfortunately, implicit lambda
> >>>>>> expressions are too vague, so they are simply ignored in this step.
> >>>>>>
> >>>>>> Therefore both methods are considered applicable methods. The most
> >>>>>> specific method is sought after. However neither method is more
> >>>>>> specific than the other, therefore we see the error message of
> >>>>>> ambiguity.
> >>>>>>
> >>>>>> If you use explicit lambda expressions, javac is able to do more
> >>>>>> pruning, so this works:
> >>>>>>
> >>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
> >>>>>> biConsumer) {
> >>>>>>            forEach((T v) -> biConsumer.accept(1, v) );
> >>>>>>        }
> >>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
> >>>>>> biPredicate) {
> >>>>>>            forEach( (T v) -> biPredicate.test(1, v) );
> >>>>>>        }
> >>>>>>
> >>>>>> So if you have overloading methods like this
> >>>>>>
> >>>>>>        public void forEach(Consumer<? super T> consumer) {
> >>>>>>            // ...
> >>>>>>        }
> >>>>>>        public void forEach(Predicate<? super T> predicate) {
> >>>>>>            // ...
> >>>>>>        }
> >>>>>>
> >>>>>> client code often cannot use implicit lambda expressions as
> arguments;
> >>>>>> and experts have advised against this kind of overloading scheme
> (two
> >>>>>> functional interfaces with the same arity)
> >>>>>>
> >>>>>>
> >>>>>> Zhong Yu
> >>>>>>
> >>>>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I'm rewriting a library and run into a strange ambiguity error
> >>>>>>> reported
> >>>>>>> by
> >>>>>>> javac in JDK 8 b115, Windows 7 x86:
> >>>>>>>
> >>>>>>> public class Bug<T> {
> >>>>>>>        public void forEach(Consumer<? super T> consumer) {
> >>>>>>>            // ...
> >>>>>>>        }
> >>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
> >>>>>>> consumer) {
> >>>>>>>            forEach((v) -> consumer.accept(1, v));
> >>>>>>>        }
> >>>>>>>        public void forEach(Predicate<? super T> stoppableConsumer)
> {
> >>>>>>>            // ...
> >>>>>>>        }
> >>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
> >>>>>>> stoppableConsumer) {
> >>>>>>>            forEach(v -> stoppableConsumer.test(1, v));
> >>>>>>>        }
> >>>>>>> }
> >>>>>>>
> >>>>>>> error: reference to forEach is ambiguous
> >>>>>>>            forEach((v) -> consumer.accept(1, v));
> >>>>>>>      both method forEach(Consumer<? super T>) in Bug and method
> >>>>>>> forEach(Predicate<? super T>) in Bug match
> >>>>>>>      where T is a type-variable:
> >>>>>>>        T extends Object declared in class Bug
> >>>>>>>
> >>>>>>> error: reference to forEach is ambiguous
> >>>>>>>            forEach(v -> stoppableConsumer.test(1, v));
> >>>>>>>      both method forEach(Consumer<? super T>) in Bug and method
> >>>>>>> forEach(Predicate<? super T>) in Bug match
> >>>>>>>      where T is a type-variable:
> >>>>>>>        T extends Object declared in class Bug
> >>>>>>>
> >>>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report
> this
> >>>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
> >>>>>>> selects
> >>>>>>> the 3rd method when I select the forEach in the 4th method.
> However,
> >>>>>>> the
> >>>>>>> clean and build fails with the errors above. I have to add explicit
> >>>>>>> cast
> >>>>>>> to
> >>>>>>> the problematic places.
> >>>>>>>
> >>>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor,
> >>>>>>> with
> >>>>>>> javac or simply the artifact of how overload resolution works?
> >>>>>>> --
> >>>>>>> Best regards,
> >>>>>>> David Karnok
> >>>>>>>
> >>
> >
>
>

From mike.duigou at oracle.com  Thu Nov 14 12:34:36 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 14 Nov 2013 13:34:36 -0700
Subject: @Override and default methods
In-Reply-To: <CABLGb9yz=ijo-7Us=hd2PfgkUdMo3dRZzrqaA68oetQ8hGeWMw@mail.gmail.com>
References: <CABLGb9yz=ijo-7Us=hd2PfgkUdMo3dRZzrqaA68oetQ8hGeWMw@mail.gmail.com>
Message-ID: <F3DF2CDB-D3E7-42EB-A008-716CC1CBFDA9@oracle.com>

Hi Paul;

This is unfortunate. Hopefully we come up with some compromise or accommodation. 

Mike


On Nov 13 2013, at 18:43 , Paul Benedict <pbenedict at apache.org> wrote:

> I saw this email come through Apache and would like your opinions:
> 
> ===
> Hi,
> 
> during the vote for collections 4.0 we have discovered a problem wrt the
> MultiMap interface in general and specifically the MultiKeyMap.

Are the problematic methods new in Collections 4.0 or were they part of previous releases as well?

> 
> Java 8 introduces a new default method in the Map interface:
> 
> boolean remove(Object key, Object value)
> 
> This clashes with the method in MultiMap:
> 
> V remove(K key, V value)
> 
> and the remove methods for multiple keys in MultiKeyMap:
> 
> V remove(K key1, K key2)

The issue is that the return types are unrelated. If the Java 8 Map method returned Object then it would be possible to specialize the return type to V but because boolean and V/Object are unrelated then the override is not allowed.



> Just changing the return type does not solve the problem, as one can not
> re-define a method in an interface without using the @Override
> annotation, but this would only work when compiling with JDK 8 and fail
> for other JDKs.
> ===
> 
> What is the correct course in such a situation?

Is it possible to rename these methods in Apache Collections to removeKey and removeValue? Understandably if these methods are not new in 4.0 then it will be difficult to remove them. The other question would be whether it's appropriate for these classes to implement or extend Map. If their semantics are such that they do not fully implement the standard Map semantics then it's probably best that they not claim to be Map implementations. 

Thanks,

Mike

From forax at univ-mlv.fr  Sat Nov 16 03:26:28 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Nov 2013 12:26:28 +0100
Subject: @Override and default methods
In-Reply-To: <F3DF2CDB-D3E7-42EB-A008-716CC1CBFDA9@oracle.com>
References: <CABLGb9yz=ijo-7Us=hd2PfgkUdMo3dRZzrqaA68oetQ8hGeWMw@mail.gmail.com>
	<F3DF2CDB-D3E7-42EB-A008-716CC1CBFDA9@oracle.com>
Message-ID: <52875664.1050004@univ-mlv.fr>

On 11/14/2013 09:34 PM, Mike Duigou wrote:
> Hi Paul;
>
> This is unfortunate. Hopefully we come up with some compromise or accommodation.
>
> Mike

I think the JDK and Apache Collections are both wrong in naming their 
methods.
For the JDK, the method should be named removeEntry and for the Apache 
Collections
it should be removeMultiKey().
Given that Apache Collections remove() method predates JDK one,
I propose to just rename remov to removeEntry
(I know it's an API change but a lot of implementations of Map may 
introduce a remove(),
the name is too common).

other comments inlined.

>
>
> On Nov 13 2013, at 18:43 , Paul Benedict <pbenedict at apache.org> wrote:
>
>> I saw this email come through Apache and would like your opinions:
>>
>> ===
>> Hi,
>>
>> during the vote for collections 4.0 we have discovered a problem wrt the
>> MultiMap interface in general and specifically the MultiKeyMap.
> Are the problematic methods new in Collections 4.0 or were they part of previous releases as well?

They were introduce in 3.1 (in 2008 it seams).
https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/org/apache/commons/collections/map/MultiKeyMap.html

>
>> Java 8 introduces a new default method in the Map interface:
>>
>> boolean remove(Object key, Object value)
>>
>> This clashes with the method in MultiMap:
>>
>> V remove(K key, V value)
>>
>> and the remove methods for multiple keys in MultiKeyMap:
>>
>> V remove(K key1, K key2)
> The issue is that the return types are unrelated. If the Java 8 Map method returned Object then it would be possible to specialize the return type to V but because boolean and V/Object are unrelated then the override is not allowed.

also the semantics is different.

>
>
>
>> Just changing the return type does not solve the problem, as one can not
>> re-define a method in an interface without using the @Override
>> annotation, but this would only work when compiling with JDK 8 and fail
>> for other JDKs.
>> ===
>>
>> What is the correct course in such a situation?
> Is it possible to rename these methods in Apache Collections to removeKey and removeValue? Understandably if these methods are not new in 4.0 then it will be difficult to remove them. The other question would be whether it's appropriate for these classes to implement or extend Map. If their semantics are such that they do not fully implement the standard Map semantics then it's probably best that they not claim to be Map implementations.
>
> Thanks,
>
> Mike
>

R?mi


From forax at univ-mlv.fr  Sat Nov 16 06:14:32 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Nov 2013 15:14:32 +0100
Subject: Javac Bug?
In-Reply-To: <528658F4.2080107@oracle.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
	<5286284B.8080608@oracle.com>
	<CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
	<52863AA0.1050206@oracle.com>
	<CACuKZqFG09qUiysCFc9JaGsSCbdKRX2yqXf-CodWApo3jAvSaA@mail.gmail.com>
	<528658F4.2080107@oracle.com>
Message-ID: <52877DC8.3070008@univ-mlv.fr>

On 11/15/2013 06:25 PM, David Holmes wrote:
> On 16/11/2013 1:36 AM, Zhong Yu wrote:
>> On Fri, Nov 15, 2013 at 9:15 AM, Vicente-Arturo Romero-Zaldivar
>> <vicente.romero at oracle.com> wrote:
>>> On 15/11/13 14:51, Zhong Yu wrote:
>>>> The return type seems also play a role here, see
>>>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
>>>>
>>>> ""
>>>> A lambda expression (15.27) is potentially compatible with a
>>>> functional interface type (9.8) if all of the following are true:
>>>>
>>>> The arity of the targeted type's function type is the same as the
>>>> arity of the lambda expression.
>>>> If the targeted type's function type has a void return, then the
>>>> lambda body is either a statement expression (14.8) or a
>>>> void-compatible block (15.27.2).
>>>> If the targeted type's function type has a (non-void) return type,
>>>> then the lambda body is either an expression or a value-compatible
>>>> block (15.27.2).
>>>> ""
>>>>
>>>> Therefore, method
>>>>        public void forEach(Consumer<? super T> consumer)
>>>> is not potentially applicable to invocation
>>>>        forEach(v -> { return biPredicate.test(1, v); } );
>>>> because the function type of Consumer has a void return, yet the
>>>> lambda body is a value-compatible block.
>>>
>>> The compiler analyze lambda expressions in several phases:
>>>
>>> first analysis is by arity, if there are two possible applicable methods by
>>> arity the compiler issues an error. If a method pass to the next phase, then
>>> the rest of the information is taken into account.
>> But the spec text I quoted mentions both arity and return type in the
>> phase of identifying potentially applicable methods (15.12.2.1)
> I have to agree - the compiler needs to consider all of the conditions
> combined as is written in the spec. It should not declare ambiguity
> based on arity alone when the return type would have reduced things to a
> single applicable method.
>
> David
> -----

Hi David, Hi all,
the lambda EG has decided that for 8 we will spec a very basic inference 
algorithm
when overloading and lambdas are used at the same time, we have explored 
many algorithms
and even found one that seems to work but we don't have the time to be 
sure that it doesn't
introduce weird behavior (as the previous proposed algorithms).
So instead of releasing a half baked algorithm, we backoff to a simple 
algorithm
that disambiguate using the arity only to be sure to not hamper our 
chance to have a better one in 9.

cheers,
R?mi

>
>>>
>>>>
>>>> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
>>>> <vicente.romero at oracle.com> wrote:
>>>>> On 13/11/13 19:04, Zhong Yu wrote:
>>>>>> This program does not compile in javac8 build 115. I think it should
>>>>>> compile (but who knows really:)
>>>>>>
>>>>>> public class Bug<T> {
>>>>>>         public void forEach(Consumer<? super T> consumer) {
>>>>>>             // ...
>>>>>>         }
>>>>>>         public void forEach(Predicate<? super T> predicate) {
>>>>>>             // ...
>>>>>>         }
>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> biConsumer) {
>>>>>>             forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>         }
>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> biPredicate) {
>>>>>>             forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>         }
>>>>>> }
>>>>> Hi Zhong Yu,
>>>>>
>>>>> No the compiler is right functional descriptors of Consumer and Predicate
>>>>> have the same arity, so the compiler determines that there is an
>>>>> ambiguity
>>>>> error.
>>>>>
>>>>> Thanks,
>>>>> Vicente
>>>>>
>>>>>>
>>>>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>>>>> Here's my understanding how the process works.
>>>>>>>
>>>>>>> When javac sees
>>>>>>>
>>>>>>>         forEach( v->... )
>>>>>>>
>>>>>>> two pieces of information of the implicit lambda are used to prune
>>>>>>> overloading methods:
>>>>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>>>>>> 2. whether the lambda body returns void or a real type.
>>>>>>>
>>>>>>> If the lambda body is a block, it's quite clear whether it's void or
>>>>>>> not. It seems to me that this would work:
>>>>>>>
>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>> biConsumer) {
>>>>>>>             forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>>         }
>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>> biPredicate) {
>>>>>>>             forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>>         }
>>>>>>>
>>>>>>> ( ... But it fails in javac build 115. javac bug?)
>>>>>>>
>>>>>>> If the lambda body is a "statement expression", like in your original
>>>>>>> example
>>>>>>>
>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>> biConsumer) {
>>>>>>>             forEach((v) -> biConsumer.accept(1, v) );
>>>>>>>         }
>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>> biPredicate) {
>>>>>>>             forEach(v -> biPredicate.test(1, v) );
>>>>>>>         }
>>>>>>>
>>>>>>> It's unclear what the return type is, so javac cannot use the return
>>>>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>>>>>> obviously returns void, javac does not know that, because the type of
>>>>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>>>>>> obviously returns boolean, it is compatible to a function type that
>>>>>>> expects void return.
>>>>>>>
>>>>>>> Now, for each invocation, we have two potentially applicable methods.
>>>>>>>
>>>>>>> The next step tries to prune methods by checking argument types
>>>>>>> against method parameter types. Unfortunately, implicit lambda
>>>>>>> expressions are too vague, so they are simply ignored in this step.
>>>>>>>
>>>>>>> Therefore both methods are considered applicable methods. The most
>>>>>>> specific method is sought after. However neither method is more
>>>>>>> specific than the other, therefore we see the error message of
>>>>>>> ambiguity.
>>>>>>>
>>>>>>> If you use explicit lambda expressions, javac is able to do more
>>>>>>> pruning, so this works:
>>>>>>>
>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>> biConsumer) {
>>>>>>>             forEach((T v) -> biConsumer.accept(1, v) );
>>>>>>>         }
>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>> biPredicate) {
>>>>>>>             forEach( (T v) -> biPredicate.test(1, v) );
>>>>>>>         }
>>>>>>>
>>>>>>> So if you have overloading methods like this
>>>>>>>
>>>>>>>         public void forEach(Consumer<? super T> consumer) {
>>>>>>>             // ...
>>>>>>>         }
>>>>>>>         public void forEach(Predicate<? super T> predicate) {
>>>>>>>             // ...
>>>>>>>         }
>>>>>>>
>>>>>>> client code often cannot use implicit lambda expressions as arguments;
>>>>>>> and experts have advised against this kind of overloading scheme (two
>>>>>>> functional interfaces with the same arity)
>>>>>>>
>>>>>>>
>>>>>>> Zhong Yu
>>>>>>>
>>>>>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com>
>>>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I'm rewriting a library and run into a strange ambiguity error
>>>>>>>> reported
>>>>>>>> by
>>>>>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>>>>>
>>>>>>>> public class Bug<T> {
>>>>>>>>         public void forEach(Consumer<? super T> consumer) {
>>>>>>>>             // ...
>>>>>>>>         }
>>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>> consumer) {
>>>>>>>>             forEach((v) -> consumer.accept(1, v));
>>>>>>>>         }
>>>>>>>>         public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>>>>>             // ...
>>>>>>>>         }
>>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>> stoppableConsumer) {
>>>>>>>>             forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>>         }
>>>>>>>> }
>>>>>>>>
>>>>>>>> error: reference to forEach is ambiguous
>>>>>>>>             forEach((v) -> consumer.accept(1, v));
>>>>>>>>       both method forEach(Consumer<? super T>) in Bug and method
>>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>>       where T is a type-variable:
>>>>>>>>         T extends Object declared in class Bug
>>>>>>>>
>>>>>>>> error: reference to forEach is ambiguous
>>>>>>>>             forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>>       both method forEach(Consumer<? super T>) in Bug and method
>>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>>       where T is a type-variable:
>>>>>>>>         T extends Object declared in class Bug
>>>>>>>>
>>>>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>>>>>> selects
>>>>>>>> the 3rd method when I select the forEach in the 4th method. However,
>>>>>>>> the
>>>>>>>> clean and build fails with the errors above. I have to add explicit
>>>>>>>> cast
>>>>>>>> to
>>>>>>>> the problematic places.
>>>>>>>>
>>>>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor,
>>>>>>>> with
>>>>>>>> javac or simply the artifact of how overload resolution works?
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>> David Karnok
>>>>>>>>


From zhong.j.yu at gmail.com  Sat Nov 16 06:59:23 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Sat, 16 Nov 2013 08:59:23 -0600
Subject: Javac Bug?
In-Reply-To: <52877DC8.3070008@univ-mlv.fr>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
	<5286284B.8080608@oracle.com>
	<CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
	<52863AA0.1050206@oracle.com>
	<CACuKZqFG09qUiysCFc9JaGsSCbdKRX2yqXf-CodWApo3jAvSaA@mail.gmail.com>
	<528658F4.2080107@oracle.com> <52877DC8.3070008@univ-mlv.fr>
Message-ID: <CACuKZqEHboe5sEhvd8FtTXn4at0gpV-acaYJTTLydL4bU592XA@mail.gmail.com>

So this is a bug in the spec text, which indicates that the kind of
return (void or value) plays a roles here?

Zhong Yu


On Sat, Nov 16, 2013 at 8:14 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> On 11/15/2013 06:25 PM, David Holmes wrote:
>> On 16/11/2013 1:36 AM, Zhong Yu wrote:
>>> On Fri, Nov 15, 2013 at 9:15 AM, Vicente-Arturo Romero-Zaldivar
>>> <vicente.romero at oracle.com> wrote:
>>>> On 15/11/13 14:51, Zhong Yu wrote:
>>>>> The return type seems also play a role here, see
>>>>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
>>>>>
>>>>> ""
>>>>> A lambda expression (15.27) is potentially compatible with a
>>>>> functional interface type (9.8) if all of the following are true:
>>>>>
>>>>> The arity of the targeted type's function type is the same as the
>>>>> arity of the lambda expression.
>>>>> If the targeted type's function type has a void return, then the
>>>>> lambda body is either a statement expression (14.8) or a
>>>>> void-compatible block (15.27.2).
>>>>> If the targeted type's function type has a (non-void) return type,
>>>>> then the lambda body is either an expression or a value-compatible
>>>>> block (15.27.2).
>>>>> ""
>>>>>
>>>>> Therefore, method
>>>>>        public void forEach(Consumer<? super T> consumer)
>>>>> is not potentially applicable to invocation
>>>>>        forEach(v -> { return biPredicate.test(1, v); } );
>>>>> because the function type of Consumer has a void return, yet the
>>>>> lambda body is a value-compatible block.
>>>>
>>>> The compiler analyze lambda expressions in several phases:
>>>>
>>>> first analysis is by arity, if there are two possible applicable methods by
>>>> arity the compiler issues an error. If a method pass to the next phase, then
>>>> the rest of the information is taken into account.
>>> But the spec text I quoted mentions both arity and return type in the
>>> phase of identifying potentially applicable methods (15.12.2.1)
>> I have to agree - the compiler needs to consider all of the conditions
>> combined as is written in the spec. It should not declare ambiguity
>> based on arity alone when the return type would have reduced things to a
>> single applicable method.
>>
>> David
>> -----
>
> Hi David, Hi all,
> the lambda EG has decided that for 8 we will spec a very basic inference
> algorithm
> when overloading and lambdas are used at the same time, we have explored
> many algorithms
> and even found one that seems to work but we don't have the time to be
> sure that it doesn't
> introduce weird behavior (as the previous proposed algorithms).
> So instead of releasing a half baked algorithm, we backoff to a simple
> algorithm
> that disambiguate using the arity only to be sure to not hamper our
> chance to have a better one in 9.
>
> cheers,
> R?mi
>
>>
>>>>
>>>>>
>>>>> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
>>>>> <vicente.romero at oracle.com> wrote:
>>>>>> On 13/11/13 19:04, Zhong Yu wrote:
>>>>>>> This program does not compile in javac8 build 115. I think it should
>>>>>>> compile (but who knows really:)
>>>>>>>
>>>>>>> public class Bug<T> {
>>>>>>>         public void forEach(Consumer<? super T> consumer) {
>>>>>>>             // ...
>>>>>>>         }
>>>>>>>         public void forEach(Predicate<? super T> predicate) {
>>>>>>>             // ...
>>>>>>>         }
>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>> biConsumer) {
>>>>>>>             forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>>         }
>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>> biPredicate) {
>>>>>>>             forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>>         }
>>>>>>> }
>>>>>> Hi Zhong Yu,
>>>>>>
>>>>>> No the compiler is right functional descriptors of Consumer and Predicate
>>>>>> have the same arity, so the compiler determines that there is an
>>>>>> ambiguity
>>>>>> error.
>>>>>>
>>>>>> Thanks,
>>>>>> Vicente
>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>>>>>> Here's my understanding how the process works.
>>>>>>>>
>>>>>>>> When javac sees
>>>>>>>>
>>>>>>>>         forEach( v->... )
>>>>>>>>
>>>>>>>> two pieces of information of the implicit lambda are used to prune
>>>>>>>> overloading methods:
>>>>>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>>>>>>> 2. whether the lambda body returns void or a real type.
>>>>>>>>
>>>>>>>> If the lambda body is a block, it's quite clear whether it's void or
>>>>>>>> not. It seems to me that this would work:
>>>>>>>>
>>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>> biConsumer) {
>>>>>>>>             forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>>>         }
>>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>> biPredicate) {
>>>>>>>>             forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>>>         }
>>>>>>>>
>>>>>>>> ( ... But it fails in javac build 115. javac bug?)
>>>>>>>>
>>>>>>>> If the lambda body is a "statement expression", like in your original
>>>>>>>> example
>>>>>>>>
>>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>> biConsumer) {
>>>>>>>>             forEach((v) -> biConsumer.accept(1, v) );
>>>>>>>>         }
>>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>> biPredicate) {
>>>>>>>>             forEach(v -> biPredicate.test(1, v) );
>>>>>>>>         }
>>>>>>>>
>>>>>>>> It's unclear what the return type is, so javac cannot use the return
>>>>>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>>>>>>> obviously returns void, javac does not know that, because the type of
>>>>>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>>>>>>> obviously returns boolean, it is compatible to a function type that
>>>>>>>> expects void return.
>>>>>>>>
>>>>>>>> Now, for each invocation, we have two potentially applicable methods.
>>>>>>>>
>>>>>>>> The next step tries to prune methods by checking argument types
>>>>>>>> against method parameter types. Unfortunately, implicit lambda
>>>>>>>> expressions are too vague, so they are simply ignored in this step.
>>>>>>>>
>>>>>>>> Therefore both methods are considered applicable methods. The most
>>>>>>>> specific method is sought after. However neither method is more
>>>>>>>> specific than the other, therefore we see the error message of
>>>>>>>> ambiguity.
>>>>>>>>
>>>>>>>> If you use explicit lambda expressions, javac is able to do more
>>>>>>>> pruning, so this works:
>>>>>>>>
>>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>> biConsumer) {
>>>>>>>>             forEach((T v) -> biConsumer.accept(1, v) );
>>>>>>>>         }
>>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>> biPredicate) {
>>>>>>>>             forEach( (T v) -> biPredicate.test(1, v) );
>>>>>>>>         }
>>>>>>>>
>>>>>>>> So if you have overloading methods like this
>>>>>>>>
>>>>>>>>         public void forEach(Consumer<? super T> consumer) {
>>>>>>>>             // ...
>>>>>>>>         }
>>>>>>>>         public void forEach(Predicate<? super T> predicate) {
>>>>>>>>             // ...
>>>>>>>>         }
>>>>>>>>
>>>>>>>> client code often cannot use implicit lambda expressions as arguments;
>>>>>>>> and experts have advised against this kind of overloading scheme (two
>>>>>>>> functional interfaces with the same arity)
>>>>>>>>
>>>>>>>>
>>>>>>>> Zhong Yu
>>>>>>>>
>>>>>>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I'm rewriting a library and run into a strange ambiguity error
>>>>>>>>> reported
>>>>>>>>> by
>>>>>>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>>>>>>
>>>>>>>>> public class Bug<T> {
>>>>>>>>>         public void forEach(Consumer<? super T> consumer) {
>>>>>>>>>             // ...
>>>>>>>>>         }
>>>>>>>>>         public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>>> consumer) {
>>>>>>>>>             forEach((v) -> consumer.accept(1, v));
>>>>>>>>>         }
>>>>>>>>>         public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>>>>>>             // ...
>>>>>>>>>         }
>>>>>>>>>         public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>>> stoppableConsumer) {
>>>>>>>>>             forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>>>         }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> error: reference to forEach is ambiguous
>>>>>>>>>             forEach((v) -> consumer.accept(1, v));
>>>>>>>>>       both method forEach(Consumer<? super T>) in Bug and method
>>>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>>>       where T is a type-variable:
>>>>>>>>>         T extends Object declared in class Bug
>>>>>>>>>
>>>>>>>>> error: reference to forEach is ambiguous
>>>>>>>>>             forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>>>       both method forEach(Consumer<? super T>) in Bug and method
>>>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>>>       where T is a type-variable:
>>>>>>>>>         T extends Object declared in class Bug
>>>>>>>>>
>>>>>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>>>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>>>>>>> selects
>>>>>>>>> the 3rd method when I select the forEach in the 4th method. However,
>>>>>>>>> the
>>>>>>>>> clean and build fails with the errors above. I have to add explicit
>>>>>>>>> cast
>>>>>>>>> to
>>>>>>>>> the problematic places.
>>>>>>>>>
>>>>>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor,
>>>>>>>>> with
>>>>>>>>> javac or simply the artifact of how overload resolution works?
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>> David Karnok
>>>>>>>>>
>
>

From david.holmes at oracle.com  Sat Nov 16 09:07:53 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 17 Nov 2013 03:07:53 +1000
Subject: Javac Bug?
In-Reply-To: <CACuKZqEHboe5sEhvd8FtTXn4at0gpV-acaYJTTLydL4bU592XA@mail.gmail.com>
References: <CACuKZqGh_6QVuq1Ukv=GvQN7U+cvYcVjD=0pW0aHAWm-mW7nww@mail.gmail.com>
	<5286284B.8080608@oracle.com>
	<CACuKZqEt+2mLfHUrvQkYoLGbM80wSfZLP8tbe8SbEijCHSBtGw@mail.gmail.com>
	<52863AA0.1050206@oracle.com>
	<CACuKZqFG09qUiysCFc9JaGsSCbdKRX2yqXf-CodWApo3jAvSaA@mail.gmail.com>
	<528658F4.2080107@oracle.com> <52877DC8.3070008@univ-mlv.fr>
	<CACuKZqEHboe5sEhvd8FtTXn4at0gpV-acaYJTTLydL4bU592XA@mail.gmail.com>
Message-ID: <5287A669.1040006@oracle.com>

On 17/11/2013 12:59 AM, Zhong Yu wrote:
> So this is a bug in the spec text, which indicates that the kind of
> return (void or value) plays a roles here?

Or a bug in javac as it doesn't implement the current spec?

Either way there is a bug. Even if there is a desire to do something 
different/better in 9, there should be consistency between the spec and 
javac in 8.

David
-----

> Zhong Yu
>
>
> On Sat, Nov 16, 2013 at 8:14 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> On 11/15/2013 06:25 PM, David Holmes wrote:
>>> On 16/11/2013 1:36 AM, Zhong Yu wrote:
>>>> On Fri, Nov 15, 2013 at 9:15 AM, Vicente-Arturo Romero-Zaldivar
>>>> <vicente.romero at oracle.com> wrote:
>>>>> On 15/11/13 14:51, Zhong Yu wrote:
>>>>>> The return type seems also play a role here, see
>>>>>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
>>>>>>
>>>>>> ""
>>>>>> A lambda expression (15.27) is potentially compatible with a
>>>>>> functional interface type (9.8) if all of the following are true:
>>>>>>
>>>>>> The arity of the targeted type's function type is the same as the
>>>>>> arity of the lambda expression.
>>>>>> If the targeted type's function type has a void return, then the
>>>>>> lambda body is either a statement expression (14.8) or a
>>>>>> void-compatible block (15.27.2).
>>>>>> If the targeted type's function type has a (non-void) return type,
>>>>>> then the lambda body is either an expression or a value-compatible
>>>>>> block (15.27.2).
>>>>>> ""
>>>>>>
>>>>>> Therefore, method
>>>>>>         public void forEach(Consumer<? super T> consumer)
>>>>>> is not potentially applicable to invocation
>>>>>>         forEach(v -> { return biPredicate.test(1, v); } );
>>>>>> because the function type of Consumer has a void return, yet the
>>>>>> lambda body is a value-compatible block.
>>>>>
>>>>> The compiler analyze lambda expressions in several phases:
>>>>>
>>>>> first analysis is by arity, if there are two possible applicable methods by
>>>>> arity the compiler issues an error. If a method pass to the next phase, then
>>>>> the rest of the information is taken into account.
>>>> But the spec text I quoted mentions both arity and return type in the
>>>> phase of identifying potentially applicable methods (15.12.2.1)
>>> I have to agree - the compiler needs to consider all of the conditions
>>> combined as is written in the spec. It should not declare ambiguity
>>> based on arity alone when the return type would have reduced things to a
>>> single applicable method.
>>>
>>> David
>>> -----
>>
>> Hi David, Hi all,
>> the lambda EG has decided that for 8 we will spec a very basic inference
>> algorithm
>> when overloading and lambdas are used at the same time, we have explored
>> many algorithms
>> and even found one that seems to work but we don't have the time to be
>> sure that it doesn't
>> introduce weird behavior (as the previous proposed algorithms).
>> So instead of releasing a half baked algorithm, we backoff to a simple
>> algorithm
>> that disambiguate using the arity only to be sure to not hamper our
>> chance to have a better one in 9.
>>
>> cheers,
>> R?mi
>>
>>>
>>>>>
>>>>>>
>>>>>> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
>>>>>> <vicente.romero at oracle.com> wrote:
>>>>>>> On 13/11/13 19:04, Zhong Yu wrote:
>>>>>>>> This program does not compile in javac8 build 115. I think it should
>>>>>>>> compile (but who knows really:)
>>>>>>>>
>>>>>>>> public class Bug<T> {
>>>>>>>>          public void forEach(Consumer<? super T> consumer) {
>>>>>>>>              // ...
>>>>>>>>          }
>>>>>>>>          public void forEach(Predicate<? super T> predicate) {
>>>>>>>>              // ...
>>>>>>>>          }
>>>>>>>>          public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>> biConsumer) {
>>>>>>>>              forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>>>          }
>>>>>>>>          public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>> biPredicate) {
>>>>>>>>              forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>>>          }
>>>>>>>> }
>>>>>>> Hi Zhong Yu,
>>>>>>>
>>>>>>> No the compiler is right functional descriptors of Consumer and Predicate
>>>>>>> have the same arity, so the compiler determines that there is an
>>>>>>> ambiguity
>>>>>>> error.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vicente
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>>>>>>> Here's my understanding how the process works.
>>>>>>>>>
>>>>>>>>> When javac sees
>>>>>>>>>
>>>>>>>>>          forEach( v->... )
>>>>>>>>>
>>>>>>>>> two pieces of information of the implicit lambda are used to prune
>>>>>>>>> overloading methods:
>>>>>>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>>>>>>>> 2. whether the lambda body returns void or a real type.
>>>>>>>>>
>>>>>>>>> If the lambda body is a block, it's quite clear whether it's void or
>>>>>>>>> not. It seems to me that this would work:
>>>>>>>>>
>>>>>>>>>          public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>>> biConsumer) {
>>>>>>>>>              forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>>>>          }
>>>>>>>>>          public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>>> biPredicate) {
>>>>>>>>>              forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>>>>          }
>>>>>>>>>
>>>>>>>>> ( ... But it fails in javac build 115. javac bug?)
>>>>>>>>>
>>>>>>>>> If the lambda body is a "statement expression", like in your original
>>>>>>>>> example
>>>>>>>>>
>>>>>>>>>          public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>>> biConsumer) {
>>>>>>>>>              forEach((v) -> biConsumer.accept(1, v) );
>>>>>>>>>          }
>>>>>>>>>          public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>>> biPredicate) {
>>>>>>>>>              forEach(v -> biPredicate.test(1, v) );
>>>>>>>>>          }
>>>>>>>>>
>>>>>>>>> It's unclear what the return type is, so javac cannot use the return
>>>>>>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>>>>>>>> obviously returns void, javac does not know that, because the type of
>>>>>>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>>>>>>>> obviously returns boolean, it is compatible to a function type that
>>>>>>>>> expects void return.
>>>>>>>>>
>>>>>>>>> Now, for each invocation, we have two potentially applicable methods.
>>>>>>>>>
>>>>>>>>> The next step tries to prune methods by checking argument types
>>>>>>>>> against method parameter types. Unfortunately, implicit lambda
>>>>>>>>> expressions are too vague, so they are simply ignored in this step.
>>>>>>>>>
>>>>>>>>> Therefore both methods are considered applicable methods. The most
>>>>>>>>> specific method is sought after. However neither method is more
>>>>>>>>> specific than the other, therefore we see the error message of
>>>>>>>>> ambiguity.
>>>>>>>>>
>>>>>>>>> If you use explicit lambda expressions, javac is able to do more
>>>>>>>>> pruning, so this works:
>>>>>>>>>
>>>>>>>>>          public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>>> biConsumer) {
>>>>>>>>>              forEach((T v) -> biConsumer.accept(1, v) );
>>>>>>>>>          }
>>>>>>>>>          public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>>> biPredicate) {
>>>>>>>>>              forEach( (T v) -> biPredicate.test(1, v) );
>>>>>>>>>          }
>>>>>>>>>
>>>>>>>>> So if you have overloading methods like this
>>>>>>>>>
>>>>>>>>>          public void forEach(Consumer<? super T> consumer) {
>>>>>>>>>              // ...
>>>>>>>>>          }
>>>>>>>>>          public void forEach(Predicate<? super T> predicate) {
>>>>>>>>>              // ...
>>>>>>>>>          }
>>>>>>>>>
>>>>>>>>> client code often cannot use implicit lambda expressions as arguments;
>>>>>>>>> and experts have advised against this kind of overloading scheme (two
>>>>>>>>> functional interfaces with the same arity)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Zhong Yu
>>>>>>>>>
>>>>>>>>> On Wed, Nov 13, 2013 at 8:01 AM, D?vid Karnok <akarnokd at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I'm rewriting a library and run into a strange ambiguity error
>>>>>>>>>> reported
>>>>>>>>>> by
>>>>>>>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>>>>>>>
>>>>>>>>>> public class Bug<T> {
>>>>>>>>>>          public void forEach(Consumer<? super T> consumer) {
>>>>>>>>>>              // ...
>>>>>>>>>>          }
>>>>>>>>>>          public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>>>>> consumer) {
>>>>>>>>>>              forEach((v) -> consumer.accept(1, v));
>>>>>>>>>>          }
>>>>>>>>>>          public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>>>>>>>              // ...
>>>>>>>>>>          }
>>>>>>>>>>          public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>>>>> stoppableConsumer) {
>>>>>>>>>>              forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>>>>          }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> error: reference to forEach is ambiguous
>>>>>>>>>>              forEach((v) -> consumer.accept(1, v));
>>>>>>>>>>        both method forEach(Consumer<? super T>) in Bug and method
>>>>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>>>>        where T is a type-variable:
>>>>>>>>>>          T extends Object declared in class Bug
>>>>>>>>>>
>>>>>>>>>> error: reference to forEach is ambiguous
>>>>>>>>>>              forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>>>>        both method forEach(Consumer<? super T>) in Bug and method
>>>>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>>>>        where T is a type-variable:
>>>>>>>>>>          T extends Object declared in class Bug
>>>>>>>>>>
>>>>>>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>>>>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>>>>>>>> selects
>>>>>>>>>> the 3rd method when I select the forEach in the 4th method. However,
>>>>>>>>>> the
>>>>>>>>>> clean and build fails with the errors above. I have to add explicit
>>>>>>>>>> cast
>>>>>>>>>> to
>>>>>>>>>> the problematic places.
>>>>>>>>>>
>>>>>>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor,
>>>>>>>>>> with
>>>>>>>>>> javac or simply the artifact of how overload resolution works?
>>>>>>>>>> --
>>>>>>>>>> Best regards,
>>>>>>>>>> David Karnok
>>>>>>>>>>
>>
>>
>

From anna.kozlova at jetbrains.com  Sat Nov 16 12:13:33 2013
From: anna.kozlova at jetbrains.com (Anna Kozlova)
Date: Sat, 16 Nov 2013 21:13:33 +0100
Subject: primitive type bounds
Message-ID: <003301cee308$53b027a0$fb1076e0$@kozlova@jetbrains.com>

Hi,

 

I don't understand why there is a compilation error (b. 115) here:

 

class Test {

    static <U> Iterable<U> map(Mapper<String, U> mapper) {

        return null;

    }

 

    static void test() {

        Iterable<Integer> map = map(Test::length);

    }

 

    public static <T> int length(String s) {

        return 0;

    }

}

interface Mapper<T, U> {

    U map(T t);

}

 

java: incompatible types: inference variable U has incompatible bounds

    equality constraints: java.lang.Integer

    lower bounds: java.lang.Integer,int

 

How does javac get 'int' lower bound here? 

 

Thanks,

Anna


From forax at univ-mlv.fr  Sat Nov 16 14:28:22 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Nov 2013 23:28:22 +0100
Subject: @Override and default methods
Message-ID: <omyd14t1vml08xlbqocq5lor.1384640674475@email.android.com>

things are more complex than i
had thunk, remove was introduced in ConcurentMap first so its name can not be changed :(

R?mi

From my smartphone

-------- Message d'origine --------
De : Remi Forax <forax at univ-mlv.fr> 
Date : 16/11/2013  12:26  (GMT+01:00) 
A : lambda-dev at openjdk.java.net 
Objet : Re: @Override and default methods 
 
On 11/14/2013 09:34 PM, Mike Duigou wrote:
> Hi Paul;
>
> This is unfortunate. Hopefully we come up with some compromise or accommodation.
>
> Mike

I think the JDK and Apache Collections are both wrong in naming their 
methods.
For the JDK, the method should be named removeEntry and for the Apache 
Collections
it should be removeMultiKey().
Given that Apache Collections remove() method predates JDK one,
I propose to just rename remov to removeEntry
(I know it's an API change but a lot of implementations of Map may 
introduce a remove(),
the name is too common).

other comments inlined.

>
>
> On Nov 13 2013, at 18:43 , Paul Benedict <pbenedict at apache.org> wrote:
>
>> I saw this email come through Apache and would like your opinions:
>>
>> ===
>> Hi,
>>
>> during the vote for collections 4.0 we have discovered a problem wrt the
>> MultiMap interface in general and specifically the MultiKeyMap.
> Are the problematic methods new in Collections 4.0 or were they part of previous releases as well?

They were introduce in 3.1 (in 2008 it seams).
https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/org/apache/commons/collections/map/MultiKeyMap.html

>
>> Java 8 introduces a new default method in the Map interface:
>>
>> boolean remove(Object key, Object value)
>>
>> This clashes with the method in MultiMap:
>>
>> V remove(K key, V value)
>>
>> and the remove methods for multiple keys in MultiKeyMap:
>>
>> V remove(K key1, K key2)
> The issue is that the return types are unrelated. If the Java 8 Map method returned Object then it would be possible to specialize the return type to V but because boolean and V/Object are unrelated then the override is not allowed.

also the semantics is different.

>
>
>
>> Just changing the return type does not solve the problem, as one can not
>> re-define a method in an interface without using the @Override
>> annotation, but this would only work when compiling with JDK 8 and fail
>> for other JDKs.
>> ===
>>
>> What is the correct course in such a situation?
> Is it possible to rename these methods in Apache Collections to removeKey and removeValue? Understandably if these methods are not new in 4.0 then it will be difficult to remove them. The other question would be whether it's appropriate for these classes to implement or extend Map. If their semantics are such that they do not fully implement the standard Map semantics then it's probably best that they not claim to be Map implementations.
>
> Thanks,
>
> Mike
>

R?mi



From pbenedict at apache.org  Sat Nov 16 18:40:01 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Sat, 16 Nov 2013 20:40:01 -0600
Subject: @Override and default methods
In-Reply-To: <omyd14t1vml08xlbqocq5lor.1384640674475@email.android.com>
References: <omyd14t1vml08xlbqocq5lor.1384640674475@email.android.com>
Message-ID: <CABLGb9xw4ZSKpY3h9rZX989wqmOnFb5UUnNFO=x7b04b_qwGyg@mail.gmail.com>

My concern is how intrusive default methods can be. If someone adds a
default method to a super interface and it conflicts with existing methods
in a sub-interface, you can't compile. This pattern is ought to repeat over
and over. JDK 9 or 10 or the future may continue to add new default methods
and break sub-interfaces.

Can anything be done so that true abstract methods always wins and default
methods in super-interfaces always lose?




On Sat, Nov 16, 2013 at 4:28 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> things are more complex than i
> had thunk, remove was introduced in ConcurentMap first so its name can not
> be changed :(
>
> R?mi
>
> From my smartphone
>
> -------- Message d'origine --------
> De : Remi Forax <forax at univ-mlv.fr>
> Date : 16/11/2013  12:26  (GMT+01:00)
> A : lambda-dev at openjdk.java.net
> Objet : Re: @Override and default methods
>
> On 11/14/2013 09:34 PM, Mike Duigou wrote:
> > Hi Paul;
> >
> > This is unfortunate. Hopefully we come up with some compromise or
> accommodation.
> >
> > Mike
>
> I think the JDK and Apache Collections are both wrong in naming their
> methods.
> For the JDK, the method should be named removeEntry and for the Apache
> Collections
> it should be removeMultiKey().
> Given that Apache Collections remove() method predates JDK one,
> I propose to just rename remov to removeEntry
> (I know it's an API change but a lot of implementations of Map may
> introduce a remove(),
> the name is too common).
>
> other comments inlined.
>
> >
> >
> > On Nov 13 2013, at 18:43 , Paul Benedict <pbenedict at apache.org> wrote:
> >
> >> I saw this email come through Apache and would like your opinions:
> >>
> >> ===
> >> Hi,
> >>
> >> during the vote for collections 4.0 we have discovered a problem wrt the
> >> MultiMap interface in general and specifically the MultiKeyMap.
> > Are the problematic methods new in Collections 4.0 or were they part of
> previous releases as well?
>
> They were introduce in 3.1 (in 2008 it seams).
>
> https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/org/apache/commons/collections/map/MultiKeyMap.html
>
> >
> >> Java 8 introduces a new default method in the Map interface:
> >>
> >> boolean remove(Object key, Object value)
> >>
> >> This clashes with the method in MultiMap:
> >>
> >> V remove(K key, V value)
> >>
> >> and the remove methods for multiple keys in MultiKeyMap:
> >>
> >> V remove(K key1, K key2)
> > The issue is that the return types are unrelated. If the Java 8 Map
> method returned Object then it would be possible to specialize the return
> type to V but because boolean and V/Object are unrelated then the override
> is not allowed.
>
> also the semantics is different.
>
> >
> >
> >
> >> Just changing the return type does not solve the problem, as one can not
> >> re-define a method in an interface without using the @Override
> >> annotation, but this would only work when compiling with JDK 8 and fail
> >> for other JDKs.
> >> ===
> >>
> >> What is the correct course in such a situation?
> > Is it possible to rename these methods in Apache Collections to
> removeKey and removeValue? Understandably if these methods are not new in
> 4.0 then it will be difficult to remove them. The other question would be
> whether it's appropriate for these classes to implement or extend Map. If
> their semantics are such that they do not fully implement the standard Map
> semantics then it's probably best that they not claim to be Map
> implementations.
> >
> > Thanks,
> >
> > Mike
> >
>
> R?mi
>
>
>
>


-- 
Cheers,
Paul

From david.holmes at oracle.com  Sat Nov 16 19:49:24 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 17 Nov 2013 13:49:24 +1000
Subject: @Override and default methods
In-Reply-To: <CABLGb9xw4ZSKpY3h9rZX989wqmOnFb5UUnNFO=x7b04b_qwGyg@mail.gmail.com>
References: <omyd14t1vml08xlbqocq5lor.1384640674475@email.android.com>
	<CABLGb9xw4ZSKpY3h9rZX989wqmOnFb5UUnNFO=x7b04b_qwGyg@mail.gmail.com>
Message-ID: <52883CC4.9010903@oracle.com>

On 17/11/2013 12:40 PM, Paul Benedict wrote:
> My concern is how intrusive default methods can be. If someone adds a
> default method to a super interface and it conflicts with existing methods
> in a sub-interface, you can't compile. This pattern is ought to repeat over
> and over. JDK 9 or 10 or the future may continue to add new default methods
> and break sub-interfaces.

This was deemed an acceptable price to pay to allow the platform classes 
to move forward. Some code will need modification to run on Java 8.

> Can anything be done so that true abstract methods always wins and default
> methods in super-interfaces always lose?

The issue here is not abstractness but incompatible/conflicting 
signatures. If a class already has a method Foo that is later added to 
an inherited interface as a default method then the class's Foo will 
continue to be invoked.

David
-----
>
>
>
> On Sat, Nov 16, 2013 at 4:28 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> things are more complex than i
>> had thunk, remove was introduced in ConcurentMap first so its name can not
>> be changed :(
>>
>> R?mi
>>
>>  From my smartphone
>>
>> -------- Message d'origine --------
>> De : Remi Forax <forax at univ-mlv.fr>
>> Date : 16/11/2013  12:26  (GMT+01:00)
>> A : lambda-dev at openjdk.java.net
>> Objet : Re: @Override and default methods
>>
>> On 11/14/2013 09:34 PM, Mike Duigou wrote:
>>> Hi Paul;
>>>
>>> This is unfortunate. Hopefully we come up with some compromise or
>> accommodation.
>>>
>>> Mike
>>
>> I think the JDK and Apache Collections are both wrong in naming their
>> methods.
>> For the JDK, the method should be named removeEntry and for the Apache
>> Collections
>> it should be removeMultiKey().
>> Given that Apache Collections remove() method predates JDK one,
>> I propose to just rename remov to removeEntry
>> (I know it's an API change but a lot of implementations of Map may
>> introduce a remove(),
>> the name is too common).
>>
>> other comments inlined.
>>
>>>
>>>
>>> On Nov 13 2013, at 18:43 , Paul Benedict <pbenedict at apache.org> wrote:
>>>
>>>> I saw this email come through Apache and would like your opinions:
>>>>
>>>> ===
>>>> Hi,
>>>>
>>>> during the vote for collections 4.0 we have discovered a problem wrt the
>>>> MultiMap interface in general and specifically the MultiKeyMap.
>>> Are the problematic methods new in Collections 4.0 or were they part of
>> previous releases as well?
>>
>> They were introduce in 3.1 (in 2008 it seams).
>>
>> https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/org/apache/commons/collections/map/MultiKeyMap.html
>>
>>>
>>>> Java 8 introduces a new default method in the Map interface:
>>>>
>>>> boolean remove(Object key, Object value)
>>>>
>>>> This clashes with the method in MultiMap:
>>>>
>>>> V remove(K key, V value)
>>>>
>>>> and the remove methods for multiple keys in MultiKeyMap:
>>>>
>>>> V remove(K key1, K key2)
>>> The issue is that the return types are unrelated. If the Java 8 Map
>> method returned Object then it would be possible to specialize the return
>> type to V but because boolean and V/Object are unrelated then the override
>> is not allowed.
>>
>> also the semantics is different.
>>
>>>
>>>
>>>
>>>> Just changing the return type does not solve the problem, as one can not
>>>> re-define a method in an interface without using the @Override
>>>> annotation, but this would only work when compiling with JDK 8 and fail
>>>> for other JDKs.
>>>> ===
>>>>
>>>> What is the correct course in such a situation?
>>> Is it possible to rename these methods in Apache Collections to
>> removeKey and removeValue? Understandably if these methods are not new in
>> 4.0 then it will be difficult to remove them. The other question would be
>> whether it's appropriate for these classes to implement or extend Map. If
>> their semantics are such that they do not fully implement the standard Map
>> semantics then it's probably best that they not claim to be Map
>> implementations.
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>
>> R?mi
>>
>>
>>
>>
>
>

From brian.goetz at oracle.com  Sun Nov 17 04:04:56 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 17 Nov 2013 07:04:56 -0500
Subject: @Override and default methods
In-Reply-To: <52883CC4.9010903@oracle.com>
References: <omyd14t1vml08xlbqocq5lor.1384640674475@email.android.com>	<CABLGb9xw4ZSKpY3h9rZX989wqmOnFb5UUnNFO=x7b04b_qwGyg@mail.gmail.com>
	<52883CC4.9010903@oracle.com>
Message-ID: <5288B0E8.2040205@oracle.com>

>> My concern is how intrusive default methods can be. If someone adds a
>> default method to a super interface and it conflicts with existing methods
>> in a sub-interface, you can't compile. This pattern is ought to repeat over
>> and over. JDK 9 or 10 or the future may continue to add new default methods
>> and break sub-interfaces.
>
> This was deemed an acceptable price to pay to allow the platform classes
> to move forward. Some code will need modification to run on Java 8.

Yes; the EG discussed this risk extensively (i.e., this is not a 
surprise to us) and further explored and ultimately rejected a number of 
mitigation strategies.  We will continue to consider the option of 
mitigation strategies going forward should things turn out to be worse 
than projected.

These particular method signatures were taken from ConcurrentMap, so 
that the methods from ConcurrentMap could (finally) be brought down to 
all Maps.  (Had default methods been around in 5, we would have likely 
added them to Map at that time, but ConcurrentMap was the best we could 
do at the time.)  So the API design work for these particular 
conflicting methods was done ten years ago.

Your gloom-and-doom "it will happen all the time, and it will be CHAOS!" 
prediction is overblown; that assumes zero restraint on the part of JDK 
maintainers.  (If anything, the more common complaint against us is 
usually "too much restraint".  But it might result in more disruption 
for users of third-party libraries, should their maintainers go 
overboard.)  But you are correct to observe that widely-implemented 
interfaces such as Iterator, Iterable, Collection, List, Map, etc, 
should be evolved minimally and carefully, as the more widely 
implemented a type is, the more likely a conflict with subclass methods 
will be.  (Note that this is by no means a problem that is new with 
default methods; we have had this problem with classes since day 1.) 
Note also that this was one of the reasons we ultimately didn't put all 
the map/filter/reduce methods directly on Collection; this would have 
greatly increased the chance of collision, adding dozens of methods 
instead of a few.

(In this particular case, we might also have had more options had we 
heard from Apache earlier.  Binary builds have been available for a 
looong time.)


From thomas.neidhart at gmail.com  Sat Nov 16 03:53:06 2013
From: thomas.neidhart at gmail.com (Thomas Neidhart)
Date: Sat, 16 Nov 2013 12:53:06 +0100
Subject: @Override and default methods
Message-ID: <52875CA2.7000003@gmail.com>

> Hi Paul;
> 
> This is unfortunate. Hopefully we come up with some compromise or accommodation. 
> 
> Mike

Hi Mike,

thanks for answering on this topic.

> On Nov 13 2013, at 18:43 , Paul Benedict <pbenedict at apache.org> wrote:
> 
>> I saw this email come through Apache and would like your opinions:
>> 
>> ===
>> Hi,
>> 
>> during the vote for collections 4.0 we have discovered a problem wrt the
>> MultiMap interface in general and specifically the MultiKeyMap.
> 
> Are the problematic methods new in Collections 4.0 or were they part of previous releases as well?

These method existed already in previous releases, but we are somewhat
fortunate to change it for this release if necessary.

>> Java 8 introduces a new default method in the Map interface:
>> 
>> boolean remove(Object key, Object value)
>> 
>> This clashes with the method in MultiMap:
>> 
>> V remove(K key, V value)
>> 
>> and the remove methods for multiple keys in MultiKeyMap:
>> 
>> V remove(K key1, K key2)
> 
> The issue is that the return types are unrelated. If the Java 8 Map method returned Object then it would be possible to specialize the return type to V but because boolean and V/Object are unrelated then the override is not allowed.
> 
> 
> 
>> Just changing the return type does not solve the problem, as one can not
>> re-define a method in an interface without using the @Override
>> annotation, but this would only work when compiling with JDK 8 and fail
>> for other JDKs.
>> ===
>> 
>> What is the correct course in such a situation?
> 
> Is it possible to rename these methods in Apache Collections to removeKey and removeValue? Understandably if these methods are not new in 4.0 then it will be difficult to remove them. The other question would be whether it's appropriate for these classes to implement or extend Map. If their semantics are such that they do not fully implement the standard Map semantics then it's probably best that they not claim to be Map implementations. 

Yes, we already discussed various options on how to rename them, but
wanted to explore also other possibilities.

The MultiMap interface, and its implementations are otherwise perfectly
compliant to the Map interface, just offering a convenient interface for
mapping multiple values to a given key by using a collection as value type.

I guess the names you suggest are pretty good, although I slightly favor
removeMapping in case of the MultiMap.

Thomas

From alan at alanpinder.com  Fri Nov  8 07:58:31 2013
From: alan at alanpinder.com (Alan)
Date: Fri, 08 Nov 2013 16:58:31 +0100
Subject: Java 8 Bug
Message-ID: <527D0A27.7000804@alanpinder.com>

Sorry if this isn't the correct list ! If not, please tell me where I 
should post this bug.

The following code works in jdk1.7.0_21 but not in jdk1.8.0

private static <E extends Enum<?>> Map<String, Enum<?>> 
parseEnumConstants(Class<E> clazz) {} = ...

Class<?> type = ...

parseEnumConstants(type.asSubclass(Enum.class))

Map<String, Enum<?>> universe = (Map<String, Enum<?>>) 
parseEnumConstants(type.asSubclass(Enum.class));
   required: Class<E>
   found: Class<CAP#1>
   reason: cannot infer type-variable(s) E,U
     (argument mismatch; Class<CAP#2> cannot be converted to Class<CAP#3>)
   where E,U are type-variables:
     E extends Enum<?> declared in method <E>parseEnumConstants(Class<E>)
     U extends Object declared in method <U>asSubclass(Class<U>)
   where CAP#1,CAP#2,CAP#3 are fresh type-variables:
     CAP#1 extends Enum from capture of ? extends Enum
     CAP#2 extends Enum from capture of ? extends Enum
     CAP#3 extends Enum from capture of ? extends Enum

What is really unusual is that I can't see how this error can be 
occuring - none of the method signatures have changed!

From zhong.j.yu at gmail.com  Sun Nov 17 08:50:29 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Sun, 17 Nov 2013 10:50:29 -0600
Subject: Java 8 Bug
In-Reply-To: <527D0A27.7000804@alanpinder.com>
References: <527D0A27.7000804@alanpinder.com>
Message-ID: <CACuKZqFQT6mHVyRVKLJ5gJaVp+32X-jzt2+SxPjCc_m0CN4tZA@mail.gmail.com>

Hi Alan, the code compiles in jdk8 build 115. (I notice that the email is from
9 days ago)

However, I doubt that it *should* compile even in Java7. Essentially,
we have a capture variable `x` whose upper bound is `Enum`, and we
need to test `x<:Enum<?>`, which should fail.

---

BTW, Your method signature is probably better off as

    <E extends Enum<E>> Map<String, Enum<E>>
    parseEnumConstants(Class<E> clazz)

An interesting question is, given a `Class<?>` object, how do we
convince compiler that it is a `Class<e>` for some `e` that
`e<:Enum<e>`? I think there are pretty good answers in
http://stackoverflow.com/questions/15366375

Zhong Yu


On Fri, Nov 8, 2013 at 9:58 AM, Alan <alan at alanpinder.com> wrote:
> Sorry if this isn't the correct list ! If not, please tell me where I
> should post this bug.
>
> The following code works in jdk1.7.0_21 but not in jdk1.8.0
>
> private static <E extends Enum<?>> Map<String, Enum<?>>
> parseEnumConstants(Class<E> clazz) {} = ...
>
> Class<?> type = ...
>
> parseEnumConstants(type.asSubclass(Enum.class))
>
> Map<String, Enum<?>> universe = (Map<String, Enum<?>>)
> parseEnumConstants(type.asSubclass(Enum.class));
>    required: Class<E>
>    found: Class<CAP#1>
>    reason: cannot infer type-variable(s) E,U
>      (argument mismatch; Class<CAP#2> cannot be converted to Class<CAP#3>)
>    where E,U are type-variables:
>      E extends Enum<?> declared in method <E>parseEnumConstants(Class<E>)
>      U extends Object declared in method <U>asSubclass(Class<U>)
>    where CAP#1,CAP#2,CAP#3 are fresh type-variables:
>      CAP#1 extends Enum from capture of ? extends Enum
>      CAP#2 extends Enum from capture of ? extends Enum
>      CAP#3 extends Enum from capture of ? extends Enum
>
> What is really unusual is that I can't see how this error can be
> occuring - none of the method signatures have changed!
>

From brian.goetz at oracle.com  Sun Nov 17 09:19:30 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 17 Nov 2013 12:19:30 -0500
Subject: @Override and default methods
In-Reply-To: <52875CA2.7000003@gmail.com>
References: <52875CA2.7000003@gmail.com>
Message-ID: <5288FAA2.9050704@oracle.com>

Great to hear there's a not-so-unhappy resolution to this story!

BTW, its easy to accidentally make a MultiMap that tries to implement 
Map<K,Something> but violates the Map contract -- so be careful.

You should also consider writing a Collector<T, MultiMap<K,List<T>> for 
grouping into your MultiMap, like Collectors.groupingBy.  Its easy and fun!

>> Are the problematic methods new in Collections 4.0 or were they part of previous releases as well?
>
> These method existed already in previous releases, but we are somewhat
> fortunate to change it for this release if necessary.
>
>>> Java 8 introduces a new default method in the Map interface:
>>>
>>> boolean remove(Object key, Object value)
>>>
>>> This clashes with the method in MultiMap:
>>>
>>> V remove(K key, V value)
>>>
>>> and the remove methods for multiple keys in MultiKeyMap:
>>>
>>> V remove(K key1, K key2)
>>
>> The issue is that the return types are unrelated. If the Java 8 Map method returned Object then it would be possible to specialize the return type to V but because boolean and V/Object are unrelated then the override is not allowed.
>>
>>
>>
>>> Just changing the return type does not solve the problem, as one can not
>>> re-define a method in an interface without using the @Override
>>> annotation, but this would only work when compiling with JDK 8 and fail
>>> for other JDKs.
>>> ===
>>>
>>> What is the correct course in such a situation?
>>
>> Is it possible to rename these methods in Apache Collections to removeKey and removeValue? Understandably if these methods are not new in 4.0 then it will be difficult to remove them. The other question would be whether it's appropriate for these classes to implement or extend Map. If their semantics are such that they do not fully implement the standard Map semantics then it's probably best that they not claim to be Map implementations.
>
> Yes, we already discussed various options on how to rename them, but
> wanted to explore also other possibilities.
>
> The MultiMap interface, and its implementations are otherwise perfectly
> compliant to the Map interface, just offering a convenient interface for
> mapping multiple values to a given key by using a collection as value type.
>
> I guess the names you suggest are pretty good, although I slightly favor
> removeMapping in case of the MultiMap.
>
> Thomas
>

From thomas.neidhart at gmail.com  Sun Nov 17 09:42:33 2013
From: thomas.neidhart at gmail.com (Thomas Neidhart)
Date: Sun, 17 Nov 2013 18:42:33 +0100
Subject: @Override and default methods
In-Reply-To: <5288FAA2.9050704@oracle.com>
References: <52875CA2.7000003@gmail.com> <5288FAA2.9050704@oracle.com>
Message-ID: <52890009.9000601@gmail.com>

On 11/17/2013 06:19 PM, Brian Goetz wrote:
> Great to hear there's a not-so-unhappy resolution to this story!
> 
> BTW, its easy to accidentally make a MultiMap that tries to implement
> Map<K,Something> but violates the Map contract -- so be careful.

Indeed, I was a bit too quick stating that a MultiMap is fully compliant
with the Map contract. In fact there are subtle differences which have
to be considered when using it. Guava has chosen to not implement the
Map interface for their Multimap, and their decision was probably wiser
in this regard.

> You should also consider writing a Collector<T, MultiMap<K,List<T>> for
> grouping into your MultiMap, like Collectors.groupingBy.  Its easy and fun!

Unfortunately, we still aim for Java 5, thus all the new additions are
not yet available for us, but this looks like really interesting stuff.
Also most of the functional aspects of Apache Collections will be
obsolete with Java 8, so we will have to see ourselves which direction
to go in the future.

Thomas

>>> Are the problematic methods new in Collections 4.0 or were they part
>>> of previous releases as well?
>>
>> These method existed already in previous releases, but we are somewhat
>> fortunate to change it for this release if necessary.
>>
>>>> Java 8 introduces a new default method in the Map interface:
>>>>
>>>> boolean remove(Object key, Object value)
>>>>
>>>> This clashes with the method in MultiMap:
>>>>
>>>> V remove(K key, V value)
>>>>
>>>> and the remove methods for multiple keys in MultiKeyMap:
>>>>
>>>> V remove(K key1, K key2)
>>>
>>> The issue is that the return types are unrelated. If the Java 8 Map
>>> method returned Object then it would be possible to specialize the
>>> return type to V but because boolean and V/Object are unrelated then
>>> the override is not allowed.
>>>
>>>
>>>
>>>> Just changing the return type does not solve the problem, as one can
>>>> not
>>>> re-define a method in an interface without using the @Override
>>>> annotation, but this would only work when compiling with JDK 8 and fail
>>>> for other JDKs.
>>>> ===
>>>>
>>>> What is the correct course in such a situation?
>>>
>>> Is it possible to rename these methods in Apache Collections to
>>> removeKey and removeValue? Understandably if these methods are not
>>> new in 4.0 then it will be difficult to remove them. The other
>>> question would be whether it's appropriate for these classes to
>>> implement or extend Map. If their semantics are such that they do not
>>> fully implement the standard Map semantics then it's probably best
>>> that they not claim to be Map implementations.
>>
>> Yes, we already discussed various options on how to rename them, but
>> wanted to explore also other possibilities.
>>
>> The MultiMap interface, and its implementations are otherwise perfectly
>> compliant to the Map interface, just offering a convenient interface for
>> mapping multiple values to a given key by using a collection as value
>> type.
>>
>> I guess the names you suggest are pretty good, although I slightly favor
>> removeMapping in case of the MultiMap.
>>
>> Thomas
>>


From pbenedict at apache.org  Sun Nov 17 21:44:42 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Sun, 17 Nov 2013 23:44:42 -0600
Subject: @Override and default methods
In-Reply-To: <5288B0E8.2040205@oracle.com>
References: <omyd14t1vml08xlbqocq5lor.1384640674475@email.android.com>
	<CABLGb9xw4ZSKpY3h9rZX989wqmOnFb5UUnNFO=x7b04b_qwGyg@mail.gmail.com>
	<52883CC4.9010903@oracle.com> <5288B0E8.2040205@oracle.com>
Message-ID: <CABLGb9wFN8BBWC4KLD5EART41Fc1ShHvo5cWvJ_i_KJQz9hHMQ@mail.gmail.com>

On Sun, Nov 17, 2013 at 6:04 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> (In this particular case, we might also have had more options had we heard
> from Apache earlier.  Binary builds have been available for a looong time.)
>

True, except volunteers only scratch an itch when they feel the need.

-- 
Cheers,
Paul

From paul.sandoz at oracle.com  Mon Nov 18 01:23:51 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 18 Nov 2013 10:23:51 +0100
Subject: Stateless traits & default interface methods question
In-Reply-To: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
References: <CAGZB7RiGsvm7xFCzyvehkkTXpmqsjL-hm5ftoixPqXRrA4Nd4w@mail.gmail.com>
Message-ID: <C7AF3052-6A8B-4F9B-B978-E9A7899A6977@oracle.com>

Hi Matthew,

You can think of a default method as "just another virtual method" i.e. there is no fundamental difference, from the perspective of the VM, between a default method on an interface and a non-abstract (or concrete) method on a class. The VM wires up method invocation at runtime and there are a few tweaks to the virtual machine specification.

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html

Paul.

On Nov 13, 2013, at 5:49 PM, Matthew Adams <matthew at matthewadams.me> wrote:

> _Note: This may be a FAQ.  RTFMs are fine._
> 
> I have a question about default interface methods, thinking in terms of
> stateless traits.
> 
> Assume at time t0 I define an interface I with a given default method
> implementation and class C implements I.  Later, at time t1, I modify the
> implementations of I's default methods _without_ recompiling C.  The next
> time that I execute a method on C that came from a default method on I, do
> I get I's implementation as it was at t0 or t1?
> 
> In other words, are default method implementations woven into classes at
> compile time, do classes delegate to the interface's default method
> implementation at runtime, or is it via some other mechanism?
> 
> -matthew
> -- 
> mailto:matthew at matthewadams.me <matthew at matthewadams.me>
> skype:matthewadams12
> googletalk:matthew at matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
> 


From vicente.romero at oracle.com  Mon Nov 18 04:19:43 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 18 Nov 2013 12:19:43 +0000
Subject: primitive type bounds
In-Reply-To: <003301cee308$53b027a0$fb1076e0$@kozlova@jetbrains.com>
References: <003301cee308$53b027a0$fb1076e0$@kozlova@jetbrains.com>
Message-ID: <528A05DF.7090203@oracle.com>

Hi Anna,

This is clearly a bug. I have created bug entry [1] to track it.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8028503

On 16/11/13 20:13, Anna Kozlova wrote:
> Hi,
>
>   
>
> I don't understand why there is a compilation error (b. 115) here:
>
>   
>
> class Test {
>
>      static <U> Iterable<U> map(Mapper<String, U> mapper) {
>
>          return null;
>
>      }
>
>   
>
>      static void test() {
>
>          Iterable<Integer> map = map(Test::length);
>
>      }
>
>   
>
>      public static <T> int length(String s) {
>
>          return 0;
>
>      }
>
> }
>
> interface Mapper<T, U> {
>
>      U map(T t);
>
> }
>
>   
>
> java: incompatible types: inference variable U has incompatible bounds
>
>      equality constraints: java.lang.Integer
>
>      lower bounds: java.lang.Integer,int
>
>   
>
> How does javac get 'int' lower bound here?
>
>   
>
> Thanks,
>
> Anna
>
>


From anna.kozlova at jetbrains.com  Mon Nov 18 07:31:30 2013
From: anna.kozlova at jetbrains.com (Anna Kozlova)
Date: Mon, 18 Nov 2013 16:31:30 +0100
Subject: javac rejects valid java 7 code
Message-ID: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>

Hi,

 

This code compiles with java 1.7 (also 1.6) but fails to compile with 1.8
(b. 115)

 

abstract class A2<T>{

    abstract <S> S foo(S x, S y);

    abstract <S1> void baz(A2<S1> a)

 

    void bar(A2<Integer> y, A2<Long> x){

         baz(foo(x, y));

    }

}

 

java: method baz in class A2<T> cannot be applied to given types;

  required: A2<S1>

  found: A2<capture#1 of ? extends java.lang.Number&java.lang.Comparable<?
extends java.lang.Number&java.lang.Comparable<?>>>

  reason: inferred type does not conform to equality constraint(s)

    inferred: java.lang.Long

    equality constraints(s): java.lang.Long,java.lang.Integer

 

Are these equality constraint really for S1? How does javac get them
independently from whom they belong?

 

Thanks,

Anna


From vicente.romero at oracle.com  Mon Nov 18 12:07:43 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 18 Nov 2013 20:07:43 +0000
Subject: javac rejects valid java 7 code
In-Reply-To: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
References: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
Message-ID: <528A738F.4000301@oracle.com>

Hi Anna,

This issue should be investigated, I have created bug entry: 
https://bugs.openjdk.java.net/browse/JDK-8028547, to track this,

Thanks,
Vicente


On 18/11/13 15:31, Anna Kozlova wrote:
> Hi,
>
>   
>
> This code compiles with java 1.7 (also 1.6) but fails to compile with 1.8
> (b. 115)
>
>   
>
> abstract class A2<T>{
>
>      abstract <S> S foo(S x, S y);
>
>      abstract <S1> void baz(A2<S1> a)
>
>   
>
>      void bar(A2<Integer> y, A2<Long> x){
>
>           baz(foo(x, y));
>
>      }
>
> }
>
>   
>
> java: method baz in class A2<T> cannot be applied to given types;
>
>    required: A2<S1>
>
>    found: A2<capture#1 of ? extends java.lang.Number&java.lang.Comparable<?
> extends java.lang.Number&java.lang.Comparable<?>>>
>
>    reason: inferred type does not conform to equality constraint(s)
>
>      inferred: java.lang.Long
>
>      equality constraints(s): java.lang.Long,java.lang.Integer
>
>   
>
> Are these equality constraint really for S1? How does javac get them
> independently from whom they belong?
>
>   
>
> Thanks,
>
> Anna
>
>


From anna.kozlova at jetbrains.com  Mon Nov 18 12:12:09 2013
From: anna.kozlova at jetbrains.com (Anna Kozlova)
Date: Mon, 18 Nov 2013 21:12:09 +0100
Subject: javac rejects valid java 7 code
In-Reply-To: <528A738F.4000301@oracle.com>
References: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
	<528A738F.4000301@oracle.com>
Message-ID: <00c401cee49a$760ad140$622073c0$@kozlova@jetbrains.com>

Vicente,

Could you please take into account also two variations (difference in bounds
of the second method type parameters only):

abstract class A<T>{
    abstract <S> S foo(S x, S y);
    <S extends Number & Comparable<? extends Number>> void baz(A<S> a){}

    void bar(A<Long> x, A<Integer> y){
        baz(foo(x, y));
    }
}

abstract class A1<T>{
    abstract <S> S foo(S x, S y);
    <T extends Number & Comparable<?>, S extends Number & Comparable<?
extends T>> void baz(A1<S> a){}

    void bar(A1<Long> x, A1<Integer> y){
        baz(foo(x, y));
    }
}

Thanks, 
Anna

-----Original Message-----
From: Vicente-Arturo Romero-Zaldivar [mailto:vicente.romero at oracle.com] 
Sent: Monday, November 18, 2013 9:08 PM
To: Anna Kozlova; lambda-dev at openjdk.java.net
Subject: Re: javac rejects valid java 7 code

Hi Anna,

This issue should be investigated, I have created bug entry: 
https://bugs.openjdk.java.net/browse/JDK-8028547, to track this,

Thanks,
Vicente


On 18/11/13 15:31, Anna Kozlova wrote:
> Hi,
>
>   
>
> This code compiles with java 1.7 (also 1.6) but fails to compile with 
> 1.8 (b. 115)
>
>   
>
> abstract class A2<T>{
>
>      abstract <S> S foo(S x, S y);
>
>      abstract <S1> void baz(A2<S1> a)
>
>   
>
>      void bar(A2<Integer> y, A2<Long> x){
>
>           baz(foo(x, y));
>
>      }
>
> }
>
>   
>
> java: method baz in class A2<T> cannot be applied to given types;
>
>    required: A2<S1>
>
>    found: A2<capture#1 of ? extends
java.lang.Number&java.lang.Comparable<?
> extends java.lang.Number&java.lang.Comparable<?>>>
>
>    reason: inferred type does not conform to equality constraint(s)
>
>      inferred: java.lang.Long
>
>      equality constraints(s): java.lang.Long,java.lang.Integer
>
>   
>
> Are these equality constraint really for S1? How does javac get them 
> independently from whom they belong?
>
>   
>
> Thanks,
>
> Anna
>
>


!DSPAM:35,528a73a262931173217933!



From jonathan.ross at imc-chicago.com  Mon Nov 18 16:43:11 2013
From: jonathan.ross at imc-chicago.com (Jonathan Ross)
Date: Mon, 18 Nov 2013 18:43:11 -0600
Subject: Overload resolution regression
Message-ID: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>

Hi,

I recently started porting a 150k-line project to jdk 8 to try my hand at
the recent changes in the collection libraries. (Hadn't done this since
last year, my apologies!)

I have run in to a large number of compilation errors: regressions in type
inference and overload resolution. A lot of these are in unit tests using
mockito and fest and other similar monadic apis that rely heavily on
overload resolution.

The code snippet below is a distilled version of my typical compilation
error: our test code relying on the compiler choosing the Object overload
by default.


import java.math.BigInteger;

public class OverloadingRegression {

    static <T> T unsafeCast(Object anObject) {
        return (T) anObject;
    }

    public void showOverloadResolutionIssue() {
        pickMe(unsafeCast(new String()));
    }

    private void pickMe(BigInteger o) { /* ClassCastException in
1.8.0-ea-b115 */ }

    private void pickMe(Object o) { /* fine, picked in 1.6 & 1.7 */ }
}


Obviously the unsafeCast is not going to win any beauty prizes, but
sometimes you just have to do this sort of thing.  My main point is: it
used to work in java 7, it doesn't any more.

Is this a known issue (or is it even expected behaviour)?

I'm using 1.8.0-ea-b115, but I verified that it fails with all 1.8 jdks I
have my box.  When I pass in -source 1.7 it does work. And when I do an
explicit cast to Object (of course).

-- Jonathan Ross

From anna.kozlova at jetbrains.com  Tue Nov 19 02:20:09 2013
From: anna.kozlova at jetbrains.com (Anna Kozlova)
Date: Tue, 19 Nov 2013 11:20:09 +0100
Subject: 18.2.2 Type Compatibility Constraints 0.7.0 changes
Message-ID: <00ec01cee510$ed532650$c7f972f0$@kozlova@jetbrains.com>

Hi,

 

In 0.7.0 spec "if T is a parameterized type of the form G<T1, ..., Tn>, and
there exists no type of the form G<S1, ..., Sn> that is a supertype of S,
but the raw type G is a supertype of S, then the constraint reduces to true"
was added. How does javac then infer raw substitution here?

 

class Test {

    interface Condition<K> {}

    class SpecialCondition<M> implements Condition {}

 

    static <T> List<T> filter(T[] c, Condition<? super T> con) {

        return null;

    }

 

    void foo(CharSequence[] es, SpecialCondition<CharSequence> con) {

        List<String> l =  filter(es, con);

    }

}

 

Thanks,

Anna


From forax at univ-mlv.fr  Tue Nov 19 03:30:27 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 19 Nov 2013 12:30:27 +0100
Subject: Overload resolution regression
In-Reply-To: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
Message-ID: <528B4BD3.2070906@univ-mlv.fr>

On 11/19/2013 01:43 AM, Jonathan Ross wrote:
> Hi,

Hi Johnathan,

>
> I recently started porting a 150k-line project to jdk 8 to try my hand at
> the recent changes in the collection libraries. (Hadn't done this since
> last year, my apologies!)
>
> I have run in to a large number of compilation errors: regressions in type
> inference and overload resolution. A lot of these are in unit tests using
> mockito and fest and other similar monadic apis that rely heavily on
> overload resolution.

It's not a regression, it's an enhancement :)

>
> The code snippet below is a distilled version of my typical compilation
> error: our test code relying on the compiler choosing the Object overload
> by default.
>
>
> import java.math.BigInteger;
>
> public class OverloadingRegression {
>
>      static <T> T unsafeCast(Object anObject) {
>          return (T) anObject;
>      }
>
>      public void showOverloadResolutionIssue() {
>          pickMe(unsafeCast(new String()));
>      }
>
>      private void pickMe(BigInteger o) { /* ClassCastException in
> 1.8.0-ea-b115 */ }
>
>      private void pickMe(Object o) { /* fine, picked in 1.6 & 1.7 */ }
> }
>
>
> Obviously the unsafeCast is not going to win any beauty prizes, but
> sometimes you just have to do this sort of thing.  My main point is: it
> used to work in java 7, it doesn't any more.
>
> Is this a known issue (or is it even expected behaviour)?

Yes, it's the expected behavior, when you try do inference inside a 
method call,
here unsafeCast is inside pickMe, in that case with jdk6 & 7, the inference
is not done and T is replaceb by its bound (Object), with jdk8, the 
compiler is smarter,
and find the most specific method first, here pickMe(BigInteger) is more
specific than pickMe(Object) and then infers T (T = BigInteger).

>
> I'm using 1.8.0-ea-b115, but I verified that it fails with all 1.8 jdks I
> have my box.  When I pass in -source 1.7 it does work. And when I do an
> explicit cast to Object (of course).

so this is the correct behavior for 8, the new stream API heavily relies 
on that,
and yes, this new semantics is not compatible with 1.7 in the case the 
inference was failing,
this is a known compatibility issue.

>
> -- Jonathan Ross
>

cheers,
R?mi


From vicente.romero at oracle.com  Tue Nov 19 05:01:09 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 19 Nov 2013 13:01:09 +0000
Subject: javac rejects valid java 7 code
In-Reply-To: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
References: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
Message-ID: <528B6115.2040107@oracle.com>

Hi Anna,

I don't think that this is a bug. This is what javac is inferring for 
your original example:

var S
     upper bounds = A2<S1>,java.lang.Object
     lower bounds = A2<java.lang.Integer>,A2<java.lang.Long>
     eq bounds = []

var S1
     upper bounds = java.lang.Object
     lower bounds = []
     eq bounds = java.lang.Long,java.lang.Integer

all types of the form Type1, Type2 are intersection types and were 
introduced to create more correct and strict inference restrictions. In 
java7 they would have been inferred as Object, and that's why the 
example works in 7. So what javac8 is saying is that it can't find a 
solution for these variables with the given restrictions. Note that if 
in your example method bar is for example defined as:

void bar(A2<Integer> y, A2<Integer> x) {...}

then the example will compile in 8 as now it's possible to find a 
solution. The inference in that case will look like:

var S
     upper bounds = A2<S1>,java.lang.Object
     lower bounds = A2<java.lang.Integer>
     eq bounds = []
var S1
     upper bounds = java.lang.Object
     lower bounds = []
     eq bounds = java.lang.Integer

As you can see the introduction of intersection types to model bounds 
makes the compiler both smarter and stricter.

I will continue checking the rest of the examples.

Thanks,
Vicente.


On 18/11/13 15:31, Anna Kozlova wrote:
> Hi,
>
>   
>
> This code compiles with java 1.7 (also 1.6) but fails to compile with 1.8
> (b. 115)
>
>   
>
> abstract class A2<T>{
>
>      abstract <S> S foo(S x, S y);
>
>      abstract <S1> void baz(A2<S1> a)
>
>   
>
>      void bar(A2<Integer> y, A2<Long> x){
>
>           baz(foo(x, y));
>
>      }
>
> }
>
>   
>
> java: method baz in class A2<T> cannot be applied to given types;
>
>    required: A2<S1>
>
>    found: A2<capture#1 of ? extends java.lang.Number&java.lang.Comparable<?
> extends java.lang.Number&java.lang.Comparable<?>>>
>
>    reason: inferred type does not conform to equality constraint(s)
>
>      inferred: java.lang.Long
>
>      equality constraints(s): java.lang.Long,java.lang.Integer
>
>   
>
> Are these equality constraint really for S1? How does javac get them
> independently from whom they belong?
>
>   
>
> Thanks,
>
> Anna
>
>


From pbenedict at apache.org  Tue Nov 19 05:53:01 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 19 Nov 2013 07:53:01 -0600
Subject: Overload resolution regression
In-Reply-To: <528B4BD3.2070906@univ-mlv.fr>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
	<528B4BD3.2070906@univ-mlv.fr>
Message-ID: <CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>

I don't see how you can call the compiler "smarter" in this example. It is
choosing pickMe(BigInteger) without >: BigInteger type being present.


On Tue, Nov 19, 2013 at 5:30 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 11/19/2013 01:43 AM, Jonathan Ross wrote:
> > Hi,
>
> Hi Johnathan,
>
> >
> > I recently started porting a 150k-line project to jdk 8 to try my hand at
> > the recent changes in the collection libraries. (Hadn't done this since
> > last year, my apologies!)
> >
> > I have run in to a large number of compilation errors: regressions in
> type
> > inference and overload resolution. A lot of these are in unit tests using
> > mockito and fest and other similar monadic apis that rely heavily on
> > overload resolution.
>
> It's not a regression, it's an enhancement :)
>
> >
> > The code snippet below is a distilled version of my typical compilation
> > error: our test code relying on the compiler choosing the Object overload
> > by default.
> >
> >
> > import java.math.BigInteger;
> >
> > public class OverloadingRegression {
> >
> >      static <T> T unsafeCast(Object anObject) {
> >          return (T) anObject;
> >      }
> >
> >      public void showOverloadResolutionIssue() {
> >          pickMe(unsafeCast(new String()));
> >      }
> >
> >      private void pickMe(BigInteger o) { /* ClassCastException in
> > 1.8.0-ea-b115 */ }
> >
> >      private void pickMe(Object o) { /* fine, picked in 1.6 & 1.7 */ }
> > }
> >
> >
> > Obviously the unsafeCast is not going to win any beauty prizes, but
> > sometimes you just have to do this sort of thing.  My main point is: it
> > used to work in java 7, it doesn't any more.
> >
> > Is this a known issue (or is it even expected behaviour)?
>
> Yes, it's the expected behavior, when you try do inference inside a
> method call,
> here unsafeCast is inside pickMe, in that case with jdk6 & 7, the inference
> is not done and T is replaceb by its bound (Object), with jdk8, the
> compiler is smarter,
> and find the most specific method first, here pickMe(BigInteger) is more
> specific than pickMe(Object) and then infers T (T = BigInteger).
>
> >
> > I'm using 1.8.0-ea-b115, but I verified that it fails with all 1.8 jdks I
> > have my box.  When I pass in -source 1.7 it does work. And when I do an
> > explicit cast to Object (of course).
>
> so this is the correct behavior for 8, the new stream API heavily relies
> on that,
> and yes, this new semantics is not compatible with 1.7 in the case the
> inference was failing,
> this is a known compatibility issue.
>
> >
> > -- Jonathan Ross
> >
>
> cheers,
> R?mi
>
>
>


-- 
Cheers,
Paul

From forax at univ-mlv.fr  Tue Nov 19 06:39:00 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 19 Nov 2013 15:39:00 +0100
Subject: Overload resolution regression
In-Reply-To: <CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
	<528B4BD3.2070906@univ-mlv.fr>
	<CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>
Message-ID: <528B7804.5000404@univ-mlv.fr>

On 11/19/2013 02:53 PM, Paul Benedict wrote:
> I don't see how you can call the compiler "smarter" in this example.

'smarter' because this is not the only use case :)
Here is an example that fails to compile with 7 but compiles with 8
(comparingByValue is also a method that only uses type variables to 
specify the return type)
   Map<String,String> map = ...
   map.entrySet().stream().sorted(Map.Entry.comparingByValue());

For pickMe(unsafe()) the inference fails in 7 and uses Object as a fallback,
it appears that it's what the user want but that's just a coincidence.

> It is choosing pickMe(BigInteger) without >: BigInteger type being 
> present.


Don't forget that pickMe(null) also choose pickMe(BigInteger),
it's the way the algorithm that choose the most specific method works 
since the beginning.
here, the constraint is that T is a subtype of Object, so both 
pickMe(Object) and pickMe(BigInteger) are applicable,
then the most specific algorithm chooses that pickMe(BigInteger) is 
better than pickMe(Object).

cheers,
R?mi

>
>
> On Tue, Nov 19, 2013 at 5:30 AM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 11/19/2013 01:43 AM, Jonathan Ross wrote:
>     > Hi,
>
>     Hi Johnathan,
>
>     >
>     > I recently started porting a 150k-line project to jdk 8 to try
>     my hand at
>     > the recent changes in the collection libraries. (Hadn't done
>     this since
>     > last year, my apologies!)
>     >
>     > I have run in to a large number of compilation errors:
>     regressions in type
>     > inference and overload resolution. A lot of these are in unit
>     tests using
>     > mockito and fest and other similar monadic apis that rely heavily on
>     > overload resolution.
>
>     It's not a regression, it's an enhancement :)
>
>     >
>     > The code snippet below is a distilled version of my typical
>     compilation
>     > error: our test code relying on the compiler choosing the Object
>     overload
>     > by default.
>     >
>     >
>     > import java.math.BigInteger;
>     >
>     > public class OverloadingRegression {
>     >
>     >      static <T> T unsafeCast(Object anObject) {
>     >          return (T) anObject;
>     >      }
>     >
>     >      public void showOverloadResolutionIssue() {
>     >          pickMe(unsafeCast(new String()));
>     >      }
>     >
>     >      private void pickMe(BigInteger o) { /* ClassCastException in
>     > 1.8.0-ea-b115 */ }
>     >
>     >      private void pickMe(Object o) { /* fine, picked in 1.6 &
>     1.7 */ }
>     > }
>     >
>     >
>     > Obviously the unsafeCast is not going to win any beauty prizes, but
>     > sometimes you just have to do this sort of thing.  My main point
>     is: it
>     > used to work in java 7, it doesn't any more.
>     >
>     > Is this a known issue (or is it even expected behaviour)?
>
>     Yes, it's the expected behavior, when you try do inference inside a
>     method call,
>     here unsafeCast is inside pickMe, in that case with jdk6 & 7, the
>     inference
>     is not done and T is replaceb by its bound (Object), with jdk8, the
>     compiler is smarter,
>     and find the most specific method first, here pickMe(BigInteger)
>     is more
>     specific than pickMe(Object) and then infers T (T = BigInteger).
>
>     >
>     > I'm using 1.8.0-ea-b115, but I verified that it fails with all
>     1.8 jdks I
>     > have my box.  When I pass in -source 1.7 it does work. And when
>     I do an
>     > explicit cast to Object (of course).
>
>     so this is the correct behavior for 8, the new stream API heavily
>     relies
>     on that,
>     and yes, this new semantics is not compatible with 1.7 in the case the
>     inference was failing,
>     this is a known compatibility issue.
>
>     >
>     > -- Jonathan Ross
>     >
>
>     cheers,
>     R?mi
>
>
>
>
>
> -- 
> Cheers,
> Paul


From pbenedict at apache.org  Tue Nov 19 07:02:30 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 19 Nov 2013 09:02:30 -0600
Subject: Overload resolution regression
In-Reply-To: <528B7804.5000404@univ-mlv.fr>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
	<528B4BD3.2070906@univ-mlv.fr>
	<CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>
	<528B7804.5000404@univ-mlv.fr>
Message-ID: <CABLGb9zDjGa=RPAjajwou+wZu3+K6BxCqMFxO8NrmpzfBp=+HQ@mail.gmail.com>

Ah, okay, that makes sense now. Filling me in on the background was a big
helper.

For the sake of clarity, what would happen to Jonathan's example if there
was also a third pickMe(BigDecimal)?


On Tue, Nov 19, 2013 at 8:39 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 11/19/2013 02:53 PM, Paul Benedict wrote:
>
>> I don't see how you can call the compiler "smarter" in this example.
>>
>
> 'smarter' because this is not the only use case :)
> Here is an example that fails to compile with 7 but compiles with 8
> (comparingByValue is also a method that only uses type variables to
> specify the return type)
>   Map<String,String> map = ...
>   map.entrySet().stream().sorted(Map.Entry.comparingByValue());
>
> For pickMe(unsafe()) the inference fails in 7 and uses Object as a
> fallback,
> it appears that it's what the user want but that's just a coincidence.
>
>  It is choosing pickMe(BigInteger) without >: BigInteger type being
>> present.
>>
>
>
> Don't forget that pickMe(null) also choose pickMe(BigInteger),
> it's the way the algorithm that choose the most specific method works
> since the beginning.
> here, the constraint is that T is a subtype of Object, so both
> pickMe(Object) and pickMe(BigInteger) are applicable,
> then the most specific algorithm chooses that pickMe(BigInteger) is better
> than pickMe(Object).
>
> cheers,
> R?mi
>
>
>>
>> On Tue, Nov 19, 2013 at 5:30 AM, Remi Forax <forax at univ-mlv.fr <mailto:
>> forax at univ-mlv.fr>> wrote:
>>
>>     On 11/19/2013 01:43 AM, Jonathan Ross wrote:
>>     > Hi,
>>
>>     Hi Johnathan,
>>
>>     >
>>     > I recently started porting a 150k-line project to jdk 8 to try
>>     my hand at
>>     > the recent changes in the collection libraries. (Hadn't done
>>     this since
>>     > last year, my apologies!)
>>     >
>>     > I have run in to a large number of compilation errors:
>>     regressions in type
>>     > inference and overload resolution. A lot of these are in unit
>>     tests using
>>     > mockito and fest and other similar monadic apis that rely heavily on
>>     > overload resolution.
>>
>>     It's not a regression, it's an enhancement :)
>>
>>     >
>>     > The code snippet below is a distilled version of my typical
>>     compilation
>>     > error: our test code relying on the compiler choosing the Object
>>     overload
>>     > by default.
>>     >
>>     >
>>     > import java.math.BigInteger;
>>     >
>>     > public class OverloadingRegression {
>>     >
>>     >      static <T> T unsafeCast(Object anObject) {
>>     >          return (T) anObject;
>>     >      }
>>     >
>>     >      public void showOverloadResolutionIssue() {
>>     >          pickMe(unsafeCast(new String()));
>>     >      }
>>     >
>>     >      private void pickMe(BigInteger o) { /* ClassCastException in
>>     > 1.8.0-ea-b115 */ }
>>     >
>>     >      private void pickMe(Object o) { /* fine, picked in 1.6 &
>>     1.7 */ }
>>     > }
>>     >
>>     >
>>     > Obviously the unsafeCast is not going to win any beauty prizes, but
>>     > sometimes you just have to do this sort of thing.  My main point
>>     is: it
>>     > used to work in java 7, it doesn't any more.
>>     >
>>     > Is this a known issue (or is it even expected behaviour)?
>>
>>     Yes, it's the expected behavior, when you try do inference inside a
>>     method call,
>>     here unsafeCast is inside pickMe, in that case with jdk6 & 7, the
>>     inference
>>     is not done and T is replaceb by its bound (Object), with jdk8, the
>>     compiler is smarter,
>>     and find the most specific method first, here pickMe(BigInteger)
>>     is more
>>     specific than pickMe(Object) and then infers T (T = BigInteger).
>>
>>     >
>>     > I'm using 1.8.0-ea-b115, but I verified that it fails with all
>>     1.8 jdks I
>>     > have my box.  When I pass in -source 1.7 it does work. And when
>>     I do an
>>     > explicit cast to Object (of course).
>>
>>     so this is the correct behavior for 8, the new stream API heavily
>>     relies
>>     on that,
>>     and yes, this new semantics is not compatible with 1.7 in the case the
>>     inference was failing,
>>     this is a known compatibility issue.
>>
>>     >
>>     > -- Jonathan Ross
>>     >
>>
>>     cheers,
>>     R?mi
>>
>>
>>
>>
>>
>> --
>> Cheers,
>> Paul
>>
>
>


-- 
Cheers,
Paul

From zhong.j.yu at gmail.com  Tue Nov 19 08:26:00 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 19 Nov 2013 10:26:00 -0600
Subject: javac rejects valid java 7 code
In-Reply-To: <528B6115.2040107@oracle.com>
References: <528B6115.2040107@oracle.com>
Message-ID: <CACuKZqHMrcUirydv76arwGbm9w6tMTxujDNgbO4Bf64+E-oRZw@mail.gmail.com>

In Java7, shouldn't S be inferred to A2<? extends Number&...> instead?
Then, the return type of `foo(x,y)` goes through capture conversion
and becomes A2<CAP#> which can be fed to baz().

On Tue, Nov 19, 2013 at 7:01 AM, Vicente-Arturo Romero-Zaldivar
<vicente.romero at oracle.com> wrote:
> Hi Anna,
>
> I don't think that this is a bug. This is what javac is inferring for
> your original example:
>
> var S
>      upper bounds = A2<S1>,java.lang.Object
>      lower bounds = A2<java.lang.Integer>,A2<java.lang.Long>
>      eq bounds = []
>
> var S1
>      upper bounds = java.lang.Object
>      lower bounds = []
>      eq bounds = java.lang.Long,java.lang.Integer
>
> all types of the form Type1, Type2 are intersection types and were
> introduced to create more correct and strict inference restrictions. In
> java7 they would have been inferred as Object, and that's why the
> example works in 7. So what javac8 is saying is that it can't find a
> solution for these variables with the given restrictions. Note that if
> in your example method bar is for example defined as:
>
> void bar(A2<Integer> y, A2<Integer> x) {...}
>
> then the example will compile in 8 as now it's possible to find a
> solution. The inference in that case will look like:
>
> var S
>      upper bounds = A2<S1>,java.lang.Object
>      lower bounds = A2<java.lang.Integer>
>      eq bounds = []
> var S1
>      upper bounds = java.lang.Object
>      lower bounds = []
>      eq bounds = java.lang.Integer
>
> As you can see the introduction of intersection types to model bounds
> makes the compiler both smarter and stricter.
>
> I will continue checking the rest of the examples.
>
> Thanks,
> Vicente.
>
>
> On 18/11/13 15:31, Anna Kozlova wrote:
>> Hi,
>>
>>
>>
>> This code compiles with java 1.7 (also 1.6) but fails to compile with 1.8
>> (b. 115)
>>
>>
>>
>> abstract class A2<T>{
>>
>>      abstract <S> S foo(S x, S y);
>>
>>      abstract <S1> void baz(A2<S1> a)
>>
>>
>>
>>      void bar(A2<Integer> y, A2<Long> x){
>>
>>           baz(foo(x, y));
>>
>>      }
>>
>> }
>>
>>
>>
>> java: method baz in class A2<T> cannot be applied to given types;
>>
>>    required: A2<S1>
>>
>>    found: A2<capture#1 of ? extends java.lang.Number&java.lang.Comparable<?
>> extends java.lang.Number&java.lang.Comparable<?>>>
>>
>>    reason: inferred type does not conform to equality constraint(s)
>>
>>      inferred: java.lang.Long
>>
>>      equality constraints(s): java.lang.Long,java.lang.Integer
>>
>>
>>
>> Are these equality constraint really for S1? How does javac get them
>> independently from whom they belong?
>>
>>
>>
>> Thanks,
>>
>> Anna
>>
>>
>
>

From jonathan.ross at imc-chicago.com  Tue Nov 19 08:43:03 2013
From: jonathan.ross at imc-chicago.com (Jonathan Ross)
Date: Tue, 19 Nov 2013 10:43:03 -0600
Subject: Overload resolution regression
In-Reply-To: <CABLGb9zDjGa=RPAjajwou+wZu3+K6BxCqMFxO8NrmpzfBp=+HQ@mail.gmail.com>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
	<528B4BD3.2070906@univ-mlv.fr>
	<CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>
	<528B7804.5000404@univ-mlv.fr>
	<CABLGb9zDjGa=RPAjajwou+wZu3+K6BxCqMFxO8NrmpzfBp=+HQ@mail.gmail.com>
Message-ID: <CABY=8csvjf_k3og1C-yC9Z=MRYEpvo2fiYrbmYLVu2r31Uk_zw@mail.gmail.com>

Or a pickMe(String) for that matter?

Thanks for the explanation, Remi.  Indeed, we were just using the
coincidence of the Object fallback; it seems to predominantly affect our
test fixtures - I hope, at least.  The nasty thing about it is that it
leads to a runtime exception rather than a compilation error, so we may not
find out for certain for a while.


On Tue, Nov 19, 2013 at 9:02 AM, Paul Benedict <pbenedict at apache.org> wrote:

> Ah, okay, that makes sense now. Filling me in on the background was a big
> helper.
>
> For the sake of clarity, what would happen to Jonathan's example if there
> was also a third pickMe(BigDecimal)?
>
>
> On Tue, Nov 19, 2013 at 8:39 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> > On 11/19/2013 02:53 PM, Paul Benedict wrote:
> >
> >> I don't see how you can call the compiler "smarter" in this example.
> >>
> >
> > 'smarter' because this is not the only use case :)
> > Here is an example that fails to compile with 7 but compiles with 8
> > (comparingByValue is also a method that only uses type variables to
> > specify the return type)
> >   Map<String,String> map = ...
> >   map.entrySet().stream().sorted(Map.Entry.comparingByValue());
> >
> > For pickMe(unsafe()) the inference fails in 7 and uses Object as a
> > fallback,
> > it appears that it's what the user want but that's just a coincidence.
> >
> >  It is choosing pickMe(BigInteger) without >: BigInteger type being
> >> present.
> >>
> >
> >
> > Don't forget that pickMe(null) also choose pickMe(BigInteger),
> > it's the way the algorithm that choose the most specific method works
> > since the beginning.
> > here, the constraint is that T is a subtype of Object, so both
> > pickMe(Object) and pickMe(BigInteger) are applicable,
> > then the most specific algorithm chooses that pickMe(BigInteger) is
> better
> > than pickMe(Object).
> >
> > cheers,
> > R?mi
> >
> >
> >>
> >> On Tue, Nov 19, 2013 at 5:30 AM, Remi Forax <forax at univ-mlv.fr <mailto:
> >> forax at univ-mlv.fr>> wrote:
> >>
> >>     On 11/19/2013 01:43 AM, Jonathan Ross wrote:
> >>     > Hi,
> >>
> >>     Hi Johnathan,
> >>
> >>     >
> >>     > I recently started porting a 150k-line project to jdk 8 to try
> >>     my hand at
> >>     > the recent changes in the collection libraries. (Hadn't done
> >>     this since
> >>     > last year, my apologies!)
> >>     >
> >>     > I have run in to a large number of compilation errors:
> >>     regressions in type
> >>     > inference and overload resolution. A lot of these are in unit
> >>     tests using
> >>     > mockito and fest and other similar monadic apis that rely heavily
> on
> >>     > overload resolution.
> >>
> >>     It's not a regression, it's an enhancement :)
> >>
> >>     >
> >>     > The code snippet below is a distilled version of my typical
> >>     compilation
> >>     > error: our test code relying on the compiler choosing the Object
> >>     overload
> >>     > by default.
> >>     >
> >>     >
> >>     > import java.math.BigInteger;
> >>     >
> >>     > public class OverloadingRegression {
> >>     >
> >>     >      static <T> T unsafeCast(Object anObject) {
> >>     >          return (T) anObject;
> >>     >      }
> >>     >
> >>     >      public void showOverloadResolutionIssue() {
> >>     >          pickMe(unsafeCast(new String()));
> >>     >      }
> >>     >
> >>     >      private void pickMe(BigInteger o) { /* ClassCastException in
> >>     > 1.8.0-ea-b115 */ }
> >>     >
> >>     >      private void pickMe(Object o) { /* fine, picked in 1.6 &
> >>     1.7 */ }
> >>     > }
> >>     >
> >>     >
> >>     > Obviously the unsafeCast is not going to win any beauty prizes,
> but
> >>     > sometimes you just have to do this sort of thing.  My main point
> >>     is: it
> >>     > used to work in java 7, it doesn't any more.
> >>     >
> >>     > Is this a known issue (or is it even expected behaviour)?
> >>
> >>     Yes, it's the expected behavior, when you try do inference inside a
> >>     method call,
> >>     here unsafeCast is inside pickMe, in that case with jdk6 & 7, the
> >>     inference
> >>     is not done and T is replaceb by its bound (Object), with jdk8, the
> >>     compiler is smarter,
> >>     and find the most specific method first, here pickMe(BigInteger)
> >>     is more
> >>     specific than pickMe(Object) and then infers T (T = BigInteger).
> >>
> >>     >
> >>     > I'm using 1.8.0-ea-b115, but I verified that it fails with all
> >>     1.8 jdks I
> >>     > have my box.  When I pass in -source 1.7 it does work. And when
> >>     I do an
> >>     > explicit cast to Object (of course).
> >>
> >>     so this is the correct behavior for 8, the new stream API heavily
> >>     relies
> >>     on that,
> >>     and yes, this new semantics is not compatible with 1.7 in the case
> the
> >>     inference was failing,
> >>     this is a known compatibility issue.
> >>
> >>     >
> >>     > -- Jonathan Ross
> >>     >
> >>
> >>     cheers,
> >>     R?mi
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Paul
> >>
> >
> >
>
>
> --
> Cheers,
> Paul
>
>
> ________________________________
>
> The information in this e-mail is intended only for the person or entity
> to which it is addressed.
>
> It may contain confidential and /or privileged material. If someone other
> than the intended recipient should receive this e-mail, he / she shall not
> be entitled to read, disseminate, disclose or duplicate it.
>
> If you receive this e-mail unintentionally, please inform us immediately
> by "reply" and then delete it from your system. Although this information
> has been compiled with great care, neither IMC Financial Markets & Asset
> Management nor any of its related entities shall accept any responsibility
> for any errors, omissions or other inaccuracies in this information or for
> the consequences thereof, nor shall it be bound in any way by the contents
> of this e-mail or its attachments. In the event of incomplete or incorrect
> transmission, please return the e-mail to the sender and permanently delete
> this message and any attachments.
>
> Messages and attachments are scanned for all known viruses. Always scan
> attachments before opening them.
>

From vicente.romero at oracle.com  Tue Nov 19 09:16:01 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 19 Nov 2013 17:16:01 +0000
Subject: Overload resolution regression
In-Reply-To: <CABY=8csvjf_k3og1C-yC9Z=MRYEpvo2fiYrbmYLVu2r31Uk_zw@mail.gmail.com>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>	<528B4BD3.2070906@univ-mlv.fr>	<CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>	<528B7804.5000404@univ-mlv.fr>	<CABLGb9zDjGa=RPAjajwou+wZu3+K6BxCqMFxO8NrmpzfBp=+HQ@mail.gmail.com>
	<CABY=8csvjf_k3og1C-yC9Z=MRYEpvo2fiYrbmYLVu2r31Uk_zw@mail.gmail.com>
Message-ID: <528B9CD1.7090009@oracle.com>

On 19/11/13 16:43, Jonathan Ross wrote:
> Or a pickMe(String) for that matter?
>
> Thanks for the explanation, Remi.  Indeed, we were just using the
> coincidence of the Object fallback; it seems to predominantly affect our
> test fixtures - I hope, at least.  The nasty thing about it is that it
> leads to a runtime exception rather than a compilation error, so we may not
> find out for certain for a while.

Hi Jonathan,

There is an undocumented, unsupported, test only, etc, compiler option 
that can be helpful to analyze what method resolution is doing:

-XDverboseResolution=success,failure,applicable

it's verbose, very verbose, but it can give you a "static" method 
resolution analysis,

for example for the code you reported:

javac -XDverboseResolution=success,failure,applicable 
OverloadingRegression.java

OverloadingRegression.java:10: Note: resolving method pickMe in type 
OverloadingRegression to candidate 1
          pickMe(unsafeCast(new String()));
          ^
   phase: BASIC
   with actuals: BigInteger
   with type-args: no arguments
   candidates:
       #0 applicable method found: pickMe(Object)
       #1 applicable method found: pickMe(BigInteger)    <---- this one 
is selected
OverloadingRegression.java:10: Note: resolving method <init> in type 
String to candidate 0
          pickMe(unsafeCast(new String()));
                            ^
   phase: BASIC
   with actuals: no arguments
   with type-args: no arguments
   candidates:
       #0 applicable method found: String()   <-- only option
OverloadingRegression.java:10: Note: resolving method unsafeCast in type 
OverloadingRegression to candidate 0
          pickMe(unsafeCast(new String()));
                 ^
   phase: BASIC
   with actuals: String
   with type-args: no arguments
   candidates:
       #0 applicable method found: <T>unsafeCast(Object) <--- only option
         (partially instantiated to: (Object)Object)
   where T is a type-variable:
     T extends Object declared in method <T>unsafeCast(Object)
Note: OverloadingRegression.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details

HTH,
Vicente

>
>
> On Tue, Nov 19, 2013 at 9:02 AM, Paul Benedict <pbenedict at apache.org> wrote:
>
>> Ah, okay, that makes sense now. Filling me in on the background was a big
>> helper.
>>
>> For the sake of clarity, what would happen to Jonathan's example if there
>> was also a third pickMe(BigDecimal)?
>>
>>
>> On Tue, Nov 19, 2013 at 8:39 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>> On 11/19/2013 02:53 PM, Paul Benedict wrote:
>>>
>>>> I don't see how you can call the compiler "smarter" in this example.
>>>>
>>> 'smarter' because this is not the only use case :)
>>> Here is an example that fails to compile with 7 but compiles with 8
>>> (comparingByValue is also a method that only uses type variables to
>>> specify the return type)
>>>    Map<String,String> map = ...
>>>    map.entrySet().stream().sorted(Map.Entry.comparingByValue());
>>>
>>> For pickMe(unsafe()) the inference fails in 7 and uses Object as a
>>> fallback,
>>> it appears that it's what the user want but that's just a coincidence.
>>>
>>>   It is choosing pickMe(BigInteger) without >: BigInteger type being
>>>> present.
>>>>
>>>
>>> Don't forget that pickMe(null) also choose pickMe(BigInteger),
>>> it's the way the algorithm that choose the most specific method works
>>> since the beginning.
>>> here, the constraint is that T is a subtype of Object, so both
>>> pickMe(Object) and pickMe(BigInteger) are applicable,
>>> then the most specific algorithm chooses that pickMe(BigInteger) is
>> better
>>> than pickMe(Object).
>>>
>>> cheers,
>>> R?mi
>>>
>>>
>>>> On Tue, Nov 19, 2013 at 5:30 AM, Remi Forax <forax at univ-mlv.fr <mailto:
>>>> forax at univ-mlv.fr>> wrote:
>>>>
>>>>      On 11/19/2013 01:43 AM, Jonathan Ross wrote:
>>>>      > Hi,
>>>>
>>>>      Hi Johnathan,
>>>>
>>>>      >
>>>>      > I recently started porting a 150k-line project to jdk 8 to try
>>>>      my hand at
>>>>      > the recent changes in the collection libraries. (Hadn't done
>>>>      this since
>>>>      > last year, my apologies!)
>>>>      >
>>>>      > I have run in to a large number of compilation errors:
>>>>      regressions in type
>>>>      > inference and overload resolution. A lot of these are in unit
>>>>      tests using
>>>>      > mockito and fest and other similar monadic apis that rely heavily
>> on
>>>>      > overload resolution.
>>>>
>>>>      It's not a regression, it's an enhancement :)
>>>>
>>>>      >
>>>>      > The code snippet below is a distilled version of my typical
>>>>      compilation
>>>>      > error: our test code relying on the compiler choosing the Object
>>>>      overload
>>>>      > by default.
>>>>      >
>>>>      >
>>>>      > import java.math.BigInteger;
>>>>      >
>>>>      > public class OverloadingRegression {
>>>>      >
>>>>      >      static <T> T unsafeCast(Object anObject) {
>>>>      >          return (T) anObject;
>>>>      >      }
>>>>      >
>>>>      >      public void showOverloadResolutionIssue() {
>>>>      >          pickMe(unsafeCast(new String()));
>>>>      >      }
>>>>      >
>>>>      >      private void pickMe(BigInteger o) { /* ClassCastException in
>>>>      > 1.8.0-ea-b115 */ }
>>>>      >
>>>>      >      private void pickMe(Object o) { /* fine, picked in 1.6 &
>>>>      1.7 */ }
>>>>      > }
>>>>      >
>>>>      >
>>>>      > Obviously the unsafeCast is not going to win any beauty prizes,
>> but
>>>>      > sometimes you just have to do this sort of thing.  My main point
>>>>      is: it
>>>>      > used to work in java 7, it doesn't any more.
>>>>      >
>>>>      > Is this a known issue (or is it even expected behaviour)?
>>>>
>>>>      Yes, it's the expected behavior, when you try do inference inside a
>>>>      method call,
>>>>      here unsafeCast is inside pickMe, in that case with jdk6 & 7, the
>>>>      inference
>>>>      is not done and T is replaceb by its bound (Object), with jdk8, the
>>>>      compiler is smarter,
>>>>      and find the most specific method first, here pickMe(BigInteger)
>>>>      is more
>>>>      specific than pickMe(Object) and then infers T (T = BigInteger).
>>>>
>>>>      >
>>>>      > I'm using 1.8.0-ea-b115, but I verified that it fails with all
>>>>      1.8 jdks I
>>>>      > have my box.  When I pass in -source 1.7 it does work. And when
>>>>      I do an
>>>>      > explicit cast to Object (of course).
>>>>
>>>>      so this is the correct behavior for 8, the new stream API heavily
>>>>      relies
>>>>      on that,
>>>>      and yes, this new semantics is not compatible with 1.7 in the case
>> the
>>>>      inference was failing,
>>>>      this is a known compatibility issue.
>>>>
>>>>      >
>>>>      > -- Jonathan Ross
>>>>      >
>>>>
>>>>      cheers,
>>>>      R?mi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>>
>>>
>>
>> --
>> Cheers,
>> Paul
>>
>>
>> ________________________________
>>
>> The information in this e-mail is intended only for the person or entity
>> to which it is addressed.
>>
>> It may contain confidential and /or privileged material. If someone other
>> than the intended recipient should receive this e-mail, he / she shall not
>> be entitled to read, disseminate, disclose or duplicate it.
>>
>> If you receive this e-mail unintentionally, please inform us immediately
>> by "reply" and then delete it from your system. Although this information
>> has been compiled with great care, neither IMC Financial Markets & Asset
>> Management nor any of its related entities shall accept any responsibility
>> for any errors, omissions or other inaccuracies in this information or for
>> the consequences thereof, nor shall it be bound in any way by the contents
>> of this e-mail or its attachments. In the event of incomplete or incorrect
>> transmission, please return the e-mail to the sender and permanently delete
>> this message and any attachments.
>>
>> Messages and attachments are scanned for all known viruses. Always scan
>> attachments before opening them.
>>


From zhong.j.yu at gmail.com  Tue Nov 19 09:19:50 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 19 Nov 2013 11:19:50 -0600
Subject: Overload resolution regression
In-Reply-To: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
Message-ID: <CACuKZqFFq5x+axKm+mebB0Wswpuw0ZbX4Z1kqxH6RkJi5KDmBA@mail.gmail.com>

Previously, the type of an argument is independent of the choice of
method. That justifies the "most specific method" mechanism - we have
this fixed argument that can be fed to two methods, and we choose the
method with a narrower signature for *that argument*.

In Java 8 that's no longer true. The argument can be a "poly
expression", the meaning of which depends on the choice of method. So
we are talking about different methods *and* different arguments.
There is no apparent justification why method signature alone is *the*
criteria for choosing among several possible *invocations*.

Zhong Yu


On Mon, Nov 18, 2013 at 6:43 PM, Jonathan Ross
<jonathan.ross at imc-chicago.com> wrote:
> Hi,
>
> I recently started porting a 150k-line project to jdk 8 to try my hand at
> the recent changes in the collection libraries. (Hadn't done this since
> last year, my apologies!)
>
> I have run in to a large number of compilation errors: regressions in type
> inference and overload resolution. A lot of these are in unit tests using
> mockito and fest and other similar monadic apis that rely heavily on
> overload resolution.
>
> The code snippet below is a distilled version of my typical compilation
> error: our test code relying on the compiler choosing the Object overload
> by default.
>
>
> import java.math.BigInteger;
>
> public class OverloadingRegression {
>
>     static <T> T unsafeCast(Object anObject) {
>         return (T) anObject;
>     }
>
>     public void showOverloadResolutionIssue() {
>         pickMe(unsafeCast(new String()));
>     }
>
>     private void pickMe(BigInteger o) { /* ClassCastException in
> 1.8.0-ea-b115 */ }
>
>     private void pickMe(Object o) { /* fine, picked in 1.6 & 1.7 */ }
> }
>
>
> Obviously the unsafeCast is not going to win any beauty prizes, but
> sometimes you just have to do this sort of thing.  My main point is: it
> used to work in java 7, it doesn't any more.
>
> Is this a known issue (or is it even expected behaviour)?
>
> I'm using 1.8.0-ea-b115, but I verified that it fails with all 1.8 jdks I
> have my box.  When I pass in -source 1.7 it does work. And when I do an
> explicit cast to Object (of course).
>
> -- Jonathan Ross
>

From henry.jen at oracle.com  Tue Nov 19 10:01:45 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 19 Nov 2013 10:01:45 -0800
Subject: Overload resolution regression
In-Reply-To: <CABY=8csvjf_k3og1C-yC9Z=MRYEpvo2fiYrbmYLVu2r31Uk_zw@mail.gmail.com>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>	<528B4BD3.2070906@univ-mlv.fr>	<CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>	<528B7804.5000404@univ-mlv.fr>	<CABLGb9zDjGa=RPAjajwou+wZu3+K6BxCqMFxO8NrmpzfBp=+HQ@mail.gmail.com>
	<CABY=8csvjf_k3og1C-yC9Z=MRYEpvo2fiYrbmYLVu2r31Uk_zw@mail.gmail.com>
Message-ID: <528BA789.9040406@oracle.com>



On 11/19/2013 08:43 AM, Jonathan Ross wrote:
> Or a pickMe(String) for that matter?
>

You will get a compiler error on reference is ambiguous. This is why we 
end up with Comparator.comparingXXX APIs.

Cheers,
Henry

> Thanks for the explanation, Remi.  Indeed, we were just using the
> coincidence of the Object fallback; it seems to predominantly affect our
> test fixtures - I hope, at least.  The nasty thing about it is that it
> leads to a runtime exception rather than a compilation error, so we may not
> find out for certain for a while.
>
>
> On Tue, Nov 19, 2013 at 9:02 AM, Paul Benedict <pbenedict at apache.org> wrote:
>
>> Ah, okay, that makes sense now. Filling me in on the background was a big
>> helper.
>>
>> For the sake of clarity, what would happen to Jonathan's example if there
>> was also a third pickMe(BigDecimal)?
>>
>>
>> On Tue, Nov 19, 2013 at 8:39 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>> On 11/19/2013 02:53 PM, Paul Benedict wrote:
>>>
>>>> I don't see how you can call the compiler "smarter" in this example.
>>>>
>>>
>>> 'smarter' because this is not the only use case :)
>>> Here is an example that fails to compile with 7 but compiles with 8
>>> (comparingByValue is also a method that only uses type variables to
>>> specify the return type)
>>>    Map<String,String> map = ...
>>>    map.entrySet().stream().sorted(Map.Entry.comparingByValue());
>>>
>>> For pickMe(unsafe()) the inference fails in 7 and uses Object as a
>>> fallback,
>>> it appears that it's what the user want but that's just a coincidence.
>>>
>>>   It is choosing pickMe(BigInteger) without >: BigInteger type being
>>>> present.
>>>>
>>>
>>>
>>> Don't forget that pickMe(null) also choose pickMe(BigInteger),
>>> it's the way the algorithm that choose the most specific method works
>>> since the beginning.
>>> here, the constraint is that T is a subtype of Object, so both
>>> pickMe(Object) and pickMe(BigInteger) are applicable,
>>> then the most specific algorithm chooses that pickMe(BigInteger) is
>> better
>>> than pickMe(Object).
>>>
>>> cheers,
>>> R?mi
>>>
>>>
>>>>
>>>> On Tue, Nov 19, 2013 at 5:30 AM, Remi Forax <forax at univ-mlv.fr <mailto:
>>>> forax at univ-mlv.fr>> wrote:
>>>>
>>>>      On 11/19/2013 01:43 AM, Jonathan Ross wrote:
>>>>      > Hi,
>>>>
>>>>      Hi Johnathan,
>>>>
>>>>      >
>>>>      > I recently started porting a 150k-line project to jdk 8 to try
>>>>      my hand at
>>>>      > the recent changes in the collection libraries. (Hadn't done
>>>>      this since
>>>>      > last year, my apologies!)
>>>>      >
>>>>      > I have run in to a large number of compilation errors:
>>>>      regressions in type
>>>>      > inference and overload resolution. A lot of these are in unit
>>>>      tests using
>>>>      > mockito and fest and other similar monadic apis that rely heavily
>> on
>>>>      > overload resolution.
>>>>
>>>>      It's not a regression, it's an enhancement :)
>>>>
>>>>      >
>>>>      > The code snippet below is a distilled version of my typical
>>>>      compilation
>>>>      > error: our test code relying on the compiler choosing the Object
>>>>      overload
>>>>      > by default.
>>>>      >
>>>>      >
>>>>      > import java.math.BigInteger;
>>>>      >
>>>>      > public class OverloadingRegression {
>>>>      >
>>>>      >      static <T> T unsafeCast(Object anObject) {
>>>>      >          return (T) anObject;
>>>>      >      }
>>>>      >
>>>>      >      public void showOverloadResolutionIssue() {
>>>>      >          pickMe(unsafeCast(new String()));
>>>>      >      }
>>>>      >
>>>>      >      private void pickMe(BigInteger o) { /* ClassCastException in
>>>>      > 1.8.0-ea-b115 */ }
>>>>      >
>>>>      >      private void pickMe(Object o) { /* fine, picked in 1.6 &
>>>>      1.7 */ }
>>>>      > }
>>>>      >
>>>>      >
>>>>      > Obviously the unsafeCast is not going to win any beauty prizes,
>> but
>>>>      > sometimes you just have to do this sort of thing.  My main point
>>>>      is: it
>>>>      > used to work in java 7, it doesn't any more.
>>>>      >
>>>>      > Is this a known issue (or is it even expected behaviour)?
>>>>
>>>>      Yes, it's the expected behavior, when you try do inference inside a
>>>>      method call,
>>>>      here unsafeCast is inside pickMe, in that case with jdk6 & 7, the
>>>>      inference
>>>>      is not done and T is replaceb by its bound (Object), with jdk8, the
>>>>      compiler is smarter,
>>>>      and find the most specific method first, here pickMe(BigInteger)
>>>>      is more
>>>>      specific than pickMe(Object) and then infers T (T = BigInteger).
>>>>
>>>>      >
>>>>      > I'm using 1.8.0-ea-b115, but I verified that it fails with all
>>>>      1.8 jdks I
>>>>      > have my box.  When I pass in -source 1.7 it does work. And when
>>>>      I do an
>>>>      > explicit cast to Object (of course).
>>>>
>>>>      so this is the correct behavior for 8, the new stream API heavily
>>>>      relies
>>>>      on that,
>>>>      and yes, this new semantics is not compatible with 1.7 in the case
>> the
>>>>      inference was failing,
>>>>      this is a known compatibility issue.
>>>>
>>>>      >
>>>>      > -- Jonathan Ross
>>>>      >
>>>>
>>>>      cheers,
>>>>      R?mi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Paul
>>
>>
>> ________________________________
>>
>> The information in this e-mail is intended only for the person or entity
>> to which it is addressed.
>>
>> It may contain confidential and /or privileged material. If someone other
>> than the intended recipient should receive this e-mail, he / she shall not
>> be entitled to read, disseminate, disclose or duplicate it.
>>
>> If you receive this e-mail unintentionally, please inform us immediately
>> by "reply" and then delete it from your system. Although this information
>> has been compiled with great care, neither IMC Financial Markets & Asset
>> Management nor any of its related entities shall accept any responsibility
>> for any errors, omissions or other inaccuracies in this information or for
>> the consequences thereof, nor shall it be bound in any way by the contents
>> of this e-mail or its attachments. In the event of incomplete or incorrect
>> transmission, please return the e-mail to the sender and permanently delete
>> this message and any attachments.
>>
>> Messages and attachments are scanned for all known viruses. Always scan
>> attachments before opening them.
>>
>

From cushon at google.com  Tue Nov 19 10:16:24 2013
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 19 Nov 2013 10:16:24 -0800
Subject: question about enhanced type-inference
Message-ID: <CAL4QsgtpK=jYMLUrY8E4rQx-uJgYPeLwL__0XACBzxptt6_ScA@mail.gmail.com>

I have been experimenting with migrating some code to compile with javac
8's new graph inference algorithm. This has generally gone quite smoothly,
but I ran into the following case where inference succeeds with legacy
inference and fails with graph inference.

Is this a known limitation of the new inference algorithm?

Here's the code:

===

interface Task<E extends Exception> {}
class Comparator<T> {}
class CustomException extends Exception {}

class TaskQueue<E extends Exception, T extends Task<E>> {}

abstract class Test {
  abstract <E extends Exception, T extends Task<E>>
      TaskQueue<E, T> create(Comparator<? super T> comparator);

  void f(Comparator<Task<CustomException>> comp) {
    TaskQueue<CustomException, Task<CustomException>> queue = create(comp);
  }
}

===

From vicente.romero at oracle.com  Tue Nov 19 13:02:59 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 19 Nov 2013 21:02:59 +0000
Subject: javac rejects valid java 7 code
In-Reply-To: <528B6115.2040107@oracle.com>
References: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
	<528B6115.2040107@oracle.com>
Message-ID: <528BD203.8000508@oracle.com>

Hi Anna,

On 19/11/13 13:01, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Anna,
>
> I don't think that this is a bug. This is what javac is inferring for 
> your original example:
>
> var S
>     upper bounds = A2<S1>,java.lang.Object
>     lower bounds = A2<java.lang.Integer>,A2<java.lang.Long>
>     eq bounds = []
>
> var S1
>     upper bounds = java.lang.Object
>     lower bounds = []
>     eq bounds = java.lang.Long,java.lang.Integer
>
> all types of the form Type1, Type2 are intersection types and were 
> introduced to create more correct and strict inference restrictions. 

This is not correct, in this case (java.lang.Long, java.lang.Integer) or 
(A2<java.lang.Integer>, A2<java.lang.Long> ) are not intersection types, 
sorry for the mistake. In any case I consider that the compiler it's OK 
but I will try to locate what was the changeset that made the difference 
between 7 and 8 and I will continue investigating this issue,

Thanks,
Vicente.

> In java7 they would have been inferred as Object, and that's why the 
> example works in 7. So what javac8 is saying is that it can't find a 
> solution for these variables with the given restrictions. Note that if 
> in your example method bar is for example defined as:
>
> void bar(A2<Integer> y, A2<Integer> x) {...}
>
> then the example will compile in 8 as now it's possible to find a 
> solution. The inference in that case will look like:
>
> var S
>     upper bounds = A2<S1>,java.lang.Object
>     lower bounds = A2<java.lang.Integer>
>     eq bounds = []
> var S1
>     upper bounds = java.lang.Object
>     lower bounds = []
>     eq bounds = java.lang.Integer
>
> As you can see the introduction of intersection types to model bounds 
> makes the compiler both smarter and stricter.
>
> I will continue checking the rest of the examples.
>
> Thanks,
> Vicente.
>
>
> On 18/11/13 15:31, Anna Kozlova wrote:
>> Hi,
>>
>>
>> This code compiles with java 1.7 (also 1.6) but fails to compile with 
>> 1.8
>> (b. 115)
>>
>>
>> abstract class A2<T>{
>>
>>      abstract <S> S foo(S x, S y);
>>
>>      abstract <S1> void baz(A2<S1> a)
>>
>>
>>      void bar(A2<Integer> y, A2<Long> x){
>>
>>           baz(foo(x, y));
>>
>>      }
>>
>> }
>>
>>
>> java: method baz in class A2<T> cannot be applied to given types;
>>
>>    required: A2<S1>
>>
>>    found: A2<capture#1 of ? extends 
>> java.lang.Number&java.lang.Comparable<?
>> extends java.lang.Number&java.lang.Comparable<?>>>
>>
>>    reason: inferred type does not conform to equality constraint(s)
>>
>>      inferred: java.lang.Long
>>
>>      equality constraints(s): java.lang.Long,java.lang.Integer
>>
>>
>> Are these equality constraint really for S1? How does javac get them
>> independently from whom they belong?
>>
>>
>> Thanks,
>>
>> Anna
>>
>>
>


From anna.kozlova at jetbrains.com  Tue Nov 19 13:09:48 2013
From: anna.kozlova at jetbrains.com (Anna Kozlova)
Date: Tue, 19 Nov 2013 22:09:48 +0100
Subject: javac rejects valid java 7 code
In-Reply-To: <528BD203.8000508@oracle.com>
References: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
	<528B6115.2040107@oracle.com> <528BD203.8000508@oracle.com>
Message-ID: <014501cee56b$ae8adac0$0ba09040$@kozlova@jetbrains.com>

Vicente, 

Thank you. I'll watch the progress in the issue.

Anna 

-----Original Message-----
From: Vicente-Arturo Romero-Zaldivar [mailto:vicente.romero at oracle.com] 
Sent: Tuesday, November 19, 2013 10:03 PM
To: Anna Kozlova; lambda-dev at openjdk.java.net
Subject: Re: javac rejects valid java 7 code

Hi Anna,

On 19/11/13 13:01, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Anna,
>
> I don't think that this is a bug. This is what javac is inferring for 
> your original example:
>
> var S
>     upper bounds = A2<S1>,java.lang.Object
>     lower bounds = A2<java.lang.Integer>,A2<java.lang.Long>
>     eq bounds = []
>
> var S1
>     upper bounds = java.lang.Object
>     lower bounds = []
>     eq bounds = java.lang.Long,java.lang.Integer
>
> all types of the form Type1, Type2 are intersection types and were 
> introduced to create more correct and strict inference restrictions.

This is not correct, in this case (java.lang.Long, java.lang.Integer) or
(A2<java.lang.Integer>, A2<java.lang.Long> ) are not intersection types,
sorry for the mistake. In any case I consider that the compiler it's OK but
I will try to locate what was the changeset that made the difference between
7 and 8 and I will continue investigating this issue,

Thanks,
Vicente.

> In java7 they would have been inferred as Object, and that's why the 
> example works in 7. So what javac8 is saying is that it can't find a 
> solution for these variables with the given restrictions. Note that if 
> in your example method bar is for example defined as:
>
> void bar(A2<Integer> y, A2<Integer> x) {...}
>
> then the example will compile in 8 as now it's possible to find a 
> solution. The inference in that case will look like:
>
> var S
>     upper bounds = A2<S1>,java.lang.Object
>     lower bounds = A2<java.lang.Integer>
>     eq bounds = []
> var S1
>     upper bounds = java.lang.Object
>     lower bounds = []
>     eq bounds = java.lang.Integer
>
> As you can see the introduction of intersection types to model bounds 
> makes the compiler both smarter and stricter.
>
> I will continue checking the rest of the examples.
>
> Thanks,
> Vicente.
>
>
> On 18/11/13 15:31, Anna Kozlova wrote:
>> Hi,
>>
>>
>> This code compiles with java 1.7 (also 1.6) but fails to compile with
>> 1.8
>> (b. 115)
>>
>>
>> abstract class A2<T>{
>>
>>      abstract <S> S foo(S x, S y);
>>
>>      abstract <S1> void baz(A2<S1> a)
>>
>>
>>      void bar(A2<Integer> y, A2<Long> x){
>>
>>           baz(foo(x, y));
>>
>>      }
>>
>> }
>>
>>
>> java: method baz in class A2<T> cannot be applied to given types;
>>
>>    required: A2<S1>
>>
>>    found: A2<capture#1 of ? extends
>> java.lang.Number&java.lang.Comparable<?
>> extends java.lang.Number&java.lang.Comparable<?>>>
>>
>>    reason: inferred type does not conform to equality constraint(s)
>>
>>      inferred: java.lang.Long
>>
>>      equality constraints(s): java.lang.Long,java.lang.Integer
>>
>>
>> Are these equality constraint really for S1? How does javac get them 
>> independently from whom they belong?
>>
>>
>> Thanks,
>>
>> Anna
>>
>>
>


!DSPAM:35,528bd236117531380419189!



From zhong.j.yu at gmail.com  Tue Nov 19 15:19:34 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 19 Nov 2013 17:19:34 -0600
Subject: Write Stream<String> to a file?
Message-ID: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>

We have convenience methods to read lines from a file:
    Stream<String> Files.lines()

What's Java's idiomatic way to write a Stream<String> to a file?

Zhong Yu

From jonathan.ross at imc-chicago.com  Tue Nov 19 15:22:42 2013
From: jonathan.ross at imc-chicago.com (Jonathan Ross)
Date: Tue, 19 Nov 2013 17:22:42 -0600
Subject: Overload resolution regression
In-Reply-To: <528BA789.9040406@oracle.com>
References: <CABY=8cswRTcJfkrpw_PQ4pxXtzN5+czUpiYxBj8LJdF1dNGGMw@mail.gmail.com>
	<528B4BD3.2070906@univ-mlv.fr>
	<CABLGb9wGaMNDTyB5bqJuhLJCmA076Ywzk1wWFVh35ARvYXyCEg@mail.gmail.com>
	<528B7804.5000404@univ-mlv.fr>
	<CABLGb9zDjGa=RPAjajwou+wZu3+K6BxCqMFxO8NrmpzfBp=+HQ@mail.gmail.com>
	<CABY=8csvjf_k3og1C-yC9Z=MRYEpvo2fiYrbmYLVu2r31Uk_zw@mail.gmail.com>
	<528BA789.9040406@oracle.com>
Message-ID: <CABY=8cs+utRwTeFzhQ8Y9GQ-HaMTijjHsEAfdVQTxD-u+qdWWg@mail.gmail.com>

Ah yes, you're right. That's a relief, as the framework in question (fest
assertions) overloads pretty much every type in Assertions.assertThat(...).
It does mean that I have a lot of sloppy generics and coincidentally
working unit tests to rework.


On Tue, Nov 19, 2013 at 12:01 PM, Henry Jen <henry.jen at oracle.com> wrote:

>
>
> On 11/19/2013 08:43 AM, Jonathan Ross wrote:
> > Or a pickMe(String) for that matter?
> >
>
> You will get a compiler error on reference is ambiguous. This is why we
> end up with Comparator.comparingXXX APIs.
>
> Cheers,
> Henry
>
> > Thanks for the explanation, Remi.  Indeed, we were just using the
> > coincidence of the Object fallback; it seems to predominantly affect our
> > test fixtures - I hope, at least.  The nasty thing about it is that it
> > leads to a runtime exception rather than a compilation error, so we may
> not
> > find out for certain for a while.
> >
> >
> > On Tue, Nov 19, 2013 at 9:02 AM, Paul Benedict <pbenedict at apache.org>
> wrote:
> >
> >> Ah, okay, that makes sense now. Filling me in on the background was a
> big
> >> helper.
> >>
> >> For the sake of clarity, what would happen to Jonathan's example if
> there
> >> was also a third pickMe(BigDecimal)?
> >>
> >>
> >> On Tue, Nov 19, 2013 at 8:39 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> >>
> >>> On 11/19/2013 02:53 PM, Paul Benedict wrote:
> >>>
> >>>> I don't see how you can call the compiler "smarter" in this example.
> >>>>
> >>>
> >>> 'smarter' because this is not the only use case :)
> >>> Here is an example that fails to compile with 7 but compiles with 8
> >>> (comparingByValue is also a method that only uses type variables to
> >>> specify the return type)
> >>>    Map<String,String> map = ...
> >>>    map.entrySet().stream().sorted(Map.Entry.comparingByValue());
> >>>
> >>> For pickMe(unsafe()) the inference fails in 7 and uses Object as a
> >>> fallback,
> >>> it appears that it's what the user want but that's just a coincidence.
> >>>
> >>>   It is choosing pickMe(BigInteger) without >: BigInteger type being
> >>>> present.
> >>>>
> >>>
> >>>
> >>> Don't forget that pickMe(null) also choose pickMe(BigInteger),
> >>> it's the way the algorithm that choose the most specific method works
> >>> since the beginning.
> >>> here, the constraint is that T is a subtype of Object, so both
> >>> pickMe(Object) and pickMe(BigInteger) are applicable,
> >>> then the most specific algorithm chooses that pickMe(BigInteger) is
> >> better
> >>> than pickMe(Object).
> >>>
> >>> cheers,
> >>> R?mi
> >>>
> >>>
> >>>>
> >>>> On Tue, Nov 19, 2013 at 5:30 AM, Remi Forax <forax at univ-mlv.fr<mailto:
> >>>> forax at univ-mlv.fr>> wrote:
> >>>>
> >>>>      On 11/19/2013 01:43 AM, Jonathan Ross wrote:
> >>>>      > Hi,
> >>>>
> >>>>      Hi Johnathan,
> >>>>
> >>>>      >
> >>>>      > I recently started porting a 150k-line project to jdk 8 to try
> >>>>      my hand at
> >>>>      > the recent changes in the collection libraries. (Hadn't done
> >>>>      this since
> >>>>      > last year, my apologies!)
> >>>>      >
> >>>>      > I have run in to a large number of compilation errors:
> >>>>      regressions in type
> >>>>      > inference and overload resolution. A lot of these are in unit
> >>>>      tests using
> >>>>      > mockito and fest and other similar monadic apis that rely
> heavily
> >> on
> >>>>      > overload resolution.
> >>>>
> >>>>      It's not a regression, it's an enhancement :)
> >>>>
> >>>>      >
> >>>>      > The code snippet below is a distilled version of my typical
> >>>>      compilation
> >>>>      > error: our test code relying on the compiler choosing the
> Object
> >>>>      overload
> >>>>      > by default.
> >>>>      >
> >>>>      >
> >>>>      > import java.math.BigInteger;
> >>>>      >
> >>>>      > public class OverloadingRegression {
> >>>>      >
> >>>>      >      static <T> T unsafeCast(Object anObject) {
> >>>>      >          return (T) anObject;
> >>>>      >      }
> >>>>      >
> >>>>      >      public void showOverloadResolutionIssue() {
> >>>>      >          pickMe(unsafeCast(new String()));
> >>>>      >      }
> >>>>      >
> >>>>      >      private void pickMe(BigInteger o) { /* ClassCastException
> in
> >>>>      > 1.8.0-ea-b115 */ }
> >>>>      >
> >>>>      >      private void pickMe(Object o) { /* fine, picked in 1.6 &
> >>>>      1.7 */ }
> >>>>      > }
> >>>>      >
> >>>>      >
> >>>>      > Obviously the unsafeCast is not going to win any beauty prizes,
> >> but
> >>>>      > sometimes you just have to do this sort of thing.  My main
> point
> >>>>      is: it
> >>>>      > used to work in java 7, it doesn't any more.
> >>>>      >
> >>>>      > Is this a known issue (or is it even expected behaviour)?
> >>>>
> >>>>      Yes, it's the expected behavior, when you try do inference
> inside a
> >>>>      method call,
> >>>>      here unsafeCast is inside pickMe, in that case with jdk6 & 7, the
> >>>>      inference
> >>>>      is not done and T is replaceb by its bound (Object), with jdk8,
> the
> >>>>      compiler is smarter,
> >>>>      and find the most specific method first, here pickMe(BigInteger)
> >>>>      is more
> >>>>      specific than pickMe(Object) and then infers T (T = BigInteger).
> >>>>
> >>>>      >
> >>>>      > I'm using 1.8.0-ea-b115, but I verified that it fails with all
> >>>>      1.8 jdks I
> >>>>      > have my box.  When I pass in -source 1.7 it does work. And when
> >>>>      I do an
> >>>>      > explicit cast to Object (of course).
> >>>>
> >>>>      so this is the correct behavior for 8, the new stream API heavily
> >>>>      relies
> >>>>      on that,
> >>>>      and yes, this new semantics is not compatible with 1.7 in the
> case
> >> the
> >>>>      inference was failing,
> >>>>      this is a known compatibility issue.
> >>>>
> >>>>      >
> >>>>      > -- Jonathan Ross
> >>>>      >
> >>>>
> >>>>      cheers,
> >>>>      R?mi
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>> Paul
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers,
> >> Paul
> >>
> >>
> >> ________________________________
> >>
> >> The information in this e-mail is intended only for the person or entity
> >> to which it is addressed.
> >>
> >> It may contain confidential and /or privileged material. If someone
> other
> >> than the intended recipient should receive this e-mail, he / she shall
> not
> >> be entitled to read, disseminate, disclose or duplicate it.
> >>
> >> If you receive this e-mail unintentionally, please inform us immediately
> >> by "reply" and then delete it from your system. Although this
> information
> >> has been compiled with great care, neither IMC Financial Markets & Asset
> >> Management nor any of its related entities shall accept any
> responsibility
> >> for any errors, omissions or other inaccuracies in this information or
> for
> >> the consequences thereof, nor shall it be bound in any way by the
> contents
> >> of this e-mail or its attachments. In the event of incomplete or
> incorrect
> >> transmission, please return the e-mail to the sender and permanently
> delete
> >> this message and any attachments.
> >>
> >> Messages and attachments are scanned for all known viruses. Always scan
> >> attachments before opening them.
> >>
> >
>
>
> ________________________________
>
> The information in this e-mail is intended only for the person or entity
> to which it is addressed.
>
> It may contain confidential and /or privileged material. If someone other
> than the intended recipient should receive this e-mail, he / she shall not
> be entitled to read, disseminate, disclose or duplicate it.
>
> If you receive this e-mail unintentionally, please inform us immediately
> by "reply" and then delete it from your system. Although this information
> has been compiled with great care, neither IMC Financial Markets & Asset
> Management nor any of its related entities shall accept any responsibility
> for any errors, omissions or other inaccuracies in this information or for
> the consequences thereof, nor shall it be bound in any way by the contents
> of this e-mail or its attachments. In the event of incomplete or incorrect
> transmission, please return the e-mail to the sender and permanently delete
> this message and any attachments.
>
> Messages and attachments are scanned for all known viruses. Always scan
> attachments before opening them.
>

From spullara at gmail.com  Tue Nov 19 15:35:13 2013
From: spullara at gmail.com (Sam Pullara)
Date: Tue, 19 Nov 2013 15:35:13 -0800
Subject: Write Stream<String> to a file?
In-Reply-To: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
Message-ID: <BCC66003-0483-4EB2-BC6D-34CC1D9D999B@gmail.com>

Hmmm. Maybe something like:

    Charset cs = Charset.forName("UTF-8");
    Stream<String> oldfile = Files.lines(Paths.get(args[0]), cs);
    Files.write(Paths.get(args[1]), oldfile::iterator, cs);

Sam

On Nov 19, 2013, at 3:19 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> We have convenience methods to read lines from a file:
>    Stream<String> Files.lines()
> 
> What's Java's idiomatic way to write a Stream<String> to a file?
> 
> Zhong Yu
> 


From jonathan.ross at imc-chicago.com  Tue Nov 19 15:37:01 2013
From: jonathan.ross at imc-chicago.com (Jonathan Ross)
Date: Tue, 19 Nov 2013 17:37:01 -0600
Subject: Guava type inference problems
Message-ID: <CABY=8ctcfP-2KPY3JpdE-AmWtw5L5RkSyf8ViHPCA_9UtbczBg@mail.gmail.com>

Hello again,

my problem below is probably also due to a well understood change to the
type inference rules, and I am sorry if this has all been said and done
before, but I really want to understand what's going on here.

Paraphrasing some production 1.7 code using guava, I have essentially the
following:

import java.util.Collection;
import java.util.List;

abstract class TypeTest {

    interface I {}

    public Collection<? extends I> excludeFrom(Collection<? extends I>
include,
            Collection<? extends I> exclude) {
        return copyOf(filter(include, not(in(exclude))));
    }

    interface Predicate<T> {
        boolean apply(T t);
    }

    abstract <T> Predicate<T> in(Collection<? extends T> target);
    abstract <T> Predicate<T> not(Predicate<T> aPredicate);
    abstract <E> List<E> copyOf(Iterable<? extends E> elements);

    abstract <T> Iterable<T> filter(Iterable<T> unfiltered, Predicate<?
super T> predicate);
}


When I compile this with b115, the compiler bails out, with

TypeTest.java:9: error: no suitable method found for copyOf(Iterable<CAP#1>)

        return copyOf(filter(include, not(in(exclude))));

               ^

    method TypeTest.<E#1>copyOf(Iterable<? extends E#1>) is not applicable

      (cannot infer type-variable(s) E#1,T#1,T#2,T#3

        (argument mismatch; Iterable<CAP#2> cannot be converted to
Iterable<? extends CAP#2>))

    method TypeTest.<E#2>copyOf(Collection<? extends E#2>) is not applicable

      (no instance(s) of type variable(s) T#1,T#2,T#3 exist so that
Iterable<T#1> conforms to Collection<? extends E#2>)

  where E#1,T#1,T#2,T#3,E#2 are type-variables:

    E#1 extends Object declared in method <E#1>copyOf(Iterable<? extends
E#1>)

    T#1 extends Object declared in method
<T#1>filter(Iterable<T#1>,Predicate<? super T#1>)

    T#2 extends Object declared in method <T#2>not(Predicate<T#2>)

    T#3 extends Object declared in method <T#3>in(Collection<? extends T#3>)

    E#2 extends Object declared in method <E#2>copyOf(Collection<? extends
E#2>)

  where CAP#1,CAP#2 are fresh type-variables:

    CAP#1 extends I from capture of ? extends I

    CAP#2 extends I from capture of ? extends I

1 error

But if I replace excludeFrom with

    public Collection<? extends I> filter(Collection<? extends I> include,
            Collection<? extends I> exclude) {
        Iterable<? extends I> myFiltered = filter(include,
not(in(exclude)));
        return copyOf(myFiltered);
    }

compilation succeeds. What gives?

Thanks in advance,

Jonathan Ross

From brian.goetz at oracle.com  Tue Nov 19 16:47:36 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Nov 2013 19:47:36 -0500
Subject: Write Stream<String> to a file?
In-Reply-To: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
Message-ID: <528C06A8.7070202@oracle.com>

How about:

     stream.forEachOrdered(writer::write);

On 11/19/2013 6:19 PM, Zhong Yu wrote:
> We have convenience methods to read lines from a file:
>      Stream<String> Files.lines()
>
> What's Java's idiomatic way to write a Stream<String> to a file?
>
> Zhong Yu
>

From mike.duigou at oracle.com  Tue Nov 19 17:04:03 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 19 Nov 2013 17:04:03 -0800
Subject: Write Stream<String> to a file?
In-Reply-To: <BCC66003-0483-4EB2-BC6D-34CC1D9D999B@gmail.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
	<BCC66003-0483-4EB2-BC6D-34CC1D9D999B@gmail.com>
Message-ID: <F790BB74-5D0B-4AEC-939D-996130C160D9@oracle.com>


There are now constants for the standard charsets. 

StandardCharsets.UTF_8

Which can be statically imported for even more concise referencing.

Mike

On Nov 19 2013, at 15:35 , Sam Pullara <spullara at gmail.com> wrote:

> Hmmm. Maybe something like:
> 
>    Charset cs = Charset.forName("UTF-8");
>    Stream<String> oldfile = Files.lines(Paths.get(args[0]), cs);
>    Files.write(Paths.get(args[1]), oldfile::iterator, cs);
> 
> Sam
> 
> On Nov 19, 2013, at 3:19 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> 
>> We have convenience methods to read lines from a file:
>>   Stream<String> Files.lines()
>> 
>> What's Java's idiomatic way to write a Stream<String> to a file?
>> 
>> Zhong Yu
>> 
> 
> 


From zhong.j.yu at gmail.com  Tue Nov 19 18:24:32 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 19 Nov 2013 20:24:32 -0600
Subject: Write Stream<String> to a file?
In-Reply-To: <528C06A8.7070202@oracle.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
	<528C06A8.7070202@oracle.com>
Message-ID: <CACuKZqGyC+QK+YqaTdwzdq9WRTcnsowuAsrony9Ny-ZybmOKiQ@mail.gmail.com>

A problem with this is that most write() methods in java.io throw
checked IOException. PrintWriter does not throw checked exceptions -
it swallows them which is not good either.

On Tue, Nov 19, 2013 at 6:47 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> How about:
>
>     stream.forEachOrdered(writer::write);
>
>
> On 11/19/2013 6:19 PM, Zhong Yu wrote:
>>
>> We have convenience methods to read lines from a file:
>>      Stream<String> Files.lines()
>>
>> What's Java's idiomatic way to write a Stream<String> to a file?
>>
>> Zhong Yu
>>
>

From spullara at gmail.com  Tue Nov 19 19:27:22 2013
From: spullara at gmail.com (Sam Pullara)
Date: Tue, 19 Nov 2013 19:27:22 -0800
Subject: Write Stream<String> to a file?
In-Reply-To: <CACuKZqGyC+QK+YqaTdwzdq9WRTcnsowuAsrony9Ny-ZybmOKiQ@mail.gmail.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
	<528C06A8.7070202@oracle.com>
	<CACuKZqGyC+QK+YqaTdwzdq9WRTcnsowuAsrony9Ny-ZybmOKiQ@mail.gmail.com>
Message-ID: <024DC23F-08B0-4A8C-BE81-3F1F4316490E@gmail.com>

My solution seems the right way to go and is basically a mirror of that method. It should probably have an override that takes a stream rather than just an Iterable to make it more obvious. Here is the form with all the static imports:

    Stream<String> s = Files.lines(get(from), UTF_8);
    Files.write(get(to), s::iterator, UTF_8);


Sam

On Nov 19, 2013, at 6:24 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> A problem with this is that most write() methods in java.io throw
> checked IOException. PrintWriter does not throw checked exceptions -
> it swallows them which is not good either.
> 
> On Tue, Nov 19, 2013 at 6:47 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> How about:
>> 
>>    stream.forEachOrdered(writer::write);
>> 
>> 
>> On 11/19/2013 6:19 PM, Zhong Yu wrote:
>>> 
>>> We have convenience methods to read lines from a file:
>>>     Stream<String> Files.lines()
>>> 
>>> What's Java's idiomatic way to write a Stream<String> to a file?
>>> 
>>> Zhong Yu
>>> 
>> 
> 


From cmotlin at gmail.com  Tue Nov 19 20:27:08 2013
From: cmotlin at gmail.com (Craig P. Motlin)
Date: Tue, 19 Nov 2013 23:27:08 -0500
Subject: Virtual Extension Method bug report
Message-ID: <CAJyUq7oH2V1GaLhRarnFeejw6-03qzo5xtMcSNdZxuPFTH+bdQ@mail.gmail.com>

I've been testing jdk-8-ea-bin-b115-windows-x64-07_nov_2013 and I ran into
a problem. My program compiles and I get an AbstractMethodError when I call
a virtual extension method using the SuperClass.super.method() syntax, when
the method body is defined higher up than SuperClass.

Exception in thread "main" java.lang.AbstractMethodError:
example.EmptyInterface.method()V
at example.ConcreteCallsSuper.method(ConcreteCallsSuper.java:9)
at example.ConcreteCallsSuper.main(ConcreteCallsSuper.java:14)

Here's the code. All three interfaces seem important.

public interface AbstractMethod
{
    void method();
}

public interface VirtualExtensionMethod extends AbstractMethod
{
    @Override
    default void method()
    {
        System.out.println("example.VirtualExtensionMethod.method");
    }
}

public interface EmptyInterface extends VirtualExtensionMethod
{
}

public class ConcreteCallsSuper implements EmptyInterface
{
    @Override
    public void method()
    {
        System.out.println("example.ConcreteCallsSuper.method");
        EmptyInterface.super.method();
    }

    public static void main(String[] args)
    {
        new ConcreteCallsSuper().method();
    }
}

From zhong.j.yu at gmail.com  Tue Nov 19 21:24:10 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 19 Nov 2013 23:24:10 -0600
Subject: Write Stream<String> to a file?
In-Reply-To: <024DC23F-08B0-4A8C-BE81-3F1F4316490E@gmail.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
	<528C06A8.7070202@oracle.com>
	<CACuKZqGyC+QK+YqaTdwzdq9WRTcnsowuAsrony9Ny-ZybmOKiQ@mail.gmail.com>
	<024DC23F-08B0-4A8C-BE81-3F1F4316490E@gmail.com>
Message-ID: <CACuKZqFLv9d=Cmpad5mELrSeXUWkwWNgwRMrH5oZ3ku0w2GTGw@mail.gmail.com>

Thanks, it works.

<pedantry>If a method accepts an Iterable, you never now how many
times it may invoke iterator(). So in theory passing a Stream to the
method isn't safe. </>

I was wishing for something like a Collector.

Zhong Yu


On Tue, Nov 19, 2013 at 9:27 PM, Sam Pullara <spullara at gmail.com> wrote:
> My solution seems the right way to go and is basically a mirror of that method. It should probably have an override that takes a stream rather than just an Iterable to make it more obvious. Here is the form with all the static imports:
>
>     Stream<String> s = Files.lines(get(from), UTF_8);
>     Files.write(get(to), s::iterator, UTF_8);
>
>
> Sam
>
> On Nov 19, 2013, at 6:24 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>
>> A problem with this is that most write() methods in java.io throw
>> checked IOException. PrintWriter does not throw checked exceptions -
>> it swallows them which is not good either.
>>
>> On Tue, Nov 19, 2013 at 6:47 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> How about:
>>>
>>>    stream.forEachOrdered(writer::write);
>>>
>>>
>>> On 11/19/2013 6:19 PM, Zhong Yu wrote:
>>>>
>>>> We have convenience methods to read lines from a file:
>>>>     Stream<String> Files.lines()
>>>>
>>>> What's Java's idiomatic way to write a Stream<String> to a file?
>>>>
>>>> Zhong Yu
>>>>
>>>
>>
>

From paul.sandoz at oracle.com  Wed Nov 20 02:32:30 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 20 Nov 2013 11:32:30 +0100
Subject: Virtual Extension Method bug report
In-Reply-To: <CAJyUq7oH2V1GaLhRarnFeejw6-03qzo5xtMcSNdZxuPFTH+bdQ@mail.gmail.com>
References: <CAJyUq7oH2V1GaLhRarnFeejw6-03qzo5xtMcSNdZxuPFTH+bdQ@mail.gmail.com>
Message-ID: <50393935-DBEB-45B9-A35D-A7658A97FACA@oracle.com>

Hi Craig,

Thanks. I can reproduce. This looks like a VM method invocation issue.

If you comment out abstract method on AbstractMethod it works.

In either case with the method commented out or not java creates the following for ConcreteCallsSuper:

Constant pool:
...
   #5 = InterfaceMethodref #10.#33        //  Test$EmptyInterface.method:()V
...
  public void method();
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #3                  // String example.ConcreteCallsSuper.method
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: aload_0       
         9: invokespecial #5                  // InterfaceMethod Test$EmptyInterface.method:()V
        12: return        

Which i believe is correct (and i think may have recently been fixed).

I tested with a later version of hotspot [*] yet to be integrated into the jdk8 and tl repos and it worked. So a fix should be on its way to a later jdk8 ea build, dunno which one though.

Paul.

[*] If you want to verify for yourself clone http://hg.openjdk.java.net/hsx/hotspot-rt and build

On Nov 20, 2013, at 5:27 AM, Craig P. Motlin <cmotlin at gmail.com> wrote:

> I've been testing jdk-8-ea-bin-b115-windows-x64-07_nov_2013 and I ran into
> a problem. My program compiles and I get an AbstractMethodError when I call
> a virtual extension method using the SuperClass.super.method() syntax, when
> the method body is defined higher up than SuperClass.
> 
> Exception in thread "main" java.lang.AbstractMethodError:
> example.EmptyInterface.method()V
> at example.ConcreteCallsSuper.method(ConcreteCallsSuper.java:9)
> at example.ConcreteCallsSuper.main(ConcreteCallsSuper.java:14)
> 
> Here's the code. All three interfaces seem important.
> 
> public interface AbstractMethod
> {
>    void method();
> }
> 
> public interface VirtualExtensionMethod extends AbstractMethod
> {
>    @Override
>    default void method()
>    {
>        System.out.println("example.VirtualExtensionMethod.method");
>    }
> }
> 
> public interface EmptyInterface extends VirtualExtensionMethod
> {
> }
> 
> public class ConcreteCallsSuper implements EmptyInterface
> {
>    @Override
>    public void method()
>    {
>        System.out.println("example.ConcreteCallsSuper.method");
>        EmptyInterface.super.method();
>    }
> 
>    public static void main(String[] args)
>    {
>        new ConcreteCallsSuper().method();
>    }
> }
> 


From paul.sandoz at oracle.com  Wed Nov 20 02:44:18 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 20 Nov 2013 11:44:18 +0100
Subject: Write Stream<String> to a file?
In-Reply-To: <024DC23F-08B0-4A8C-BE81-3F1F4316490E@gmail.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>
	<528C06A8.7070202@oracle.com>
	<CACuKZqGyC+QK+YqaTdwzdq9WRTcnsowuAsrony9Ny-ZybmOKiQ@mail.gmail.com>
	<024DC23F-08B0-4A8C-BE81-3F1F4316490E@gmail.com>
Message-ID: <5DD6D7BF-CEAF-4E25-866A-658D93E63480@oracle.com>


On Nov 20, 2013, at 4:27 AM, Sam Pullara <spullara at gmail.com> wrote:

> My solution seems the right way to go and is basically a mirror of that method. It should probably have an override that takes a stream rather than just an Iterable to make it more obvious. Here is the form with all the static imports:
> 
>    Stream<String> s = Files.lines(get(from), UTF_8);

>    Files.write(get(to), s::iterator, UTF_8);
> 

We recently added some more methods to avoid passing in the charset for UTF-8, so you can do this:

   Stream<String> s = Files.lines(get(from));
   Files.write(get(to), s::iterator);

Ideally we should have a Files.write accepting a Stream<? extends CharSequence> and use forEachOrdered:

    public static Path write(Path path, Stream<? extends CharSequence> lines,
                             Charset cs, OpenOption... options)
        throws IOException
    {
        // ensure lines is not null before opening file
        Objects.requireNonNull(lines);
        CharsetEncoder encoder = cs.newEncoder();
        OutputStream out = newOutputStream(path, options);
        try (BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(out, encoder))) {
            lines.forEachOrdered(line -> {
                writer.append(line);
                writer.newLine();  // @@@ need to manage the annoying checked exception issue
            });
        }
        return path;
    }

Then we can do a particularly inefficient file copy :-)

  Files.write(get(to), Files.lines(get(from)));

For parallel streams forEachOrdered will ensure there is no concurrent execution of the Consumer but that execution may still occur on different threads to that of the calling thread, which in this context i presume is OK. There is also the potential for OOME if the writing is slower than the reading + stream ops, since forEachOrdered will buffer elements that are ahead of elements yet to be reported.

Paul.

From brian.goetz at oracle.com  Wed Nov 20 05:50:13 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Nov 2013 08:50:13 -0500
Subject: Write Stream<String> to a file?
In-Reply-To: <CACuKZqFLv9d=Cmpad5mELrSeXUWkwWNgwRMrH5oZ3ku0w2GTGw@mail.gmail.com>
References: <CACuKZqFf8nEeC9sV+yCteQC2USsGuophUdKaHZBj8AwhJt_SfQ@mail.gmail.com>	<528C06A8.7070202@oracle.com>	<CACuKZqGyC+QK+YqaTdwzdq9WRTcnsowuAsrony9Ny-ZybmOKiQ@mail.gmail.com>	<024DC23F-08B0-4A8C-BE81-3F1F4316490E@gmail.com>
	<CACuKZqFLv9d=Cmpad5mELrSeXUWkwWNgwRMrH5oZ3ku0w2GTGw@mail.gmail.com>
Message-ID: <528CBE15.4020304@oracle.com>

That's why Stream does not implement Iterable.


On 11/20/2013 12:24 AM, Zhong Yu wrote:
> Thanks, it works.
>
> <pedantry>If a method accepts an Iterable, you never now how many
> times it may invoke iterator(). So in theory passing a Stream to the
> method isn't safe. </>
>
> I was wishing for something like a Collector.
>
> Zhong Yu
>
>
> On Tue, Nov 19, 2013 at 9:27 PM, Sam Pullara <spullara at gmail.com> wrote:
>> My solution seems the right way to go and is basically a mirror of that method. It should probably have an override that takes a stream rather than just an Iterable to make it more obvious. Here is the form with all the static imports:
>>
>>      Stream<String> s = Files.lines(get(from), UTF_8);
>>      Files.write(get(to), s::iterator, UTF_8);
>>
>>
>> Sam
>>
>> On Nov 19, 2013, at 6:24 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>>> A problem with this is that most write() methods in java.io throw
>>> checked IOException. PrintWriter does not throw checked exceptions -
>>> it swallows them which is not good either.
>>>
>>> On Tue, Nov 19, 2013 at 6:47 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>> How about:
>>>>
>>>>     stream.forEachOrdered(writer::write);
>>>>
>>>>
>>>> On 11/19/2013 6:19 PM, Zhong Yu wrote:
>>>>>
>>>>> We have convenience methods to read lines from a file:
>>>>>      Stream<String> Files.lines()
>>>>>
>>>>> What's Java's idiomatic way to write a Stream<String> to a file?
>>>>>
>>>>> Zhong Yu
>>>>>
>>>>
>>>
>>

From blackdrag at gmx.org  Thu Nov 21 00:48:41 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 21 Nov 2013 09:48:41 +0100
Subject: List of all default methods
Message-ID: <528DC8E9.20807@gmx.org>

Hi all,

we already found we have some trouble with List#sort(Comparable) in 
Groovy, but to be able to identify further problems it would be very 
helpful to have a list of all default methods, that have been added. Is 
there one somewhere?

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From forax at univ-mlv.fr  Thu Nov 21 03:59:52 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 21 Nov 2013 12:59:52 +0100
Subject: List of all default methods
In-Reply-To: <528DC8E9.20807@gmx.org>
References: <528DC8E9.20807@gmx.org>
Message-ID: <528DF5B8.9010301@univ-mlv.fr>

On 11/21/2013 09:48 AM, Jochen Theodorou wrote:
> Hi all,
>
> we already found we have some trouble with List#sort(Comparable) in
> Groovy, but to be able to identify further problems it would be very
> helpful to have a list of all default methods, that have been added. Is
> there one somewhere?
>
> bye Jochen
>

Not a beautiful code, it takes rt.jar as argument and do the job :)

public class AllDefaultMethods {
   private static Class<?> loadClassFromFileName(String name) {
     String className = name.substring(0, name.length() - 
".class".length());
     try {
       return Class.forName(className.replace('/', '.'));
     } catch (Throwable t) {
       // skip unknown class, or LinkageError
       return null;
     }
   }

   public static void main(String[] args) throws IOException {
     try(JarFile jarFile = new JarFile(args[0])) {
       jarFile.stream()
              .map(JarEntry::getName)
              .filter(name -> name.endsWith(".class"))
              .map(AllDefaultMethods::loadClassFromFileName)
              .filter(Objects::nonNull)
              .flatMap(type -> Arrays.stream(type.getDeclaredMethods()))
              .filter(Method::isDefault)
              .forEach(System.out::println);
     }
   }
}

cheers,
R?mi


From blackdrag at gmx.org  Thu Nov 21 04:49:50 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 21 Nov 2013 13:49:50 +0100
Subject: List of all default methods
In-Reply-To: <528DF5B8.9010301@univ-mlv.fr>
References: <528DC8E9.20807@gmx.org> <528DF5B8.9010301@univ-mlv.fr>
Message-ID: <528E016E.8000801@gmx.org>

Am 21.11.2013 12:59, schrieb Remi Forax:
> On 11/21/2013 09:48 AM, Jochen Theodorou wrote:
>> Hi all,
>>
>> we already found we have some trouble with List#sort(Comparable) in
>> Groovy, but to be able to identify further problems it would be very
>> helpful to have a list of all default methods, that have been added. Is
>> there one somewhere?
>
> Not a beautiful code, it takes rt.jar as argument and do the job :)
[...]

thanks Remi ;)

from what I can see Groovy has only this one conflict of 
Iterable#sort(Comparable) from us with List#sort(Comparable) from jdk8. 
Is there any rationale behind adding a mutating sort method to List by 
default?

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From forax at univ-mlv.fr  Thu Nov 21 05:53:12 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 21 Nov 2013 14:53:12 +0100
Subject: List of all default methods
In-Reply-To: <528E016E.8000801@gmx.org>
References: <528DC8E9.20807@gmx.org> <528DF5B8.9010301@univ-mlv.fr>
	<528E016E.8000801@gmx.org>
Message-ID: <528E1048.2060302@univ-mlv.fr>

On 11/21/2013 01:49 PM, Jochen Theodorou wrote:
> Am 21.11.2013 12:59, schrieb Remi Forax:
>> On 11/21/2013 09:48 AM, Jochen Theodorou wrote:
>>> Hi all,
>>>
>>> we already found we have some trouble with List#sort(Comparable) in
>>> Groovy, but to be able to identify further problems it would be very
>>> helpful to have a list of all default methods, that have been added. Is
>>> there one somewhere?
>>
>> Not a beautiful code, it takes rt.jar as argument and do the job :)
> [...]
>
> thanks Remi ;)
>
> from what I can see Groovy has only this one conflict of 
> Iterable#sort(Comparable) from us with List#sort(Comparable) from 
> jdk8. Is there any rationale behind adding a mutating sort method to 
> List by default?

Collections.sort(list) doesn't have access to the underlying array of 
the ArrayList so sorting an ArrayList with Collections.sort() is done by 
dumping the ArrayList into an array, sorting it and then replacing the 
values inside the ArrayList by the one of the intermediary array.

With List.sort(), because a default method can be overridden, 
ArrayList.sort() can do the sort on the underlying array directly 
without using an intermediary array.

why it's a mutating sort:
All methods on collections that do mutations, do mutation on the current 
structure directly so from the API consistency point of view, 
List.sort() should be mutable. That's also one of the reason why there 
is a Stream API an not a method filter or map directly on Iterable.

>
> bye Jochen
>

regards,
R?mi


From vicente.romero at oracle.com  Thu Nov 21 05:58:28 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 21 Nov 2013 13:58:28 +0000
Subject: question about enhanced type-inference
In-Reply-To: <CAL4QsgtpK=jYMLUrY8E4rQx-uJgYPeLwL__0XACBzxptt6_ScA@mail.gmail.com>
References: <CAL4QsgtpK=jYMLUrY8E4rQx-uJgYPeLwL__0XACBzxptt6_ScA@mail.gmail.com>
Message-ID: <528E1184.3090004@oracle.com>

Hi Liam,

I have included your test case in this bug entry [1], as it has some 
similarities with a previously reported issue.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8028547

On 19/11/13 18:16, Liam Miller-Cushon wrote:
> I have been experimenting with migrating some code to compile with javac
> 8's new graph inference algorithm. This has generally gone quite smoothly,
> but I ran into the following case where inference succeeds with legacy
> inference and fails with graph inference.
>
> Is this a known limitation of the new inference algorithm?
>
> Here's the code:
>
> ===
>
> interface Task<E extends Exception> {}
> class Comparator<T> {}
> class CustomException extends Exception {}
>
> class TaskQueue<E extends Exception, T extends Task<E>> {}
>
> abstract class Test {
>    abstract <E extends Exception, T extends Task<E>>
>        TaskQueue<E, T> create(Comparator<? super T> comparator);
>
>    void f(Comparator<Task<CustomException>> comp) {
>      TaskQueue<CustomException, Task<CustomException>> queue = create(comp);
>    }
> }
>
> ===
>


From vicente.romero at oracle.com  Thu Nov 21 06:10:44 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 21 Nov 2013 14:10:44 +0000
Subject: Guava type inference problems
In-Reply-To: <CABY=8ctcfP-2KPY3JpdE-AmWtw5L5RkSyf8ViHPCA_9UtbczBg@mail.gmail.com>
References: <CABY=8ctcfP-2KPY3JpdE-AmWtw5L5RkSyf8ViHPCA_9UtbczBg@mail.gmail.com>
Message-ID: <528E1464.4060001@oracle.com>

Hi Jonathan,

Thanks for the bug report. I have filed bug entry [1] to track it.

Very nice report, it provides two examples with a minimum difference 
between them that uncover a possible bug.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8028774

On 19/11/13 23:37, Jonathan Ross wrote:
> Hello again,
>
> my problem below is probably also due to a well understood change to the
> type inference rules, and I am sorry if this has all been said and done
> before, but I really want to understand what's going on here.
>
> Paraphrasing some production 1.7 code using guava, I have essentially the
> following:
>
> import java.util.Collection;
> import java.util.List;
>
> abstract class TypeTest {
>
>      interface I {}
>
>      public Collection<? extends I> excludeFrom(Collection<? extends I>
> include,
>              Collection<? extends I> exclude) {
>          return copyOf(filter(include, not(in(exclude))));
>      }
>
>      interface Predicate<T> {
>          boolean apply(T t);
>      }
>
>      abstract <T> Predicate<T> in(Collection<? extends T> target);
>      abstract <T> Predicate<T> not(Predicate<T> aPredicate);
>      abstract <E> List<E> copyOf(Iterable<? extends E> elements);
>
>      abstract <T> Iterable<T> filter(Iterable<T> unfiltered, Predicate<?
> super T> predicate);
> }
>
>
> When I compile this with b115, the compiler bails out, with
>
> TypeTest.java:9: error: no suitable method found for copyOf(Iterable<CAP#1>)
>
>          return copyOf(filter(include, not(in(exclude))));
>
>                 ^
>
>      method TypeTest.<E#1>copyOf(Iterable<? extends E#1>) is not applicable
>
>        (cannot infer type-variable(s) E#1,T#1,T#2,T#3
>
>          (argument mismatch; Iterable<CAP#2> cannot be converted to
> Iterable<? extends CAP#2>))
>
>      method TypeTest.<E#2>copyOf(Collection<? extends E#2>) is not applicable
>
>        (no instance(s) of type variable(s) T#1,T#2,T#3 exist so that
> Iterable<T#1> conforms to Collection<? extends E#2>)
>
>    where E#1,T#1,T#2,T#3,E#2 are type-variables:
>
>      E#1 extends Object declared in method <E#1>copyOf(Iterable<? extends
> E#1>)
>
>      T#1 extends Object declared in method
> <T#1>filter(Iterable<T#1>,Predicate<? super T#1>)
>
>      T#2 extends Object declared in method <T#2>not(Predicate<T#2>)
>
>      T#3 extends Object declared in method <T#3>in(Collection<? extends T#3>)
>
>      E#2 extends Object declared in method <E#2>copyOf(Collection<? extends
> E#2>)
>
>    where CAP#1,CAP#2 are fresh type-variables:
>
>      CAP#1 extends I from capture of ? extends I
>
>      CAP#2 extends I from capture of ? extends I
>
> 1 error
>
> But if I replace excludeFrom with
>
>      public Collection<? extends I> filter(Collection<? extends I> include,
>              Collection<? extends I> exclude) {
>          Iterable<? extends I> myFiltered = filter(include,
> not(in(exclude)));
>          return copyOf(myFiltered);
>      }
>
> compilation succeeds. What gives?
>
> Thanks in advance,
>
> Jonathan Ross
>


From forax at univ-mlv.fr  Thu Nov 21 06:31:25 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 21 Nov 2013 15:31:25 +0100
Subject: Guava type inference problems
In-Reply-To: <CABY=8ctcfP-2KPY3JpdE-AmWtw5L5RkSyf8ViHPCA_9UtbczBg@mail.gmail.com>
References: <CABY=8ctcfP-2KPY3JpdE-AmWtw5L5RkSyf8ViHPCA_9UtbczBg@mail.gmail.com>
Message-ID: <528E193D.4050503@univ-mlv.fr>

On 11/20/2013 12:37 AM, Jonathan Ross wrote:
> Hello again,
>
> my problem below is probably also due to a well understood change to the
> type inference rules, and I am sorry if this has all been said and done
> before, but I really want to understand what's going on here.
>
> Paraphrasing some production 1.7 code using guava, I have essentially the
> following:
>
> import java.util.Collection;
> import java.util.List;
>
> abstract class TypeTest {
>
>      interface I {}
>
>      public Collection<? extends I> excludeFrom(Collection<? extends I>
> include,
>              Collection<? extends I> exclude) {
>          return copyOf(filter(include, not(in(exclude))));
>      }

My comment will not solve your problem but returning a Foo<? extends 
Bar> or a Foo<? super Bar>
is not a good idea because it forces the user code of excludeFrom to use 
wildcards too.

The wildcard mechanism was introduced to enable API writers to write 
method signature that accept to be called using subtypes/supertypes of 
parametrized types that are declared by formal parameters of the method. 
So there is no point to use wildcards in a return type.

Wildcards are tools for API writers and should not be used in code that 
use APIs.

cheers,
R?mi


From brian.goetz at oracle.com  Thu Nov 21 06:40:15 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 Nov 2013 09:40:15 -0500
Subject: List of all default methods
In-Reply-To: <528DC8E9.20807@gmx.org>
References: <528DC8E9.20807@gmx.org>
Message-ID: <528E1B4F.4030403@oracle.com>

Get the JCP Public Review draft of JSR-335; it has a specdiff against 
JDK 7.

On 11/21/2013 3:48 AM, Jochen Theodorou wrote:
> Hi all,
>
> we already found we have some trouble with List#sort(Comparable) in
> Groovy, but to be able to identify further problems it would be very
> helpful to have a list of all default methods, that have been added. Is
> there one somewhere?
>
> bye Jochen
>

From brian.goetz at oracle.com  Thu Nov 21 06:56:39 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 Nov 2013 09:56:39 -0500
Subject: List of all default methods
In-Reply-To: <528E016E.8000801@gmx.org>
References: <528DC8E9.20807@gmx.org> <528DF5B8.9010301@univ-mlv.fr>
	<528E016E.8000801@gmx.org>
Message-ID: <528E1F27.7090600@oracle.com>

> from what I can see Groovy has only this one conflict of
> Iterable#sort(Comparable) from us with List#sort(Comparable) from jdk8.
> Is there any rationale behind adding a mutating sort method to List by
> default?

Yes!  All the other methods on List (add, remove, retainAll) are 
in-place mutative.  The standard way to sort a List is 
Collections.sort(List), which is also in-place (and less efficient). 
The new method on List is simply Collections.sort(List), but in the 
right place, and can be optimized by implementations.

All the new methods which produce lazy / functional views are on Stream. 
  So you can do

   list.stream().sorted()

to produce a new sorted stream.  To avoid making things more confusing, 
we followed the guideline of adding in-place mutative methods to the 
concrete collections, and adding functional / lazy methods to Stream, 
rather than mixing.

BTW, adding stuff to Iterable is dangerous, as you've seen.  And you 
wouldn't even need default methods for that to happen; if we'd not done 
default methods at all, but added this sort method to ArrayList, you'd 
have the exact same conflict.

This worked as long as those JDK guys were asleep at the switch, and 
never updated the libraries.  But those days are over!

I think you've got a few choices here:
  - update your libraries
  - modify your compiler to resolve these sorts of conflicts.

For example, now that List has a conflict between

   void sort(Comparator)
and
   List sort(Comparator)

you could use target-typing in your method overload selection to pick 
one of these, rather than reporting a conflict.

As a general rule, adding stuff to Iterable is probably going to cause 
ongoing pain.  Use with care.


From brian.goetz at oracle.com  Thu Nov 21 07:01:02 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 Nov 2013 10:01:02 -0500
Subject: List of all default methods
In-Reply-To: <528DC8E9.20807@gmx.org>
References: <528DC8E9.20807@gmx.org>
Message-ID: <528E202E.4050203@oracle.com>

Note also that its not just default methods; any new method in a class 
that implements interface K is a candidate for conflicting with methods 
that Groovy has injected into K.

On 11/21/2013 3:48 AM, Jochen Theodorou wrote:
> Hi all,
>
> we already found we have some trouble with List#sort(Comparable) in
> Groovy, but to be able to identify further problems it would be very
> helpful to have a list of all default methods, that have been added. Is
> there one somewhere?
>
> bye Jochen
>

From blackdrag at gmx.org  Thu Nov 21 07:22:52 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 21 Nov 2013 16:22:52 +0100
Subject: List of all default methods
In-Reply-To: <528E1F27.7090600@oracle.com>
References: <528DC8E9.20807@gmx.org> <528DF5B8.9010301@univ-mlv.fr>
	<528E016E.8000801@gmx.org> <528E1F27.7090600@oracle.com>
Message-ID: <528E254C.80509@gmx.org>

Am 21.11.2013 15:56, schrieb Brian Goetz:
[...]
> Yes!  All the other methods on List (add, remove, retainAll) are
> in-place mutative.  The standard way to sort a List is
> Collections.sort(List), which is also in-place (and less efficient). The
> new method on List is simply Collections.sort(List), but in the right
> place, and can be optimized by implementations.
>
> All the new methods which produce lazy / functional views are on Stream.
>   So you can do
>
>    list.stream().sorted()
>
> to produce a new sorted stream.  To avoid making things more confusing,
> we followed the guideline of adding in-place mutative methods to the
> concrete collections, and adding functional / lazy methods to Stream,
> rather than mixing.

yes, only the problem is, that if we follow that rationale then we have 
to remove dozens of our additions plus, the non-mutating versions would 
not be available on a jvm before 8. Sadly we cannot strictly follow that

> BTW, adding stuff to Iterable is dangerous, as you've seen.  And you
> wouldn't even need default methods for that to happen; if we'd not done
> default methods at all, but added this sort method to ArrayList, you'd
> have the exact same conflict.

sure. That is always a danger. I don't say it is wrong to have it there, 
just wanted to know the background a bit more. On any interface there is 
a danger like that. Before the method was on List... that would have 
been an even worse conflict

> This worked as long as those JDK guys were asleep at the switch, and
> never updated the libraries.  But those days are over!
>
> I think you've got a few choices here:
>   - update your libraries
>   - modify your compiler to resolve these sorts of conflicts.
>
> For example, now that List has a conflict between
>
>    void sort(Comparator)
> and
>    List sort(Comparator)
>
> you could use target-typing in your method overload selection to pick
> one of these, rather than reporting a conflict.

you are forgetting that even though we also provide now a static 
compiler for a subset of Groovy, Groovy is basically a dynamic language. 
The chance, that there is no target type is high and runtime method 
selection does not even have that information.

> As a general rule, adding stuff to Iterable is probably going to cause
> ongoing pain.  Use with care.

Iterable, List, Collection, Map, CharSequence, Enumeration, Set, 
SortedSet, SortedMap, Iterable

That's about the interfaces we enhance.. Besides Enumeration all of them 
are dangerous I would assume.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From jonathan.ross at imc-chicago.com  Thu Nov 21 07:45:25 2013
From: jonathan.ross at imc-chicago.com (Jonathan Ross)
Date: Thu, 21 Nov 2013 09:45:25 -0600
Subject: Guava type inference problems
In-Reply-To: <528E193D.4050503@univ-mlv.fr>
References: <CABY=8ctcfP-2KPY3JpdE-AmWtw5L5RkSyf8ViHPCA_9UtbczBg@mail.gmail.com>
	<528E193D.4050503@univ-mlv.fr>
Message-ID: <CABY=8csYVB-rXBEdm5-GLSYeistHZLnZLeQY4=_N7JGkzOTciA@mail.gmail.com>

Good catch R?mi, thanks for pointing that one out.  In defence of the
original author, the case at hand was a private method - the wildcard in
the return type was a probably a refactoring accident ;-)

Thanks for adding the bug report, Vicente.


On Thu, Nov 21, 2013 at 8:31 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 11/20/2013 12:37 AM, Jonathan Ross wrote:
> > Hello again,
> >
> > my problem below is probably also due to a well understood change to the
> > type inference rules, and I am sorry if this has all been said and done
> > before, but I really want to understand what's going on here.
> >
> > Paraphrasing some production 1.7 code using guava, I have essentially the
> > following:
> >
> > import java.util.Collection;
> > import java.util.List;
> >
> > abstract class TypeTest {
> >
> >      interface I {}
> >
> >      public Collection<? extends I> excludeFrom(Collection<? extends I>
> > include,
> >              Collection<? extends I> exclude) {
> >          return copyOf(filter(include, not(in(exclude))));
> >      }
>
> My comment will not solve your problem but returning a Foo<? extends
> Bar> or a Foo<? super Bar>
> is not a good idea because it forces the user code of excludeFrom to use
> wildcards too.
>
> The wildcard mechanism was introduced to enable API writers to write
> method signature that accept to be called using subtypes/supertypes of
> parametrized types that are declared by formal parameters of the method.
> So there is no point to use wildcards in a return type.
>
> Wildcards are tools for API writers and should not be used in code that
> use APIs.
>
> cheers,
> R?mi
>
>
>
> ________________________________
>
> The information in this e-mail is intended only for the person or entity
> to which it is addressed.
>
> It may contain confidential and /or privileged material. If someone other
> than the intended recipient should receive this e-mail, he / she shall not
> be entitled to read, disseminate, disclose or duplicate it.
>
> If you receive this e-mail unintentionally, please inform us immediately
> by "reply" and then delete it from your system. Although this information
> has been compiled with great care, neither IMC Financial Markets & Asset
> Management nor any of its related entities shall accept any responsibility
> for any errors, omissions or other inaccuracies in this information or for
> the consequences thereof, nor shall it be bound in any way by the contents
> of this e-mail or its attachments. In the event of incomplete or incorrect
> transmission, please return the e-mail to the sender and permanently delete
> this message and any attachments.
>
> Messages and attachments are scanned for all known viruses. Always scan
> attachments before opening them.
>

From bitterfoxc at gmail.com  Thu Nov 21 08:49:21 2013
From: bitterfoxc at gmail.com (bitter_fox)
Date: Fri, 22 Nov 2013 01:49:21 +0900
Subject: Typo in Javadoc of Optional{Int, Double, Long}
Message-ID: <CAHjBcHMffBVYdZ9Tt44XnM8nRC93u52918cD8fF8XVa0PjDE6w@mail.gmail.com>

Hi,
I found a typo in Javadoc of Optional{Int, Double, Long}:

--------------------------------------------------------------
/**
 * {@code get()} will return the value.
 */
public final class OptionalInt {
...
    public int getAsInt() {
---------------------------------------------------------

" * {@code get()} will return the value."
would be
" * {@code getAsInt()} will return the value."

OptionalDouble and Long have a same typo.

diff -r 042a473535aa src/share/classes/java/util/OptionalDouble.java
--- a/src/share/classes/java/util/OptionalDouble.java   Thu Oct 17 19:47:47
2013 -0700
+++ b/src/share/classes/java/util/OptionalDouble.java   Fri Nov 22 01:44:55
2013 +0900
@@ -31,7 +31,7 @@
 /**
  * A container object which may or may not contain a {@code double} value.
  * If a value is present, {@code isPresent()} will return {@code true} and
- * {@code get()} will return the value.
+ * {@code getAsDouble()} will return the value.
  *
  * <p>Additional methods that depend on the presence or absence of a
contained
  * value are provided, such as {@link #orElse(double) orElse()}
diff -r 042a473535aa src/share/classes/java/util/OptionalInt.java
--- a/src/share/classes/java/util/OptionalInt.java      Thu Oct 17 19:47:47
2013 -0700
+++ b/src/share/classes/java/util/OptionalInt.java      Fri Nov 22 01:44:55
2013 +0900
@@ -31,7 +31,7 @@
 /**
  * A container object which may or may not contain a {@code int} value.
  * If a value is present, {@code isPresent()} will return {@code true} and
- * {@code get()} will return the value.
+ * {@code getAsInt()} will return the value.
  *
  * <p>Additional methods that depend on the presence or absence of a
contained
  * value are provided, such as {@link #orElse(int) orElse()}
diff -r 042a473535aa src/share/classes/java/util/OptionalLong.java
--- a/src/share/classes/java/util/OptionalLong.java     Thu Oct 17 19:47:47
2013 -0700
+++ b/src/share/classes/java/util/OptionalLong.java     Fri Nov 22 01:44:55
2013 +0900
@@ -31,7 +31,7 @@
 /**
  * A container object which may or may not contain a {@code long} value.
  * If a value is present, {@code isPresent()} will return {@code true} and
- * {@code get()} will return the value.
+ * {@code getAsLong()} will return the value.
  *
  * <p>Additional methods that depend on the presence or absence of a
contained
  * value are provided, such as {@link #orElse(long) orElse()}

Regards,
bitter_fox

From daniel.smith at oracle.com  Thu Nov 21 09:43:35 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 21 Nov 2013 10:43:35 -0700
Subject: javac rejects valid java 7 code
In-Reply-To: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
References: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
Message-ID: <57A1A263-6163-447F-9CBA-F14A401CF5A8@oracle.com>

On Nov 18, 2013, at 8:31 AM, Anna Kozlova <Anna.Kozlova at jetbrains.com> wrote:

> This code compiles with java 1.7 (also 1.6) but fails to compile with 1.8
> (b. 115)
> 
> 
> 
> abstract class A2<T>{
> 
>    abstract <S> S foo(S x, S y);
> 
>    abstract <S1> void baz(A2<S1> a)
> 
> 
> 
>    void bar(A2<Integer> y, A2<Long> x){
> 
>         baz(foo(x, y));
> 
>    }
> 
> }

Thanks for this example.  It illustrates a design flaw: inference in 8 supports capture on a nested method's return type (see Lambda Spec, Part G, 18.5.2), but only when the return type is a parameterized type.  As this example illustrates, it may also be necessary to perform capture when the return type is an inference variable (which can be instantiated to a parameterized type).

I've created a bug:
https://bugs.openjdk.java.net/browse/JDK-8028800

?Dan

From daniel.smith at oracle.com  Thu Nov 21 10:25:31 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 21 Nov 2013 11:25:31 -0700
Subject: 18.2.2 Type Compatibility Constraints 0.7.0 changes
In-Reply-To: <00ec01cee510$ed532650$c7f972f0$@kozlova@jetbrains.com>
References: <00ec01cee510$ed532650$c7f972f0$@kozlova@jetbrains.com>
Message-ID: <87A09006-4EAC-481B-B72F-B578D7B734BF@oracle.com>

On Nov 19, 2013, at 3:20 AM, Anna Kozlova <Anna.Kozlova at jetbrains.com> wrote:

> In 0.7.0 spec "if T is a parameterized type of the form G<T1, ..., Tn>, and
> there exists no type of the form G<S1, ..., Sn> that is a supertype of S,
> but the raw type G is a supertype of S, then the constraint reduces to true"
> was added. How does javac then infer raw substitution here?
> 
> 
> 
> class Test {
> 
>    interface Condition<K> {}
> 
>    class SpecialCondition<M> implements Condition {}
> 
>    static <T> List<T> filter(T[] c, Condition<? super T> con) {
>        return null;
>    }
> 
>    void foo(CharSequence[] es, SpecialCondition<CharSequence> con) {
>        List<String> l =  filter(es, con);
>    }
> 
> }

So we have

SpecialCondition<CharSequence> -> Condition<? super t>

And, per 18.2.2 (as quoted above), this reduces to true.

18.5.1 concludes that the method is applicable, with bound set { t <: Object, CharSequence <: t }.

For invocation typing, we have this clause in 15.12.2.6:

"Otherwise, if unchecked conversion was necessary for the method to be applicable, then the invocation type is the erasure (4.6) of the method's type."

Was unchecked conversion necessary to demonstrate the method's applicability?  Yes.  (This could be more clear; hence the "to do" item in 18.5.2.)

So, per 15.12.2.6, the method returns List, and the assignment allows an unchecked conversion to List<String>.

?Dan

From cushon at google.com  Thu Nov 21 10:49:41 2013
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 21 Nov 2013 10:49:41 -0800
Subject: question about enhanced type-inference
In-Reply-To: <528E1184.3090004@oracle.com>
References: <CAL4QsgtpK=jYMLUrY8E4rQx-uJgYPeLwL__0XACBzxptt6_ScA@mail.gmail.com>
	<528E1184.3090004@oracle.com>
Message-ID: <CAL4QsgvoNHVNxAy18O5PVNX+ZFF7OBbtQfEdJf30rHqrsGnkDA@mail.gmail.com>

Thanks Vicente,

I will follow the original issue.

Liam


On Thu, Nov 21, 2013 at 5:58 AM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

> Hi Liam,
>
> I have included your test case in this bug entry [1], as it has some
> similarities with a previously reported issue.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8028547
>
>
> On 19/11/13 18:16, Liam Miller-Cushon wrote:
>
>> I have been experimenting with migrating some code to compile with javac
>> 8's new graph inference algorithm. This has generally gone quite smoothly,
>> but I ran into the following case where inference succeeds with legacy
>> inference and fails with graph inference.
>>
>> Is this a known limitation of the new inference algorithm?
>>
>> Here's the code:
>>
>> ===
>>
>> interface Task<E extends Exception> {}
>> class Comparator<T> {}
>> class CustomException extends Exception {}
>>
>> class TaskQueue<E extends Exception, T extends Task<E>> {}
>>
>> abstract class Test {
>>    abstract <E extends Exception, T extends Task<E>>
>>        TaskQueue<E, T> create(Comparator<? super T> comparator);
>>
>>    void f(Comparator<Task<CustomException>> comp) {
>>      TaskQueue<CustomException, Task<CustomException>> queue =
>> create(comp);
>>    }
>> }
>>
>> ===
>>
>>
>

From daniel.smith at oracle.com  Thu Nov 21 11:23:11 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 21 Nov 2013 12:23:11 -0700
Subject: Guava type inference problems
In-Reply-To: <528E1464.4060001@oracle.com>
References: <CABY=8ctcfP-2KPY3JpdE-AmWtw5L5RkSyf8ViHPCA_9UtbczBg@mail.gmail.com>
	<528E1464.4060001@oracle.com>
Message-ID: <27D9C47F-AB08-414E-A85C-A20BF33A01AD@oracle.com>

Looks to me like this should succeed.  I'll include my "by hand" inference notes in the bug.

?Dan

On Nov 21, 2013, at 7:10 AM, Vicente-Arturo Romero-Zaldivar <vicente.romero at oracle.com> wrote:

> Hi Jonathan,
> 
> Thanks for the bug report. I have filed bug entry [1] to track it.
> 
> Very nice report, it provides two examples with a minimum difference 
> between them that uncover a possible bug.
> 
> Thanks,
> Vicente
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8028774
> 
> On 19/11/13 23:37, Jonathan Ross wrote:
>> Hello again,
>> 
>> my problem below is probably also due to a well understood change to the
>> type inference rules, and I am sorry if this has all been said and done
>> before, but I really want to understand what's going on here.
>> 
>> Paraphrasing some production 1.7 code using guava, I have essentially the
>> following:
>> 
>> import java.util.Collection;
>> import java.util.List;
>> 
>> abstract class TypeTest {
>> 
>>     interface I {}
>> 
>>     public Collection<? extends I> excludeFrom(Collection<? extends I>
>> include,
>>             Collection<? extends I> exclude) {
>>         return copyOf(filter(include, not(in(exclude))));
>>     }
>> 
>>     interface Predicate<T> {
>>         boolean apply(T t);
>>     }
>> 
>>     abstract <T> Predicate<T> in(Collection<? extends T> target);
>>     abstract <T> Predicate<T> not(Predicate<T> aPredicate);
>>     abstract <E> List<E> copyOf(Iterable<? extends E> elements);
>> 
>>     abstract <T> Iterable<T> filter(Iterable<T> unfiltered, Predicate<?
>> super T> predicate);
>> }
>> 
>> 
>> When I compile this with b115, the compiler bails out, with
>> 
>> TypeTest.java:9: error: no suitable method found for copyOf(Iterable<CAP#1>)
>> 
>>         return copyOf(filter(include, not(in(exclude))));
>> 
>>                ^
>> 
>>     method TypeTest.<E#1>copyOf(Iterable<? extends E#1>) is not applicable
>> 
>>       (cannot infer type-variable(s) E#1,T#1,T#2,T#3
>> 
>>         (argument mismatch; Iterable<CAP#2> cannot be converted to
>> Iterable<? extends CAP#2>))
>> 
>>     method TypeTest.<E#2>copyOf(Collection<? extends E#2>) is not applicable
>> 
>>       (no instance(s) of type variable(s) T#1,T#2,T#3 exist so that
>> Iterable<T#1> conforms to Collection<? extends E#2>)
>> 
>>   where E#1,T#1,T#2,T#3,E#2 are type-variables:
>> 
>>     E#1 extends Object declared in method <E#1>copyOf(Iterable<? extends
>> E#1>)
>> 
>>     T#1 extends Object declared in method
>> <T#1>filter(Iterable<T#1>,Predicate<? super T#1>)
>> 
>>     T#2 extends Object declared in method <T#2>not(Predicate<T#2>)
>> 
>>     T#3 extends Object declared in method <T#3>in(Collection<? extends T#3>)
>> 
>>     E#2 extends Object declared in method <E#2>copyOf(Collection<? extends
>> E#2>)
>> 
>>   where CAP#1,CAP#2 are fresh type-variables:
>> 
>>     CAP#1 extends I from capture of ? extends I
>> 
>>     CAP#2 extends I from capture of ? extends I
>> 
>> 1 error
>> 
>> But if I replace excludeFrom with
>> 
>>     public Collection<? extends I> filter(Collection<? extends I> include,
>>             Collection<? extends I> exclude) {
>>         Iterable<? extends I> myFiltered = filter(include,
>> not(in(exclude)));
>>         return copyOf(myFiltered);
>>     }
>> 
>> compilation succeeds. What gives?
>> 
>> Thanks in advance,
>> 
>> Jonathan Ross
>> 
> 
> 


From daniel.smith at oracle.com  Thu Nov 21 12:51:01 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 21 Nov 2013 13:51:01 -0700
Subject: question about enhanced type-inference
In-Reply-To: <CAL4QsgtpK=jYMLUrY8E4rQx-uJgYPeLwL__0XACBzxptt6_ScA@mail.gmail.com>
References: <CAL4QsgtpK=jYMLUrY8E4rQx-uJgYPeLwL__0XACBzxptt6_ScA@mail.gmail.com>
Message-ID: <A5BA46AE-ED79-4285-812B-E7AB1642694C@oracle.com>

The fact that this compiles in 7 is an implementation quirk.  During overload resolution, the compiler is supposed to decide that the method is applicable by (tentatively) inferring E and T while ignoring the assignment target.  javac cannot do this (as you can see if you comment out the assignment), but cheats by not really fully inferring E and T.

We haven't considered this a JLS compliance bug because JLS is pretty vague about how this process is supposed to work, leaving expected behavior open to interpretation.

In 8, the spec has been tightened and it's now clear that E and T must be (tentatively) inferred independent of the assignment target.  Since the 8 algorithm is not powerful enough to perform that inference, the error occurs.

The specific problem -- inference is not smart enough to conclude that
t <: Task<e>
and
t <: Task<CustomException>
imply
e = CustomException

However, it does seem plausible that an inference rule could be added to handle this.  Since this falls somewhere in the space between "bug" and "feature request", I'll consider it...

Here's my spec bug: https://bugs.openjdk.java.net/browse/JDK-8028813

?Dan

On Nov 19, 2013, at 11:16 AM, Liam Miller-Cushon <cushon at google.com> wrote:

> I have been experimenting with migrating some code to compile with javac
> 8's new graph inference algorithm. This has generally gone quite smoothly,
> but I ran into the following case where inference succeeds with legacy
> inference and fails with graph inference.
> 
> Is this a known limitation of the new inference algorithm?
> 
> Here's the code:
> 
> ===
> 
> interface Task<E extends Exception> {}
> class Comparator<T> {}
> class CustomException extends Exception {}
> 
> class TaskQueue<E extends Exception, T extends Task<E>> {}
> 
> abstract class Test {
>  abstract <E extends Exception, T extends Task<E>>
>      TaskQueue<E, T> create(Comparator<? super T> comparator);
> 
>  void f(Comparator<Task<CustomException>> comp) {
>    TaskQueue<CustomException, Task<CustomException>> queue = create(comp);
>  }
> }
> 
> ===
> 


From mike.duigou at oracle.com  Thu Nov 21 13:36:50 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 21 Nov 2013 13:36:50 -0800
Subject: Typo in Javadoc of Optional{Int, Double, Long}
In-Reply-To: <CAHjBcHMffBVYdZ9Tt44XnM8nRC93u52918cD8fF8XVa0PjDE6w@mail.gmail.com>
References: <CAHjBcHMffBVYdZ9Tt44XnM8nRC93u52918cD8fF8XVa0PjDE6w@mail.gmail.com>
Message-ID: <EEE32174-5906-462F-879D-F9DF60BA51E8@oracle.com>

Thank you.

I have created https://bugs.openjdk.java.net/browse/JDK-8028816 for this issue and will push your patch as the solution.

Mike

On Nov 21 2013, at 08:49 , bitter_fox <bitterfoxc at gmail.com> wrote:

> Hi,
> I found a typo in Javadoc of Optional{Int, Double, Long}:
> 
> --------------------------------------------------------------
> /**
> * {@code get()} will return the value.
> */
> public final class OptionalInt {
> ...
>    public int getAsInt() {
> ---------------------------------------------------------
> 
> " * {@code get()} will return the value."
> would be
> " * {@code getAsInt()} will return the value."
> 
> OptionalDouble and Long have a same typo.
> 
> diff -r 042a473535aa src/share/classes/java/util/OptionalDouble.java
> --- a/src/share/classes/java/util/OptionalDouble.java   Thu Oct 17 19:47:47
> 2013 -0700
> +++ b/src/share/classes/java/util/OptionalDouble.java   Fri Nov 22 01:44:55
> 2013 +0900
> @@ -31,7 +31,7 @@
> /**
>  * A container object which may or may not contain a {@code double} value.
>  * If a value is present, {@code isPresent()} will return {@code true} and
> - * {@code get()} will return the value.
> + * {@code getAsDouble()} will return the value.
>  *
>  * <p>Additional methods that depend on the presence or absence of a
> contained
>  * value are provided, such as {@link #orElse(double) orElse()}
> diff -r 042a473535aa src/share/classes/java/util/OptionalInt.java
> --- a/src/share/classes/java/util/OptionalInt.java      Thu Oct 17 19:47:47
> 2013 -0700
> +++ b/src/share/classes/java/util/OptionalInt.java      Fri Nov 22 01:44:55
> 2013 +0900
> @@ -31,7 +31,7 @@
> /**
>  * A container object which may or may not contain a {@code int} value.
>  * If a value is present, {@code isPresent()} will return {@code true} and
> - * {@code get()} will return the value.
> + * {@code getAsInt()} will return the value.
>  *
>  * <p>Additional methods that depend on the presence or absence of a
> contained
>  * value are provided, such as {@link #orElse(int) orElse()}
> diff -r 042a473535aa src/share/classes/java/util/OptionalLong.java
> --- a/src/share/classes/java/util/OptionalLong.java     Thu Oct 17 19:47:47
> 2013 -0700
> +++ b/src/share/classes/java/util/OptionalLong.java     Fri Nov 22 01:44:55
> 2013 +0900
> @@ -31,7 +31,7 @@
> /**
>  * A container object which may or may not contain a {@code long} value.
>  * If a value is present, {@code isPresent()} will return {@code true} and
> - * {@code get()} will return the value.
> + * {@code getAsLong()} will return the value.
>  *
>  * <p>Additional methods that depend on the presence or absence of a
> contained
>  * value are provided, such as {@link #orElse(long) orElse()}
> 
> Regards,
> bitter_fox
> 


From brian.goetz at oracle.com  Thu Nov 21 13:49:34 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 Nov 2013 16:49:34 -0500
Subject: List of all default methods
In-Reply-To: <528E254C.80509@gmx.org>
References: <528DC8E9.20807@gmx.org> <528DF5B8.9010301@univ-mlv.fr>
	<528E016E.8000801@gmx.org> <528E1F27.7090600@oracle.com>
	<528E254C.80509@gmx.org>
Message-ID: <528E7FEE.2020404@oracle.com>

>> to produce a new sorted stream.  To avoid making things more confusing,
>> we followed the guideline of adding in-place mutative methods to the
>> concrete collections, and adding functional / lazy methods to Stream,
>> rather than mixing.
>
> yes, only the problem is, that if we follow that rationale then we have
> to remove dozens of our additions plus, the non-mutating versions would
> not be available on a jvm before 8. Sadly we cannot strictly follow that

Well, you have to decide what is best for *your* users.

>> As a general rule, adding stuff to Iterable is probably going to cause
>> ongoing pain.  Use with care.
>
> Iterable, List, Collection, Map, CharSequence, Enumeration, Set,
> SortedSet, SortedMap, Iterable

Its a spectrum.  Adding methods involves reasoning about the probability 
of collision, and whether the weighted downside of collision is 
outweighed by the upside of the new functionality.  The more widely 
implemented an interface is (Iterable more so than List, List much more 
so than BeanContextServiceProvider), the more likely collision is just 
on a quantitative basis.  The more *abstract* it is, the more likely 
you'll have semantic conflicts.  Both suggest Iterable is about the 
worst interface to choose to "enhance".  (This is why we didn't add 
.stream() to Iterable; we forsaw semantic conflicts.)

In any case, now that we're in the business of evolving interfaces as 
well as classes, I think you can expect some additional conflicts in the 
future.  Not necessarily too many, as we try to have restraint, but its 
going to happen.  Seems it happened once or twice in 8.  It might happen 
a few more times in 9.  You'll just need a plan for dealing with it.


From pbenedict at apache.org  Thu Nov 21 14:23:38 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 21 Nov 2013 16:23:38 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
Message-ID: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>

While reading the Observer javadocs [1], I noticed the message of it being
a functional interface yet the annotation is not appearing on the signature:

"public interface Observer" without the annotation.

Now compare that to javadocs of Comparator:
"@FunctionalInterface
public interface Comparator<T>"

[1] http://download.java.net/jdk8/docs/api/java/util/Observer.html

-- 
Cheers,
Paul

From pbenedict at apache.org  Thu Nov 21 14:47:29 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 21 Nov 2013 16:47:29 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
Message-ID: <CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>

I have found some more inconsistencies in other types.

These have it:
* FileFilter
* FilenameFilter
* Runnable

These do not:
* AutoCloseable
* Comparable
* Iterable
* Readable
* Closeable
* Flushable

If there are more, I don't know; I just wanted to give an FYI to start the
investigation.


On Thu, Nov 21, 2013 at 4:23 PM, Paul Benedict <pbenedict at apache.org> wrote:

> While reading the Observer javadocs [1], I noticed the message of it being
> a functional interface yet the annotation is not appearing on the signature:
>
> "public interface Observer" without the annotation.
>
> Now compare that to javadocs of Comparator:
> "@FunctionalInterface
> public interface Comparator<T>"
>
> [1] http://download.java.net/jdk8/docs/api/java/util/Observer.html
>
> --
> Cheers,
> Paul
>



-- 
Cheers,
Paul

From joe.darcy at oracle.com  Thu Nov 21 19:02:48 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Thu, 21 Nov 2013 19:02:48 -0800
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
Message-ID: <528EC958.9080500@oracle.com>

Hi Paul,

On 11/21/2013 2:47 PM, Paul Benedict wrote:
> I have found some more inconsistencies in other types.
>
> These have it:
> * FileFilter
> * FilenameFilter
> * Runnable
>
> These do not:
> * AutoCloseable
> * Comparable
> * Iterable
> * Readable
> * Closeable
> * Flushable
>
> If there are more, I don't know; I just wanted to give an FYI to start the
> investigation.

At least some of these are intentional omissions; see

         JDK-8022658 Revisit FunctionalInterface on some core libs types
         https://bugs.openjdk.java.net/browse/JDK-8022658

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022416.html

HTH,

-Joe

>
>
> On Thu, Nov 21, 2013 at 4:23 PM, Paul Benedict <pbenedict at apache.org> wrote:
>
>> While reading the Observer javadocs [1], I noticed the message of it being
>> a functional interface yet the annotation is not appearing on the signature:
>>
>> "public interface Observer" without the annotation.
>>
>> Now compare that to javadocs of Comparator:
>> "@FunctionalInterface
>> public interface Comparator<T>"
>>
>> [1] http://download.java.net/jdk8/docs/api/java/util/Observer.html
>>
>> --
>> Cheers,
>> Paul
>>
>
>


From pbenedict at apache.org  Thu Nov 21 19:35:35 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 21 Nov 2013 21:35:35 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <528EC958.9080500@oracle.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
Message-ID: <CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>

My point is not who should/shouldn't have the annotation, but that the
annotation appears (or disappears) seemingly randomly in the generated
javadoc signature... and yet the statement "This is a functional interface"
is on them all.



On Thu, Nov 21, 2013 at 9:02 PM, Joseph Darcy <joe.darcy at oracle.com> wrote:

> Hi Paul,
>
>
> On 11/21/2013 2:47 PM, Paul Benedict wrote:
>
>> I have found some more inconsistencies in other types.
>>
>> These have it:
>> * FileFilter
>> * FilenameFilter
>> * Runnable
>>
>> These do not:
>> * AutoCloseable
>> * Comparable
>> * Iterable
>> * Readable
>> * Closeable
>> * Flushable
>>
>> If there are more, I don't know; I just wanted to give an FYI to start the
>> investigation.
>>
>
> At least some of these are intentional omissions; see
>
>         JDK-8022658 Revisit FunctionalInterface on some core libs types
>         https://bugs.openjdk.java.net/browse/JDK-8022658
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-
> October/022416.html
>
> HTH,
>
> -Joe
>
>
>
>>
>> On Thu, Nov 21, 2013 at 4:23 PM, Paul Benedict <pbenedict at apache.org>
>> wrote:
>>
>>  While reading the Observer javadocs [1], I noticed the message of it
>>> being
>>> a functional interface yet the annotation is not appearing on the
>>> signature:
>>>
>>> "public interface Observer" without the annotation.
>>>
>>> Now compare that to javadocs of Comparator:
>>> "@FunctionalInterface
>>> public interface Comparator<T>"
>>>
>>> [1] http://download.java.net/jdk8/docs/api/java/util/Observer.html
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>>
>>
>>
>


-- 
Cheers,
Paul

From pbenedict at apache.org  Thu Nov 21 19:40:35 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 21 Nov 2013 21:40:35 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
Message-ID: <CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>

Look at, Closeable, as an example. You removed the @FunctionalInterface
annotation but the javadocs still report it as a functional interface in
the class description.

http://download.java.net/jdk8/docs/api/java/io/Closeable.html


On Thu, Nov 21, 2013 at 9:35 PM, Paul Benedict <pbenedict at apache.org> wrote:

> My point is not who should/shouldn't have the annotation, but that the
> annotation appears (or disappears) seemingly randomly in the generated
> javadoc signature... and yet the statement "This is a functional interface"
> is on them all.
>
>
>
> On Thu, Nov 21, 2013 at 9:02 PM, Joseph Darcy <joe.darcy at oracle.com>wrote:
>
>> Hi Paul,
>>
>>
>> On 11/21/2013 2:47 PM, Paul Benedict wrote:
>>
>>> I have found some more inconsistencies in other types.
>>>
>>> These have it:
>>> * FileFilter
>>> * FilenameFilter
>>> * Runnable
>>>
>>> These do not:
>>> * AutoCloseable
>>> * Comparable
>>> * Iterable
>>> * Readable
>>> * Closeable
>>> * Flushable
>>>
>>> If there are more, I don't know; I just wanted to give an FYI to start
>>> the
>>> investigation.
>>>
>>
>> At least some of these are intentional omissions; see
>>
>>         JDK-8022658 Revisit FunctionalInterface on some core libs types
>>         https://bugs.openjdk.java.net/browse/JDK-8022658
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-
>> October/022416.html
>>
>> HTH,
>>
>> -Joe
>>
>>
>>
>>>
>>> On Thu, Nov 21, 2013 at 4:23 PM, Paul Benedict <pbenedict at apache.org>
>>> wrote:
>>>
>>>  While reading the Observer javadocs [1], I noticed the message of it
>>>> being
>>>> a functional interface yet the annotation is not appearing on the
>>>> signature:
>>>>
>>>> "public interface Observer" without the annotation.
>>>>
>>>> Now compare that to javadocs of Comparator:
>>>> "@FunctionalInterface
>>>> public interface Comparator<T>"
>>>>
>>>> [1] http://download.java.net/jdk8/docs/api/java/util/Observer.html
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>
>>>
>>
>
>
> --
> Cheers,
> Paul
>



-- 
Cheers,
Paul

From joe.darcy at oracle.com  Thu Nov 21 19:43:16 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 21 Nov 2013 19:43:16 -0800
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>	<528EC958.9080500@oracle.com>	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
Message-ID: <528ED2D4.3090908@oracle.com>

On 11/21/2013 07:40 PM, Paul Benedict wrote:
> Look at, Closeable, as an example. You removed the 
> @FunctionalInterface annotation but the javadocs still report it as a 
> functional interface in the class description.
>
> http://download.java.net/jdk8/docs/api/java/io/Closeable.html

Yes, that is the correct and expected outcome.

The type java.io.Closeable meets the JLS definition of a functional 
interface and gets reported accordingly by javac. However, it is not 
morally a functional interface so it no longer has the 
@FunctionalInterface annotation, an annotation which indicates 
intentions towards usage and interface evolution.

-Joe

From pbenedict at apache.org  Thu Nov 21 19:50:16 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 21 Nov 2013 21:50:16 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <528ED2D4.3090908@oracle.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
	<528ED2D4.3090908@oracle.com>
Message-ID: <CABLGb9xi1Lpynr1R8q4xspW6xNe=f+tPwP=gJtexPahTkaiDkA@mail.gmail.com>

Alright, I suppose. Very surprising to see such a distinction being made in
these reports; I think the output is not intuitive, but at least I can
explain it to someone else now.


On Thu, Nov 21, 2013 at 9:43 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> On 11/21/2013 07:40 PM, Paul Benedict wrote:
>
>> Look at, Closeable, as an example. You removed the @FunctionalInterface
>> annotation but the javadocs still report it as a functional interface in
>> the class description.
>>
>> http://download.java.net/jdk8/docs/api/java/io/Closeable.html
>>
>
> Yes, that is the correct and expected outcome.
>
> The type java.io.Closeable meets the JLS definition of a functional
> interface and gets reported accordingly by javac. However, it is not
> morally a functional interface so it no longer has the @FunctionalInterface
> annotation, an annotation which indicates intentions towards usage and
> interface evolution.
>
> -Joe
>



-- 
Cheers,
Paul

From robert.field at oracle.com  Thu Nov 21 20:21:33 2013
From: robert.field at oracle.com (Robert Field)
Date: Thu, 21 Nov 2013 20:21:33 -0800
Subject: RFR: 8028739: javac generates incorrect descriptor for
	MethodHandle::invoke
Message-ID: <528EDBCD.5090101@oracle.com>

Please review fix for:

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

Webrev:

http://cr.openjdk.java.net/~rfield/8028739v0/ 
<http://cr.openjdk.java.net/%7Erfield/8028739v0/>

Thank you,
Robert


From john.r.rose at oracle.com  Thu Nov 21 22:55:51 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 21 Nov 2013 22:55:51 -0800
Subject: RFR: 8028739: javac generates incorrect descriptor for
	MethodHandle::invoke
In-Reply-To: <528EDBCD.5090101@oracle.com>
References: <528EDBCD.5090101@oracle.com>
Message-ID: <B571E3B9-1CF4-4F60-8B44-342215F7B061@oracle.com>

I think you will get a false positive on MethodHandle.invokeWithArguments. 

There are more precise tests for sig. polymorphism. It must be native final; the code should check for that. 

-- John  (on my iPhone)

On Nov 21, 2013, at 8:21 PM, Robert Field <robert.field at oracle.com> wrote:

> Please review fix for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8028739
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~rfield/8028739v0/ 
> <http://cr.openjdk.java.net/%7Erfield/8028739v0/>
> 
> Thank you,
> Robert
> 
> 

From blackdrag at gmx.org  Thu Nov 21 23:14:49 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 22 Nov 2013 08:14:49 +0100
Subject: List of all default methods
In-Reply-To: <528E7FEE.2020404@oracle.com>
References: <528DC8E9.20807@gmx.org> <528DF5B8.9010301@univ-mlv.fr>
	<528E016E.8000801@gmx.org> <528E1F27.7090600@oracle.com>
	<528E254C.80509@gmx.org> <528E7FEE.2020404@oracle.com>
Message-ID: <528F0469.6030005@gmx.org>

Am 21.11.2013 22:49, schrieb Brian Goetz:
>>> to produce a new sorted stream.  To avoid making things more confusing,
>>> we followed the guideline of adding in-place mutative methods to the
>>> concrete collections, and adding functional / lazy methods to Stream,
>>> rather than mixing.
>>
>> yes, only the problem is, that if we follow that rationale then we have
>> to remove dozens of our additions plus, the non-mutating versions would
>> not be available on a jvm before 8. Sadly we cannot strictly follow that
>
> Well, you have to decide what is best for *your* users.

This is no easy decision for us.

>>> As a general rule, adding stuff to Iterable is probably going to cause
>>> ongoing pain.  Use with care.
>>
>> Iterable, List, Collection, Map, CharSequence, Enumeration, Set,
>> SortedSet, SortedMap, Iterable
>
> Its a spectrum.  Adding methods involves reasoning about the probability
> of collision, and whether the weighted downside of collision is
> outweighed by the upside of the new functionality.

As you pointed out, the game changed. Before the classes almost did not 
change. With Java8 this is different.

> The more widely
> implemented an interface is (Iterable more so than List, List much more
> so than BeanContextServiceProvider), the more likely collision is just
> on a quantitative basis.  The more *abstract* it is, the more likely
> you'll have semantic conflicts.  Both suggest Iterable is about the
> worst interface to choose to "enhance".  (This is why we didn't add
> .stream() to Iterable; we forsaw semantic conflicts.)

We even have methods on Object. More far reaching than that is impossible ;)

> In any case, now that we're in the business of evolving interfaces as
> well as classes, I think you can expect some additional conflicts in the
> future.  Not necessarily too many, as we try to have restraint, but its
> going to happen.  Seems it happened once or twice in 8.  It might happen
> a few more times in 9.  You'll just need a plan for dealing with it.

yes,we are discussing about that.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


From pbenedict at apache.org  Fri Nov 22 07:52:55 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 22 Nov 2013 09:52:55 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CABLGb9xi1Lpynr1R8q4xspW6xNe=f+tPwP=gJtexPahTkaiDkA@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
	<528ED2D4.3090908@oracle.com>
	<CABLGb9xi1Lpynr1R8q4xspW6xNe=f+tPwP=gJtexPahTkaiDkA@mail.gmail.com>
Message-ID: <CABLGb9zfD8eN4juHXZZkK7vo948J2ErFTMfEaQ4aCP0vbtRt1g@mail.gmail.com>

Joe, what do you think rewording the description to saying: "This an
implicit functional interface" (adding the word implicit)? I think we must
differentiate between the two; I would find this clarification in the docs
much more meaningful in light of your explanation.




On Thu, Nov 21, 2013 at 9:50 PM, Paul Benedict <pbenedict at apache.org> wrote:

> Alright, I suppose. Very surprising to see such a distinction being made
> in these reports; I think the output is not intuitive, but at least I can
> explain it to someone else now.
>
>
> On Thu, Nov 21, 2013 at 9:43 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
>
>> On 11/21/2013 07:40 PM, Paul Benedict wrote:
>>
>>> Look at, Closeable, as an example. You removed the @FunctionalInterface
>>> annotation but the javadocs still report it as a functional interface in
>>> the class description.
>>>
>>> http://download.java.net/jdk8/docs/api/java/io/Closeable.html
>>>
>>
>> Yes, that is the correct and expected outcome.
>>
>> The type java.io.Closeable meets the JLS definition of a functional
>> interface and gets reported accordingly by javac. However, it is not
>> morally a functional interface so it no longer has the @FunctionalInterface
>> annotation, an annotation which indicates intentions towards usage and
>> interface evolution.
>>
>> -Joe
>>
>
>
>
> --
> Cheers,
> Paul
>



-- 
Cheers,
Paul

From zhong.j.yu at gmail.com  Fri Nov 22 09:29:35 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 22 Nov 2013 11:29:35 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <528ED2D4.3090908@oracle.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
	<528ED2D4.3090908@oracle.com>
Message-ID: <CACuKZqFLVHwXfWDFfJSdQKKr1KF=QrZN1R72ij-JDo+xqhod4Q@mail.gmail.com>

On Thu, Nov 21, 2013 at 9:43 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> On 11/21/2013 07:40 PM, Paul Benedict wrote:
>> Look at, Closeable, as an example. You removed the
>> @FunctionalInterface annotation but the javadocs still report it as a
>> functional interface in the class description.
>>
>> http://download.java.net/jdk8/docs/api/java/io/Closeable.html
>
> Yes, that is the correct and expected outcome.
>
> The type java.io.Closeable meets the JLS definition of a functional
> interface and gets reported accordingly by javac. However, it is not
> morally a functional interface so it no longer has the
> @FunctionalInterface annotation, an annotation which indicates
> intentions towards usage and interface evolution.

How it is related to interface evolution? Adding an abstract method to
an interface will always break a lot of things. You can do that if the
interface is in-house where all implementations can be refactored. If
the interface is public with lots of 3rd party implementations, you
simply cannot do that. None of these has anything to do with how many
abstract methods the interface had, or whether it was a functional
interface or not.

I still have no idea how the annotation is supposed to help us. Can
anyone provide a concrete use case for @FunctionalInterface?

Zhong Yu

From brian.goetz at oracle.com  Fri Nov 22 09:52:53 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 22 Nov 2013 12:52:53 -0500
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CACuKZqFLVHwXfWDFfJSdQKKr1KF=QrZN1R72ij-JDo+xqhod4Q@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>	<528EC958.9080500@oracle.com>	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>	<528ED2D4.3090908@oracle.com>
	<CACuKZqFLVHwXfWDFfJSdQKKr1KF=QrZN1R72ij-JDo+xqhod4Q@mail.gmail.com>
Message-ID: <528F99F5.2010606@oracle.com>

> I still have no idea how the annotation is supposed to help us. Can
> anyone provide a concrete use case for @FunctionalInterface?

It captures design intent; the compiler assists you by enforcing that 
design intent (erroring if the class has more than one abstract method.) 
  Like the @Override annotation.

From zhong.j.yu at gmail.com  Fri Nov 22 10:09:46 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 22 Nov 2013 12:09:46 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <528F99F5.2010606@oracle.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
	<528ED2D4.3090908@oracle.com>
	<CACuKZqFLVHwXfWDFfJSdQKKr1KF=QrZN1R72ij-JDo+xqhod4Q@mail.gmail.com>
	<528F99F5.2010606@oracle.com>
Message-ID: <CACuKZqEpXOQPzEvGqW=7QCD0Z35J2jdeSNciBmORziSf04gBxw@mail.gmail.com>

The chance seems very small that one could accidentally add an
abstract method to an interface (without being hit by lots of
compilation errors else where).

On Fri, Nov 22, 2013 at 11:52 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> I still have no idea how the annotation is supposed to help us. Can
>> anyone provide a concrete use case for @FunctionalInterface?
>
>
> It captures design intent; the compiler assists you by enforcing that design
> intent (erroring if the class has more than one abstract method.)  Like the
> @Override annotation.

From robert.field at oracle.com  Fri Nov 22 10:31:02 2013
From: robert.field at oracle.com (Robert Field)
Date: Fri, 22 Nov 2013 10:31:02 -0800
Subject: RFR: 8028739: javac generates incorrect descriptor for
	MethodHandle::invoke
In-Reply-To: <B571E3B9-1CF4-4F60-8B44-342215F7B061@oracle.com>
References: <528EDBCD.5090101@oracle.com>
	<B571E3B9-1CF4-4F60-8B44-342215F7B061@oracle.com>
Message-ID: <528FA2E6.6000103@oracle.com>

Thanks John!

Updated webrev:

http://cr.openjdk.java.net/~rfield/8028739v1/ 
<http://cr.openjdk.java.net/%7Erfield/8028739v1/>

Only change is to use the pre-existing test for signature polymorphic:

2121             final boolean isSignaturePolymorphic() {
2122                 return  tree.sym instanceof MethodSymbol &&
2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
2124             }


-Robert


On 11/21/13 22:55, John Rose wrote:
> I think you will get a false positive on MethodHandle.invokeWithArguments.
>
> There are more precise tests for sig. polymorphism. It must be native final; the code should check for that.
>
> -- John  (on my iPhone)
>
> On Nov 21, 2013, at 8:21 PM, Robert Field <robert.field at oracle.com> wrote:
>
>> Please review fix for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8028739
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~rfield/8028739v0/
>> <http://cr.openjdk.java.net/%7Erfield/8028739v0/>
>>
>> Thank you,
>> Robert
>>
>>


From pbenedict at apache.org  Fri Nov 22 10:39:11 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 22 Nov 2013 12:39:11 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CACuKZqEpXOQPzEvGqW=7QCD0Z35J2jdeSNciBmORziSf04gBxw@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
	<528ED2D4.3090908@oracle.com>
	<CACuKZqFLVHwXfWDFfJSdQKKr1KF=QrZN1R72ij-JDo+xqhod4Q@mail.gmail.com>
	<528F99F5.2010606@oracle.com>
	<CACuKZqEpXOQPzEvGqW=7QCD0Z35J2jdeSNciBmORziSf04gBxw@mail.gmail.com>
Message-ID: <CABLGb9x7w2GUeSHc3S40nOGqmOLvsTWKYtj-dz-5B1s4yPuAkA@mail.gmail.com>

The design intent is important to me. I want the compiler to enforce the
intent with @FunctionalInterface. Zhong, where you get compiler errors is
project specific. Not all consuming code is in the same project. The errors
may not show up until the client uses the upgraded jar.

But I am not sure this thread should be hijacked with that concern. I'd
like to keep the discussion on simply enhancing the javadocs to call out
the implicitness of some functional interfaces. I think the word "implicit"
should be used, with perhaps a warning that no intent exists it will remain
a functional interface.


On Fri, Nov 22, 2013 at 12:09 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> The chance seems very small that one could accidentally add an
> abstract method to an interface (without being hit by lots of
> compilation errors else where).
>
> On Fri, Nov 22, 2013 at 11:52 AM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >> I still have no idea how the annotation is supposed to help us. Can
> >> anyone provide a concrete use case for @FunctionalInterface?
> >
> >
> > It captures design intent; the compiler assists you by enforcing that
> design
> > intent (erroring if the class has more than one abstract method.)  Like
> the
> > @Override annotation.
>
>


-- 
Cheers,
Paul

From zhong.j.yu at gmail.com  Fri Nov 22 12:49:16 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 22 Nov 2013 14:49:16 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CABLGb9x7w2GUeSHc3S40nOGqmOLvsTWKYtj-dz-5B1s4yPuAkA@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
	<528ED2D4.3090908@oracle.com>
	<CACuKZqFLVHwXfWDFfJSdQKKr1KF=QrZN1R72ij-JDo+xqhod4Q@mail.gmail.com>
	<528F99F5.2010606@oracle.com>
	<CACuKZqEpXOQPzEvGqW=7QCD0Z35J2jdeSNciBmORziSf04gBxw@mail.gmail.com>
	<CABLGb9x7w2GUeSHc3S40nOGqmOLvsTWKYtj-dz-5B1s4yPuAkA@mail.gmail.com>
Message-ID: <CACuKZqEgKBGGwkmpa4UKaS2PAD_SNsZ7vguhQw6uJW=Cy6um_A@mail.gmail.com>

On Fri, Nov 22, 2013 at 12:39 PM, Paul Benedict <pbenedict at apache.org> wrote:
> The design intent is important to me. I want the compiler to enforce the
> intent with @FunctionalInterface. Zhong, where you get compiler errors is
> project specific. Not all consuming code is in the same project. The errors
> may not show up until the client uses the upgraded jar.

In the long history of Java, are there anecdotes that a new method is
accidentally added to a public interface? Has the experience shown
that it is worthy of a prevention mechanism (which is far from free)?

>
> But I am not sure this thread should be hijacked with that concern. I'd like

No hijacking. The center issue here is what @FunctionalInterface is
intended for. The discussion goes no where if we are not clear about
that.

> to keep the discussion on simply enhancing the javadocs to call out the
> implicitness of some functional interfaces. I think the word "implicit"
> should be used, with perhaps a warning that no intent exists it will remain
> a functional interface.

A functional interface is a functional interface. A public one will
remain a functional interface till the end of time. If unforeseeable
things happen that break that assumption, the marking of
@FunctionalInterface will not make any difference.

The concept of "functional interface" is only to serve lambda
expressions and method references. That's at use-site, not declaration
site of interfaces. There's no reason to say that a Closeable could
not be used as a method parameter type, and the argument could not be
a lambda expression. There's no reason to say that a Consumer<T> could
not be used as a non-functional interface could be used typically.
@FunctionalInterface on an interface does not convey anything that
users should adhere to.


>
>
> On Fri, Nov 22, 2013 at 12:09 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> The chance seems very small that one could accidentally add an
>> abstract method to an interface (without being hit by lots of
>> compilation errors else where).
>>
>> On Fri, Nov 22, 2013 at 11:52 AM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>> >> I still have no idea how the annotation is supposed to help us. Can
>> >> anyone provide a concrete use case for @FunctionalInterface?
>> >
>> >
>> > It captures design intent; the compiler assists you by enforcing that
>> > design
>> > intent (erroring if the class has more than one abstract method.)  Like
>> > the
>> > @Override annotation.
>>
>
>
>
> --
> Cheers,
> Paul

From jonathan.gibbons at oracle.com  Fri Nov 22 12:59:23 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 22 Nov 2013 12:59:23 -0800
Subject: RFR: 8028739: javac generates incorrect descriptor for
	MethodHandle::invoke
In-Reply-To: <528FA2E6.6000103@oracle.com>
References: <528EDBCD.5090101@oracle.com>	<B571E3B9-1CF4-4F60-8B44-342215F7B061@oracle.com>
	<528FA2E6.6000103@oracle.com>
Message-ID: <528FC5AB.7070705@oracle.com>

Robert,

In this code:
> 2121             final boolean isSignaturePolymorphic() {
> 2122                 return  tree.sym instanceof MethodSymbol &&
> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
> 2124             }

it is not javac style to do instanceof like that -- the normal style is 
to check the kind, as in
     tree.sym.kind == MTH

-- Jon




On 11/22/2013 10:31 AM, Robert Field wrote:
> Thanks John!
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~rfield/8028739v1/
> <http://cr.openjdk.java.net/%7Erfield/8028739v1/>
>
> Only change is to use the pre-existing test for signature polymorphic:
>
> 2121             final boolean isSignaturePolymorphic() {
> 2122                 return  tree.sym instanceof MethodSymbol &&
> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
> 2124             }
>
>
> -Robert
>
>
> On 11/21/13 22:55, John Rose wrote:
>> I think you will get a false positive on MethodHandle.invokeWithArguments.
>>
>> There are more precise tests for sig. polymorphism. It must be native final; the code should check for that.
>>
>> -- John  (on my iPhone)
>>
>> On Nov 21, 2013, at 8:21 PM, Robert Field <robert.field at oracle.com> wrote:
>>
>>> Please review fix for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8028739
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~rfield/8028739v0/
>>> <http://cr.openjdk.java.net/%7Erfield/8028739v0/>
>>>
>>> Thank you,
>>> Robert
>>>
>>>
>


From robert.field at oracle.com  Fri Nov 22 13:13:04 2013
From: robert.field at oracle.com (Robert Field)
Date: Fri, 22 Nov 2013 13:13:04 -0800
Subject: RFR: 8028739: javac generates incorrect descriptor for
	MethodHandle::invoke
In-Reply-To: <528FC5AB.7070705@oracle.com>
References: <528EDBCD.5090101@oracle.com>	<B571E3B9-1CF4-4F60-8B44-342215F7B061@oracle.com>	<528FA2E6.6000103@oracle.com>
	<528FC5AB.7070705@oracle.com>
Message-ID: <528FC8E0.20001@oracle.com>


On 11/22/13 12:59, Jonathan Gibbons wrote:
> Robert,
>
> In this code:
>> 2121             final boolean isSignaturePolymorphic() {
>> 2122                 return  tree.sym instanceof MethodSymbol &&
>> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
>> 2124             }
> it is not javac style to do instanceof like that -- the normal style is
> to check the kind, as in
>       tree.sym.kind == MTH

OK.

Even if you are about to do a cast?

-Robert

>
> -- Jon
>
>
>
>
> On 11/22/2013 10:31 AM, Robert Field wrote:
>> Thanks John!
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~rfield/8028739v1/
>> <http://cr.openjdk.java.net/%7Erfield/8028739v1/>
>>
>> Only change is to use the pre-existing test for signature polymorphic:
>>
>> 2121             final boolean isSignaturePolymorphic() {
>> 2122                 return  tree.sym instanceof MethodSymbol &&
>> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
>> 2124             }
>>
>>
>> -Robert
>>
>>
>> On 11/21/13 22:55, John Rose wrote:
>>> I think you will get a false positive on MethodHandle.invokeWithArguments.
>>>
>>> There are more precise tests for sig. polymorphism. It must be native final; the code should check for that.
>>>
>>> -- John  (on my iPhone)
>>>
>>> On Nov 21, 2013, at 8:21 PM, Robert Field <robert.field at oracle.com> wrote:
>>>
>>>> Please review fix for:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8028739
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~rfield/8028739v0/
>>>> <http://cr.openjdk.java.net/%7Erfield/8028739v0/>
>>>>
>>>> Thank you,
>>>> Robert
>>>>
>>>>
>


From pbenedict at apache.org  Fri Nov 22 13:21:46 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 22 Nov 2013 15:21:46 -0600
Subject: Javadoc (b116) lacks @FunctionalInterface on Observer signature
In-Reply-To: <CACuKZqEgKBGGwkmpa4UKaS2PAD_SNsZ7vguhQw6uJW=Cy6um_A@mail.gmail.com>
References: <CABLGb9wcxeihY8iz7jFeJfO0aoKBpwFXQd4b7BQGuKWZ2cqPmw@mail.gmail.com>
	<CABLGb9zs3qq27LoYaPuWd=yuPDpPryZ3iEWCv3Ppy90wyPDVTg@mail.gmail.com>
	<528EC958.9080500@oracle.com>
	<CABLGb9wN1ojmZM7HT=vM5Cp7D99_fU-srj2sEaWMz-53kuX5Mw@mail.gmail.com>
	<CABLGb9wytbjnhtj+hkH4BpXZqn3TBYhgipu0D8=dYwN=Qz5-7A@mail.gmail.com>
	<528ED2D4.3090908@oracle.com>
	<CACuKZqFLVHwXfWDFfJSdQKKr1KF=QrZN1R72ij-JDo+xqhod4Q@mail.gmail.com>
	<528F99F5.2010606@oracle.com>
	<CACuKZqEpXOQPzEvGqW=7QCD0Z35J2jdeSNciBmORziSf04gBxw@mail.gmail.com>
	<CABLGb9x7w2GUeSHc3S40nOGqmOLvsTWKYtj-dz-5B1s4yPuAkA@mail.gmail.com>
	<CACuKZqEgKBGGwkmpa4UKaS2PAD_SNsZ7vguhQw6uJW=Cy6um_A@mail.gmail.com>
Message-ID: <CABLGb9zkHdeKcAbJryCZamyQf48Tyzm8HPFWpRrqfi8-O+Unmw@mail.gmail.com>

On Fri, Nov 22, 2013 at 2:49 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> On Fri, Nov 22, 2013 at 12:39 PM, Paul Benedict <pbenedict at apache.org>
> wrote:
> > The design intent is important to me. I want the compiler to enforce the
> > intent with @FunctionalInterface. Zhong, where you get compiler errors is
> > project specific. Not all consuming code is in the same project. The
> errors
> > may not show up until the client uses the upgraded jar.
>
> In the long history of Java, are there anecdotes that a new method is
> accidentally added to a public interface? Has the experience shown
> that it is worthy of a prevention mechanism (which is far from free)?
>
>
I think you're looking at this from the wrong perspective. The idea is to
delineate between explicit and implicit functional interfaces. If a
designer absolutely intends this interface to be the subject of a lambda
assignment target, it makes total sense to use @FunctionalInterface. Other
interfaces -- just by happenstance alone -- may have one method with
intention of adding others later; you can call it a "functional interface"
today but it won't be tomorrow when the design evolves. So in the case of
implicit functional interfaces, use it at your own risk, because tomorrow
you may be out of luck.


> >
> > But I am not sure this thread should be hijacked with that concern. I'd
> like
>
> No hijacking. The center issue here is what @FunctionalInterface is
> intended for. The discussion goes no where if we are not clear about
> that.
>
>
OK, but that wasn't my issue. Mine was thinking there was a bug in javadoc.
It turns out Oracle wants to call out implicit functional interfaces, but I
just want them to tweak the message.

Paul

From robert.field at oracle.com  Fri Nov 22 13:52:12 2013
From: robert.field at oracle.com (Robert Field)
Date: Fri, 22 Nov 2013 13:52:12 -0800
Subject: RFR: 8028739: javac generates incorrect descriptor for
	MethodHandle::invoke
In-Reply-To: <528FC5AB.7070705@oracle.com>
References: <528EDBCD.5090101@oracle.com>	<B571E3B9-1CF4-4F60-8B44-342215F7B061@oracle.com>	<528FA2E6.6000103@oracle.com>
	<528FC5AB.7070705@oracle.com>
Message-ID: <528FD20C.8010306@oracle.com>

Thanks Jon!

Updated webrev:

http://cr.openjdk.java.net/~rfield/8028739v2/ 
<http://cr.openjdk.java.net/%7Erfield/8028739v2/>


Again, the only change is to the isSignaturePolymorphic method:

2121             final boolean isSignaturePolymorphic() {
2122                 return_tree.sym.kind == MTH_  &&
2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
2124             }


-Robert


On 11/22/13 12:59, Jonathan Gibbons wrote:
> Robert,
>
> In this code:
>> 2121             final boolean isSignaturePolymorphic() {
>> 2122                 return  tree.sym instanceof MethodSymbol &&
>> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
>> 2124             }
> it is not javac style to do instanceof like that -- the normal style is
> to check the kind, as in
>       tree.sym.kind == MTH
>
> -- Jon
>
>
>
>
> On 11/22/2013 10:31 AM, Robert Field wrote:
>> Thanks John!
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~rfield/8028739v1/
>> <http://cr.openjdk.java.net/%7Erfield/8028739v1/>
>>
>> Only change is to use the pre-existing test for signature polymorphic:
>>
>> 2121             final boolean isSignaturePolymorphic() {
>> 2122                 return  tree.sym instanceof MethodSymbol &&
>> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
>> 2124             }
>>
>>
>> -Robert
>>
>>
>> On 11/21/13 22:55, John Rose wrote:
>>> I think you will get a false positive on MethodHandle.invokeWithArguments.
>>>
>>> There are more precise tests for sig. polymorphism. It must be native final; the code should check for that.
>>>
>>> -- John  (on my iPhone)
>>>
>>> On Nov 21, 2013, at 8:21 PM, Robert Field <robert.field at oracle.com> wrote:
>>>
>>>> Please review fix for:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8028739
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~rfield/8028739v0/
>>>> <http://cr.openjdk.java.net/%7Erfield/8028739v0/>
>>>>
>>>> Thank you,
>>>> Robert
>>>>
>>>>
>


From jonathan.gibbons at oracle.com  Fri Nov 22 14:30:00 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 22 Nov 2013 14:30:00 -0800
Subject: RFR: 8028739: javac generates incorrect descriptor for
	MethodHandle::invoke
In-Reply-To: <528FD20C.8010306@oracle.com>
References: <528EDBCD.5090101@oracle.com>	<B571E3B9-1CF4-4F60-8B44-342215F7B061@oracle.com>	<528FA2E6.6000103@oracle.com>	<528FC5AB.7070705@oracle.com>
	<528FD20C.8010306@oracle.com>
Message-ID: <528FDAE8.6070908@oracle.com>

Looks OK to me.

-- Jon


On 11/22/2013 01:52 PM, Robert Field wrote:
> Thanks Jon!
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~rfield/8028739v2/
> <http://cr.openjdk.java.net/%7Erfield/8028739v2/>
>
>
> Again, the only change is to the isSignaturePolymorphic method:
>
> 2121             final boolean isSignaturePolymorphic() {
> 2122                 return_tree.sym.kind == MTH_  &&
> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
> 2124             }
>
>
> -Robert
>
>
> On 11/22/13 12:59, Jonathan Gibbons wrote:
>> Robert,
>>
>> In this code:
>>> 2121             final boolean isSignaturePolymorphic() {
>>> 2122                 return  tree.sym instanceof MethodSymbol &&
>>> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
>>> 2124             }
>> it is not javac style to do instanceof like that -- the normal style is
>> to check the kind, as in
>>        tree.sym.kind == MTH
>>
>> -- Jon
>>
>>
>>
>>
>> On 11/22/2013 10:31 AM, Robert Field wrote:
>>> Thanks John!
>>>
>>> Updated webrev:
>>>
>>> http://cr.openjdk.java.net/~rfield/8028739v1/
>>> <http://cr.openjdk.java.net/%7Erfield/8028739v1/>
>>>
>>> Only change is to use the pre-existing test for signature polymorphic:
>>>
>>> 2121             final boolean isSignaturePolymorphic() {
>>> 2122                 return  tree.sym instanceof MethodSymbol &&
>>> 2123                         types.isSignaturePolymorphic((MethodSymbol)tree.sym);
>>> 2124             }
>>>
>>>
>>> -Robert
>>>
>>>
>>> On 11/21/13 22:55, John Rose wrote:
>>>> I think you will get a false positive on MethodHandle.invokeWithArguments.
>>>>
>>>> There are more precise tests for sig. polymorphism. It must be native final; the code should check for that.
>>>>
>>>> -- John  (on my iPhone)
>>>>
>>>> On Nov 21, 2013, at 8:21 PM, Robert Field <robert.field at oracle.com> wrote:
>>>>
>>>>> Please review fix for:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8028739
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~rfield/8028739v0/
>>>>> <http://cr.openjdk.java.net/%7Erfield/8028739v0/>
>>>>>
>>>>> Thank you,
>>>>> Robert
>>>>>
>>>>>
>


From richard.warburton at gmail.com  Fri Nov 22 16:50:04 2013
From: richard.warburton at gmail.com (Richard Warburton)
Date: Sat, 23 Nov 2013 00:50:04 +0000
Subject: @FunctionalInterface implications
Message-ID: <CAMaYbv+oeWCuDo6cFbRChy5AtEa9P+aUss+wcJdC3FO7pbtbvQ@mail.gmail.com>

Hi,

If the intent of an interface marked with @FunctionalInterface is to be
used as such then should it ever be extended by another interface?

I appreciate there are probably enough complex interactions that generating
a compile error if this happens would be too restrictive but what about
'morally' or as a guideline?

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>

From brian.goetz at oracle.com  Fri Nov 22 17:32:32 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 22 Nov 2013 20:32:32 -0500
Subject: @FunctionalInterface implications
In-Reply-To: <CAMaYbv+oeWCuDo6cFbRChy5AtEa9P+aUss+wcJdC3FO7pbtbvQ@mail.gmail.com>
References: <CAMaYbv+oeWCuDo6cFbRChy5AtEa9P+aUss+wcJdC3FO7pbtbvQ@mail.gmail.com>
Message-ID: <529005B0.5080307@oracle.com>

Function is extended by BinaryOperator, also a functional interface, 
which specializes its type parameters.  I think that's a fine pattern.

More generally, its perfectly fine for an interface to extend a 
functional interface but not itself be a functional interface.  See 
Node.Builder inside the Stream package, for example.

On 11/22/2013 7:50 PM, Richard Warburton wrote:
> Hi,
>
> If the intent of an interface marked with @FunctionalInterface is to be
> used as such then should it ever be extended by another interface?
>
> I appreciate there are probably enough complex interactions that generating
> a compile error if this happens would be too restrictive but what about
> 'morally' or as a guideline?
>
> regards,
>
>    Richard Warburton
>
>    http://insightfullogic.com
>    @RichardWarburto <http://twitter.com/richardwarburto>
>

From kevinb at google.com  Fri Nov 22 19:05:31 2013
From: kevinb at google.com (Kevin Bourrillion)
Date: Fri, 22 Nov 2013 22:05:31 -0500
Subject: @FunctionalInterface implications
In-Reply-To: <529005B0.5080307@oracle.com>
References: <CAMaYbv+oeWCuDo6cFbRChy5AtEa9P+aUss+wcJdC3FO7pbtbvQ@mail.gmail.com>
	<529005B0.5080307@oracle.com>
Message-ID: <CAGKkBkv-SSU8W0GXLpgoZk9CQA6tzD8Y650m_XiyukVVsiH2dQ@mail.gmail.com>

Another example: Guava's Predicate, Function, etc. will probably have to
extend their JDK counterparts as a partially-helpful transitional measure,
for who knows how long before they can be removed.


On Fri, Nov 22, 2013 at 8:32 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Function is extended by BinaryOperator, also a functional interface,
> which specializes its type parameters.  I think that's a fine pattern.
>
> More generally, its perfectly fine for an interface to extend a
> functional interface but not itself be a functional interface.  See
> Node.Builder inside the Stream package, for example.
>
> On 11/22/2013 7:50 PM, Richard Warburton wrote:
> > Hi,
> >
> > If the intent of an interface marked with @FunctionalInterface is to be
> > used as such then should it ever be extended by another interface?
> >
> > I appreciate there are probably enough complex interactions that
> generating
> > a compile error if this happens would be too restrictive but what about
> > 'morally' or as a guideline?
> >
> > regards,
> >
> >    Richard Warburton
> >
> >    http://insightfullogic.com
> >    @RichardWarburto <http://twitter.com/richardwarburto>
> >
>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

From forax at univ-mlv.fr  Sat Nov 23 03:17:53 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 23 Nov 2013 12:17:53 +0100
Subject: @FunctionalInterface implications
In-Reply-To: <529005B0.5080307@oracle.com>
References: <CAMaYbv+oeWCuDo6cFbRChy5AtEa9P+aUss+wcJdC3FO7pbtbvQ@mail.gmail.com>
	<529005B0.5080307@oracle.com>
Message-ID: <52908EE1.4070903@univ-mlv.fr>

On 11/23/2013 02:32 AM, Brian Goetz wrote:
> Function is extended by BinaryOperator, also a functional interface,
> which specializes its type parameters.  I think that's a fine pattern.

Brian,
I don't want to restart the thread about the naming of UnaryOperator and 
BinaryOperator,
but  BinaryOperator is a BiFunction not a Function, UnaryOperator is a 
Function.

BTW I've recently discover something weird, Function.identity() should 
return a UnaryOperator<T> and not a Function<T,T> which can be seen as 
an hint of the fact that having two interfaces for something so similar 
is not a good idea.

I think we have missed a point when we have discussed about naming, the 
real question is why UnaryOperator and BinaryOperator exist, from now, 
they does not seem to worth their weight (naming, specialization, etc) ?

R?mi

>
> More generally, its perfectly fine for an interface to extend a
> functional interface but not itself be a functional interface.  See
> Node.Builder inside the Stream package, for example.
>
> On 11/22/2013 7:50 PM, Richard Warburton wrote:
>> Hi,
>>
>> If the intent of an interface marked with @FunctionalInterface is to be
>> used as such then should it ever be extended by another interface?
>>
>> I appreciate there are probably enough complex interactions that generating
>> a compile error if this happens would be too restrictive but what about
>> 'morally' or as a guideline?
>>
>> regards,
>>
>>     Richard Warburton
>>
>>     http://insightfullogic.com
>>     @RichardWarburto <http://twitter.com/richardwarburto>
>>


From anna.kozlova at jetbrains.com  Sun Nov 24 02:23:06 2013
From: anna.kozlova at jetbrains.com (Anna Kozlova)
Date: Sun, 24 Nov 2013 11:23:06 +0100
Subject: well-formed type in 18.5.3
Message-ID: <00ca01cee8ff$2af1d780$80d58680$@kozlova@jetbrains.com>

Hi,

 

18.5.3 Functional Interface Parameterization Interface uses the term
well-formed type but seems that it was not defined anywhere.

 

Thanks,

Anna


From bitterfoxc at gmail.com  Mon Nov 25 21:32:33 2013
From: bitterfoxc at gmail.com (bitter_fox)
Date: Tue, 26 Nov 2013 14:32:33 +0900
Subject: javac produces a compile error for valid java 7 codes: Cast vs
	Boolean Expression
Message-ID: <CAHjBcHNyvcxyGZVEqzXAvuqo8JEf313zWUvYb2uCabS76DRoGQ@mail.gmail.com>

Hi,
I found a javac bug.

Javac reject valid java 7 codes:

public class Test
{
    static int a, b, c, d;

    public static void main(String[] args)
    {
        boolean cond = (a < b & c > d);

        /*
      JavacParser#analyzeParens
          LPAREN
          IDENT(a) : skip
          LT : depth = 1
          IDENT(b) : skip
          AMP : skip
          IDENT(c) : skip
          GT : depth = 0 -> type = true
          IDENT(d) : skip
          RPAREN : type == true -> return ParensResult.CAST
        */
    }
}

This is a simple parened boolean expression.
But javac(JavacParser#analyzeParens) analyzes it into CAST expression from
above.

Today's JavacParser#analyzeParens take no thought that intersection type
for type parameter isn't accepted.

You should change JavacParser#analyzeParens like following.

--- a/src/share/classes/com/sun/tools/javac/parser/JavacParser.java     Mon
Nov 11 23:16:35 2013 -0800
+++ b/src/share/classes/com/sun/tools/javac/parser/JavacParser.java     Tue
Nov 26 14:27:43 2013 +0900
@@ -1536,7 +1536,14 @@
             switch (tk) {
                 case COMMA:
                     type = true;
-                case EXTENDS: case SUPER: case DOT: case AMP:
+                    break;
+                case AMP:
+                    if (depth > 0) {
+                        // < ... & -> parens
+                        // (for type parameter, intersection type isn't
accepted)
+                        return ParensResult.PARENS;
+                    }
+                case EXTENDS: case SUPER: case DOT:
                     //skip
                     break;
                 case QUES:

Regards,
bitter_fox

From vicente.romero at oracle.com  Tue Nov 26 06:48:18 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 26 Nov 2013 14:48:18 +0000
Subject: javac produces a compile error for valid java 7 codes: Cast vs
	Boolean Expression
In-Reply-To: <CAHjBcHNyvcxyGZVEqzXAvuqo8JEf313zWUvYb2uCabS76DRoGQ@mail.gmail.com>
References: <CAHjBcHNyvcxyGZVEqzXAvuqo8JEf313zWUvYb2uCabS76DRoGQ@mail.gmail.com>
Message-ID: <5294B4B2.8050206@oracle.com>

Hi bitter_fox,

Thanks for your bug report, I have filed bug entry [1] to track it,

Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8029179

On 26/11/13 05:32, bitter_fox wrote:
> Hi,
> I found a javac bug.
>
> Javac reject valid java 7 codes:
>
> public class Test
> {
>      static int a, b, c, d;
>
>      public static void main(String[] args)
>      {
>          boolean cond = (a < b & c > d);
>
>          /*
>        JavacParser#analyzeParens
>            LPAREN
>            IDENT(a) : skip
>            LT : depth = 1
>            IDENT(b) : skip
>            AMP : skip
>            IDENT(c) : skip
>            GT : depth = 0 -> type = true
>            IDENT(d) : skip
>            RPAREN : type == true -> return ParensResult.CAST
>          */
>      }
> }
>
> This is a simple parened boolean expression.
> But javac(JavacParser#analyzeParens) analyzes it into CAST expression from
> above.
>
> Today's JavacParser#analyzeParens take no thought that intersection type
> for type parameter isn't accepted.
>
> You should change JavacParser#analyzeParens like following.
>
> --- a/src/share/classes/com/sun/tools/javac/parser/JavacParser.java     Mon
> Nov 11 23:16:35 2013 -0800
> +++ b/src/share/classes/com/sun/tools/javac/parser/JavacParser.java     Tue
> Nov 26 14:27:43 2013 +0900
> @@ -1536,7 +1536,14 @@
>               switch (tk) {
>                   case COMMA:
>                       type = true;
> -                case EXTENDS: case SUPER: case DOT: case AMP:
> +                    break;
> +                case AMP:
> +                    if (depth > 0) {
> +                        // < ... & -> parens
> +                        // (for type parameter, intersection type isn't
> accepted)
> +                        return ParensResult.PARENS;
> +                    }
> +                case EXTENDS: case SUPER: case DOT:
>                       //skip
>                       break;
>                   case QUES:
>
> Regards,
> bitter_fox
>


From mohan.radhakrishnan at polarisFT.com  Tue Nov 26 22:27:48 2013
From: mohan.radhakrishnan at polarisFT.com (mohan.radhakrishnan at polarisFT.com)
Date: Wed, 27 Nov 2013 11:57:48 +0530
Subject: Basic functional style question
Message-ID: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FCE@polarisft.com>

Hi,

This is a question from a user. I am trying to jdk 8 to parse a file and 
apply a regex on it.

public class GCLogParser {

    private void readFile() throws IOException {

        Stream<String> s = Files.lines(get(("D:\\GC 
Analysis\\usage.txt")), UTF_8);
        s.forEach( this::parse  );
    }

    public static void parseDocument(  Parseable parser,
 String data){
        parser.apply(data);
    }
    private void parse( String data ){

        Scanner s = new Scanner( data );
        s.findInLine("Current.*?[/|]");
        System.out.println(s.match().group());
    }

    public static void main( String... argv ) throws IOException {
        new GCLogParser().readFile();
    }

    @FunctionalInterface
    public interface Parseable{
         void apply( String s);
    }
}


This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com

From mohan.radhakrishnan at polarisFT.com  Tue Nov 26 22:38:33 2013
From: mohan.radhakrishnan at polarisFT.com (mohan.radhakrishnan at polarisFT.com)
Date: Wed, 27 Nov 2013 12:08:33 +0530
Subject: Basic functional style question
In-Reply-To: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FB0@LocalDomain>
References: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FB0@LocalDomain>
Message-ID: <OFB946AEEA.491D0FE2-ON65257C30.0023A4D9-65257C30.00247BA9@polarisft.com>

Sent by mistake. The actual question is this.

The code in the previous mail works but when I use 'R' language this is 
accomplished by this line.

y <- apply( y, 1, function(z) str_extract(z,"Current.*?[/|]"))

I can again operate on the data structure like this.

z <- str_extract_all(y,"[0-9]+(/,|/|)")

I think this is possible using Streams and filters.

How should I use these lines without defining new Functional interfaces ?

        Scanner s = new Scanner( data );
        s.findInLine("Current.*?[/|]");
        System.out.println(s.match().group());

Thanks.



From:   Mohan Radhakrishnan/BSC31/polarisFT
To:     lambda-dev at openjdk.java.net
Date:   11/27/2013 11:57 AM
Subject:        Basic functional style question


Hi,

This is a question from a user. I am trying to jdk 8 to parse a file and 
apply a regex on it.

public class GCLogParser {

    private void readFile() throws IOException {

        Stream<String> s = Files.lines(get(("D:\\GC 
Analysis\\usage.txt")), UTF_8);
        s.forEach( this::parse  );
    }

    public static void parseDocument(  Parseable parser,
 String data){
        parser.apply(data);
    }
    private void parse( String data ){

        Scanner s = new Scanner( data );
        s.findInLine("Current.*?[/|]");
        System.out.println(s.match().group());
    }

    public static void main( String... argv ) throws IOException {
        new GCLogParser().readFile();
    }

    @FunctionalInterface
    public interface Parseable{
         void apply( String s);
    }
}



This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com

From stuart.marks at oracle.com  Wed Nov 27 00:17:38 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 27 Nov 2013 00:17:38 -0800
Subject: Basic functional style question
In-Reply-To: <OFB946AEEA.491D0FE2-ON65257C30.0023A4D9-65257C30.00247BA9@polarisft.com>
References: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FB0@LocalDomain>
	<OFB946AEEA.491D0FE2-ON65257C30.0023A4D9-65257C30.00247BA9@polarisft.com>
Message-ID: <5295AAA2.4060409@oracle.com>

I started scratching this out and I got a sense of d?j? vu, and then I realized 
Kirk Pepperdine recently wrote a blog post last week about using lambda to parse 
and pattern match GC logs. Were you at his talk at ?redev?

https://weblogs.java.net/blog/kcpeppe/archive/2013/11/10/fun-lambdas

The approach he ended up with (with help from Brian Goetz), applied to your 
example, would look something like this:

     Pattern pat = Pattern.compile("Current.*?[/|]");
     Files.lines(Paths.get(...))
          .map(pat::matcher)
          .filter(Matcher::find)
          .map(Matcher::group)
          .forEach(System.out::println);

Note this uses Pattern and Matcher instead of Scanner, as they're more flexible.

The insight is to map each input string to a Matcher so that midway through the 
pipeline we have Stream<Matcher>. We then filter the matchers to get only the 
successful ones, and then extract the matched string from them.

Does this do what you want?

s'marks

On 11/26/13 10:38 PM, mohan.radhakrishnan at polarisft.com wrote:
> Sent by mistake. The actual question is this.
>
> The code in the previous mail works but when I use 'R' language this is
> accomplished by this line.
>
> y <- apply( y, 1, function(z) str_extract(z,"Current.*?[/|]"))
>
> I can again operate on the data structure like this.
>
> z <- str_extract_all(y,"[0-9]+(/,|/|)")
>
> I think this is possible using Streams and filters.
>
> How should I use these lines without defining new Functional interfaces ?
>
>          Scanner s = new Scanner( data );
>          s.findInLine("Current.*?[/|]");
>          System.out.println(s.match().group());
>
> Thanks.
>
>
>
> From:   Mohan Radhakrishnan/BSC31/polarisFT
> To:     lambda-dev at openjdk.java.net
> Date:   11/27/2013 11:57 AM
> Subject:        Basic functional style question
>
>
> Hi,
>
> This is a question from a user. I am trying to jdk 8 to parse a file and
> apply a regex on it.
>
> public class GCLogParser {
>
>      private void readFile() throws IOException {
>
>          Stream<String> s = Files.lines(get(("D:\\GC
> Analysis\\usage.txt")), UTF_8);
>          s.forEach( this::parse  );
>      }
>
>      public static void parseDocument(  Parseable parser,
>   String data){
>          parser.apply(data);
>      }
>      private void parse( String data ){
>
>          Scanner s = new Scanner( data );
>          s.findInLine("Current.*?[/|]");
>          System.out.println(s.match().group());
>      }
>
>      public static void main( String... argv ) throws IOException {
>          new GCLogParser().readFile();
>      }
>
>      @FunctionalInterface
>      public interface Parseable{
>           void apply( String s);
>      }
> }
>
>
>
> This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>

From mohan.radhakrishnan at polarisFT.com  Wed Nov 27 02:47:42 2013
From: mohan.radhakrishnan at polarisFT.com (mohan.radhakrishnan at polarisFT.com)
Date: Wed, 27 Nov 2013 16:17:42 +0530
Subject: Basic functional style question
In-Reply-To: <5295AAA2.4060409@oracle.com>
References: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FB0@LocalDomain>
	<OFB946AEEA.491D0FE2-ON65257C30.0023A4D9-65257C30.00247BA9@polarisft.com>
	<5295AAA2.4060409@oracle.com>
Message-ID: <OFBB1836EA.0B173D69-ON65257C30.0039E334-65257C30.003B49E4@polarisft.com>

Yes. Thanks Stuart. 

I also have these questions.

1. How do I apply a large number of regex patterns one by one in the same 
pipeline ? When is a new functional interface needed ?

2.  function(){
        return (data$V1[ grep ("(.*)Full GC(.*)", data[,1])])
     }

     Is there a way to do this ? This R code uses code to change values in 
a data structure in-place. Code and data are together here.

Mohan




From:   Stuart Marks <stuart.marks at oracle.com>
To:     mohan.radhakrishnan at polarisft.com, lambda-dev at openjdk.java.net
Date:   11/27/2013 01:46 PM
Subject:        Re: Basic functional style question



I started scratching this out and I got a sense of d?j? vu, and then I 
realized 
Kirk Pepperdine recently wrote a blog post last week about using lambda to 
parse 
and pattern match GC logs. Were you at his talk at ?redev?

https://weblogs.java.net/blog/kcpeppe/archive/2013/11/10/fun-lambdas

The approach he ended up with (with help from Brian Goetz), applied to 
your 
example, would look something like this:

     Pattern pat = Pattern.compile("Current.*?[/|]");
     Files.lines(Paths.get(...))
          .map(pat::matcher)
          .filter(Matcher::find)
          .map(Matcher::group)
          .forEach(System.out::println);

Note this uses Pattern and Matcher instead of Scanner, as they're more 
flexible.

The insight is to map each input string to a Matcher so that midway 
through the 
pipeline we have Stream<Matcher>. We then filter the matchers to get only 
the 
successful ones, and then extract the matched string from them.

Does this do what you want?

s'marks

On 11/26/13 10:38 PM, mohan.radhakrishnan at polarisft.com wrote:
> Sent by mistake. The actual question is this.
>
> The code in the previous mail works but when I use 'R' language this is
> accomplished by this line.
>
> y <- apply( y, 1, function(z) str_extract(z,"Current.*?[/|]"))
>
> I can again operate on the data structure like this.
>
> z <- str_extract_all(y,"[0-9]+(/,|/|)")
>
> I think this is possible using Streams and filters.
>
> How should I use these lines without defining new Functional interfaces 
?
>
>          Scanner s = new Scanner( data );
>          s.findInLine("Current.*?[/|]");
>          System.out.println(s.match().group());
>
> Thanks.
>
>
>
> From:   Mohan Radhakrishnan/BSC31/polarisFT
> To:     lambda-dev at openjdk.java.net
> Date:   11/27/2013 11:57 AM
> Subject:        Basic functional style question
>
>
> Hi,
>
> This is a question from a user. I am trying to jdk 8 to parse a file and
> apply a regex on it.
>
> public class GCLogParser {
>
>      private void readFile() throws IOException {
>
>          Stream<String> s = Files.lines(get(("D:\\GC
> Analysis\\usage.txt")), UTF_8);
>          s.forEach( this::parse  );
>      }
>
>      public static void parseDocument(  Parseable parser,
>   String data){
>          parser.apply(data);
>      }
>      private void parse( String data ){
>
>          Scanner s = new Scanner( data );
>          s.findInLine("Current.*?[/|]");
>          System.out.println(s.match().group());
>      }
>
>      public static void main( String... argv ) throws IOException {
>          new GCLogParser().readFile();
>      }
>
>      @FunctionalInterface
>      public interface Parseable{
>           void apply( String s);
>      }
> }
>
>
>
> This e-Mail may contain proprietary and confidential information and is 
sent for the intended recipient(s) only.  If by an addressing or 
transmission error this mail has been misdirected to you, you are 
requested to delete this mail immediately. You are also hereby notified 
that any use, any form of reproduction, dissemination, copying, 
disclosure, modification, distribution and/or publication of this e-mail 
message, contents or its attachment other than by its intended recipient/s 
is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>




This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com

From paul.sandoz at oracle.com  Wed Nov 27 03:31:21 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 27 Nov 2013 12:31:21 +0100
Subject: Basic functional style question
In-Reply-To: <OFBB1836EA.0B173D69-ON65257C30.0039E334-65257C30.003B49E4@polarisft.com>
References: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FB0@LocalDomain>
	<OFB946AEEA.491D0FE2-ON65257C30.0023A4D9-65257C30.00247BA9@polarisft.com>
	<5295AAA2.4060409@oracle.com>
	<OFBB1836EA.0B173D69-ON65257C30.0039E334-65257C30.003B49E4@polarisft.com>
Message-ID: <2E9FA8B6-36D7-4B41-AC2F-9FB1ADE3117C@oracle.com>


On Nov 27, 2013, at 11:47 AM, mohan.radhakrishnan at polarisft.com wrote:

> Yes. Thanks Stuart. 
> 
> I also have these questions.
> 
> 1. How do I apply a large number of regex patterns one by one in the same 
> pipeline ? When is a new functional interface needed ?
> 

Do you want to fork the stream of lines into N separate stream of lines each mapping/filtering using a separate regex?


> 2.  function(){
>        return (data$V1[ grep ("(.*)Full GC(.*)", data[,1])])
>     }
> 
>     Is there a way to do this ? This R code uses code to change values in 
> a data structure in-place. Code and data are together here.
> 

Structural modifications to the source should not be made during executing of the pipeline, otherwise it will lead to either a ConcurrentModificationException or undefined results. 

In place modifications, like the above, might be possible depending on the source, such as an array, but you really need to be careful and know what you are doing e.g. using a forEach with side-effects such that those side-effects are safe under concurrent operation. 

Trying to do this in anything other than forEach is asking for trouble and going against the rules that function values passed to operations should be stateless and not have side-effects (or more specifically side-effects that may effect results, but in general it is best to try and always avoid side-effects).

Hth,
Paul.

From mohan.radhakrishnan at polarisFT.com  Wed Nov 27 04:08:44 2013
From: mohan.radhakrishnan at polarisFT.com (mohan.radhakrishnan at polarisFT.com)
Date: Wed, 27 Nov 2013 17:38:44 +0530
Subject: Basic functional style question
In-Reply-To: <2E9FA8B6-36D7-4B41-AC2F-9FB1ADE3117C@oracle.com>
References: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FB0@LocalDomain>	<OFB946AEEA.491D0FE2-ON65257C30.0023A4D9-65257C30.00247BA9@polarisft.com>
	<5295AAA2.4060409@oracle.com>	<OFBB1836EA.0B173D69-ON65257C30.0039E334-65257C30.003B49E4@polarisft.com>
	<2E9FA8B6-36D7-4B41-AC2F-9FB1ADE3117C@oracle.com>
Message-ID: <OF63A0EF30.24E911B0-ON65257C30.00417D89-65257C30.0042B4FB@polarisft.com>

Not a fork. I used to filter 'Full GC' lines and then apply a pattern to 
filter the times and then get the sizes of memory pools. How is this done 
if I have several regex patterns ?
The pipeline could be long.

I have seen that array initializers use lambdas. So I thought that an 
array/ArrayList of values can be filtered in-place by applying a function 
assuming no concurrency is required. 


Thanks. 
Mohan



From:   Paul Sandoz <paul.sandoz at oracle.com>
To: 
Cc:     lambda-dev at openjdk.java.net
Date:   11/27/2013 05:03 PM
Subject:        Re: Basic functional style question
Sent by:        lambda-dev-bounces at openjdk.java.net




On Nov 27, 2013, at 11:47 AM, mohan.radhakrishnan at polarisft.com wrote:

> Yes. Thanks Stuart. 
> 
> I also have these questions.
> 
> 1. How do I apply a large number of regex patterns one by one in the 
same 
> pipeline ? When is a new functional interface needed ?
> 

Do you want to fork the stream of lines into N separate stream of lines 
each mapping/filtering using a separate regex?


> 2.  function(){
>        return (data$V1[ grep ("(.*)Full GC(.*)", data[,1])])
>     }
> 
>     Is there a way to do this ? This R code uses code to change values 
in 
> a data structure in-place. Code and data are together here.
> 

Structural modifications to the source should not be made during executing 
of the pipeline, otherwise it will lead to either a 
ConcurrentModificationException or undefined results. 

In place modifications, like the above, might be possible depending on the 
source, such as an array, but you really need to be careful and know what 
you are doing e.g. using a forEach with side-effects such that those 
side-effects are safe under concurrent operation. 

Trying to do this in anything other than forEach is asking for trouble and 
going against the rules that function values passed to operations should 
be stateless and not have side-effects (or more specifically side-effects 
that may effect results, but in general it is best to try and always avoid 
side-effects).

Hth,
Paul.





This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com

From paul.sandoz at oracle.com  Wed Nov 27 04:34:48 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 27 Nov 2013 13:34:48 +0100
Subject: Basic functional style question
In-Reply-To: <OF63A0EF30.24E911B0-ON65257C30.00417D89-65257C30.0042B4FB@polarisft.com>
References: <OF2881C205.53EFB025-ON65257C30.0022A25E-65257C30.00237FB0@LocalDomain>	<OFB946AEEA.491D0FE2-ON65257C30.0023A4D9-65257C30.00247BA9@polarisft.com>
	<5295AAA2.4060409@oracle.com>	<OFBB1836EA.0B173D69-ON65257C30.0039E334-65257C30.003B49E4@polarisft.com>
	<2E9FA8B6-36D7-4B41-AC2F-9FB1ADE3117C@oracle.com>
	<OF63A0EF30.24E911B0-ON65257C30.00417D89-65257C30.0042B4FB@polarisft.com>
Message-ID: <1348FFC0-A95E-489E-AA04-77FED1B03B17@oracle.com>


On Nov 27, 2013, at 1:08 PM, mohan.radhakrishnan at polarisFT.com wrote:

> Not a fork. I used to filter 'Full GC' lines and then apply a pattern to 
> filter the times and then get the sizes of memory pools. How is this done 
> if I have several regex patterns ?
> The pipeline could be long.
> 

There are a couple of options:

- abstract out the creation of the sub-stream pipeline as a bi-function of Pattern,Stream -> Stream

Stream<String> s = ...
BiFunction<Pattern, Stream<String>, Stream<String>> f = ...
for (Pattern p : ps) {
  s = s.apply(p, s);  

- use flatMap, which can be used as a combined filter+map.


> I have seen that array initializers use lambdas.

Yes, but you still have to be careful if you want to do in-place updates, as the functions passed, to say setAll, will have side-effects as they are are not "pure" functions whose result depends solely on what is input.


> So I thought that an 
> array/ArrayList of values can be filtered in-place by applying a function 
> assuming no concurrency is required. 
> 

Yes, as i said it depends on the source and you need to be careful.

Given that we don't have indexed-based streams a common pattern when operating on arrays is to create an IntStream over the range of indexes of the array

Paul.

From Sebastian.Millies at softwareag.com  Thu Nov 28 02:24:04 2013
From: Sebastian.Millies at softwareag.com (Millies, Sebastian)
Date: Thu, 28 Nov 2013 10:24:04 +0000
Subject: Parallel processing of lines ina file (was RE: Basic functional
	style question)
Message-ID: <32F15738E8E5524DA4F01A0FA4A8E490C2FF5BDD@HQMBX5.eur.ad.sag>

Hello there,

Assuming very large log files, how well does that approach parallelize?
Can/should I use  "Files.lines(path).parallel()" ?

I assume that the JRE would buffer blocks of lines in an array, the elements of which would then
be processed in parallel. Is that right? Is there any way to tweak the buffer size etc.? And will the next
block be read in parallel to processing the previous one, or after processing of each block has finished?

-- Sebastian

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Stuart Marks
Sent: Wednesday, November 27, 2013 9:18 AM
To: mohan.radhakrishnan at polarisft.com; lambda-dev at openjdk.java.net
Subject: Re: Basic functional style question

I started scratching this out and I got a sense of d?j? vu, and then I realized Kirk Pepperdine recently wrote a blog post last week about using lambda to parse and pattern match GC logs. Were you at his talk at ?redev?

https://weblogs.java.net/blog/kcpeppe/archive/2013/11/10/fun-lambdas

The approach he ended up with (with help from Brian Goetz), applied to your example, would look something like this:

     Pattern pat = Pattern.compile("Current.*?[/|]");
     Files.lines(Paths.get(...))
          .map(pat::matcher)
          .filter(Matcher::find)
          .map(Matcher::group)
          .forEach(System.out::println);

Note this uses Pattern and Matcher instead of Scanner, as they're more flexible.

The insight is to map each input string to a Matcher so that midway through the pipeline we have Stream<Matcher>. We then filter the matchers to get only the successful ones, and then extract the matched string from them.

Does this do what you want?

s'marks

Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From paul.sandoz at oracle.com  Thu Nov 28 02:52:36 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 28 Nov 2013 11:52:36 +0100
Subject: Parallel processing of lines ina file (was RE: Basic functional
	style question)
In-Reply-To: <32F15738E8E5524DA4F01A0FA4A8E490C2FF5BDD@HQMBX5.eur.ad.sag>
References: <32F15738E8E5524DA4F01A0FA4A8E490C2FF5BDD@HQMBX5.eur.ad.sag>
Message-ID: <15E7B97B-DB57-4522-826B-3A67379E18BA@oracle.com>

Hi,

On Nov 28, 2013, at 11:24 AM, "Millies, Sebastian" <Sebastian.Millies at softwareag.com> wrote:

> Hello there,
> 
> Assuming very large log files, how well does that approach parallelize?
> Can/should I use  "Files.lines(path).parallel()" ?
> 

You can, but you might want to measure. Since the log is very large there is a good chance of some speed up, especially so if the cost of processing an element through the pipeline is high, but may also depend on the terminal operation and whether order is important or not.


> I assume that the JRE would buffer blocks of lines in an array, the elements of which would then
> be processed in parallel. Is that right?

Yes.


> Is there any way to tweak the buffer size etc.?

No, unless you write your own Spliterator (see below).


> And will the next
> block be read in parallel to processing the previous one, or after processing of each block has finished?
> 

In parallel, with only at most one thread copying lines into an array.

The problem can be reduced to splitting from an Iterator. Splitting will copy a prefix of elements from the Iterator into an array and return a Spliterator wrapping that array. Here is some internal documentation from one of the Spltierator from Iterator implementations:

            /*
             * Split into arrays of arithmetically increasing batch
             * sizes.  This will only improve parallel performance if
             * per-element Consumer actions are more costly than
             * transferring them into an array.  The use of an
             * arithmetic progression in split sizes provides overhead
             * vs parallelism bounds that do not particularly favor or
             * penalize cases of lightweight vs heavyweight element
             * operations, across combinations of #elements vs #cores,
             * whether or not either are known.  We generate
             * O(sqrt(#elements)) splits, allowing O(sqrt(#cores))
             * potential speedup.
             */

The initial batch size is 1024 and increases arithmetically by 1024 for each split. Originally the initial size was 1 and the size increased arithmetically by 1, but this created much larger right-balanced trees that unduly affected the performance of reduction operations. Note that many collection implementations also use this technique (such as LinkedList or ConcurrentLinkedQueue).

So if you have less than <= 1024 elements you are unfortunately out of luck and are not gonna observe any speed up. We could improve matters here if we know the size of the input (which for processing lines is likely not to be the case, but will be for LinkedList) or in the future expose some control over the arithmetic progression. The smaller the size the higher the cost of per-element-processing will need to be. In general it is a very tricky problem to automate.

Paul.

From paul.sandoz at oracle.com  Fri Nov 29 02:34:28 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 29 Nov 2013 11:34:28 +0100
Subject: Forked streams
Message-ID: <40ACB28A-8047-4827-941F-2FEB40A7EA3F@oracle.com>

Hi,

Recently on this list Stuart mentioned Kirk's blog entry on lambdas, which has some discussion on forked streams:

https://weblogs.java.net/blog/kcpeppe/archive/2013/11/10/fun-lambdas

To get across the issues and have a little fun i wrote a simple stream forker.

The basic approach is to create a recipe to fork a stream multiple times, apply that recipe to a stream, and collect the results. The results of each fork are encapsulated in instances of CompletableFuture. Each fork is executed asynchronously. The stream to fork is operated on using forEach with a consumer that pushes an element to each fork via a LinkedBlockingQueue. A forked stream's source is a special Spliterator covering the elements of the associated LinkedBlockingQueue.

It's not very complicated, quite rough, and i am sure just one of many ways if doing this, but it does highlight the complexities/issues here.

What does it mean for parallel streams? If a parallel forEach is performed on the stream to be forked that means elements will be pushed to the forked streams out of order. Resources for parallel execution of a stream will complete with concurrent execution of the forked streams, which may complication the performance characteristics.

Each fork represents a separate computation, which may be formulated differently for parallel execution. The computation of toArray is different to that of findFirst.

I can think of improvements to the current API that could enable better sequential forking, but for parallel forking it will be particularly tricky to fork the whole computation across thread boundaries and a questionable endeavour IMHO. 

So in general this can be complex, there are different models of execution competing for attention, and streams has currently opted for a simpler model that is easy to grok that with a bit of work can be utilized with forking if one is careful. There are probably ways we could improve that for any further streams work, perhaps with an SPI supporting user-defined operations where one could write a fork operation that behaves like a hybrid intermediate/terminal operation. 

Anyway, that's all speculation right now; hope some people find this a fun exercise too.

Paul.

package stream.fork;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Optional;
import java.util.Spliterator;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.function.Consumer;
import java.util.function.Function;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
import java.util.stream.Stream;
import java.util.stream.StreamSupport;

public class ForkExample {

    public static void main(String[] args) throws Exception {
        // Set up the forks
        StreamForker<String> forker = new StreamForker<>();
        StreamForker.Memento<String> mr1 = forker.addFork(
                s -> s.map(String::toUpperCase).collect(Collectors.joining()));
        StreamForker.Memento<Integer> mr2 = forker.addFork(
                s -> s.mapToInt(Integer::valueOf).sum());
        StreamForker.Memento<Map<Integer, Long>> mr3 = forker.addFork(
                s -> s.collect(Collectors.groupingBy(String::length, Collectors.counting())));
        StreamForker.Memento<Optional<String>> mr4 = forker.addFork(
                s -> s.skip(10).findFirst());

        // Fork an existing stream 4 times
        Stream<String> p = IntStream.range(0, 100).mapToObj(Integer::toString);
        ForkedStreamResults rs = forker.fork(p);

        // Wait for all forks to complete
        rs.all().join();

        // Get the results of each fork
        CompletableFuture<String> r1 = rs.get(mr1);
        CompletableFuture<Integer> r2 = rs.get(mr2);
        CompletableFuture<Map<Integer, Long>> r3 = rs.get(mr3);
        CompletableFuture<Optional<String>> r4 = rs.get(mr4);
        System.out.println(r1.get());
        System.out.println(r2.get());
        System.out.println(r3.get());
        System.out.println(r4.get());
    }

    /**
     * A forker of streams
     *
     * @param <T> the type of elements output from the forked stream.
     */
    public static class StreamForker<T> {

        /**
         * A memento to a fork
         *
         * @param <R> the type of result of the fork
         */
        static class Memento<R> {
        }

        private Map<Memento<?>, Function<Stream<T>, ?>> forks = new HashMap<>();

        /**
         * Add a fork
         *
         * @param f the fork function to apply to a forked stream. The stream is
         * forked, and the function is applied to that forked stream to produce
         * a result.
         * @param <R> the type of result of the fork
         * @return a typed memento associated with the fork that can be used to
         * obtain the result returned by the fork function
         */
        public <R> Memento<R> addFork(Function<Stream<T>, R> f) {
            Memento<R> m = new Memento<>();
            forks.put(m, f);
            return m;
        }

        /**
         * Fork a stream
         *
         * <p>The stream will be forked N times where N is the number of forks
         * added.
         *
         * @param s the stream to fork
         * @return the results of forking
         */
        public ForkedStreamResults fork(Stream<T> s) {
            // @@@ Obtain the spliterator from the stream so as to
            // get the characteristics that can be passed to the
            // LinkedBlockingQueueSpliterator, then re-create the
            // to-be-forked stream from that Spliterator

            ForkingStreamConsumer<T> consumer = build();
            try {
                // @@@ If the stream is parallel then the encounter order,
                // if any, will not be preserved, in addition the parallel
                // execution will compete with the execution of the forked
                // streams
                s.sequential().forEach(consumer);
            }
            finally {
                consumer.finish();
            }
            return consumer;
        }

        ForkingStreamConsumer<T> build() {
            List<LinkedBlockingQueue<T>> queues = new ArrayList<>();
            Map<Memento<?>, CompletableFuture<?>> actions = new HashMap<>();
            for (Map.Entry<Memento<?>, Function<Stream<T>, ?>> e : forks.entrySet()) {
                LinkedBlockingQueue<T> queue = new LinkedBlockingQueue<>();
                queues.add(queue);

                // Forked representation of the stream
                Stream<T> source = StreamSupport.stream(
                        new LinkedBlockingQueueSpliterator<>(queue), false);
                Function<Stream<T>, ?> f = e.getValue();
                CompletableFuture<?> action = CompletableFuture.supplyAsync(
                        () -> f.apply(source));
                actions.put(e.getKey(), action);
            }

            return new ForkingStreamConsumer<>(queues, actions);
        }
    }

    /**
     * The results of forking a stream
     */
    public static interface ForkedStreamResults {
        /**
         * @return a completable future encapsulating the futures of all forks
         * that is completed when all forks complete.
         */
        public CompletableFuture<Void> all();

        /**
         * Get the completable future encapsulating the result of a fork
         * @param m the memento associated with the fork
         * @param <R> the type of results of the fork
         * @return the completable future encapsulating the result of the fork
         */
        public <R> CompletableFuture<R> get(StreamForker.Memento<R> m);
    }

    static class ForkingStreamConsumer<T> implements Consumer<T>, ForkedStreamResults {
        // Object element marking the end of the stream
        static final Object SENTINAL = new Object();

        private final List<LinkedBlockingQueue<T>> queues;
        private final Map<StreamForker.Memento<?>, CompletableFuture<?>> actions;

        ForkingStreamConsumer(List<LinkedBlockingQueue<T>> queues, Map<StreamForker.Memento<?>,
                CompletableFuture<?>> actions) {
            this.queues = queues;
            this.actions = actions;
        }

        @Override
        public void accept(T t) {
            // @@@ Buffering issues, can barf if queue is full
            // i.e. producer is faster than consumer
            queues.forEach(q -> q.add(t));
        }

        @Override
        public CompletableFuture<Void> all() {
            return CompletableFuture.allOf(
                    actions.values().stream().toArray(CompletableFuture[]::new));
        }

        @Override
        @SuppressWarnings("unchecked")
        public <R> CompletableFuture<R> get(StreamForker.Memento<R> m) {
            return (CompletableFuture<R>) actions.get(m);
        }

        @SuppressWarnings("unchecked")
        void finish() {
            accept((T) SENTINAL);
        }
    }

    static class LinkedBlockingQueueSpliterator<T> implements Spliterator<T> {
        private final LinkedBlockingQueue<T> q;

        private boolean finished;

        LinkedBlockingQueueSpliterator(LinkedBlockingQueue<T> q) {
            this.q = q;
        }

        @Override
        public boolean tryAdvance(Consumer<? super T> action) {
            if (!finished) {
                T t;
                while (true) {
                    try {
                        t = q.take();
                        break;
                    }
                    catch (InterruptedException e) {
                    }
                }

                if (t != ForkingStreamConsumer.SENTINAL) {
                    action.accept(t);
                    return true;
                }

                finished = true;
            }
            return false;
        }

        @Override
        public Spliterator<T> trySplit() {
            // @@@ Support limited splitting, using buffering with say
            // q.drainTo
            return null;
        }

        @Override
        public long estimateSize() {
            // @@@ Support size if known by forking stream
            return 0;
        }

        @Override
        public int characteristics() {
            // @@@ Inherit characters from forking stream
            return 0;
        }
    }
}


From richard.warburton at gmail.com  Fri Nov 29 04:41:33 2013
From: richard.warburton at gmail.com (Richard Warburton)
Date: Fri, 29 Nov 2013 12:41:33 +0000
Subject: Forked streams
In-Reply-To: <40ACB28A-8047-4827-941F-2FEB40A7EA3F@oracle.com>
References: <40ACB28A-8047-4827-941F-2FEB40A7EA3F@oracle.com>
Message-ID: <CAMaYbvKybbvJ1krF5vag=HZVMx6Kv0tyxOcV42srVwQZewt+=g@mail.gmail.com>

Hi,

Recently on this list Stuart mentioned Kirk's blog entry on lambdas, which
> has some discussion on forked streams:
>
> https://weblogs.java.net/blog/kcpeppe/archive/2013/11/10/fun-lambdas
>
> To get across the issues and have a little fun i wrote a simple stream
> forker.
>
> The basic approach is to create a recipe to fork a stream multiple times,
> apply that recipe to a stream, and collect the results. The results of each
> fork are encapsulated in instances of CompletableFuture. Each fork is
> executed asynchronously. The stream to fork is operated on using forEach
> with a consumer that pushes an element to each fork via a
> LinkedBlockingQueue. A forked stream's source is a special Spliterator
> covering the elements of the associated LinkedBlockingQueue.
>
> It's not very complicated, quite rough, and i am sure just one of many
> ways if doing this, but it does highlight the complexities/issues here.
>
> What does it mean for parallel streams? If a parallel forEach is performed
> on the stream to be forked that means elements will be pushed to the forked
> streams out of order. Resources for parallel execution of a stream will
> complete with concurrent execution of the forked streams, which may
> complication the performance characteristics.
>
> Each fork represents a separate computation, which may be formulated
> differently for parallel execution. The computation of toArray is different
> to that of findFirst.
>
> I can think of improvements to the current API that could enable better
> sequential forking, but for parallel forking it will be particularly tricky
> to fork the whole computation across thread boundaries and a questionable
> endeavour IMHO.
>
> So in general this can be complex, there are different models of execution
> competing for attention, and streams has currently opted for a simpler
> model that is easy to grok that with a bit of work can be utilized with
> forking if one is careful. There are probably ways we could improve that
> for any further streams work, perhaps with an SPI supporting user-defined
> operations where one could write a fork operation that behaves like a
> hybrid intermediate/terminal operation.
>

tl;dr whilst the core Java streams library may not be the right place to
support forkable streams, you can use RxJava to get what you want.

Another thing to mention on the front of forkable streams is the RxJava
project which brings reactive programming to the JVM. [0]  They have a
concept called an Observable, that in many ways acts like stream.  The
underlying threading model is quite different though, I won't go into
details but if you're interested in project lambda, then you should also
take a look at RxJava.

They have a way of connecting observables [1] which means elements in one
observable can be multicasted to other observables. The differences in the
underlying implementation between streams and observables mean that while
the idea of multicasting values from one stream into another brings a
series of complications that Paul has outlined, they don't really exist in
RxJava. Which is why I suggest that if you want that feature, maybe RxJava
is the library that you really should be using rather than Streams.

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>

[0] https://github.com/Netflix/RxJava
[1] https://github.com/Netflix/RxJava/wiki/Connectable-Observable-Operators

From paul.sandoz at oracle.com  Fri Nov 29 05:49:31 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 29 Nov 2013 14:49:31 +0100
Subject: Forked streams
In-Reply-To: <CAMaYbvKybbvJ1krF5vag=HZVMx6Kv0tyxOcV42srVwQZewt+=g@mail.gmail.com>
References: <40ACB28A-8047-4827-941F-2FEB40A7EA3F@oracle.com>
	<CAMaYbvKybbvJ1krF5vag=HZVMx6Kv0tyxOcV42srVwQZewt+=g@mail.gmail.com>
Message-ID: <175AAE28-A7FD-4821-860D-DFDE0BE20E73@oracle.com>

On Nov 29, 2013, at 1:41 PM, Richard Warburton <richard.warburton at gmail.com> wrote:
> tl;dr whilst the core Java streams library may not be the right place to support forkable streams, you can use RxJava to get what you want.
> 

Yes, i am glad you brought up RxJava, it's a great example of an alternative streamy API with a different model.


> Another thing to mention on the front of forkable streams is the RxJava project which brings reactive programming to the JVM. [0]  They have a concept called an Observable, that in many ways acts like stream.  The underlying threading model is quite different though, I won't go into details but if you're interested in project lambda, then you should also take a look at RxJava.
> 

Indeed, there is some sophisticated stuff going on underneath, as well as a rich set operations on Observable.


> They have a way of connecting observables [1] which means elements in one observable can be multicasted to other observables. The differences in the underlying implementation between streams and observables mean that while the idea of multicasting values from one stream into another brings a series of complications that Paul has outlined, they don't really exist in RxJava. Which is why I suggest that if you want that feature, maybe RxJava is the library that you really should be using rather than Streams.
> 

Right, pick the API/framework to match the programming model.

Even if the Stream API evolves to support some style of forking [1] or cancellation it is unlikely to ever evolve to support the same model as RxJava.

It would be interesting to explore how Stream and RxJava could be hooked up, or even how RxJava could take advantage of Spliterator.

Paul.

[1] e.g. via an SPI

Stream<String> s = ...
ForkingStream<String> f = s.op(forking());  // terminal op
CompletableFuture<Integer> r = f.pitch(
    s -> s.mapToInt(...).sum());
CompletableFuture<Map<Integer, Long>> r = f.pitch(
    s -> s.collect(Collectors.groupingBy(String::length, Collectors.counting())));
CompletableFuture<Void> all = f.fork();


From anthony.vanelverdinghe at gmail.com  Sat Nov 30 02:05:53 2013
From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe)
Date: Sat, 30 Nov 2013 11:05:53 +0100
Subject: BufferedReader::lines
Message-ID: <5299B881.3040702@gmail.com>

Hi

I have some questions concerning this method's implementation (in b117):

* the Spliterator only has the ORDERED characteristic. Why aren't the 
NONNULL and IMMUTABLE characteristics specified as well?

* this pattern (creating a Stream from an Iterator) seems like a great 
way to implement a Producer-Consumer pattern. When there's inherently 
only 1 producer & 1 consumer: what are the disadvantages of this pattern 
compared to an implementation with 2 Runnables and a BlockingQueue, if any?

PS: some javadoc nitpicking:
"i.e," should be "i.e."

"Any operation on that stream requires reading from the BufferedReader 
after is it closed will cause an UncheckedIOException to be thrown."
should be
"Any operation on that stream that requires reading from the 
BufferedReader after it is closed, will cause an UncheckedIOException to 
be thrown."

Regards, Anthony

From bitterfoxc at gmail.com  Sat Nov 30 20:21:48 2013
From: bitterfoxc at gmail.com (bitter_fox)
Date: Sun, 1 Dec 2013 13:21:48 +0900
Subject: SOfError by Lambda expr in Local Class
Message-ID: <CAHjBcHMqn+05wO7oPrvLsf1hX+f7G98a-qMZn_zo3z4cNAQZCw@mail.gmail.com>

Hi,
When I compile the following code, StackOverflowError occur.

public class Main
{
    interface F {void f();}

    public static void main(String[] args)
    {
        class Local
        {
            public Local()
            {
                F f = () -> new Local();
            }
        }
    }
}

It may be a cause that
c.s.t.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor#capturelocalClassDefs
is called recursively.

            void captureLocalClassDefs(Symbol csym, final
LambdaTranslationContext lambdaContext) {
                JCClassDecl localCDef = localClassDefs.get(csym);
                if (localCDef != null && localCDef.pos <
lambdaContext.tree.pos) {
                    BasicFreeVarCollector fvc = lower.new
BasicFreeVarCollector() {
                        @Override
                        void addFreeVars(ClassSymbol c) {
                            captureLocalClassDefs(c, lambdaContext);
                        }
            // ...
                    };
                    fvc.scan(localCDef);
                }
        }

Following is a stack trace of the Error
java.lang.StackOverflowError
    at com.sun.tools.javac.tree.JCTree$JCModifiers.accept(JCTree.java:2337)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.tree.TreeScanner.visitMethodDef(TreeScanner.java:84)
    at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:772)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
    at
com.sun.tools.javac.tree.TreeScanner.visitClassDef(TreeScanner.java:80)
    at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:687)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.captureLocalClassDefs(LambdaToMethod.java:1325)
    at
com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$1.addFreeVars(LambdaToMethod.java:1306)
    at
com.sun.tools.javac.comp.Lower$BasicFreeVarCollector.visitNewClass(Lower.java:242)
    at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1510)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.tree.TreeScanner.visitLambda(TreeScanner.java:221)
    at com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1618)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.visitVarDef(TreeScanner.java:98)
    at
com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:846)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
    at com.sun.tools.javac.tree.TreeScanner.visitBlock(TreeScanner.java:105)
    at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:903)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.tree.TreeScanner.visitMethodDef(TreeScanner.java:91)
    at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:772)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
    at
com.sun.tools.javac.tree.TreeScanner.visitClassDef(TreeScanner.java:80)
    at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:687)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.captureLocalClassDefs(LambdaToMethod.java:1325)
    at
com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$1.addFreeVars(LambdaToMethod.java:1306)
    at
com.sun.tools.javac.comp.Lower$BasicFreeVarCollector.visitNewClass(Lower.java:242)
    at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1510)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.tree.TreeScanner.visitLambda(TreeScanner.java:221)
    at com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1618)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.visitVarDef(TreeScanner.java:98)
    at
com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:846)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
    at com.sun.tools.javac.tree.TreeScanner.visitBlock(TreeScanner.java:105)
    at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:903)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.tree.TreeScanner.visitMethodDef(TreeScanner.java:91)
    at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:772)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
    at
com.sun.tools.javac.tree.TreeScanner.visitClassDef(TreeScanner.java:80)
    at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:687)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.captureLocalClassDefs(LambdaToMethod.java:1325)
    at
com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$1.addFreeVars(LambdaToMethod.java:1306)
    at
com.sun.tools.javac.comp.Lower$BasicFreeVarCollector.visitNewClass(Lower.java:242)
    at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1510)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.tree.TreeScanner.visitLambda(TreeScanner.java:221)
    at com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1618)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.visitVarDef(TreeScanner.java:98)
    at
com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:846)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
    at com.sun.tools.javac.tree.TreeScanner.visitBlock(TreeScanner.java:105)
    at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:903)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.tree.TreeScanner.visitMethodDef(TreeScanner.java:91)
    at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:772)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
    at
com.sun.tools.javac.tree.TreeScanner.visitClassDef(TreeScanner.java:80)
    at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:687)
    at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    at
com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.captureLocalClassDefs(LambdaToMethod.java:1325)
.
.
.


Regards,
bitter_fox