what does it mean that "method reference needs an explicit target-type"?

[Anil Philip]

tb864615.OCPJAVASE17PT.c06.078

        var c5 = String::new;

java: cannot infer type for local variable c5
 (method reference needs an explicit target-type)

Why can't it take it as String?

String c5 = new String();

[Campbell Ritchie]

String::new, as you doubtless already know, is not a String at all, but a λ expression, which represents the activity of a certain functional interface. Or maybe several functional interfaces. Tell us how the compiler is going to know how many there are, or which of them you want. Maybe you wanted a Supplier<String>. Or maybe a different interface. Remember, λs were up and running 3½ years before var was introduced.
Supply a type instead of var for that statement and you will see it compile nicely.

[Paul Clapham]

Anil Philip wrote:Why can't it take it as String?

String c5 = new String();

Because that doesn't mean the same thing at all. The error message tells you it wants

T c5 = String::new;

where T is the target type. You'll find that "String" doesn't work there for the reasons that Campbell stated.

[Campbell Ritchie]

Last night, I wrote:String::new, as you doubtless already know, is not a String . . .

Nor is it a String constructor. The nearest I would say is, it is an expression that calls the constructor.

Or maybe several functional interfaces. . . .

I have two examples, which both compiled and ran correctly. In the second case, it shows that the new String is a copy of the original using the == same object operator.
What follows has been edited.

My JShell wrote:jshell> Function<String, String> f = String::new;
f ==> $Lambda/0x00007f37fc00a200@9807454

jshell> Supplier<String> s = String::new;
s ==> $Lambda/0x00007f37fc00a638@b1bc7ed
jshell> System.out.printf(
  ...> """
  ...> String produced = "%s"
  ...> """, s.get());
String produced = ""
$5 ==> java.io.PrintStream@64a294a6

jshell> List<String> words = Stream.of("Campbell", "Ritchie").map(f).toList();
words ==> [Campbell, Ritchie]

jshell> void foo()
  ...> {
  ...>     List<String> words = Stream.of("Campbell", "Ritchie").map(f).toList();
  ...>     System.out.println(words);
  ...>     System.out.printf(
  ...>     """
  ...>     words.get(0) == the literal "Campbell": %b
  ...>     """, words.get(0) == "Campbell");
  ...> }
|  created method foo()

jshell> foo()
[Campbell, Ritchie]
words.get(0) == the literal "Campbell": false

If I can find two interfaces that will act as targets for that λ expression, how would you expect the compiler to know which you want?

[Piet Souris]

Also a nice one is:

interface QuadFunction<A, B, C, D, E> {
    E apply(A a, B b, C c, D d);
}
QuadFunction<byte[], Integer, Integer, Charset, String> flup = String::new;

[Stephan van Hulst]

Campbell Ritchie wrote:The nearest I would say is, it is an expression that calls the constructor.

Just to be pedantic, it's not.

It's an expression that, when evaluated, returns a function that calls a constructor.

[Anil Philip]

Campbell Ritchie wrote:If I can find two interfaces that will act as targets for that λ expression, how would you expect the compiler to know which you want?

Thank you. I did not realize it would be ambiguous.
For Generics expressions, there are rules where if there is an ambiguity then the compiler defaults to a certain type like Object - I can't think of an example right now.
In the same way, I am wondering why the compiler couldn't apply some default rule (that makes sense) in this case of var and method reference, instead of complaining and giving up. Even giving up, the error message isn't clear.

[Stephan van Hulst]

Anil Philip wrote:For Generics expressions, there are rules where if there is an ambiguity then the compiler defaults to a certain type like Object

Please do try to think of an example, because this doesn't sound correct.

[Campbell Ritchie]

Anil Philip wrote:. . . For Generics . . . if there is an ambiguity then the compiler defaults to a certain type like Object  . . .

Stephan is right; you are more likely to get a warning or for the code to fail to compile.

. . . why the compiler couldn't apply some default rule . . .

When you put <XYZ>  anywhere in your code, you are instructing the compiler to go into fusspot mode and complain at the slightest ambiguity of types. The code will be completely type‑safe, iff there are no compiler warnings and @SuppressWarnings is only used where the programmer is absolutely sure the type is correct.
You cannot expect the compiler to infer types from λs. That is beyond the capabilities of most compilers, and if you look in the JLS (=Java® Language Specification), you will find that combining var and λs as you showed earlier is not permitted.

the error message isn't clear.

It is very difficult to write good compiler error messages.

[Anil Philip]

Campbell Ritchie wrote:Stephan is right; you are more likely to get a warning

A warning is still good - it will compile and run.
I will go through the generics chapter again and post back here if I find something or think of something.

[Campbell Ritchie]

Anil Philip wrote:. . . A warning is still good - it will compile and run. . . .

When you get a ClassCastException, you will not think it is good.
The whole idea of type‑safety is to obviate that sort of error. That is what generics is there for.

[Anil Philip]

Stephan van Hulst wrote:

Anil Philip wrote:For Generics expressions, there are rules where if there is an ambiguity then the compiler defaults to a certain type like Object

