From timo.kinnunen at gmail.com  Thu May  1 09:11:22 2014
From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=)
Date: Thu, 1 May 2014 09:11:22 +0000
Subject: =?utf-8?Q?Re:_Does_not_pertinent_to_applicability_mean_not_used=3F?=
In-Reply-To: <C39D17F71FB39E488EA35B99FB027447128BAA15@G9W0743.americas.hpqcorp.net>
References: <536014b6.48040e0a.799b.ffffb393@mx.google.com>
	<CACuKZqGAD_sjC22+ipiCAQ+87AiEN3g=ugRCYRAoZ9pwokXiUA@mail.gmail.com>
	<536043db.c7490f0a.410e.ffffd449@mx.google.com>
	<CACuKZqF6_+djw+SuC13OXMT3bwi2NSsEa9D0B=BCLmb4FaUGuA@mail.gmail.com>,
	<C39D17F71FB39E488EA35B99FB027447128BAA15@G9W0743.americas.hpqcorp.net>
Message-ID: <53621363.82690e0a.7dd1.7183@mx.google.com>

What?s more, not incorporating those constraints doesn?t automatically mean type inference will fail and cause a compile error. This kind of code that?s currently rejected by Javac can end up compiling and typechecking correctly instead:


public static void main(String[] args) {

System.out.println(test(Stream.of(Stream.of("3"))));

System.out.println(test2(Stream.of(Stream.of("1")).skip(1)));

System.out.println(test31(Stream.of(Stream.of("2")).skip(1)));

}


static Optional<Stream<Object>> test(Stream<Stream<String>> s31) {

return s31.map(s2 -> s2.map(s1 -> Integer.parseInt(s1))).findAny();

}


static Object test2(Stream<Stream<String>> s3) {

return s3.map(s2 -> s2.map(s1 -> Integer.parseInt(s1))).flatMap(Function.identity()).findAny().orElse(Object.class);

}


static Stream<Object> test31(Stream<Stream<String>> s3) {

return s3.map(s2 -> s2.map(s1 -> Integer.parseInt(s1))).findAny().orElse(Stream.of((Object) "gotcha!"));

}


This doesn?t even seem to be unsound, just less useable, so it could be argued that this is really what should be allowed and enforced and what Javac should be changed to treat as correct too.






-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Rafkind, Jon
Sent: ?Thursday?, ?May? ?1?, ?2014 ?01?:?13
To: Zhong Yu, Timo Kinnunen
Cc: lambda-dev at openjdk.java.net





On 04/29/2014 06:45 PM, Zhong Yu wrote:
> If an argument is not pertinent to applicability, it is ignored during
> the applicability test. Other than that, I don't see what effect it
> has.
>
> Consider this simple code
>
>     void test(Stream<String> ss)
>     {
>         ss.map( s->Integer.parseInt(s) );
>     }
>
> The implicit lambda expression is not pertinent to applicability; it
> does not prevent the compiler from inferring that the invocation
> returns Stream<Integer>

I think this case is different because the lambda is added as an
additional constraint, as per 18.5.2:

"For all i (1 ? i ? k), additional constraints may be included,
according to the form of ei:
  If the expression is a LambdaExpression, the set contains
?LambdaExpression ?throws Fi ??."

FWIW, my compiler also reports an error on this line

Map<String, List<String>> methodReferenceVersionWithError() {
    return s2.flatMap(p -> entryToStream(p).map(p::replaceKey)).collect(c2);
}

When the type if flatMap() is inferred the constraint 'p ->
entryToStream ...' is added. Reducing that lambda constraint produces
the constraint 'map(p::replaceKey) -> Stream<%a1>', where map() is a
poly invocation. Reducing a poly invocation reduces to the set B3 that
is described in section 18.5.2 as per 18.2.1:

"If the expression is a class instance creation expression or a method
invocation, the constraint reduces to the bound set B3 which would be
used to determine the expression's invocation type when targeting T, as
defined in 18.5.2 (in the case of a class instance creation, the
corresponding "method" used for inference is defined in 15.9.3)."

But B3 ignores non-pertinent expressions so p::replaceKey is not used in
a constraint formula. B3 basically comprises the pertinent expressions
and the return type.

From zhong.j.yu at gmail.com  Thu May  1 14:46:18 2014
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Thu, 1 May 2014 09:46:18 -0500
Subject: Does not pertinent to applicability mean not used?
In-Reply-To: <53621363.82690e0a.7dd1.7183@mx.google.com>
References: <536014b6.48040e0a.799b.ffffb393@mx.google.com>
	<CACuKZqGAD_sjC22+ipiCAQ+87AiEN3g=ugRCYRAoZ9pwokXiUA@mail.gmail.com>
	<536043db.c7490f0a.410e.ffffd449@mx.google.com>
	<CACuKZqF6_+djw+SuC13OXMT3bwi2NSsEa9D0B=BCLmb4FaUGuA@mail.gmail.com>
	<C39D17F71FB39E488EA35B99FB027447128BAA15@G9W0743.americas.hpqcorp.net>
	<53621363.82690e0a.7dd1.7183@mx.google.com>
