mirror of
https://github.com/corda/corda.git
synced 2025-04-07 19:34:41 +00:00
Address review comments
This commit is contained in:
Mike Hearn
parent
43e4279250
commit
cd0fd628e6
@ -40,11 +40,13 @@ Step 2. Add a "cordapp" section to your Gradle build file
|
||||
This is used by the Corda Gradle build plugin to populate your app JAR with useful information. It should look like this::
|
||||
|
||||
cordapp {
|
||||
info {
|
||||
targetPlatformVersion 4
|
||||
minimumPlatformVersion 4
|
||||
contract {
|
||||
name "MegaApp"
|
||||
vendor "MegaCorp"
|
||||
targetPlatformVersion 4
|
||||
minimumPlatformVersion 4
|
||||
license "A really expensive license"
|
||||
versionId 1
|
||||
}
|
||||
}
|
||||
|
||||
@ -169,24 +171,11 @@ Step 5. Security: refactor to avoid violating sealed packages
|
||||
Hardly any apps will need to do anything in this step.
|
||||
|
||||
App isolation has been improved. Version 4 of the finance CorDapp (*corda-finance.jar*) is now built as a sealed and signed JAR file.
|
||||
This means classes in your own CorDapps cannot be placed under the following packages:
|
||||
This means classes in your own CorDapps cannot be placed under the following package namespace: ``net.corda.finance``
|
||||
|
||||
.. sourcecode:: java
|
||||
|
||||
net.corda.finance
|
||||
net.corda.finance.contracts
|
||||
net.corda.finance.contracts.asset.cash.selection
|
||||
net.corda.finance.contracts.asset
|
||||
net.corda.finance.contracts.math
|
||||
net.corda.finance.flows
|
||||
net.corda.finance.internal
|
||||
net.corda.finance.plugin
|
||||
net.corda.finance.schemas
|
||||
net.corda.finance.utils
|
||||
|
||||
In the unlikely event that you were injecting code into ``net.corda.*`` package namespaces from your own apps, you will need to move them
|
||||
into a new package, e.g. *net/corda/finance/flows.MyClass.java* can be moved to *net/corda/finance/flows/company/MyClass.java*.
|
||||
Also your classes are no longer able to access non-public members of finance CorDapp classes.
|
||||
In the unlikely event that you were injecting code into ``net.corda.finance.*`` package namespaces from your own apps, you will need to move them
|
||||
into a new package, e.g. ``net/corda/finance/flows/MyClass.java`` can be moved to ``com/company/corda/finance/flows/MyClass.java``.
|
||||
As a consequence your classes are no longer able to access non-public members of finance CorDapp classes.
|
||||
|
||||
When recompiling your JARs for Corda 4, your own apps will also become sealed, meaning other JARs cannot place classes into your own packages.
|
||||
This is a security upgrade that ensures package-private visibility in Java code works correctly.
|
||||
|
||||
@ -3,7 +3,7 @@ Versioning
|
||||
|
||||
As the Corda platform evolves and new features are added it becomes important to have a versioning system which allows
|
||||
its users to easily compare versions and know what feature are available to them. Each Corda release uses the standard
|
||||
semantic versioning scheme of ``major.minor.patch``. This is useful when making releases in the public domain but is not
|
||||
semantic versioning scheme of ``major.minor``. This is useful when making releases in the public domain but is not
|
||||
friendly for a developer working on the platform. It first has to be parsed and then they have three separate segments on
|
||||
which to determine API differences. The release version is still useful and every MQ message the node sends attaches it
|
||||
to the ``release-version`` header property for debugging purposes.
|
||||
@ -17,7 +17,7 @@ It starts at 1 and will increment by exactly 1 for each release which changes an
|
||||
entire platform. This includes public APIs on the node itself, the RPC system, messaging, serialisation, etc. API backwards
|
||||
compatibility will always be maintained, with the use of deprecation to suggest migration away from old APIs. In very rare
|
||||
situations APIs may have to be changed, for example due to security issues. There is no relationship between the platform version
|
||||
and the release version - a change in the major, minor or patch values may or may not increase the platform version. However
|
||||
and the release version - a change in the major or minor values may or may not increase the platform version. However
|
||||
we do endeavour to keep them synchronised for now, as a convenience.
|
||||
|
||||
The platform version is part of the node's ``NodeInfo`` object, which is available from the ``ServiceHub``. This enables
|
||||
@ -30,7 +30,7 @@ Minimum platform version
|
||||
Applications can advertise a *minimum platform version* they require. If your app uses new APIs that were added in (for example) Corda 5,
|
||||
you should specify a minimum version of 5. This will ensure the app won't be loaded by older nodes. If you can *optionally* use the new
|
||||
APIs, you can keep the minimum set to a lower number. Attempting to use new APIs on older nodes can cause ``NoSuchMethodError`` exceptions
|
||||
and similar problems, so it's best to advertise the correct requirements so problems are caught up front, instead of at runtime.
|
||||
and similar problems, so you'd want to check the node version using ``ServiceHub.myInfo``.
|
||||
|
||||
Target version
|
||||
--------------
|
||||
@ -48,7 +48,7 @@ this, you promise that you understood all the changes in Corda 6 and have thorou
|
||||
|
||||
Target versioning is one of the mechanisms we have to keep the platform evolving and improving, without being permanently constrained to
|
||||
being bug-for-bug compatible with old versions. When no apps are loaded that target old versions, any emulations of older bugs or problems
|
||||
can be disabled.
|
||||
can be disabled (in Corda 4, an example of this is the old FinalityFlow handler that would accept any transactions into the vault, context free).
|
||||
|
||||
Publishing versions in your JAR manifest
|
||||
----------------------------------------
|
||||
@ -56,14 +56,17 @@ Publishing versions in your JAR manifest
|
||||
In your ``build.gradle`` file, add a block like this::
|
||||
|
||||
cordapp {
|
||||
info {
|
||||
targetPlatformVersion 5
|
||||
minimumPlatformVersion 4
|
||||
contract {
|
||||
name "MegaApp"
|
||||
vendor "MegaCorp"
|
||||
targetPlatformVersion 5
|
||||
minimumPlatformVersion 4
|
||||
license "MegaLicense"
|
||||
versionId 1
|
||||
}
|
||||
}
|
||||
|
||||
This will put the necessary entries into your JAR manifest to set both version numbers. If they aren't specified, both default to 1.
|
||||
This will put the necessary entries into your JAR manifest to set both platform version numbers. If they aren't specified, both default to 1.
|
||||
Your app can itself has a version number, which should always increment and must also always be an integer.
|
||||
|
||||
.. note:: You can read the original design doc here: :doc:`design/targetversion/design`.
|
||||
Loading…
x
Reference in New Issue
Block a user