Please do try to think of an example, because this doesn't sound correct.

I don't know why Java has had to become so complex and bloated (in my humble opinion).
After studying for OCP17, I don't think there's any other language so complicated.
Even C++ which had a steep learning curve was nowhere this complicated.
In my previous job, I did not see wildcards and even lambdas being used by most developers. At code reviews,
they simply did not understand, and ignored any code that contained them. Most code was at a pre-Java 5 level.
Like a balloon floating out of a child's hand and into the blue sky all by itself, Java is passing out of reach of the average developer.
To what benefit?

[Stephan van Hulst]

Languages evolve, and a lot of modern programming languages are evolving in the same direction, believe it or not. It turns out that many developers not only want their language to be object oriented, but they also want a strong type system with covariant and contravariant generics and functional programming with lambdas and currying.

Not only languages that target the JVM (such as Java, Scala and Kotlin) have these features, but also other languages such as C#.

And if you think Java is hard to program in, wait 'til you try Haskell.

[Anil Philip]

Is Python the same way? (I need to learn it next).
I thought I read somewhere that Python is a simpler language and also used on the backend.
I wonder why it has become the language of AI and data science.

[Anil Philip]

Stephan van Hulst wrote:It turns out that many developers not only want their language to be object oriented, but they also want a strong type system with covariant and contravariant generics and functional programming with lambdas and currying.

... to add to my comment above, even if other languages implement covariance, contravariance and lambdas - do they do it simpler (without so much retrofitting) and easier to use and learn?

[Stephan van Hulst]

On the other hand, I've had my software break time and again in other languages when I updated a compiler or runtime.

In Java, not so much.

If you want the spiffiest cleanest new language to work with, there's plenty of good alternatives. If you want your application to run forever, Java is a very good choice.

[Campbell Ritchie]

Anil Philip wrote:Is Python the same way? (I need to learn it next). . . .

I suggest you learn Java® properly first. As Stephan says, the type‑safety is a lot better.

[Paul Clapham]

Stephan van Hulst wrote:If you want your application to run forever, Java is a very good choice.

One could interpret this as a comment about Java's performance, a slur that has been voiced since the day that Java was released. But to reply to your actual meaning: I have an application which I use frequently, written in Java. I first wrote it in about 2005, I think -- it replaced a version which was written in Turbo Pascal. The code I have now could never have been written in Turbo Pascal or any of its follow-on products, I'm sure. But it could be written in Java because Java has absorbed so many new features over time.

[Anil Philip]

Campbell Ritchie wrote:I suggest you learn Java® properly first.

To give you context for my comment:  
I started working in Java in 1998 and got the SCJP in 2000 and SCJD in 2003.
However, I did not keep up with the changes and fell behind.
I needed to reskill as I lost my job last year.
I am an average developer and learn slowly. In this industry, you have to learn quickly.
I get ideas but never get to implement them (I have to sit and learn everything first).
If I implemented them, I would have been more successful.
I thought I should get my Java certification up to date - but this has been a nightmare.
Compared to the Java I knew, this is bloated and complicated.
I really wonder if it was a mistake starting this exam. 1000 pages of reading over and over! I hear the Mughal book is also 1000 pages.
In interviews they seem to want SpringBoot, Microservice, CICD and Cloud components, more than Java.
They want you to do coding tasks straight from LeetCode and HackerRank.
In other words, Java is just a small part and not important at all.
Twenty years ago, just Java was enough.

[Stephan van Hulst]

I've never held programming certifications in high regard. Studying for a certification is not going to teach you how to be a good programmer. Instead, you need to program. Work on a project. Make mistakes. Ask questions.

I'm not saying a certification is useless: many companies seem impressed by them and with certifications on your resume it's easier to get a foot in the door. But personally I think they're a poor measure of actual skill.

Java IS a complex language. But it's also extremely stable, well documented and has a fantastic community. You also don't need to know all the ins and out of the Java language to be a good Java programmer. A lot of the learning can be done on the job or while working on a project.

[Anil Philip]

Stephan van Hulst wrote:I've never held programming certifications in high regard. Studying for a certification is not going to teach you how to be a good programmer. Instead, you need to program. Work on a project. Make mistakes. Ask questions.

I'm not saying a certification is useless: many companies seem impressed by them and with certifications on your resume it's easier to get a foot in the door. But personally I think they're a poor measure of actual skill.

I appreciate this advice.

[Anil Philip]

Paul Clapham wrote:I have an application which I use frequently, written in Java. I first wrote it in about 2005, I think -- it replaced a version which was written in Turbo Pascal. The code I have now could never have been written in Turbo Pascal or any of its follow-on products, I'm sure. But it could be written in Java because Java has absorbed so many new features over time.

Could you get that program to run in Java 11 without any code refactoring?

[Paul Clapham]

Anil Philip wrote:

Paul Clapham wrote:I have an application which I use frequently, written in Java. I first wrote it in about 2005, I think -- it replaced a version which was written in Turbo Pascal. The code I have now could never have been written in Turbo Pascal or any of its follow-on products, I'm sure. But it could be written in Java because Java has absorbed so many new features over time.