Message-ID: <CACuKZqHPRnWgoc8yBo7vUmtkyyn9wdyBXDqMv1UtUdDm11-7FA@mail.gmail.com>

On Thu, May 1, 2014 at 4:11 AM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:
> What?s more, not incorporating those constraints doesn?t automatically mean
> type inference will fail and cause a compile error. This kind of code that?s
> currently rejected by Javac can end up compiling and typechecking correctly
> instead:
>
> public static void main(String[] args) {
> System.out.println(test(Stream.of(Stream.of("3"))));
> System.out.println(test2(Stream.of(Stream.of("1")).skip(1)));
> System.out.println(test31(Stream.of(Stream.of("2")).skip(1)));
> }
>
> static Optional<Stream<Object>> test(Stream<Stream<String>> s31) {
> return s31.map(s2 -> s2.map(s1 -> Integer.parseInt(s1))).findAny();
> }

I would not want s32.map() return type to be inferred as
Stream<Stream<Object>>, regardless whether it's doable by the machine.
It is too much work for the programmer to come to the same conclusion;
too much contextual information needs to be considered for the
inference.

The real problem here is that Optional<Stream<Integer>> is-not-a
Optional<Stream<Object>>. If the return type of test() is changed to
Optional<? extends Stream<? extends Object>>, the code compiles. But
yikes! That is unbearable! Java needs to do something about wildcards,
badly.


>
> static Object test2(Stream<Stream<String>> s3) {
> return s3.map(s2 -> s2.map(s1 ->
> Integer.parseInt(s1))).flatMap(Function.identity()).findAny().orElse(Object.class);
> }

Here we need a lower-bounded type parameter

    <S super T> S orElese(S other)

this feature becomes more and more needed when we go beyond the
original use cases of generics that mainly focused on Collection APIs.

>
> static Stream<Object> test31(Stream<Stream<String>> s3) {
> return s3.map(s2 -> s2.map(s1 ->
> Integer.parseInt(s1))).findAny().orElse(Stream.of((Object) "gotcha!"));
> }
>
> This doesn?t even seem to be unsound, just less useable, so it could be
> argued that this is really what should be allowed and enforced and what
> Javac should be changed to treat as correct too.
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
> From: Rafkind, Jon
> Sent: ?Thursday?, ?May? ?1?, ?2014 ?01?:?13
> To: Zhong Yu, Timo Kinnunen
> Cc: lambda-dev at openjdk.java.net
>
> On 04/29/2014 06:45 PM, Zhong Yu wrote:
>> If an argument is not pertinent to applicability, it is ignored during
>> the applicability test. Other than that, I don't see what effect it
>> has.
>>
>> Consider this simple code
>>
>>     void test(Stream<String> ss)
>>     {
>>         ss.map( s->Integer.parseInt(s) );
>>     }
>>
>> The implicit lambda expression is not pertinent to applicability; it
>> does not prevent the compiler from inferring that the invocation
>> returns Stream<Integer>
>
> I think this case is different because the lambda is added as an
> additional constraint, as per 18.5.2:
>
> "For all i (1 ? i ? k), additional constraints may be included,
> according to the form of ei:
>   If the expression is a LambdaExpression, the set contains
> ?LambdaExpression ?throws Fi ??."
>
> FWIW, my compiler also reports an error on this line
>
> Map<String, List<String>> methodReferenceVersionWithError() {
>     return s2.flatMap(p -> entryToStream(p).map(p::replaceKey)).collect(c2);
> }
>
> When the type if flatMap() is inferred the constraint 'p ->
> entryToStream ...' is added. Reducing that lambda constraint produces
> the constraint 'map(p::replaceKey) -> Stream<%a1>', where map() is a
> poly invocation. Reducing a poly invocation reduces to the set B3 that
> is described in section 18.5.2 as per 18.2.1:
>
> "If the expression is a class instance creation expression or a method
> invocation, the constraint reduces to the bound set B3 which would be
> used to determine the expression's invocation type when targeting T, as
> defined in 18.5.2 (in the case of a class instance creation, the
> corresponding "method" used for inference is defined in 15.9.3)."
>
> But B3 ignores non-pertinent expressions so p::replaceKey is not used in
> a constraint formula. B3 basically comprises the pertinent expressions
> and the return type.

From pl at dhbw.de  Fri May  2 15:41:01 2014
From: pl at dhbw.de (Martin Pluemicke)
Date: Fri, 2 May 2014 17:41:01 +0200
Subject: PPPJ 2014: Call for Papers 
Message-ID: <201405021541.s42Ff1aa004252@pcpl.ba-horb.de>

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

                       2014 INTERNATIONAL CONFERENCE 
     ON PRINCIPLES AND PRACTICES OF PROGRAMMING ON THE JAVA PLATFORM:
           VIRTUAL MACHINES, PROGRAMMING LANGUAGES AND TOOLS


                 Cracow, Poland, September 23-26, 2014  

		   http://www.pppj2014.uck.pk.edu.pl/

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   CALL FOR PAPERS

