Utilize basic read-write functions

Sky-Tiger

Typical use case:
Support various implementations of the same interface. In Flyway's case, this applies to the Jdbc drivers. Flyway supports many of them, and yet they are all accessed through the same API (Jdbc).

Advantage for the End-User:
A single library module to depend upon.
Smallest amount of code in KB as only code to support the common SPI is pulled in.

Disadvantage for the End-User:
No transitive dependency support. Must manually reference optional dependency in own project.
May have to configure which SPI implementation to use.

Advantage for the Library Developer:
Common SPI to program against, with compile-time checking and IDE completion.
A single module to maintain and release.

Disadvantage for the Library Developer:
Must match the SPI with its implementation at runtime. Failure to properly do so will result in Exceptions at runtime.
Should test the library with the different SPI implementations to ensure they behave as expected.

Sky-Tiger

A number of these strategies depend on being able to check whether a certain dependency is available at runtime and guard against using its related features if it isn't.

This sounds complicated, but it turns out to be relatively easy on the Java platform:
?
public static boolean isPresent(String className) {
    try {
        Class.forName(className);
        return true;
    } catch (Throwable ex) {
        // Class or one of its dependencies is not present...
        return false;
    }
}

...

if (isPresent("com.optionaldependency.DependencyClass")) {
    // This block will never execute when the dependency is not present
    // There is therefore no more risk of code throwing NoClassDefFoundException.
    executeCodeLinkingToDependency();
}

Sky-Tiger

Conclusion

The 5 different strategies each deal with different scenarios and different forces that must be balanced. Even in a relatively small library like Flyway, it wasn't possible to simply rely on a single one. Know them well and know when to use them. But if there has to be a single most important guideline to remember, let it be this one:

Always favor the convenience of the end-user over your own when designing your library or framework.

Sky-Tiger

In software, contrary to common belief, lines of code are a liability not an asset. As you gradually accumulate code, little by little the pain sets in. The complexity increases. It gets harder to understand. And eventually, quality suffers.

Dependencies only exacerbate this problem. With each dependency you add, you pull in more code, more APIs to learn and more potential bugs.

Transitive dependencies take this problem to 11. You now have the possible issue of conflicting dependencies! And before you know it ... you have landed in JAR Hell! So much for laughing at our Windows friends stuck in DLL Hell...

And yet, dependencies are a necessary evil. If you want to avoid reinventing the wheel or if you want to integrate with the outside world, there very often is no way to avoid them. In the spirit of doing the simplest thing that could possibly work, strive to reduce the number of dependencies to the absolute minimum required. Every single dependency you add should be weighed carefully: does the functional benefit outweigh the complexity cost?

Sky-Tiger

This quote comes from an article published on TheServerSide.com earlier this year about emerging cloud computing trends. It is fairly demonstrative of where cloud adoption stands now and where it's going. At the start of the year about a third of developers were using cloud based technologies and by the middle of next year, we may see the cloud users rise to about half of the development community.

Sky-Tiger

This may mean that many application developers are taking advantage of quick and easy cloud-based development tools. For companies that are taking this route to the cloud, the actual development may remain fairly close to the way it is now. The tough changes will likely be the headache of operations folks who are in charge of deployment and runtime management, while developers are able to take advantage of cloud-based software (potentially software as a service) that makes life easier.

Sky-Tiger

As Ryan Shriver pointed out to our own Cameron McKenzie, "Tools for source code control, continuous integration and automated testing have been around forever, long prior to the emergence of the cloud. But now, those tools are becoming easier to use than ever."

Platform as a Service (PaaS) is supposed to abstract the difficulties of infrastructure management away from the developers so they can focus on building better apps. However, some organizations may find more rewards in making deeper changes to the way they develop applications. In an article from SearchSOA.com, Java middleware expert Steve Millidge, explains that in order to really get the most advantage out of Infrastructure as a Service (IaaS), it's important for the developers to focus on service elasticity.

Sky-Tiger

Of course, Millidge is focused on a service-oriented architecture (SOA) approach. For organizations that haven't gotten into SOA, the route to the cloud may look very different. For more information on the cloud check out the cloud computing classroom at TheServerSide.com's Java University, which includes fifteen minute video lessons on:

The future of private vs. public cloud: Key decision points for Java strategists
How to achieve a state-of-the-art Java PaaS
Preparing for the impact of cloud computing on enterprise architecture
Scaling SOA services: New approaches to Elastic SOA in the cloud

Sky-Tiger

According to Millidge, one of the key factors for service elasticity in a cloud model is that "networking is dynamic. Servers come and go. Load balancers must be able to discover and use services dynamically." He warns against static typing, which developers would use in an on-premises data center with a known number of nodes. However, dynamic typing may be a challenge for some Java development teams.

Sky-Tiger

Disadvantage for the End-User:
No transitive dependency support. Must manually reference optional dependency in own project.
May have to configure which SPI implementation to use.

Advantage for the Library Developer: