Download SDK

Subscribe to our Shark-news- mailing list to get announcements about new releases and patches.

Current version

SharkFW 2.13.1
SharkFW changelog 2.13.1
Javadoc SharkFW 2.13
Current Javadoc online reference.

Previous versions

2.13.0, 2.12.1, 2.12.0, 2.11.0, 2.10.1, 2.9.0, 2.8.3, 2.8.2, 2.8.1, 2.8.0, 2.7.0, 2.0.0

Working with the source code

You can also access Shark framwork source code directly at Github which is open for reading even if your are not registered. The project is open for new developers. Volunteers are welcome. Send an email.

Setting up your development environment for J2SE and Android

You can set up our development environment with the source from GitHub. There are two options: Working with J2SE or Android. In any case, the following folder must be part of your sources:

core (interfaces and platform independent implementations of key Shark concept)

coreApps (platform independent implementations application building blocks)

j2se_android (implementations that work in Android and J2SE)

In most cases, peer should be able to communicate with e-mail. In that case, add

j2seMail to your source path. Also add javamail to your lib folder!

Those packages are sufficient to work at the framework itself. Any code works with J2SE and Android. Graphical user interface (GUI) are usually written for a specific platform. Sometimes, specific classes are required as well. Thus, in some those circumstances additional folders are required:

J2SE

When working on J2SE applications, add

j2seApps to your source path. Note: Those classes might not work with Android. Also add

j2seTests to your test folder path. There are test suites under revisionTests. Choose the highest number and run the test. The test suite must run with 100% success before committing code.

Android

When working on Android applications, add

android to your source path. Note: Those classes won't work with J2SE.

About version numbers

There is an ongoing work on Shark. In parallel, we keep our developer guide to date. As usually the code is ahead the developer guide. We use a three digit pattern to name our releases:release.major.fixes

• Release is a collection of features. Each version of our developers guide describes a release. We plan to make releases backward compatible. For very good reasons we would break the rule, though.

• Major number is changed whenever a new feature, methode was added to the framework. A new javadoc is created and published with each new major version.
  Major number make the ongoing development process transparent. At some point in development we decide that we have enough new feature to pronounce it a new release. That triggers work on a fresh developer guide.

• The final number counts fixes. A new fix release is published whenever a reasonable number of fixes are made.