XXXXXXXXXXXXXXXXXXXXXXXXXX

Java today is envisaged as a fundamental technology for future generation 
scalable intelligent systems. The modern Java-based Platforms cover 
a rich diversity of system components, languages, tools, frameworks 
and techniques. It impacts and is impacted by all recent developments 
in the cloud, networks and mobile computing and related spaces.

PPPJ'14 - the 11th conference in the PPPJ series - provides a forum 
for researchers, practitioners, and educators to present and discuss 
novel results on all aspects of programming on the Java platform 
including virtual machines, languages, tools, methods, frameworks, 
libraries, case studies, and experience reports.

XXXXXXXXXXXXXXXXXXXXXXXXXX

      TOPICS

XXXXXXXXXXXXXXXXXXXXXXXXXX

Topics of interest include but are not limited to:

Virtual machines for Java and Java-like language support:

- JVM and similar VMs
- VM design and optimization
- VMs for mobile and embedded devices
- Real-time VMs
- Isolation and resource control

Languages on the Java platform:
- JVM languages (Clojure, Groovy, Java, JRuby, Kotlin, Scala, ?)
- Domain-specific languages
- Language design and calculi
- Compilers
- Language interoperability
- Parallelism and concurrency
- Modular and aspect-oriented programming
- Model-driven development
- Frameworks and applications
- Teaching

Techniques and tools for the Java platform:
- Static and dynamic program analysis
- Testing
- Verification
- Security and information flow
- Workload characterization

Please contact the PC Chair, Bruce Childers (email: childers(at)cs.pitt.edu) 
to clarify whether a particular topic falls within the scope of PPPJ?14.

XXXXXXXXXXXXXXXXXXXXXXXXXX

  SUBMISSION INFORMATION

XXXXXXXXXXXXXXXXXXXXXXXXXX

PPPJ accepts three types of papers: full research papers (up to 12
pages), short research and industry papers (up to 6 pages), and tool 
papers (up to 4 pages).  All accepted papers will appear in the proceedings,
which will be available from the ACM Digital Library.  More information
about review criteria, submission guidelines and paper format are 
available from the PPPJ web site.


XXXXXXXXXXXXXXXXXXXXXXXXXX

  DATES

XXXXXXXXXXXXXXXXXXXXXXXXXX

Paper submission: May 31, 2014, 11:59 PM EST
Author notification: July 12, 2014
Camera-ready papers due: July 26, 2014
Conference: September 23-26, 2014

XXXXXXXXXXXXXXXXXXXXXXXXXX

 CONFERENCE ORGANIZERS

XXXXXXXXXXXXXXXXXXXXXXXXXX
PROGRAM COMMITTEE:
 
Lorenzo Bettini, University of Torino, Italy
Fernando Miguel Gamboa Carvalho, Polytechnic Institute of Lisbon, Portugal
Xavier Clerc, INRIA, France
Luke D?Alessandro, Indiana University, USA
Cormac Flanagan, University of California, Santa Cruz, USA
Michael Franz, University of California, Irvine, USA
John Gough, Oracle, USA
David Gregg, University of Dublin, Trinity College, Ireland
Apala Guha, Indraprastha Institute of Information Technology, Delhi, India
Rajiv Gupta, Univeristy of California Riverside, USA
Andreas Krall, Vienna University of Technology, Austria
Herbert Kuchen, University of Muenster, Germany 
Prasad Kulkarni, University of Kansas, USA
Ondrej Lhotak, University of Waterloo, USA
Du Li, Carnegie Mellon University, USA
Jonathan Misurda, University of Pittsburgh, USA
Hanspeter M?ssenb?ck, University of Linz, Austria
Nathaniel Nystrom, University of Lugano, Italy
Mauricio Pilla, University of Pelotas (UFPEL), Brasil
Vivek Sarkar, Rice University, USA
Jennifer B. Sartor, Ghent University, Belgium
Martin Schoeberl, Technical University of Denmark, Denmark
Mary Lou Soffa, University of Virginia, USAia
Chenggang Wu, Institute of Computing Technology, Chinese Academy of Sciences, China
Jingling Xue, University of New South Wales, Australia

GENERAL CHAIR:
   Joanna Kolodziej, Cracow University of Technology, Poland

PROGRAMME CHAIR:
    Bruce R. Childers, University of Pittsburgh, USA 

PUBLICITY CHAIRS:
   Ciprian Dobre, University POLITEHNICA of Bucharest, Romania
   Prem Jayaraman, CSIRO, Australia

STEERING COMMITTEE:
    Markus Aleksy, ABB Corporate Research, Germany
    Walter Binder, University of Lugano, Switzerland
    Conrad Cunningham, University of Mississippi, USA
    Martin Pl?micke, Duale Hochschule Baden-W?rttemberg, Germany
    Christian Probst, Technical University of Denmark, Denmark

WEB ADMINISTRATOR:
    Magdalena Szmajduch, Cracow University of Technology, Poland
    Daniel Grzonka, Cracow University of Technology, Poland

