JReFrameworker is ignoring multiple annotations in a row. It works for single annotations, but not for more than 1.

Example:
@DefineMethodVisibility(type = "com.my.Type", method = "test", visibility = "public")
@DefineMethodVisibility(type = "com.my.Type", method = "test2", visibility = "public")

The @MergeMethod annotation allows a user to augment an existing method on a class. However, no checks are done to verify that such a method actually exists. In most cases, this isn't a major issue since the user can use the @Override annotation to ensure such a method exists on the parent class.

However, there are cases where using @Override isn't actually possible. In particular, static methods can't use @Override since you can't use virtual dispatch with a static method. In such a case, it's possible to specify an incorrect signature for a @MergeMethod, and would look like a silent failure from a user perspective: the method wouldn't be overridden, and the default behavior for the overridden method would remain. In most cases this would just be a silent failure, but in some cases if there are multiple merged methods this could lead to crashes or other weird behavior.

All this would be mitigated by issuing an error or warning when a @MergeMethod does not replace something.

This is really needed to streamline the development process when using the visibility or finality annotations.

Aside from jar signing details (issue #9), the manifest details should be preserved.

Merging of initializers "" and static initializers "" is currently not supported.

The org.objectweb.asm.getCommonSuperClass method (and potentially others) load the current classpath of the plugin's instance to locate class files needed for rewrites. This is a problem when editing class files that involve classes not on the default class path.

The fix is pretty simple, for example in getCommonSuperClass we could do the following, but a more thorough investigation of ASMs use of class loaders is warranted. Also should investigate if this was an issue in ASM before 5.2.0 update.

 Class<?> c, d;
 ClassLoader classLoader = getClass().getClassLoader();
 try {
    c = Class.forName(type1.replace('/', '.'), false, classLoader);
    d = Class.forName(type2.replace('/', '.'), false, classLoader);
} catch (Exception e) {
	try {
        // TODO: may need to search multiple jars...
		String pathToJar = "PATH_TO_MY_JAR_HERE";
		URL[] urls = { new URL("jar:file:" + pathToJar+"!/") };
		classLoader = URLClassLoader.newInstance(urls);
		c = Class.forName(type1.replace('/', '.'), false, classLoader);
        d = Class.forName(type2.replace('/', '.'), false, classLoader);
	} catch (Exception e2){
		throw new RuntimeException(e.toString());
	}
}

Finish implementing Atlas program analysis integrations

When we use annotations to change the targets finality/visibility in order to override the definition there should be a way to restore it without another compilation pass.

By default the runtime library jar paths are absolute paths, which means modules are hard to import on different workstations. The default runtime path can be made symbolically in Eclipse projects and local jars can be made relative to the project path.

We can add/remove/modify, but we can't delete although the rewrite engine supports it now. There may be some use cases to purge a field or method from its pitiful existence.

Specifically, there really shouldn't be a workflow difference between the two. JReFrameworker should just examine the JARs on the classpath and output modified JARs for each JAR that has a class that is modified by JReFrameworker.

Question: Since namespaces/classes can collide between different JARs should JReFrameworker modify each matching version or prompt user to specify the JAR or allow both options???

So far Oracle/OpenJDK haven't been signing rt.jar, but if they did or if the user was editing a signed JAR then it's probably best to unsign the JAR and then let the user decide how to resign it with a newly generated key or a store key.

Currently writing anonymous inner classes is not supported. A work around is to declare the class in a separate Java file.

Should implement regression testing for core functionality

Test case: https://github.com/JReFrameworker/modules/tree/master/TestStringReframeworking

Crashes Java 8 JREs. May need to update ASM library.

The Android branch of this project was so rough I'm tempted to just delete it entirely. However recent workflow changes and the Enjarify project may make implementation much cleaner.

Currently methods to be replaced are simply marked private and renamed with the prefix "jref_purge_". They should be removed entirely.

@MergeMethod annotations for static methods does not support static dispatches to the preserved base class method. Currently it acts as a @DefineMethod (except it preserves the original method with the renamed method prefix), which is not correct. Base class static method dispatches to the method to merge should be treated as recursive calls and parent class static method dispatches to the method should be treated as dispatches to the preserved method.