[
https://issues.apache.org/jira/browse/RIVER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Firmstone updated RIVER-316:
----------------------------------
Attachment: VersionedDynamicClassesRev4.tgz
Please have a look tell me what you think, what changes can I make to simplify,
what issues am I overlooking. Is there something else I could be taking
advantage of?
> RFC Library, Application & Class Versioning, Dynamically Mobile Codebases and
> Classloading enhancements
> -------------------------------------------------------------------------------------------------------
>
> Key: RIVER-316
> URL: https://issues.apache.org/jira/browse/RIVER-316
> Project: River
> Issue Type: New Feature
> Components: net_jini_loader
> Environment: All
> Reporter: Peter Firmstone
> Attachments: classworlds-1.0-src.zip, Java Classloader issues
> relating to Jini smli_tr-2006-149.pdf, VersionedDynamicClassesRev2.tgz,
> VersionedDynamicClassesRev3.tgz, VersionedDynamicClassesRev4.tgz
>
>
> Request for Comments:
> Proposal to add support for Dynamic Mobile Codebases and Application fine
> grained class versioning as well as Coarse grained Library versioning , to
> enable River User devolopers, to provide distinction between classes with the
> same fully qualified class name when code differences created by refactoring
> packages or library updates break backward compatibility between classes
> contained within that library or package. ClassWorlds can be used to
> segregate ClassRealms for application packages and different library versions.
> A dependency tree array object (contains dependency references between
> classes, fully qualified class names are stored as String objects) returned
> by the new ClassDepend tool (replacement of classdep functionality) may be
> suitable (with some modification) for recording class versioning, for later
> navigation of the codebase for class version verification, perhaps this could
> be stored in serialized form with the codebase.
> The ASM library might be used to modify existing, externally sourced library
> class file bytecodes to add a LIBRARYVERSIONID static final field, with an
> accessor method, for library code used in codebases, to mark the class files
> with the library release version.
> serialVersionUID (when it exists), along with the CLASSVERSION static field,
> might be used to determine the dependency and backward compatibility of
> classes in a codebase, this information could be stored in the dependency
> tree along with the CLASSVERSION, fully qualified class name and class file
> checksum.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
