100%

The EnumJ library has 100% code coverage again (according to the JaCoCo tool for Java 8). I used to be there in February, but because of many useful changes (like this, this, this, this and this and this and this) the percentage decreased along the way. It feels good to be back.

Still, not enough

Having 100% coverage does not mean the software is perfect. In fact, there is no such thing as perfect software as a “perfect program” would theoretically require an infinite succession of error blocks. Nevertheless, even for practical practical purposes 100% code coverage is not enough:

• code coverage usually means block coverage. Arc coverage, path coverage, condition coverage and method coverage are important metrics, too.
• code coverage doesn’t tell anything about missing features
• code coverage doesn’t tell anything about robustness, long-haul or scalability

The last point is very important for EnumJ.

What is next?

The goal is to make EnumJ a high-quality, industry-strength library – from easiness to use to code quality, to robustness, to scalability and to documentation. The user should not to feel it as a third-party library, but something like JDK or SDK+MSDN. The terms of comparison are, of course, the Java 8 streams and .NET LINQ.

Robustness

Both Java 8 streams and .NET LINQ are robust components. Nevertheless, EnumJ adds fault-tolerance to the mix and this puts special pressure on robustness.

Scalability

EnumJ is by design highly scalable, to degrees that Java 8 streams and .NET LINQ do not match. EnumJ enumerators and enumerables may undergo an insanely large number of compositions and still work as expected. A specialized battery of scalability tests is utterly necessary.

OBS: Java 8 streams are partially scalable. .NET LINQ is not scalable at all in what compositions are concerned.

Performance

EnumJ enumerators must be fast. My preliminary performance tests show they are about twice as fast as sequential Java 8 streams but more thorough performance testing is in order.

Long-haul

EnumJ must work virtually flawlessly for about three years under web-like usage - a conservative limit for software replacement in web servers. The techniques described here need to be applied.

Coverage

Even with 100% code coverage, EnumJ does not have 100% method coverage yet. Method coverage is necessary as protection against bugs introduced as the software evolves in the future.

Documentation

Complete and thorough JavaDocs will enforce a second, deep review of the whole code base and it will help with future maintenance. I intend to document internal classes as well.

Design

One or two documents sketching the design decisions that stand behind the scalability of EnumJ might be useful.

Publishing and promotion

The place to publish is obvious: Maven Central. Other venues where to publish and promote the usage of the library might be worthy to consider.

OBS: EnumJ can be used in many domains like functional programming over Java, Monte Carlo simulations, programming with constraints or even logic programming in Java. Promoting EnumJ might involve showing how to do those things with the library.

Conclusion

Achieving 100% code coverage is an important milestone in the development of EnumJ. But making it an industry-strength component requires more work. The progress of this work will provide the topics of next articles.