Koloboke jar size

[nicoulaj]

Koloboke jar size

[leventov]

@nicoulaj what about Koloboke Compile? Why doesn't it work for you?

[nicoulaj]

@leventov I did not not know about it, thanks.

After giving it a try, it does work, but it has the following drawbacks in my use case:

1. I work on a quite big project, and we already had bad experiences with annotation processors generating code (JMH, to name it), due to Eclipse incremental compilation. Eclipse would "forget" to invoke the annotation processor on change, and you run old code without being aware. For JMH, we ended up removing the annoation processor, and developping our own code that would invoke it at runtime before running the benchmarks. We try to stay away from it when not really needed.
2. When working with a large team of developers, it is easier to tell people to just use HashIntSets/etc factories than to learn how to use koloboke-compile, which requires a bit more investment. And we have to pay attention so that developers do not create duplicate implementations everywhere.

For these reasons, I prefer to stick with good old compile dependency, but I understand koloboke-compile answers this need.

Anyway, the default static factories are contained in the API jar, so even when using koloboke-compile, someone could call it and get this kind of error at runtime:

java.lang.ExceptionInInitializerError: null
      at com.koloboke.collect.set.hash.HashIntSets.getDefaultFactory(HashIntSets.java:51)
    at com.koloboke.collect.set.hash.HashIntSets.newMutableSet(HashIntSets.java:70)
Caused by: java.util.NoSuchElementException: null
    at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:365)
      at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
    at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
    at com.koloboke.collect.set.hash.HashIntSets$DefaultFactoryHolder.<clinit>(HashIntSets.java:38)
    ... 33 common frames omitted

So in the end, I think the most simple solution could be to:

• move the HashIntSets/etc factories to the impl jar
• no need to use ServiceLoader then

[leventov]

@nicoulaj

1. Unlike benchmarks, abstract classes (or interfaces) from which Koloboke Compile derives implementations are not supposed to be changed often, if ever since creation. Maybe only for adding new abstract methods or static factory methods, but you will immediately catch omission in compile time if Eclipse will "forget" to regenerate implementations in this case.
2. In Koloboke Compile it is supposed that you create abstract classes with static factory methods in it, as a single entry point. People don't have to learn Koloboke Compile, they can just use com.yourcompany.collections.YourHashIntSet.createWithExpectedSize() or something like that. Similar to HashIntSets, but defined by you.
3. Indeed, presence of classes HashIntSets in runtime deps needed for Koloboke Compile seems like a problem I didn't think about before; thanks for observation. In a long term it will be resolved by Koloboke Compile not requiring any runtime deps; In the meantime classes like HashIntSets may be inhibited in IDE settings (prevent from import, prohibit, mark as deprecated, etc.)

Nevertheless I acknowledge that api/impl jar separation of koloboke was an "overdesigned" decision and doens't really help anybody. I will try to do the next release unified.

[nicoulaj]

Anyway, this is a very minor annoyance, but thanks for listening :)