Stephan van Hulst

Maybe in the case of lambda expressions, but it seems unreasonable to disallow method references that reference pre-existing methods that weren't necessarily written to implement a specific functional interface.

It really depends on what you mean by "standard functional interfaces".

There's plenty of functional interfaces in the standard API that return void. For instance, Swing has a bunch of listener interfaces. ActionListener springs to mind.

Didn't they mean that, if the functional interface contains an abstract method that returns void, the return type of the lambda body or method reference doesn't matter?

In the first program you're trying to add Integer to List<?>.

In the second program you're getting Object out of List<?>.

So you didn't do the same thing.

Tim, you'd still need to install Lombok into Eclipse separately, because it needs a separate compiler/code analyzer that knows to convert Lombok magic to plain Java.

Did you already install Lombok into Eclipse? Just declaring the Maven dependency is not enough.

Anyway, what's the point of declaring a variable of type var anyway, if you're going to cast it to String immediately afterward?

It depends on your definition of "reduction operation".

If by "reduction operation" you specifically mean the reduce() method, then not all terminal operations are reduction operations. For instance, Stream.count() is a different terminal operation.

If by "reduction operation" you mean a terminal operation that returns a single value type, then still not all terminal operations are reduction operations. For instance, according to this definition, Stream.count() would be a reduction operation, but Stream.toArray() would not.

If by "reduction operation" you mean any operation that consumes the stream to produce a final result, then yes, all terminal operations are reduction operations. According to this definition, you could say that Stream.toArray() "reduces" a stream of elements to an array. However, even here there is some gray area:

Does Stream.iterator() really return a "final value"?

When the return type is void, such as with Stream.close(), can you really say that the stream has been reduced to a result?

You can see that the answer to your question is rather philosophical in nature. In practice, when discussing a Java issue, it's better to use well defined terms such "terminal operation" in preference to vague terms such as "reduction operation".

Suhaas Parekh wrote:In the javadoc it is mentioned there are 2 ways to call an instance method by using method reference.

You mean there are different ways to "pass" a method, not "call". When you use a method reference, you don't call the referenced method directly.

Anyway, please quote your sources. I'm not aware of any Javadoc that explains how to use method references.

I cannot really understand whats the difference and when to use what.

You use the variant that starts with a type name when the functional interface that you're trying to implement DOES, as its first parameter, expect an argument of the type that you're using the method reference on:
void pickColor(Function<? super Palette, ? extends Color> colorPicker) {  ... } ... pickColor(Palette::getBackgroundColor);

You use the variant that starts with an object reference when the functional interface that you're trying to implement DOES NOT, as its first parameter, expect an argument of the type of the object that you're using the method reference on:
void pickColor(Supplier<? extends Color> colorProvider) {  ... } ... pickColor(myPalette::getBackgroundColor);
In the first example, pickColor() needs a function that implements Function.apply(? super Palette). The first parameter of the apply() method takes a Palette, so if you want to use a method reference to implement the apply() method, you can use Palette::getBackgroundColor.

In the second example, pickColor() needs a function that implements Supplier.get(). The first parameter of the get() method does NOT take a Palette (in fact, it takes no arguments at all), so if you want to use a method reference to implement the get() method, you must use myPalette::getBackgroundColor, where myPalette is a reference to an object of type Palette.

The main method is not the proper place to get beans from the application context. It's only there to set up the application context.

When a request hits your application, Spring will create controllers and inject beans automatically. You just need to annotate your classes with annotations that indicate that those instances are also managed by Spring. Examples include @Component, @Controller, etc.

Xarzu Thompson wrote:What are the pros and cons of plain PHP or Classic ASP?

Any attempt at making such a list is invariably going to be incomplete and vague. I can only offer you a very broad comparison of server-side versus client-side applications.

Client-side applications have the advantage that they can update the user interface without reloading the page.

Server-side applications have the advantage that they run "privately", meaning the user can't see or alter the code or the data that the code is running on.

