0.3.0 Series Release

[05nelsonm]

0.3.0 Series Release

I felt it would be better to do a write up here in order to link to it in each repository's change log, given the issue at hand and the changes required to fix it.

A major bug was discovered requiring API breaking changes.

The Issue

Java Package Module System (JPMS) does not allow 2 modules to export the same package paths and will throw exception.

e.g. If both lib-a and lib-b export package com.example

As such, the core, hash, and MACs repositories were affected because of a poorly thought out library architecture where package names were being shared within each module for the given repository.

This meant anyone depending on core, hash, or MACs libraries (either directly or transitively) would encounter exceptions with JPMS.

The Fix

Classes and functions were moved to appropriately named packages for their given modules. This unfortunately breaks binary compatibility of prior versions. The hash repository was left rather unscathed as the package names were already correct, but the core and MACs repository's were deeply affected and all package names needed to be corrected.

The following PRs fixed the underlying issue:

• core-48
• hash-49
• MACs-40

Going Forward

New modules added for all Kotlin Crypto repositories will have an appropriately named package path that does not conflict with other Kotlin Crypto dependencies.

The following naming convention will be utilized (in most instances):

• org.kotlincrypto.<lowercase repository name>.<lowercase module name>
• Example:
  • Repository KotlinCrypto/ASN1
  • Module :library:core
  • Root package name org.kotlincrypto.asn1.core
  • Maven Central Publication org.kotlincrypto.asn1:core:x.x.x

An issue ticket has been opened to document this as a requirement for future Kotlin Crypto libraries.

Thoughts

My personal opinions about JPMS aside, some frameworks require its usage (JavaFX). Additionally, some projects may, or have already migrated to JPMS (especially as Java 8 reaches the end of it's LTS lifecycle). KotlinCypto libraries should not be a source of issue for them.

As the user-base of KotlinCrypto libraries are currently small (thank you for your support!), I felt it better to fix this issue immediately (and before a 1.0.0 release) to minimize the number of projects that would be impacted by the API breaking changes.

I sincerely apologize for any inconvenience caused as we march onward to a 1.0.0.