• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
  • paul wheaton
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Rob Spoor
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:

min by doesn't compile? (Sybex)

 
Greenhorn
Posts: 13
1
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The last example from chapter 4, "Collecting Using Grouping, Partitioning, and Mapping" does not compile:


The problem seems to be with the minBy collector. I'm using IntelliJ with java version 1.8.0_45
 
author & internet detective
Posts: 41763
887
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mihaela Hetea wrote:The last example from chapter 4, "Collecting Using Grouping, Partitioning, and Mapping" does not compile:


It works for me both in Eclipse at the command line using Mac and Eclipse. Both with Java 1.8.0_45.

Here's the exact file I tested with:



What compiler error do you get?
 
Bartender
Posts: 2236
63
IntelliJ IDE Firefox Browser Spring Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tried to compile this using javac 1.8.0_40.

The output is:

PlayTest.java:11: error: no suitable method found for groupingBy(String::length,Collector<Object,CAP#1,Optional<T#1>>)
           Collectors.groupingBy(
                     ^
    method Collectors.<T#3,K#1>groupingBy(Function<? super T#3,? extends K#1>) is not applicable
      (cannot infer type-variable(s) T#3,K#1
        (actual and formal argument lists differ in length))
    method Collectors.<T#4,K#2,A#1,D#1>groupingBy(Function<? super T#4,? extends K#2>,Collector<? super T#4,A#1,D#1>) is not applicable
      (inferred type does not conform to upper bound(s)
        inferred: Object
        upper bound(s): T#5,Comparable<? super T#5>,Object)
    method Collectors.<T#6,K#3,D#2,A#2,M>groupingBy(Function<? super T#6,? extends K#3>,Supplier<M>,Collector<? super T#6,A#2,D#2>) is not applicable
      (cannot infer type-variable(s) T#6,K#3,D#2,A#2,M
        (actual and formal argument lists differ in length))
  where T#1,T#2,T#3,K#1,T#4,K#2,A#1,D#1,T#5,T#6,K#3,D#2,A#2,M are type-variables:
    T#1 extends T#2
    T#2 extends Comparable<? super T#2>
    T#3 extends Object declared in method <T#3,K#1>groupingBy(Function<? super T#3,? extends K#1>)
    K#1 extends Object declared in method <T#3,K#1>groupingBy(Function<? super T#3,? extends K#1>)
    T#4 extends Object declared in method <T#4,K#2,A#1,D#1>groupingBy(Function<? super T#4,? extends K#2>,Collector<? super T#4,A#1,D#1>)
    K#2 extends Object declared in method <T#4,K#2,A#1,D#1>groupingBy(Function<? super T#4,? extends K#2>,Collector<? super T#4,A#1,D#1>)
    A#1 extends Object declared in method <T#4,K#2,A#1,D#1>groupingBy(Function<? super T#4,? extends K#2>,Collector<? super T#4,A#1,D#1>)
    D#1 extends Object declared in method <T#4,K#2,A#1,D#1>groupingBy(Function<? super T#4,? extends K#2>,Collector<? super T#4,A#1,D#1>)
    T#5 extends Comparable<? super T#5> declared in method <T#5>naturalOrder()
    T#6 extends Object declared in method <T#6,K#3,D#2,A#2,M>groupingBy(Function<? super T#6,? extends K#3>,Supplier<M>,Collector<? super T#6,A#2,D#2>)
    K#3 extends Object declared in method <T#6,K#3,D#2,A#2,M>groupingBy(Function<? super T#6,? extends K#3>,Supplier<M>,Collector<? super T#6,A#2,D#2>)
    D#2 extends Object declared in method <T#6,K#3,D#2,A#2,M>groupingBy(Function<? super T#6,? extends K#3>,Supplier<M>,Collector<? super T#6,A#2,D#2>)
    A#2 extends Object declared in method <T#6,K#3,D#2,A#2,M>groupingBy(Function<? super T#6,? extends K#3>,Supplier<M>,Collector<? super T#6,A#2,D#2>)
    M extends Map<K#3,D#2> declared in method <T#6,K#3,D#2,A#2,M>groupingBy(Function<? super T#6,? extends K#3>,Supplier<M>,Collector<? super T#6,A#2,D#2>)
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object from capture of ?
PlayTest.java:13: error: cannot find symbol
              Collectors.mapping(s -> s.charAt(0),
                                       ^
  symbol:   method charAt(int)
  location: variable s of type Object
PlayTest.java:12: error: invalid method reference
              String::length,
              ^
  non-static method length() cannot be referenced from a static context
3 errors


Is there any bug that was fixed in _45?
 
Mihaela Hetea
Greenhorn
Posts: 13
1
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is the error I have too. Tried also with javac from command line but doesn't work either.
Tried also with java x86 1.8.0_45 and with java 1.8.0_71, same error.
 
Ranch Hand
Posts: 241
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I get the same error, both from IntelliJ and from the command line. I have tried JDK 1.8.0_60 and the latest JDK 1.8.0_71 on Windows.

This is related to this thread.
 
Bartender
Posts: 5458
212
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Works for me, on jdk1.8.0_65 NetBeans:


Output:

 
T Vergilio
Ranch Hand
Posts: 241
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Piet,

But does it work if you replace

with
 
Piet Souris
Bartender
Posts: 5458
212
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm... but not with Compare instead of (c1, c2) ->
 
Piet Souris
Bartender
Posts: 5458
212
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That would be: NO!

and I do not understand this; Java 8 bug?
 
T Vergilio
Ranch Hand
Posts: 241
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Looks like it

Funny how it will accept



which has a different signature!
 
Piet Souris
Bartender
Posts: 5458
212
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, your remark brings me to


Works a treat!
 
T Vergilio
Ranch Hand
Posts: 241
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Indeed, how bizarre! It's looking more and more like a bug to me.
 
Piet Souris
Bartender
Posts: 5458
212
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, remarkable is that in

no type is specified in the right hand side of the assignment. It looks like the compiler
infers the type from the left hand side.

Now, if you use the RHS in the minBy(), could it be that the compiler cannot infer
the type, for the same reason?
 
Saloon Keeper
Posts: 15252
349
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's create an overview of all the type parameters:

Now we infer types from top to bottom by substituting type arguments into the requested return types. For brevity, we replace every occurrence of Map<Integer, Optional<Character>> with MAP:

Now we infer types from bottom to top by substituting return type arguments into the method arguments:

As you can see, U1 can't be inferred. The solution is to explicitly specify the type in one of the three incomplete method calls.

Either of the following solutions should work:

  • Comparator.<Character>naturalOrder()
  • Collectors.<Character>minBy()
  • (String s) -> s.charAt(0)


  • [edit]

    Sorry for the long lines, it's the only way I could format it with it still making sense.
     
    T Vergilio
    Ranch Hand
    Posts: 241
    5
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    It seems that way, since casting the argument also works:

     
    T Vergilio
    Ranch Hand
    Posts: 241
    5
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Stephan,

    Thanks for the insight. What I don't understand though is how it seems to work for certain people. Either the type can be inferred and it will always work, or it can't and it will never work.

    Don't you agree?
     
    Piet Souris
    Bartender
    Posts: 5458
    212
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Good heavens!

    But very educational. I know know that it is:

    Comparator.<Character>naturalOrder()

    No wonder all my attemps: Comparator<Character>.naturalOrder()
    failed. Never too old to learn, I guess.

    @T Vergilio
    Indeed. Maybe Jeanne can explain how she managed.

    @Stephan
    Great job!
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 15252
    349
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    T Vergilio wrote:What I don't understand though is how it seems to work for certain people. Either the type can be inferred and it will always work, or it can't and it will never work.


    I agree in part. Note that in my schema above, Collectors.minBy() could have inferred that U1 is Character, because Collectors.mapping() requested a Collector that produces an Optional<Character>. I think it was too complicated to implement at this time, but that doesn't mean it couldn't in the future.

    What's weird is that it works for Jeanne, who isn't using a particularly new Java version.

    Piet Souris wrote:No wonder all my attemps: Comparator<Character>.naturalOrder() failed. Never too old to learn, I guess.


    That's why I like the C# way of explicitly providing type arguments after the identifier of whatever it is you're providing the types to. For a generic class: List<Character>, for a generic method: Comparator.naturalOrder<Character>().
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 41763
    887
    Eclipse IDE VI Editor Java
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'm late to the party, but I agree it was a JDK "change of behavior." I had an older version of Java 8 in my path when I tried it on January 27th so that wasn't a valid test.
     
    Ranch Hand
    Posts: 91
    1
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'd buy pie (or   ) for everyone, but I'm too tired after going through all the variants and clicking the +1 button on the posts    
     
    Greenhorn
    Posts: 3
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Jeanne Boyarsky wrote:I'm late to the party, but I agree it was a JDK "change of behavior." I had an older version of Java 8 in my path when I tried it on January 27th so that wasn't a valid test.




    I think this should be added to list of errata (https://www.selikoff.net/jpt/)?
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 41763
    887
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Ramesh Natesan wrote:

    Jeanne Boyarsky wrote:I'm late to the party, but I agree it was a JDK "change of behavior." I had an older version of Java 8 in my path when I tried it on January 27th so that wasn't a valid test.




    I think this should be added to list of errata (https://www.selikoff.net/jpt/)?


    This thread is about the OCP book. Do you see an example that is wrong in the Java Practice Tests book?
     
    So I left, I came home, and I ate some pie. And then I read this tiny ad:
    a bit of art, as a gift, the permaculture playing cards
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic