I've been asked for details on "Java API/ABI changes checker" by a few
students so I am putting them all here so I don't have to repeat
myself.
I envision following use cases for this toolset:
1. packagers will run this on new release of upstream jar, and old
release of upstream jar, compare results and decide how to proceed
2. generate a big database of comparison data for a lot of different
versions of various projects/jars where developers can go and see
the stuff without actually running the tool themselves (similar to [1])
3. [possibly in the far future] runs by automatic quality control
tools such as AutoQA that would prevent an update to a package in a
released version of distribution that would break compatibility.
Not all of this needs to be included in the proposal, try to get a
good idea what you would like to do, how you'd like to do it.
There are several available approaches including but not limited to:
1. Modify some of the existing solutions. I've linked 2 of them in
the idea page, but they are not the only one. I encourage you to find
others, look at them, evaluate them, learn from them...and make sure
you mention this in your proposal
2. Start from scratch. While this approach is viable, I would like to
see good reasons why modifying existing solutions is not the right
path. This will require even better research/evaluation part. Be sure
you know what you are getting into
A very simple example how I envision the package to work:
----------------------------------------------------
$ javachecker "utils-1.0.jar:commons-1.0.jar" \
"utils-2.0.jar:commons-1.1.jar"
ERRORS:
Class Util in utils-2.0.jar removes method helper()
WARNINGS
Superclass for VersionProp changed in commons-1.1.jar
Field VersionProp added to abstract class CommonFunc in commons-1.1.jar
----------------------------------------------------
This is more-less minimal that would be considered as a "solution",
though output would have to be also accessible in parseable formats
(xml/json). There is also great deal of problems that would have to
be detected, categorized (especially if you start from scratch). That
is why this project requires non-trivial knowledge how Java
inheritance works, including overrides, generics etc and even some
JVM bytecode knowledge might be necessary. Be sure you know how
classpaths work, how JVM finds classes you are import-ing etc.
Having the solution modular, being able to be integrated with other
tools is also very important.
If there are still things I haven't answered feel free to ask for more
specific details.
[1] http://upstream-tracker.org/java/
--
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
