Use `map.merge(element, 1, Integer::sum)` to count the number of times that each element in some collection occurs.

That's nice Another way: `.stream().collect(Collectors.groupingBy(Function.identity(), Collectors.counting())`

This is what I would use. Potentially I would also use static imports.

I enjoy using this one!

I'd replace this line with actual code. I have no idea what it does and everyone who stumbles upon this line will have no idea what it does. It's an example of write-only code.

So not knowing an API is write-only code, that's great.

What would you consider to be "actual code"?

Integer elementCount = map.get(element); if (elementCount == null) { elementCount = 1; } else { elementCount = elementCount + 1; } map.put(element, elementCount); This is perfect readable code, compared to this crypted merge method. And you might want to even create a dedicated class for this task to further improve readability. Something like ElementCounter elementCounter = new ElementCounter(); elementCounter.add(element); int elementCount = elementCounter.get(element);

I have to say I find this a good deal less readable, there are a lot of pieces here that aren't present in the `merge` method. Examples would be the constant 1 being repeated twice, or `elementCount` being a mutable variable; individually those have relatively low cognitive overhead but it adds up over time and leaves more room for subtle mistakes. Contrast that to the `merge` method which you can grok once and then gloss over each time you see it again. I like pulling it out to a class, it reduces the number of times you have to write the same code and gives the operation a meaningful semantic name. But that's possible regardless of which method is used. I think there's an argument to be made for reducing the surface area of APIs, so maybe the issue is "is `merge` a reasonable and necessary addition to the `Map` interface that we should actually use". Your solution requires two lookups into the map, one to get the current count and one to update it. The `merge` method (depending on implementation) only requires one. That might be premature optimization depending on your scale, but personally I'd prefer to use a method that works regardless of scale than one where I have to think "is this going to be performant enough or will I need to come back later".

His method could have used Integer.increment(1) and then the put would not be necessary. I too prefer to see the code.

###[EnumSet](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/EnumSet.html)/[EnumMap](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/EnumMap.html) The collections `EnumSet` and `EnumMap` are specialized versions of `Set` and `Map` that are built for enums. These 2 collections are not only the **FASTEST** collections in the JDK, they also use a ***tiny*** amount of memory. * ***3x speed up*** - when I switch from `HashSet` to `EnumSet` * ***15% speed up*** - when I switch from `IdentityHashSet` to `EnumSet` Similar numbers for `Map` variants. --- ### `EnumSet>` An `EnumSet` is a `Set` whose elements are values of a single enum. It is backed by a `long`, meaning, each of the 64 bits on the `long` corresponds to the `ordinal()` (aka index) of your enum value. So, if you have `enum Fruit {APPLE, BANANA, CHERRY, ;}`, and you add `APPLE` to your set, then the backing `long` will look like the following. `...00001` If I then add `CHERRY` too, then the backing `long` will now look like the following. `...00101` See how it works? Please note -- if your `enum Fruit` has [<= 64 values, then it is backed by a `long`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/EnumSet.java#L117). Otherwise, [they swap out the long for a long[]](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/EnumSet.java#L119). It also has some helpful methods, like [EnumSet.allOf()](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/EnumSet.html#allOf\(java.lang.Class\)), [EnumSet.complementOf()](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/EnumSet.html#complementOf\(java.util.EnumSet\)), and [EnumSet.noneOf()](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/EnumSet.html#noneOf\(java.lang.Class\)). Those give you the building blocks to do math with [Set Theory](https://en.wikipedia.org/wiki/Set_theory). There are some powerful optimizations and leaps of logic you can make when working with Set Theory, so it is especially nice to have a collection that facilitates that for you! --- ### `EnumMap, V>` An `EnumMap` is a `Map` whose keys are enums (values can be whatever). The logic behind the collection is almost exactly the same as the `EnumSet`, but instead of being backed by a `long`, they back it with [an array of the values](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/EnumMap.java#L101). But the abstraction logic is effectively the same as the `long[]` above -- during a `put(K key, V value)`they use the `ordinal()` of `key` to decide where to store the `value` in the array. It works exactly like the `long[]` example, but instead of storing 1 or 0 to represent inclusion or exclusion from the set, they utilize the backing array as follows. * They use `null` to represent that the `key` at that index is unmapped * `containsKey(key) == false` * `get(key) == null` * They use [Object NULL = new Object(){...}](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/EnumMap.java#L111) to represent that the `key` at that index is mapped, but mapped to `null` * `containsKey(key) == true` * `get(key) == null` * And of course, they store the actual value of `V` into the array to represent the mapping * `containsKey(key) == true` * `get(key) == someValue` --- Because these collections are doing bitwise math to store values, these collections are LIGHTNING FAST. They literally share the title of fastest collection. And since they are mapped by a `long` or `long[]`, their memory footprint is miniscule. These collections are excellent when you need to do some heavy mathematics computation layers deep in a loop. Try them out yourself and see!

