import org.apache.bcel.classfile.*;
import org.apache.bcel.generic.*;
import org.apache.bcel.Constants;
// Developed against BCEL 5.1
import java.io.*;
import java.util.jar.JarFile;
import java.util.jar.JarEntry;
import java.util.jar.JarInputStream;
import java.util.jar.JarOutputStream;
import java.util.Enumeration;
import java.util.zip.ZipEntry;
import java.lang.reflect.Modifier;
/**
* This utility takes a .class or .jar file and replaces it with a no-op equivalent that you
* can compile against (but not run against).
*
* It basically re-creates classes with the same names and signatures as the ones in the original,
* making all the methods native (so we don't have to provide behavior) (except constructors, which
* are just left with an empty body, easy because they don't have to return anything).
*
* It does this because there are bugs in the type-erasure used by the early-access JDK compiler,
* such that I can't compile against idea.jar directly due to the following error:
*
* [javac] F:\source\nm\dpj\ojde302\fingertips\src\com\compuware\ojde\ij\EditorTrackingFeature.java:16: cannot access com.intellij.openapi.vfs.VirtualFile
* [javac] bad class file: F:\source\nm\dpj\ojde302\imports\intellij\lib\idea.jar(com/intellij/openapi/vfs/VirtualFile.class)
* [javac] bad signature: r? B z? ?
* [javac] Please remove or make sure it appears in the correct subdirectory of the classpath.
* [javac] import com.intellij.openapi.vfs.VirtualFile;
* [javac] ^
* [javac] 1 error
*
*
* This only happens when I use the generics compiler, not the real compiler. So, I'm not sure what it is
* about the type data in VirtualFile that has it so upset, but this stub generator was built to strip
* all that information out.
*
* @author Paul Mclachlan
*/
public class CompileStubGenerator
{
public static void main( String args[] ) throws IOException
{
if( args.length != 2 )
{
System.err.println( "Usage: java -jar classRewriter.jar <.class or .jar>