Project Proposal: CompatibleChanges

[Sebastian Sickelmann]

I want to add some more ideas what can be done in the CompatibleChanges 
Project.
I also would add some tools that can help developers to check for binary 
compatibility and to simplify the process of creating binary compatible 
solutions.

Here are some samples:
     - Integrate tools to check for binary compatiblity like : 
https://github.com/lvc/japi-compliance-checker
     - Tools that can help to create compatible serialization 
implementations.
     - Tools for visualisation serialization; create human 
readable/comparable textual forms of serialization results.

I hope that someone have some more good ideas how we can 
improve/simplify the creation of binary compatible changes.

-- Sebastian
Am 17.08.2012 10:15, schrieb Sebastian Sickelmann:
> In accordance with the OpenJDK guidelines [1], I would like to start 
> discussion
> of a new Project to change the OpenJDK JVM implementation to make it 
> possible to
> update java apis in ways that are not possible today.
>
> The goal of the CompatibleChanges Project will be to change the 
> OpenJDK JVM implementation.
> It is not intented to change Java The-Language. Currently i there is 
> one Proof of Concept[2]
> that shows the possible-usage in an example (remove public static- and 
> instance-fields in a
> binary compatible way).
> The POC uses bytecode-rewrite at loadtime and invokedynamic at runtime 
> to figure out
> which method to call instead of an fieldaccess. My initial suggest 
> would be to
> change the JVMS-rules for Field Resolution and don't do it with 
> instrumentation and
> invoke-dynamic.
>
> Real-Short Example:
> public class ClassToChange {
>     public Throwable cause = new RuntimeException("INIT");
>     public static Object staticField = "ORIG_VALUE";
> }
> Evolved Implementation:
> public class OLD {
>     private Throwable cause = new RuntimeException("INIT");
>     private static Object staticField = "ORIG_VALUE";
>     @Accessor("cause") public Throwable getCause() { return cause; }
>     @Accessor("cause") public void initCause(Throwable cause) { 
> this.cause = cause; }
>     @Accessor("staticField") public static Object getFoo() { return 
> staticField; }
>     @Accessor("staticField") public static void setFoo(Object value) { 
> staticField = value; }
> }
>
>
> Some initial thoughts about Reflection-Changes and 3 ways of how the 
> Field Resolution Rules can
> be changed are documented here[3]. It is written in the textual form 
> of a JEP, but it is not
> intended to be a JEP.
>
> There is some initial feedback (on my first discussion request in 
> jdk8-dev) by Brian Goetz
> and Joe Darcy back in Oct 2011[4].
>
> The initial committers are proposed to be: Sebastian Sickelmann
>
> Please discuss and let me know what you think.
>
> Thank you for your consideration,
>
> [1] http://openjdk.java.net/projects/#new-project
> [2] 
> https://github.com/picpromusic/incubator/tree/projectProposal/jdk/compatibleFieldAccess
> [3] 
> https://github.com/picpromusic/incubator/blob/projectProposal/jdk/compatibleFieldAccess/JEP.markdown
> [4]http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html 
>