How to negate a method reference predicate
Predicate.not( … ) java-11 offers a new method Predicate#not So you can negate the method reference: Stream<String> s = …; long nonEmptyStrings = s.filter(Predicate.not(String::isEmpty)).count();
Predicate.not( … ) java-11 offers a new method Predicate#not So you can negate the method reference: Stream<String> s = …; long nonEmptyStrings = s.filter(Predicate.not(String::isEmpty)).count();
Lambdas are purely a call-site construct: the recipient of the lambda does not need to know that a Lambda is involved, instead it accepts an Interface with the appropriate method. In other words, you define or use a functional interface (i.e. an interface with a single method) that accepts and returns exactly what you want. … Read more
tl;dr Instant and LocalDateTime are two entirely different animals: One represents a moment, the other does not. Instant represents a moment, a specific point in the timeline. LocalDateTime represents a date and a time-of-day. But lacking a time zone or offset-from-UTC, this class cannot represent a moment. It represents potential moments along a range of … Read more
This will work, but the i -> i is doing some automatic unboxing which is why it “feels” strange. mapToInt converts the stream to an IntStream “of primitive int-valued elements”. Either of the following will work and better explain what the compiler is doing under the hood with your original syntax: integers.values().stream().mapToInt(i -> i.intValue()).sum(); integers.values().stream().mapToInt(Integer::intValue).sum();
There actually is a trick how to execute a parallel operation in a specific fork-join pool. If you execute it as a task in a fork-join pool, it stays there and does not use the common one. final int parallelism = 4; ForkJoinPool forkJoinPool = null; try { forkJoinPool = new ForkJoinPool(parallelism); final List<Integer> primes … Read more
What you are doing may be the simplest way, provided your stream stays sequential—otherwise you will have to put a call to sequential() before forEach. [later edit: the reason the call to sequential() is necessary is that the code as it stands (forEach(targetLongList::add)) would be racy if the stream was parallel. Even then, it will … Read more
The cleanest way is to start from a stream of indices: String[] names = {“Sam”, “Pamela”, “Dave”, “Pascal”, “Erik”}; IntStream.range(0, names.length) .filter(i -> names[i].length() <= i) .mapToObj(i -> names[i]) .collect(Collectors.toList()); The resulting list contains “Erik” only. One alternative which looks more familiar when you are used to for loops would be to maintain an ad … Read more
There’s a much better answer than using spliteratorUnknownSize directly, which is both easier and gets a better result. Iterable has a spliterator() method, so you should just use that to get your spliterator. In the worst case, it’s the same code (the default implementation uses spliteratorUnknownSize), but in the more common case, where your Iterable … Read more
The better practice is to use for-each. Besides violating the Keep It Simple, Stupid principle, the new-fangled forEach() has at least the following deficiencies: Can’t use non-final variables. So, code like the following can’t be turned into a forEach lambda: Object prev = null; for(Object curr : list) { if( prev != null ) foo(prev, … Read more
Short answer Date input = new Date(); LocalDate date = input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate(); Explanation Despite its name, java.util.Date represents an instant on the time-line, not a “date”. The actual data stored within the object is a long count of milliseconds since 1970-01-01T00:00Z (midnight at the start of 1970 GMT/UTC). The equivalent class to java.util.Date in JSR-310 is … Read more