LOCAL ORGANIZATION AND MANAGEMENT:
    Anna Plichta, Cracow University of Technology, Poland
    Katarzyna Smelcerz, Cracow University of Technology, Poland
    

From lukas.eder at gmail.com  Sun May  4 07:42:02 2014
From: lukas.eder at gmail.com (Lukas Eder)
Date: Sun, 4 May 2014 09:42:02 +0200
Subject: Lambda expression and method overloading
Message-ID: <CAB4ELO4nNXeuzg8zro53djGwd419J6smdc-hwVSEw38JfdqXTQ@mail.gmail.com>

Dear EG,

This is a cross-post of my Stack Overflow question here:
http://stackoverflow.com/questions/23430854/lambda-expression-and-method-overloading-doubts

The question has reached above-average popularity on SO, so I thought I
would reach out to you for an authoritative reply. At the current stage of
Java 8 adoption, I'm afraid that there might still be a bit of speculation
from the community about such compiler issues.

Answers on lambda-dev and/or on SO would be greatly appreciated.

--------
Let's assume I have this API:

    static void run(Consumer<Integer> consumer) {
        System.out.println("consumer");
    }

    static void run(Function<Integer, Integer> function) {
        System.out.println("function");
    }

Using Java 8 lambda expressions, I can call the above like so:

    // Consumer
    run((Integer i) -> {});

    // Function
    run((Integer i) -> 1);

But this will not compile:

    // Consumer
    run(i -> {});

    // Function
    run(i -> 1);

I get this error message:

    Test.java:63: error: reference to run is ambiguous
            run(i -> {});
            ^
      both method run(Consumer<Integer>) in Test and
           method run(Function<Integer,Integer>) in Test match

I *suspect* that this is due to JLS ?15.12.2:

> Certain argument expressions that contain implicitly typed
> lambda expressions (?15.27.1) or inexact method references
> (?15.13.1) are ignored by the applicability tests, because
> their meaning cannot be determined until a target type is selected.

Is that assumption true? And why were things decided this way? I'm
particularly interested in the applicability of "void-compatible" vs.
"value-compatible" expressions *might* be a more special case, as the
target type can "easily" be determined, at least in my example. Of course,
I'm certainly not seeing the big picture.

Looking forward to hearing from you,
Lukas

From vicente.romero at oracle.com  Tue May  6 17:15:34 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 06 May 2014 18:15:34 +0100
Subject: javac rejects valid java 7 code
In-Reply-To: <57A1A263-6163-447F-9CBA-F14A401CF5A8@oracle.com>
References: <009701cee473$4157fb20$c407f160$@kozlova@jetbrains.com>
	<57A1A263-6163-447F-9CBA-F14A401CF5A8@oracle.com>
Message-ID: <536918B6.1080306@oracle.com>

Hi Anna,

This bug has been fixed in both 9 and 8 dev repos.

Thanks,
Vicente

On 21/11/13 17:43, Dan Smith wrote:
> 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 vicente.romero at oracle.com  Tue May  6 17:40:22 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 06 May 2014 18:40:22 +0100
Subject: Javac Bug?
In-Reply-To: <0f0601cf607a$269e7830$73db6890$@jetbrains.com>
References: <0f0601cf607a$269e7830$73db6890$@jetbrains.com>
Message-ID: <53691E86.4020504@oracle.com>

Hi Anna,

This has been fixed in 8 and 9 dev repos due to [1].

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8030741

On 25/04/14 12:33, Anna Kozlova wrote:
> Hi,
>
> This code compiles
>
> class Test {
>     {
>          putPrefWriter(Short.class, Preferences::putInt);
>      }
>
>      private static <T> void putPrefWriter(Class<T> type, PrefWriter<T>
> prefWriter) {}
>
>      interface PrefWriter<T> {
>          void write(Preferences preferences, String key, T value);
>      }
> }
>
> but this is not (only parameters order was changed)
>
> class Test {
>      {
>          putPrefWriter(Preferences::putInt, Short.class);
>      }
>
>      private static <T> void putPrefWriter(PrefWriter<T> prefWriter, Class<T>
> type) {}
>
>      interface PrefWriter<T> {
>          void write(Preferences preferences, String key, T value);
>      }
> }
>
> As for me, javac should reject both cases due to
> http://docs.oracle.com/javase/specs/jls/se8/html/jls-18.html#jls-18.2.2 (if
> T is a primitive type, let T' be the result of applying boxing conversion
> (?5.1.7) to T. Then the constraint reduces to ?S = T'?.)
>
> Initially reported as http://youtrack.jetbrains.com/issue/IDEA-124366
>
> Thanks,
> Anna
>


From vicente.romero at oracle.com  Tue May  6 17:48:27 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 06 May 2014 18:48:27 +0100
Subject: Javac Bug
In-Reply-To: <53569AF9.7080200@oracle.com>
References: <CAMUF1Smv=mbmoMv0oBxfxCFmCw_HcJMOqDP2fWuKryUKXXEWow@mail.gmail.com>	<53567B90.4000604@oracle.com>
	<53569AF9.7080200@oracle.com>
