Stub API generator?

[Abuse]

Does anyone know of a tool that can take a library jar, and generate a stub jar containing the libraries public interface, but with a do-nothing implementation?

[CaptainJester]

It's not that hard to do yourself.  Use the java.util.jar.* package to load the entries from the library.  Then take the file name for each entry, strip the .class and pass it to Class.forName();  On the result check for isInterface();  Then if it is create the stub class that implements it.

[Abuse]

It's not that hard to do yourself.  Use the java.util.jar.* package to load the entries from the library.  Then take the file name for each entry, strip the .class and pass it to Class.forName();  On the result check for isInterface();  Then if it is create the stub class that implements it.

That isn't what I'm after.

I want a tool to generate a stub implementation of a given library, in other words a 'do-nothing' implementation.
And for the record the 'public interface' of a library is all the libraries public classes, interfaces, methods & members - not just the classes that fulfill the java definition of an 'interface'.

I can put together a tool to do it using javassist in a matter of hours; I was just expecting such a tool to already exist.
Oh well, I guess I'll write it, and put it up here.

Games published by our own members! Check 'em out!

[rreyelts]

That isn't what I'm after.

I want a tool to generate a stub implementation of a given library, in other words a 'do-nothing' implementation.
And for the record the 'public interface' of a library is all the libraries public classes, interfaces, methods & members - not just the classes that fulfill the java definition of an 'interface'.

I created one of these about six years ago or so. The concept was that we needed an API for people to compile against, while keeping the actual runtime encrypted. At the time, I just used reflection and generated source code. I don't remember it taking more than a day to go from concept to implementation, though I do remember there being a couple of sticky issues. Off the top of my head, you have to be concerned about package members if people can place classes in the same package, or protected members if people can subclass your classes. You also need to make sure all of your constants have their correct values.