Could you get that program to run in Java 11 without any code refactoring?

It's running in Java 21 at the moment. I've done a lot of changes to it in order to use new features of Java so yes, if I wanted it to run in Java 11 I would have to refactor it by removing those changes. I can't imagine why I would want to do that though.

[Anil Philip]

Paul Clapham wrote:It's running in Java 21 at the moment. I've done a lot of changes to it in order to use new features of Java so yes, if I wanted it to run in Java 11 I would have to refactor it by removing those changes. I can't imagine why I would want to do that though.

I meant, would the code originally written in 2005 run in Java 11 without refactoring?
I think you will agree that it will not.
(in my previous job, moving from Java 8 to 11 was a separate project in itself, across the organization - forced by security issues, if I remember correctly).
So Java is not 100% backwardly compatible.
It would have been better if it had not tried to be so backwardly compatible and introduce so many complications and corner cases - especially with generics.
It should have instead made new versions simpler and easier to develop in,
pruning features that are recognized as "mistakes", but adopting new powerful features that other languages locked onto.
The cost would have been in code refactoring.

[Paul Clapham]

Anil Philip wrote:I meant, would the code originally written in 2005 run in Java 11 without refactoring? I think you will agree that it will not.

I wouldn't agree with that at all. I'm not aware of anything that I would have had to rewrite.

[Anil Philip]

Paul Clapham wrote:I wouldn't agree with that at all. I'm not aware of anything that I would have had to rewrite.

Perhaps this does not apply to your code https://docs.oracle.com/en/java/javase/11/migrate/index.html#GUID-4B3D2D73-359C-4ADA-937E-BAEA79CFDF0F

[Stephan van Hulst]

So your point of view is that just because there are a few incompatibilities, we should throw out the baby with the bathwater? That's a very narrow perspective.

How much effort did it really cost you to refactor your application for Java 11? And how much of that refactoring had to do with Java itself, and not some enterprise application container?

I can tell you from experience that I was spared a huge amount of pain and frustration when porting one of our customers' applications from Java 6 to Java 11. This was a huge project consisting of different services running on different hosts, and I was able to do it all by myself in less than two weeks.

Note that most incompatibilities stem from Java moving classes from the standard API to external libraries. The fix is often as easy as adding a dependency to the application.

I think your misgivings regarding Java's generics are also mostly misplaced. Sure, type erasure isn't very sexy and people used to other languages have been complaining about Java's lack of runtime generics for years, but in practice it really isn't a big issue. Personally I think it's much better than what C# did by adding a whole second library of collection types just to make them generic. Now all my collection types have to awkwardly extend two different collection hierarchies in a confusing and inconsistent way.

[Paul Clapham]

Anil Philip wrote:

Paul Clapham wrote:I wouldn't agree with that at all. I'm not aware of anything that I would have had to rewrite.

Perhaps this does not apply to your code https://docs.oracle.com/en/java/javase/11/migrate/index.html#GUID-4B3D2D73-359C-4ADA-937E-BAEA79CFDF0F

No, not at all.

Now, the place where I used to work did use Web Start, but the last I heard they were transitioning to one of those large all-encompassing business systems, which would be a large multi-year process.

[Anil Philip]

Stephan van Hulst wrote:That's a very narrow perspective.

I disagree.
I only see that to get the Java 17 certification, one has to study a 1000-page textbook (either Boyarsky's or Mughal's).
Now if it were something timeless like Mathematics or Algorithms - knowing that the knowledge gained would last 10, 20 years and more, I would be loving it.
But this feels like so much complicated bloat, adding layer upon layer and constructs to "cover" for past mistakes. Wearisome.
Chaff that will be gone with the wind.

I understand it is done to minimize the amount of refactoring to be done on old code when upgrading to the new version of Java - perhaps advances in AI will make it so that a tool will run through the code and refactor it automatically.

Another example, IO and NIO2. They couldn't just scrap IO and replace it with NIO2. They keep both.

[Stephan van Hulst]

Anil Philip wrote:I only see

As I said, a narrow perspective.

Your opinion is strongly colored by your recent experiences with the certification. The things you need to know to pass the certification exam are nothing like the things you need to know to develop and maintain a real world solution.

Consider having to maintain an application that you have to completely rewrite every two years because the underlying platform just decides to throw away all compatibility with every release. At some point, you just stop updating the underlying platform.

When Python went to version 3, some companies went out of business in the time it took for them to port their applications. Some applications are still running on Python 2, because it simply wasn't feasible to rewrite the application. That means no security fixes either. Now imagine Java breaking backwards compatibility every six months. It will be a dead language in fewer than five years.

Another example, IO and NIO2. They couldn't just scrap IO and replace it with NIO2. They keep both.

NIO2 is not a replacement of NIO, and NIO is not a replacement of Java IO. They are different APIs with different features and responsibilities.

Sure, there may be some overlap in functionality, but if Java stopped supporting the File class, it'd break so many applications that it would be front page news on par with the Y2K problem.