Message-ID: <5369206B.5020009@oracle.com>

Hi,

For completeness, I have filed this bug: 
https://bugs.openjdk.java.net/browse/JDK-8035761

Thanks,
Vicente

On 22/04/14 17:38, Vicente-Arturo Romero-Zaldivar wrote:
> On 22/04/14 15:24, Vicente-Arturo Romero-Zaldivar wrote:
>> Hi Sam,
>>
>> Thanks for this report. Do you know if a bug entry was created for 
>> this issue?
>
> Never mind, I found it.
>
> Vicente
>
>>
>> Thanks,
>> Vicente
>>
>> On 19/04/14 22:22, Sam Pullara wrote:
>>> Reported this awhile ago, finally have a simple reproduction for it. 
>>> Any
>>> ideas?
>>>
>>> https://gist.github.com/spullara/11097851
>>>
>>> Results in:
>>>
>>> Information:Using javac 1.8.0_20-ea to compile java sources
>>> Information:java: An exception has occurred in the compiler 
>>> (1.8.0_20-ea).
>>> Please file a bug at the Java Developer Connection (
>>> http://java.sun.com/webapps/bugreport)  after checking the Bug 
>>> Parade for
>>> duplicates. Include your program and the following diagnostic in your
>>> report.  Thank you.
>>> Information:java: at 
>>> com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3385)
>>> Information:java: at
>>> com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257)
>>> Information:java: at
>>> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891)
>>> Information:java: at 
>>> com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596)
>>> Information:java: at
>>> com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1828)
>>>
>>
>>
>
>


From vicente.romero at oracle.com  Tue May  6 20:14:50 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 06 May 2014 21:14:50 +0100
Subject: Lambda expression and method overloading
In-Reply-To: <CAB4ELO4nNXeuzg8zro53djGwd419J6smdc-hwVSEw38JfdqXTQ@mail.gmail.com>
References: <CAB4ELO4nNXeuzg8zro53djGwd419J6smdc-hwVSEw38JfdqXTQ@mail.gmail.com>
Message-ID: <536942BA.4020802@oracle.com>

Hi Lukas,

Thanks for your mail. This bug has already been reported in the JDK Bug 
System: https://bugs.openjdk.java.net/browse/JDK-8029718. The bug has 
been fixed so the code it's correctly accepted by the compiler now.

Vicente

On 04/05/14 08:42, Lukas Eder wrote:
> Dear EG,
>
> This is a cross-post of my Stack Overflow question here:
> http://stackoverflow.com/questions/23430854/lambda-expression-and-method-overloading-doubts
>
> The question has reached above-average popularity on SO, so I thought I
> would reach out to you for an authoritative reply. At the current stage of
> Java 8 adoption, I'm afraid that there might still be a bit of speculation
> from the community about such compiler issues.
>
> Answers on lambda-dev and/or on SO would be greatly appreciated.
>
> --------
> Let's assume I have this API:
>
>      static void run(Consumer<Integer> consumer) {
>          System.out.println("consumer");
>      }
>
>      static void run(Function<Integer, Integer> function) {
>          System.out.println("function");
>      }
>
> Using Java 8 lambda expressions, I can call the above like so:
>
>      // Consumer
>      run((Integer i) -> {});
>
>      // Function
>      run((Integer i) -> 1);
>
> But this will not compile:
>
>      // Consumer
>      run(i -> {});
>
>      // Function
>      run(i -> 1);
>
> I get this error message:
>
>      Test.java:63: error: reference to run is ambiguous
>              run(i -> {});
>              ^
>        both method run(Consumer<Integer>) in Test and
>             method run(Function<Integer,Integer>) in Test match
>
> I *suspect* that this is due to JLS ?15.12.2:
>
>> Certain argument expressions that contain implicitly typed
>> lambda expressions (?15.27.1) or inexact method references
>> (?15.13.1) are ignored by the applicability tests, because
>> their meaning cannot be determined until a target type is selected.
> Is that assumption true? And why were things decided this way? I'm
> particularly interested in the applicability of "void-compatible" vs.
> "value-compatible" expressions *might* be a more special case, as the
> target type can "easily" be determined, at least in my example. Of course,
> I'm certainly not seeing the big picture.
>
> Looking forward to hearing from you,
> Lukas
>


From timo.kinnunen at gmail.com  Wed May  7 10:11:51 2014
From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=)
Date: Wed, 7 May 2014 10:11:51 +0000
Subject: =?utf-8?Q?Re:_Does_not_pertinent_to_applicability_mean_not_used=3F?=
In-Reply-To: <C39D17F71FB39E488EA35B99FB027447128BAA15@G9W0743.americas.hpqcorp.net>
References: <536014b6.48040e0a.799b.ffffb393@mx.google.com>
	<CACuKZqGAD_sjC22+ipiCAQ+87AiEN3g=ugRCYRAoZ9pwokXiUA@mail.gmail.com>
	<536043db.c7490f0a.410e.ffffd449@mx.google.com>
	<CACuKZqF6_+djw+SuC13OXMT3bwi2NSsEa9D0B=BCLmb4FaUGuA@mail.gmail.com>,
	<C39D17F71FB39E488EA35B99FB027447128BAA15@G9W0743.americas.hpqcorp.net>
