Your code would need to iterate over all elements. If you want to make sure that there are no duplicates simple method like public static <T> boolean areAllUnique(List<T> list){ Set<T> set = new HashSet<>(); for (T t: list){ if (!set.add(t)) return false; } return true; } would be more efficient since it can give you … Read more
You can do it with groupingBy. Assuming that your input is a List<Dog>, the Map member inside the Dog class is called map, and the Breed is stored for the “Breed” key : List<Dog> dogs = … Map<String, List<Dog>> map = dogs.stream() .collect(Collectors.groupingBy(d -> d.map.get(“Breed”)));
@Test public void test14() throws Exception { Map<String, Integer> m1 = ImmutableMap.of(“a”, 2, “b”, 3); Map<String, Integer> m2 = ImmutableMap.of(“a”, 3, “c”, 4); Map<String, Integer> mx = Stream.of(m1, m2) .map(Map::entrySet) // converts each map into an entry set .flatMap(Collection::stream) // converts each set into an entry stream, then // “concatenates” it in place of the … Read more
There’s lots of performance advice here, but sadly much of it is guesswork, and little of it points to the real performance considerations. @Holger gets it right by pointing out that we should resist the seemingly overwhelming tendency to let the performance tail wag the API design dog. While there are a zillion considerations that … Read more
I had the same kind of problem. This failed, because groupingBy performs Objects.requireNonNull on the value returned from the classifier: Map<Long, List<ClaimEvent>> map = events.stream() .filter(event -> eventTypeIds.contains(event.getClaimEventTypeId())) .collect(groupingBy(ClaimEvent::getSubprocessId)); Using Optional, this works: Map<Optional<Long>, List<ClaimEvent>> map = events.stream() .filter(event -> eventTypeIds.contains(event.getClaimEventTypeId())) .collect(groupingBy(event -> Optional.ofNullable(event.getSubprocessId())));
If it’s the Items that may be null, use @rgettman’s solution. If it’s the LocalDates that may be null, use this: items.stream() .sorted(Comparator.comparing(Item::getCreateDt, Comparator.nullsLast(Comparator.reverseOrder()))); In either case, note that sorted().findFirst() is likely to be inefficient as most standard implementations sort the entire stream first. You should use Stream.min instead.
I have to admit that I had difficulties too when I first tried to find out the actual meaning of the characteristics and had the feeling that their meaning was not clearly settled during the implementation phase of Java 8 and is used inconsistently for that reason. Consider Spliterator.IMMUTABLE: Characteristic value signifying that the element source … Read more
Yes, this was a deliberate decision. We considered both alternatives. The operating design principle here is “whoever acquires the resource should release the resource”. Files don’t auto-close when you read to EOF; we expect files to be closed explicitly by whoever opened them. Streams that are backed by IO resources are the same. Fortunately, the … Read more
What you have here are two stream pipelines. These stream pipelines each consist of a source, several intermediate operations, and a terminal operation. But the intermediate operations are lazy. This means that nothing happens unless a downstream operation requires an item. When it does, then the intermediate operation does all it needs to produce the … Read more
There are several issues going on here in parallel, as it were. The first is that solving a problem in parallel always involves performing more actual work than doing it sequentially. Overhead is involved in splitting the work among several threads and joining or merging the results. Problems like converting short strings to lower-case are … Read more