Summary

Tools for implementing OSID Providers.

The Need For Tooling

Stock tools are essential in OSID development. The OSID Specification does not instruct how OSID Providers ought to be implemented. The OSID Specification allows for a broad range of OSID Providers but it doesn't say that we need to spend our time writing directly off the interfaces from scratch.

The OSIDs are highly patterned. Any code developed for one OSID will be strikingly similar when adapted for another OSID.

Coding Conventions

The conventions used in this package may seem a bit unorthodox (or just anal).

Java Packaging

When we say "package," it means functional area. Every functional area is a Java package. Within each functional area, there is a Java package for every OSID, which may have sub-packages. There are lots of Java packages.

Abstract vs. Concrete Classes

Every concept is implemented using abstract classes. These are always in "spi" Java packages.

Some families of abstract classes need something implemented in order to fulfill their interface contract. Some of them are useful without having to subclass. Others not so much. Binding everything to a concrete class help validate the abstract classes (and were used to validate the OSIDs themselves).

All concrete classes are final.

Member Visibility

In the abstract classes, most non-OSID methods including its constructors are protected. You should have the ability to encapsulate whatever logic you like or override or constrain any behavior. A concrete class decides what will be visible outside the package.

Yes, Java Has an Import Statement

But it gets bloody confusing between the OSID Java interfaces, implementations classes, other Java interfaces in this framework, and external tools. As it turns out, there's useful information in the package name (not all of it) and it's important to always know where the OSID is.

Package-qualifying in some places and not others just looked stupid. Stretch your window to 120 lines.

No, Not Exception Swallowing

It happens. Within a functional area in Jamocha, OSID Java interfaces are often used compositionally or as decorators in lieu of defining a custom interface that does the same thing only more specific to our implementation (as opposed to consuming OSIDs through the OSID Runtime in which case they are OSID Adapters). OSIDs exceptions don't always apply in certain cases where it is known that it either can't happen or it doesn't matter.

Implement Statements Repeated Up the Class Hierarchies

Wanted to make it clear what OSID Java interface was being implemented.

Use the Source

Want to know more about how something works, read it! This wiki doesn't document every feature or nuance (not yet anyway).

Disclaimer

The code examples on the wiki are illustrative. They have not been compiled. You'll find working code in the source.

Browser not supported