What is wrong with having a website written in this instead of the trendy JavaScript Frameworks like React, Angular etc.?

"Wrong" depends on the purpose of the website. A site written completely in a server-side language will not be able to update the user interface except through page reloads. If your application state rarely changes as a result of user input (for example, when your website is purely informational, such as an encyclopedia, user manual or educational pamphlet) then you don't need any client-side code except for the static HTML.

If on the other hand you want your user interface to react to user-input responsively, using only server-side code is not going to cut it. Another drawback is that validating user input on the server-side without pre-validating it on the client can put undue strain on a server. If you can validate user input on the client side and prevent a round-trip when the user has input invalid data, do it. However, even if you validate user input on the client-side, you must ALWAYS validate it on the server-side a second time to prevent tampering.

Your question implies that it is not uncommon to write an application completely in client-side code. This is not the case. Almost every web application will interact with a server, in which case you will need at least *some* server-side code. Applications written completely in client-side code are typically simple tools such as calculators or encoders/decoders, or single player games.

What does a JavaScript framework or Node.js bring to the table that would otherwise be lacking?

Node.js is a JavaScript runtime that typically runs on the server-side. Running JavaScript on Node.js is no different from running PHP on an AMP stack or ASP.NET on IIS.

I think you mean, what does running JavaScript in the browser bring to the table. I explained this earlier.

All I know right now is that it is written in PHP and Classic ASP. I am in the process of investigating these scripting languages and I want to know what the opinion of other developers are.

Don't call them scripting languages. The phrase "scripting language" is meaningless. Call them "programming languages" or just "languages".

There's not much to say here. If the website you have to maintain doesn't use client-side programming, it won't be able to react to user-input responsively. If the website doesn't take (much) user input, it might not even need client-side programming.

Your inquiry seems to be: "what benefit does BufferedInputStream provide when I pass an array to the read() method that has a size similar to the buffer size used by the BufferedInputStream internally?"

Multiple contributors have pointed out that in such a case, there is no benefit.

I added that such a case is purely academic. In practice, you would virtually never pass an array of such a large size to the read() method, because there is no good use case for it.

Nyeng Gyang wrote:If you would take a moment to compare your quoted remarks above with my updated rule

I will not waste my time.

Your "rules" are overly complex, unnecessarily loquacious, and plainly put, a headache to read.

Once again you insist that any confusion in this matter is caused by all except the imperspicuity of your own posts.

The original code is just a demonstration of how using a buffered stream can increase throughput when compared to a bare file stream.

Yes, you can change the amount of bytes read from the stream to coincide with the size of the buffer used internally by the buffered stream, and it will effectively make the buffered stream pointless, but such a scenario is not probable in the real world.

In the real world, you typically only want to work with a handful of bytes at a time, not thousands. Requesting only a handful of bytes at a time from a file without buffering input is extremely slow.

Nyeng Gyang wrote:Practically every aspect of computer programming is the existence and application of rules, whether it is the programmer following these rules as they write code or it is the compiler checking whether a programmer has followed these rules as well as enforcing that a programmer follows the rules.

Paul's point is that it's not helpful to generate additional rules that are overly complex, especially when they're not even correct.


There really is no need to make it so difficult:

1) The compiler determines what overload will be called, based on the formal type of the reference you're calling the method on AND the formal types of the method arguments.

2) Of the overload picked by the compiler, the runtime determines what override it will call, based on the actual type of the reference you're calling the method on.



In your original example, Reader is the formal type of the in variable. Reader has a read() method that takes no parameters, so the compiler raises no error on line 8. At runtime, the actual type of in would be BufferedReader, so the BufferedReader.read() override would be called.

On the other hand, Reader has no readLine() method declared, so the compiler can't determine an overload to be called, so it raises a compiler error. That the actual type would be BufferedReader is of no consequence, because the application never reaches runtime.


Make of this what you want. If you need to rewrite it to a set of rules that only make sense to you, that is fine, but we can't help you with those, because they don't make sense to us.