Message-ID: <536a0b6a.84020e0a.4993.ffff97fc@mx.google.com>

Taking this as an example:


static Optional<?> test(Stream<Stream<String>> stream2) {

  return stream2.map(stream -> stream.map(string -> Integer.parseInt(string))).findAny();

}


If not pertinent to applicability works as specified, then the inner ?string -> Integer.parseInt(string)? actually means ?string -> (Object) Integer.parseInt(string)? as compiled with current Javac. 


On the other hand, if a programmer were to write the inner lambda as ?(String string) -> Integer.parseInt(string)?, repeating the type String ?coming from the outside? redundantly, then the type Integer would be incorporated as normal.


This subtle difference between 


string -> Integer.parseInt(string)

versus


(String string) -> Integer.parseInt(string)

having the effects


string -> (Object) Integer.parseInt(string)

and


(String string) -> (Integer) Integer.parseInt(string)

is not useful. 


The specification should be changed so that Integer is incorporated in both cases.


If I got anything wrong please correct me.








-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Rafkind, Jon
Sent: ?Thursday?, ?May? ?1?, ?2014 ?01?:?13
To: Zhong Yu, Timo Kinnunen
Cc: lambda-dev at openjdk.java.net





On 04/29/2014 06:45 PM, Zhong Yu wrote:
> If an argument is not pertinent to applicability, it is ignored during
> the applicability test. Other than that, I don't see what effect it
> has.
>
> Consider this simple code
>
>     void test(Stream<String> ss)
>     {
>         ss.map( s->Integer.parseInt(s) );
>     }
>
> The implicit lambda expression is not pertinent to applicability; it
> does not prevent the compiler from inferring that the invocation
> returns Stream<Integer>

I think this case is different because the lambda is added as an
additional constraint, as per 18.5.2:

"For all i (1 ? i ? k), additional constraints may be included,
according to the form of ei:
  If the expression is a LambdaExpression, the set contains
?LambdaExpression ?throws Fi ??."

FWIW, my compiler also reports an error on this line

Map<String, List<String>> methodReferenceVersionWithError() {
    return s2.flatMap(p -> entryToStream(p).map(p::replaceKey)).collect(c2);
}

When the type if flatMap() is inferred the constraint 'p ->
entryToStream ...' is added. Reducing that lambda constraint produces
the constraint 'map(p::replaceKey) -> Stream<%a1>', where map() is a
poly invocation. Reducing a poly invocation reduces to the set B3 that
is described in section 18.5.2 as per 18.2.1:

"If the expression is a class instance creation expression or a method
invocation, the constraint reduces to the bound set B3 which would be
used to determine the expression's invocation type when targeting T, as
defined in 18.5.2 (in the case of a class instance creation, the
corresponding "method" used for inference is defined in 15.9.3)."

But B3 ignores non-pertinent expressions so p::replaceKey is not used in
a constraint formula. B3 basically comprises the pertinent expressions
and the return type.

From vicente.romero at oracle.com  Wed May  7 14:19:57 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Wed, 07 May 2014 15:19:57 +0100
Subject: Lambda behaving differently than anonymous inner class
In-Reply-To: <CACuKZqH_rvJey7XyXmDXh0XsSFPb0XouV41iKKj1jB0L1d7tOw@mail.gmail.com>
References: <CADEK1vcBsYBD8NyhiWS4ne4CKEKFijALTrOEv=OHZYmP5e5TfA@mail.gmail.com>
	<CACuKZqH_rvJey7XyXmDXh0XsSFPb0XouV41iKKj1jB0L1d7tOw@mail.gmail.com>
Message-ID: <536A410D.8000802@oracle.com>

Hi Victor,

The bug you reported [1] has already been fixed,

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8038420

On 26/03/14 19:32, Zhong Yu wrote:
> Another example:
>
>          Consumer<Integer> c = t -> System.out.println(t++);
>          c.accept(2);
>
> no no no no...
>
> Zhong Yu
>
>
> On Wed, Mar 26, 2014 at 10:03 AM, Victor Antunes
> <victor.antunes.ignacio at gmail.com> wrote:
>> Hello all,
>>
>> This e-mail is a follow-up to a question I've posted on StackOverflow:
>> http://stackoverflow.com/questions/22648079/lambda-behaving-differently-than-anonymous-inner-class
>>
>>
>> I'm relatively new to Java, and decided to pick up on lambda since the past
>> few days. So I wrote a very simple anonymous inner class and wrote an
>> equivalent lambda.
>>
>> However, the lambda output was different, and it very strongly appears to
>> be a bug.
>>
>> Given:
>>
>> interface Supplier<T> {
>>
>>      T get(T t);}
>>
>> Supplier<Integer> s1 = new Supplier<Integer>() {
>>      @Override
>>      public Integer get(Integer t) {
>>          return t++;
>>      }};Supplier<Integer> s2 = t ->
>> t++;System.out.println(s1.get(2));System.out.println(s2.get(2));
>>
>> The output is 2 and 3, NOT 2 and 2, as one would expect.
>>
>> More info, including discussion about bytecode is available at the SO link
>> above.
>>
>> I'm also new to this list, so apologies if I've broken any mailing list
>> etiquette.
>>
>> --
>> Kind regards,
>>
>> Victor Antunes
>>