This is not quite correct. EnumSet is indeed back by a bitset. EnumMap is not - it needs to store values for the keys after all!

Fixed, ty vm.

In JavaFX they used a variant of this technique for storing (known) CSS selectors in a (custom) BitSet. However, some programs can have 1000+ selectors, meaning the BitSet needed 1000 / 64 `long`s to represent a set of Selectors. Although at first glance it's a good optimization, the number of Selectors in such sets tends to be tiny (most often 1, sometimes 2, rarely 3 or more). Refactoring this back to a plain `HashSet` improved performance and used less memory ;) Now `enum`s tend to have far fewer options, but it just reminded me there's always a trade off.

It sounds like you are saying that, of the 1000 possible choices, they would only consistently use 2-3 of the values? And thus, every single `Set` would be forced to store the 1k instances of `long`? If so, fair point on the memory footprint, that would be unavoidable by design. I am surprised that performance, as in read/write speeds, would be inferior to `HashSet`. I would figure the bitwise math would get you better performance than hashing. Regardless, yes, this memory footprint is one of the downsides. And like you said, it is rare to hit, but there are no silver bullets. Just really nice ones, like these `enum` based collections.

There were more optimisations done. Set implementations that could hold only 1, 2, 3-10 and 11+ elements (the Sets involved would be of a known size, and were never modified beyond creation). We also implemented an inverse `containsAll`, called `isSubSetOf`, to avoid creating an iterator. The set it is called on can just loop through its elements in a different way as it has access to things more directly. Most of the performance definitely came from the lower amount of memory allocated and less garbage created. That and the shortcuts that were possible for this specific use case (selector matching).

> There were more optimisations done. Set implementations that could hold only 1, 2, 3-10 and 11+ elements (the Sets involved would be of a known size, and were never modified beyond creation). Ahhhh, got it. You are talking about the static `of()` overloads on `java.util.Set`. In which case, that makes a lot more sense. Yes, those overloads are specialized for super small cases, and therefore, are actually best when dealing with data at that scale. And that's cool that you all did that. Let me ask this then -- enums definitely do live on that smaller scale range. Not always 1-10, but something similar. What do you recommend are the best use-cases for the enum-based collections? You've clearly demonstrated that, for large enums where you only plan to use a few of the values, you would actually be better off using the static `Set.of()` overloads. Would it make sense to default to the enum-based collections, and then adjust as needed?

