Stephan van Hulst

ssiva raman wrote:why there two provided by sdk 2?

So people can choose what implementation they want to use, if they prefer one over the other.

I can find lot of ideas but want to know what is the right approach

If you don't have a strong preference, it probably doesn't matter too much. Just pick one.

Monica Shiralkar wrote:What would be a good simple example?

I already mentioned the quintessential functions map, filter and reduce.

And wanted to ask that while lambdas were introduced in Java 8, was it possible to write to above code using anonymous class before Java 8 ?

Yes.

Paul Clapham wrote:Sure. Even today, 15 years after Java 8 was released, you'll find Swing code using anonymous classes to respond to events. It's not necessarily that there's a learning curve, it's just easier to write code the same way as you did before, or the same way as the tutorials you're copying from. And most people wouldn't go back and change existing working code to use lambdas, either.

Let's not forget that many event listeners still can't be implemented using lambda expressions, because they are not functional interfaces: Either they contain multiple abstract methods (example: MouseListener) or they are an abstract class and not an interface (example: AbstractAction).

I just did a quick count of the interfaces of Java 8 that extend java.util.EventListener, and not even 50% of them are functional interfaces. That's not even taking into account all the abstract classes that people might want to extend instead.

I don't understand your question. Can you rephrase please?

final class Application {  private final Properties properties;  Application(Properties properties) {    this.properties = properties;  }  boolean isDebugEnabled() {    return (boolean) properties.get("debug");  } }

Welcome to CodeRanch, Martin!

I have given Peter a cow in recognition of how helpful their post appears to be. I'm not sure they're still around though.

Welcome to CodeRanch!

giannis vout wrote:I was expecting 1,1 since sheep++ returns the original value before increment.

Sure, but you're not printing the return value of the sheep++ expression. You're printing sheep.

Then I think it's fair to say that participants "must treat the rows as if they have actually been inserted".

Hi Darcy!

My experience with Agile development is that every company has their own way of doing it, and usually even every team within a company. Now, this is not necessarily a bad thing and I also don't think there is "one true Agile way".

My problem is that many teams appear to be insisting that their way is the "one true Agile way", and it's exactly this rigidity that, to me at least, appears to be counterproductive.

Do you have experience with this, or opinions or anecdotes?

Monica Shiralkar wrote:Thanks all. Is it so that while Java was having higher order functions before Java 8 but largely a lot of higher order functions were added in Java 8.?

I wouldn't even call it "a lot".

In version 8, some higher order functions were added that in functional languages are considered "standard". In pretty much every functional language, you will find some form of the map, filter, and reduce functions. Without some form of these functions, your API can hardly be called "functional".

The Stream API isn't really the special part about Java 8 though. Technically, it would have been possible for any third party library to provide this API before Java 8. In fact, I seem to recall that RxJava was already widely in use well before Java 8 appeared, and many people used it in order to bring a more functional programming style to Java.

Java 8 is special because it allowed you to implement functional interfaces using lambda expressions and method references.

Like the forEach method taking lambda expressions as argument.

This is probably the worst example. While the forEach() method can be considered a higher order function, its existence is only justified because Java is NOT a functional language. A purely functional language has no need for a forEach function.

Another example is comparator taking lambda expression as argument. Comparator has been since earlier in Java, but was ability of comparator to take lambda expression as argument in Java from earlier or got added in Java 8?

Comparator does not accept lambda expressions. You mean, Comparator is a functional interface, and therefore can be implemented using a lambda expression.

No, you could not implement Comparator using a lambda expression before Java 8, because lambda expressions are a language feature that got introduced in Java 8.

However, even though you could not implement Comparator using a lambda expression before Java 8, methods that accepted a Comparator might still be considered a higher order function even before Java 8. The reason is simple: The Comparator interface represents a functional type. Objects that implement that interface can be considered functions, and methods that accept those objects can be considered higher order functions.

annomous

Anonymous.

And despite these added in Java 8, if someone wanted to use functional programming in Java but not comfortable yet with lambda expressions then they were using annomous classes only until they would get familiar with lambda expressions in Java.

I don't think there would have been many of those people. Most people that were already familiar with functional programming would also already have been familiar with lambda expressions. Paul Clapham already pointed this out to you.

Paul Anilprem wrote:That depends on the isolation level.

Does the exam cover isolation levels?

Welcome to CodeRanch, Amer!

Rows that you have inserted are in fact in the table, it doesn't matter whether you commit them or not.

When the connection is closed before the rows are committed, there is a possibility that the transaction manager might roll back the uncommitted rows. Until that time, you must treat the rows as if they have actually been inserted.

You're not really using the lambda expressions correctly though. The point of a lambda expression is to pass the function it evaluates to to a higher order function, not to call it directly. Here is a better example:

Without lambda expressions, Python:
def is_even(x):    return x % 2 == 0 numbers = [1, 2, 3, 4, 5] even_numbers = list(filter(is_even, numbers))
With lambda expressions, Python:
numbers = [1, 2, 3, 4, 5] even_numbers = list(filter(lambda x: x % 2 == 0, numbers))
As you can see, lambda expressions in Python allow you to define a function inline with the higher order function call. This makes the code slightly less verbose, but the tradeoff is that your code becomes slightly more difficult to read.

Personally, I find that lambda expressions are rarely worth it. I prefer the more readable version where you declare a named function.

In Java, I would declare an isEven() method explicitly, and then pass it as a predicate function to the filter() call by using a method reference:
final class Numbers {  private static boolean isEven(int x) {    return x % 2 == 0;  }  public static void main(String... args) {    var numbers = List.of(1, 2, 3, 4, 5);    var evenNumbers = numbers.stream().filter(Numbers::isEven).toList();    System.out.println(evenNumbers);  } }

Didn't we already answer this question here?
https://coderanch.com/t/777533/languages/Lambda-fuctions-Python-compared-Java#3554430

You asked whether Java had higher order functions before Java 8. I said yes, Java's version of higher order functions already existed before Java 8. It might not have been possible to pass them lambda expressions or method references, but passing them a function object by way of an anonymous class instance was still possible.

Java was (and is) not really a functional programming language. But that doesn't mean that it doesn't support a form of functional programming.

Functional programming is rather a programming style than a technical feature. You can do it in pretty much any programming language. It's just that functional languages like Haskell, Erlang or JavaScript make it more easy and natural.

Where did you get the P_SALT value from in the first place. Is it also hardcoded in your PHP application?

This code is hopelessly insecure. Your application is begging to be hacked.

Welcome to CodeRanch Darcy, I hope you have fun with the book promotion!