From r.spilker at gmail.com  Wed May  7 22:28:27 2014
From: r.spilker at gmail.com (Roel Spilker)
Date: Thu, 8 May 2014 00:28:27 +0200
Subject: Cast in front of conditional seems to be invalid in javac
Message-ID: <CAO91Z4zDqg+Q-q-f3hpHizyxpA=L3EU7qY=Bd9ipgdfSNdPdDg@mail.gmail.com>

Hi all,

Introducing a type cast just in front of a conditional (?:) seems not to be
valid using javac 1.8.0_05

The reason to add a cast might be to create a Runnable that is also
Serializable:

Runnable r = (Runnable & Serializable) ()->{};

So I would expect adding a cast to any expression would be okay.

Is this a bug? If so, how/where should I register it?

Roel

==== file TestCastInFrontOfConditional.java ====

public class TestCastInFrontOfConditional {
{
 Runnable works = (Boolean.TRUE ? () -> {} : () -> {});
Runnable alsoWorks = Boolean.TRUE ? (Runnable) () -> {} : (Runnable) () ->
{};
 Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : () -> {});
}
}

==== output ====

TestCastInFrontOfConditional.java:6: error: lambda expression not expected
here
                Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
-> {});
                                                            ^
TestCastInFrontOfConditional.java:6: error: lambda expression not expected
here
                Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
-> {});
                                                                       ^
2 errors

==== end =====

From r.spilker at gmail.com  Wed May  7 22:37:31 2014
From: r.spilker at gmail.com (Roel Spilker)
Date: Thu, 8 May 2014 00:37:31 +0200
Subject: Cast in front of conditional seems to be invalid in javac
In-Reply-To: <CAO91Z4zDqg+Q-q-f3hpHizyxpA=L3EU7qY=Bd9ipgdfSNdPdDg@mail.gmail.com>
References: <CAO91Z4zDqg+Q-q-f3hpHizyxpA=L3EU7qY=Bd9ipgdfSNdPdDg@mail.gmail.com>
Message-ID: <CAO91Z4xVsNpg5XbjAgyy9jeGJi7BccLG1btAreSF-iz1X5v9dA@mail.gmail.com>

By the way, ecj errors "The target type of this expression must be a
functional interface"



On Thu, May 8, 2014 at 12:28 AM, Roel Spilker <r.spilker at gmail.com> wrote:

> Hi all,
>
> Introducing a type cast just in front of a conditional (?:) seems not to
> be valid using javac 1.8.0_05
>
> The reason to add a cast might be to create a Runnable that is also
> Serializable:
>
> Runnable r = (Runnable & Serializable) ()->{};
>
> So I would expect adding a cast to any expression would be okay.
>
> Is this a bug? If so, how/where should I register it?
>
> Roel
>
> ==== file TestCastInFrontOfConditional.java ====
>
> public class TestCastInFrontOfConditional {
> {
>  Runnable works = (Boolean.TRUE ? () -> {} : () -> {});
> Runnable alsoWorks = Boolean.TRUE ? (Runnable) () -> {} : (Runnable) () ->
> {};
>  Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : () -> {});
> }
> }
>
> ==== output ====
>
> TestCastInFrontOfConditional.java:6: error: lambda expression not expected
> here
>                 Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
> -> {});
>                                                             ^
> TestCastInFrontOfConditional.java:6: error: lambda expression not expected
> here
>                 Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
> -> {});
>                                                                        ^
> 2 errors
>
> ==== end =====
>

From zhong.j.yu at gmail.com  Thu May  8 02:47:51 2014
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 7 May 2014 21:47:51 -0500
Subject: Cast in front of conditional seems to be invalid in javac
In-Reply-To: <CAO91Z4zDqg+Q-q-f3hpHizyxpA=L3EU7qY=Bd9ipgdfSNdPdDg@mail.gmail.com>
References: <CAO91Z4zDqg+Q-q-f3hpHizyxpA=L3EU7qY=Bd9ipgdfSNdPdDg@mail.gmail.com>
Message-ID: <CACuKZqHc___Csb+dRNeujMqWww9M3UvZ86MRN-c1-YFYrK1x9g@mail.gmail.com>

Relevant spec[1]:

> 15.25.3. A reference conditional expression is a poly expression if it appears in an assignment context or an invocation context (?5.2. ?5.3). Otherwise, it is a standalone expression.

This means propagation of target type only works in these 2 contexts.