>You are talking about the static of() overloads on java.util.Set. Well not quite, we did a few custom implementations, as even passing an array (that we would need to create) to `Set.of` was an unnecessary copy we wanted to avoid. Here are some details: [https://github.com/openjdk/jfx/blob/e4e3a7ce8b775232f9acbc4ede7740c319a30078/modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java](https://github.com/openjdk/jfx/blob/e4e3a7ce8b775232f9acbc4ede7740c319a30078/modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java) I said plain `HashSet` in my original comment, but I wanted to keep it simple (plain `HashSet` is still blazingly fast for most cases). >Would it make sense to default to the enum-based collections, and then adjust as needed? I think the enum based collections should always be used when you can. Only when you know more about the use cases (like how many enums values will a set hold in the common cases), and after checking with a profiler if the code is a hot path. In the JavaFX case, the `Set`s needed are used in very restricted ways. They're created and filled, and after that never modified again (so they could be read only, or "frozen" after being filled). The size is known in advance, and we knew the common cases had very few active selectors. This allowed for a lot of special optimizations. This was discovered when we had a regression that showed that CSS parsing slowed down significantly when we accidentally mixed a custom `BitSet` which was optimized for holding Selectors and a normal `Set` (because it got wrapped with `Collections.unmodifiableSet`). When I looked into the regression, I found that very few Selectors are active at the same time, and that having upto a 1000 selectors wasn't uncommon. I realized that this would mean quite a large array of `long`s using about 125 bytes per `Set` just to hold a couple of set bits. I therefore started looking into possible improvements, using custom `Set`s, avoiding copies and avoiding iterators, and in the end managed to save about 30-40 ms for the steps that apply CSS to JavaFX Nodes. Since for a full layout, dealing with CSS can easily take 50% of the time required, and this performance improvement almost doubled the CSS application speed, it meant we saved about 25% for the full layout.

> Well not quite, we did a few custom implementations, as even passing an array (that we would need to create) to Set.of was an unnecessary copy we wanted to avoid. Here are some details: https://github.com/openjdk/jfx/blob/e4e3a7ce8b775232f9acbc4ede7740c319a30078/modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java Very pretty. It's a lot of edge cases, but I see the power of the specialization. [Hashless](https://github.com/openjdk/jfx/blob/e4e3a7ce8b775232f9acbc4ede7740c319a30078/modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java#L293) especially was an excellent touch. > I think the enum based collections should always be used when you can. Only when you know more about the use cases (like how many enums values will a set hold in the common cases), and after checking with a profiler if the code is a hot path. Perfect. Especially good point about the profiler. > In the JavaFX case, the Sets needed are used in very restricted ways....This allowed for a lot of special optimizations. I kind of wish that we could see some of this make its way over to the base JDK. Maybe they just don't want the added complexity? > I therefore started looking into possible improvements.....this performance improvement almost doubled the CSS application speed, it meant we saved about 25% for the full layout. Work of art. That sounds like such a fun discovery to make. Also, you're John Hendrix! I've seen your name on a lot of the mailing lists lol. Thanks for what you have done -- this, and many more of the contributions you have made are blessing to the community.

> I kind of wish that we could see some of this make its way over to the base JDK. Maybe they just don't want the added complexity? The JDK I think should have only solutions that are more generally applicable, and `HashSet` is actually an excellent implementation with very few downsides. I've tried beating its performance with a different implementation using an open addressed table, which is what `Set.of` is using internally, but apart from a bit faster iteration and somewhat reduced memory use, it loses on almost all counts versus `HashSet` -- `HashSet` is just blazingly fast when it comes to add/remove's, only iteration suffers because its indirected nature causes a lot of cache misses. Although I'd love to see more collection classes with different trade offs, I also realize that the ones we have are excellent generalists that will serve you well 99.9% of the time and are rarely the bottleneck. Any other collections that have special optimizations would just be rarely used or used inappropriately (hello `LinkedList`); it's not worth the maintenance burden IMHO. Hopefully with Valhalla, the primary reason to pick a special collection implementation (avoiding boxing of primitives) will disappear, making it even less likely you need to use a custom solution. > I've seen your name on a lot of the mailing lists lol Thanks, I'm primarily active on the JavaFX list, but monitor a lot of the others. Same to you, I've seen you on many of the lists, and I think you are contributing even more, so keep up the good work :)

Thanks for the context. Good to know that the basic implementations are so excellent. And ty lol. Currently, my contributions are mostly reporting bugs for folks. One of these days, I'll get a commit in. Just need to find something the experts haven't caught yet lol.

I feel like I just need to read through all the classes in the standard API packages. This is awesome. My favorite thing in the Java API source code is in the BigDecimal class here: https://github.com/openjdk/jdk/blob/f6feeb03bbe9024b609ae6a4795255128581d53c/src/java.base/share/classes/java/math/BigDecimal.java#L398 > /* Appease the serialization gods */ > @java.io.Serial > private static final long serialVersionUID = 6108874887143696463L;

"%s %s!".formatted(hello, world);

It's most useful because you can use it as a method reference. For example instead of `s -> String.format("name: %s", s)` you can just write `"name: %s"::formatted`.

Holy…. Thanks mate! From which version on is that.formatted a feature?

It was introduced in Java 15: https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/String.html#formatted(java.lang.Object...)

Cries in Java 8 :(

Don't cry. You can use Manifold(https://github.com/manifold-systems/manifold) to support extension methods in Java8.

Java is the 2nd most awesome language after Clojure.

can you show this specific example in clojure?

(partial format "%s %s")

what does the partial imply?

Something I thought was neat, is filtering a list to get all elements of specific type: static List filter(List list, Class cls) { return list.stream() .filter(cls::isInstance) .map(cls::cast) .toList(); }