Mike Simmons

Going back to the original question, I think there *is* a valid use case for using Streams here, rather than Lists, or writing a recursive method.  Unlike Lists (or any Collection), a Stream need not contain all elements in memory at once.  This can be important for large solutions - e.g. for 30 different elements, there are over a trillion possible combinations.  You don't want to try to save those all in memory.  Also, streams give you access to extensive additional capabilities, including making things faster with concurrency by simply adding .parallel() to the call.

Here's a way to answer the question as originally asked:
public static Stream<List<Integer>> powerSet(int elements) { return powerSet(elements, Collections.emptyList()); } private static Stream<List<Integer>> powerSet(int elements, List<Integer> suffix) { if (elements == 0) { return Stream.of(suffix); } int newElements = elements - 1; Supplier<Stream<List<Integer>>> supplier1 = () -> powerSet(newElements, suffix), supplier2 = () -> powerSet(newElements, concat(List.of(newElements), suffix)); return Stream.of(supplier1, supplier2).flatMap(Supplier::get); } private static <T> List<T> concat(Collection<? extends T> a, Collection<? extends T> b) { List<T> combined = new ArrayList<>(a.size() + b.size()); combined.addAll(a); combined.addAll(b); return Collections.unmodifiableList(combined); }
The key part of returning a new Stream is accomplished by:
Supplier<Stream<List<Integer>>> supplier1 = () -> powerSet(newElements, suffix), supplier2 = () -> powerSet(newElements, concat(List.of(newElements), suffix)); return Stream.of(supplier1, supplier2).flatMap(Supplier::get);
Note that an earlier version of the code did this instead:
return Stream.concat( powerSet(newElements, suffix), powerSet(newElements, concat(List.of(newElements), suffix)));
However this was undesirable; it had the effect of recursively creating all the nested streams at once when the stream is first created - leading to excessive memory use.  Better to use Suppliers and flatMap to defer the creation of each stream until the code is ready to actually use it.

I believe the problem is here:
threading.Thread(target = print_t('hello',1))
Try replacing those with:
threading.Thread(target = print_t, args=('hello',1))
The difference is, the first form invokes print_t immediately, calling it with the given arguments.  The second form lets the new thread call the method, after start() has been called.

Campbell Ritchie wrote:The “line” is the remainder of the current line.

Exactly.  I think the confusion here comes from the fact that the previous call to scanner.nextInt() consumes whatever digits were typed for the age, but it doesn't consume the newline characters after that.  So it doesn't actually go on to the next line.  And when findInLine(".") comes along after that, it finds the newline characters right away, and immediately identifies that as the end of the line it's looking for.  Very counterintuitive.  Good explanation, Campbell!

Yes, but that's after line 15.  What happens on line 15?  What does findInLine() do?

Campbell Ritchie wrote:

Piet Souris wrote:It is not advisable to use a double as key, . . .

Why not? A double will be boxed to a Double, and that is an immutable object. The problem I can see is that you will try something like
myMap.put(1.23, xxx)
and then not remember which “K” you used.
myMap.get1.2299999999999) won't find xxx.

That is exactly the problem.  Depending how these key are obtained, they may well have rounding errors, making them unreliable keys.  There are various possible workarounds.  You could switch to a String representation of the double, enforcing precise rounding rules consistently.  Or you could use a TreeMap or other NavigableMap instance, and use methods like floorKey() and ceilingKey() to find the two (or one, or zero) closest keys, and see if either one is "close enough", however you might choose to define that.

Incidentally, there is at least one good reason that Java was designed this way - it helps eliminate a common bug.  Consider this code:
if (x = 42) {     doSomething(); }
Note that it has a = rather than ==.  Probably, the author meant to use ==, to test if x is equal to 42.  However, since instead they used =, they are instead assigning x to be 42, and also returning 42 as a side effect.  In a language that considers 42 to be true, this will compile just fine, and doSomething() will always execute, since 42 is true.  Is that what the author intended?  Probably not - Java will instead give a compile error here, and make the author fix their error.

There's another issue here as well:
  if (otherUser.likesCats()) {     userBuilder.likesCats();   } else {     userBuilder.dislikesCats();   }
