Thanks for the review, I will apply the requested formatting next time. So I guess I am not running checkstyle correctly, because I did not see any of those errors in the report. I run it from command line "mvn checkstyle:checkstyle", and I have modified my local copy of pom.xml with the following:
inserted in <build>. Is there something I am missing ?
About "assert", In the case of private or package private methods, is it also required to turn them into runtime checks ? Is it acceptable to simply comment them if the performance impact is significant ?
interface Primes<T extends Number> -> agreed
implementation/performance question: I expect implementation for long to be significantly slower, as it is the case for gcd. int implementation uses long for some internal values, so a long implementation will need to use BigInteger at those places, that should slow down things... Also current int implementation contain an array with all primes smaller or equal to the cubic square of Integer.MAX_VALUE. Doing the same for Long.MAX_VALUE is going to significantly increase the size of the array, I am not sure if this is desirable -> in short some performance tricks applicable to int don't scale well. In case of isPrime, the trick to get a provable result using Miller-Rabin works well for int, but I have to search additional reference to get the magic numbers to scale it to long, and even after that, maybe we will end up with something slower than a true provable algorithm.
I am more inclined to share the same implementation for long and BigInteger.