[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25.3

On Wed, May 7, 2014 at 5:28 PM, Roel Spilker <r.spilker at gmail.com> wrote:
> Hi all,
>
> Introducing a type cast just in front of a conditional (?:) seems not to be
> valid using javac 1.8.0_05
>
> The reason to add a cast might be to create a Runnable that is also
> Serializable:
>
> Runnable r = (Runnable & Serializable) ()->{};
>
> So I would expect adding a cast to any expression would be okay.
>
> Is this a bug? If so, how/where should I register it?
>
> Roel
>
> ==== file TestCastInFrontOfConditional.java ====
>
> public class TestCastInFrontOfConditional {
> {
>  Runnable works = (Boolean.TRUE ? () -> {} : () -> {});
> Runnable alsoWorks = Boolean.TRUE ? (Runnable) () -> {} : (Runnable) () ->
> {};
>  Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : () -> {});
> }
> }
>
> ==== output ====
>
> TestCastInFrontOfConditional.java:6: error: lambda expression not expected
> here
>                 Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
> -> {});
>                                                             ^
> TestCastInFrontOfConditional.java:6: error: lambda expression not expected
> here
>                 Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
> -> {});
>                                                                        ^
> 2 errors
>
> ==== end =====
>

From luan.cestari at gmail.com  Mon May 19 12:30:49 2014
From: luan.cestari at gmail.com (Luan Cestari)
Date: Mon, 19 May 2014 12:30:49 +0000 (UTC)
Subject: Stay in touch with me through LinkedIn
Message-ID: <1930047112.4604668.1400502649064.JavaMail.app@ela4-app1327.prod>

LinkedIn
------------



I'd like to add you to my professional network on LinkedIn.

- Luan

Luan Cestari
Senior?Technical?Support Engineer at Red Hat
S?o Paulo Area, Brazil

Confirm that you know Luan Cestari:
https://www.linkedin.com/e/-95vf1z-hvdr482n-45/isd/5874133788421799941/_uswrU_s/?hs=false&tok=2Cr6-yuNueaCg1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-95vf1z-hvdr482n-45/uKFHsXVlWsNFwHU0OcFFVuqfWb_BZUU0f-HH3hsNK8/goo/lambda-dev%40openjdk%2Ejava%2Enet/20061/I7099596357_1/?hs=false&tok=1tUhIwkcWeaCg1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.


  

From r.spilker at gmail.com  Mon May 19 12:33:56 2014
From: r.spilker at gmail.com (Roel Spilker)
Date: Mon, 19 May 2014 14:33:56 +0200
Subject: Cast in front of conditional seems to be invalid in javac
In-Reply-To: <CACuKZqHc___Csb+dRNeujMqWww9M3UvZ86MRN-c1-YFYrK1x9g@mail.gmail.com>
References: <CAO91Z4zDqg+Q-q-f3hpHizyxpA=L3EU7qY=Bd9ipgdfSNdPdDg@mail.gmail.com>
	<CACuKZqHc___Csb+dRNeujMqWww9M3UvZ86MRN-c1-YFYrK1x9g@mail.gmail.com>
Message-ID: <CAO91Z4yFv9ujgeFivB3+vHXZbE00+2+HOGUAoFJZQ3at3A2NXA@mail.gmail.com>

Thanks for the pointer.

Is there a good reason why this is the spec?
What would change if a next version of the spec will be modified to also
allow a casting context, as is currently the case for method references[1]

[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.13.2


On Thu, May 8, 2014 at 4:47 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> Relevant spec[1]:
>
> > 15.25.3. A reference conditional expression is a poly expression if it
> appears in an assignment context or an invocation context (?5.2. ?5.3).
> Otherwise, it is a standalone expression.
>
> This means propagation of target type only works in these 2 contexts.
>
> [1]
> http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25.3
>
> On Wed, May 7, 2014 at 5:28 PM, Roel Spilker <r.spilker at gmail.com> wrote:
> > Hi all,
> >
> > Introducing a type cast just in front of a conditional (?:) seems not to
> be
> > valid using javac 1.8.0_05
> >
> > The reason to add a cast might be to create a Runnable that is also
> > Serializable:
> >
> > Runnable r = (Runnable & Serializable) ()->{};
> >
> > So I would expect adding a cast to any expression would be okay.
> >
> > Is this a bug? If so, how/where should I register it?
> >
> > Roel
> >
> > ==== file TestCastInFrontOfConditional.java ====
> >
> > public class TestCastInFrontOfConditional {
> > {
> >  Runnable works = (Boolean.TRUE ? () -> {} : () -> {});
> > Runnable alsoWorks = Boolean.TRUE ? (Runnable) () -> {} : (Runnable) ()
> ->
> > {};
> >  Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : () -> {});
> > }
> > }
> >
> > ==== output ====
> >
> > TestCastInFrontOfConditional.java:6: error: lambda expression not
> expected
> > here
> >                 Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
> > -> {});
> >                                                             ^
> > TestCastInFrontOfConditional.java:6: error: lambda expression not
> expected
> > here
> >                 Runnable fails = (Runnable) (Boolean.TRUE ? () -> {} : ()
> > -> {});
> >                                                                        ^
> > 2 errors
> >
> > ==== end =====
> >
>