In the User class, likesCats() is a getter, returning a boolean.  In the UserBuilder class, likesCats() is a self-returning setter.  I find that confusing.  And if you ever need both a setter and a getter in the same class, it's a serious problem.  I'm usually all for getting rid of the get- and set- prefixes, but I think that only works if there's still a consistent rule for naming without them.  I would assume that a method name with no params, e.g. likesCats(), is a getter, while one with a param, likesCats(boolean), is a setter.  Consequently, I would prefer not to have any no-arg setters for boolean properties; they're confusing to me.

Hmmm, looks like IntelliJ's "replace constructor with builder" refactoring by default uses the setXxx() naming convention, and also a fluent style, returning this.  Fortunately, that's configurable - I just did "rename setters prefix" to make it blank, and it replaces setXxx() with xxx().

I don't like using setXxx() for this, as it leads people to expect a conventional setter, with void return type.  I prefer a fluent interface, returning the builder, and I find this conflicts with people's expectations for the "set" pattern.  I also seem to recall there was a tool we were using at one employer about ten years ago that complained whenever it found a setXxx() without a void return type - so we learned to avoid it.

I don't see an example in GoF that uses the setXxx() nomenclature.  But then, that book doesn't use any Java anyway, so it's not a good authority on Java naming conventions.  Design Patterns in Java does use setXxx(), but it also returns void.  Blech.  Check out Bloch's Effective Java, which just uses the attribute name (as Dave showed above).  That's the style I prefer.  Using withXxx() is also OK, but unnecessary, in my opinion.

Look at the SQL given with the error message:
insert into employee values(1,Shubham,100000.0)
What happens if you run this in a SQL client?  Does it work?  If not, what changes would you need to make to fix this?

There's a quick fix for the code you've shown, but more generally, it's probably a good idea to use a PreparedStatement for this.  Since you're using Spring's jdbcTemplate, this functionality is found in the 3-arg version of update(), not the single-arg version that you used.  See example here - the part about
int rows = template.update(updateSql, params, types);

[Posted before seeing Roel's reply; consider this a separate response to Murat - Mike]

The notion of what is "reachable" can be somewhat counterintuitive.  The compiler is required to follow certain rules about what it considered reachable, and what isn't.  These rules don't always match up with what is really reachable, or not.   But the compiler is required to follow them consistently, because Sun and Oracle don't want code to compile successfully on some compilers but not others.

In your original class A, the println is considered reachable because of the catch NumberFormatException, which, if an exception were caught there, would cause program execution to proceed on to the println statement.  In reality, there's no way that the code shown would ever throw a NumberFormatException, so this isn't really reachable.  However the compiler is required to assume that an unchecked exception could possibly be thrown from any code, anywhere, with no warning.  Since NumberFormatException is unchecked, the catch clause is considered reachable, even if there's no way it could really happen.

In the case of if (true) example given by Roel, there's another special rule on reachability, found in the Java Language Specification, with an explanation.  Can you find the relevant rule?

Also: is it really necessary to multiply all those numbers?  Couldn't you also just find the two biggest numbers, and the product of those two should be the biggest, overall?

That gets a bit more complicated if there are also negative numbers in the list - the two most negative numbers might have a bigger product than the two most positive numbers.

Edited to add: OK, I now see that's what the intent of the "optimized" code was.  Good, keep this idea.

If you're calculating the product of two ints, then long should be big enough already.  I suspect that the problem is that you're getting int overflow in the multiplication before it gets converted to int.  (As Carey noted earlier, I see.)  Take a look at the output of the following, and see if you can understand what's happening in each case:
    int a = Integer.MAX_VALUE;     long b = Integer.MAX_VALUE;     System.out.println(a * a);     System.out.println(a * b);     System.out.println(b * b);     System.out.println(Integer.MAX_VALUE * Integer.MAX_VALUE);     System.out.println(((long) Integer.MAX_VALUE) * Integer.MAX_VALUE);

Sorry, there is no "entries()" - I meant to say, "values()".  Use values() if you only need values.

Well, you can use forEach on the HashMap - not on an entry.  So:
countryListHsMp.forEach((k, v) -> {     System.out.print("Country: " + k);     System.out.print(", Capital: " + v);     System.out.println();     System.out.println("-----------------------------------------"); });
You can also use the entrySet(), or keySet() or entries() if you only need keys or only need entries.