The problem is: I have a class with only private constructor available (and I cannot modify it's source code), and I need to extend it.
Since reflections allow us to create instances of such classes whenever we want (with getting constructors and calling for newInstance()), is there any way to create an instance of an extended version of such class (I mean, really any way, even if it is against OOP)?
I know, it is a bad practice, but looks like I have no choice: I need to intercept some calls to one class (it is a singleton, and it's not an interface realization, so dynamic proxies do not work here).
Minimal example (as requested):
public class Singleton {
static private Singleton instance;
private Singleton() {
}
public static Singleton getFactory() {
if (instance == null)
instance = new Singleton();
return instance;
}
public void doWork(String arg) {
System.out.println(arg);
}}
all I want to do is to construct my own wrapper (like this one)
class Extension extends Singleton {
#Override
public void doWork(String arg) {
super.doWork("Processed: " + arg);
}}
and the inject it into Factory using reflection:
Singleton.class.getField("instance").set(null, new Extension());
But I do not see any way to construct such object cause its superclass's constructor is private. The question is "is that possible at all".
It is possible (but a bad hack) if
you have the source code of the class with the private constructors or you can reconstitute it from bytecode
the class is loaded by the application class loader
you can modify the jvm's classpath
You can than create a patch that is binary compatible with the original class.
I will call the class you want to extend PrivateConstructorClass in the following section.
Take the source code of PrivateConstructorClass and copy it to a source file. The package and class name must not be changed.
Change the constructors of the PrivateConstructorClass from private to protected.
Re-compile the modified source file of PrivateConstructorClass.
Package the compiled class file into a jar archive. E.g. called "patch.jar"
Create a class that extends the first one and compile it against the class in the patch.jar
Change the jvm's classpath so that the patch.jar is the first entry in the classpath.
Now some example code that let you examine how it works:
Expect the following folder structure
+-- workspace
+- private
+- patch
+- client
Create the PrivateConstructor class in the private folder
public class PrivateConstructor {
private String test;
private PrivateConstructor(String test){
this.test = test;
}
#Override
public String toString() {
return test;
}
}
Open a command prompt in the private folder, compile and package it.
$ javac PrivateConstructor.java
$ jar cvf private.jar PrivateConstructor.class
Now create the patch file in the patch folder:
public class PrivateConstructor {
private String test;
protected PrivateConstructor(String test){
this.test = test;
}
#Override
public String toString() {
return test;
}
}
Compile and package it
$ javac PrivateConstructor.java
$ jar cvf patch.jar PrivateConstructor.class
Now comes the interresting part.
Create a class that extends the PrivateConstructor in the client folder.
public class ExtendedPrivateConstructor extends PrivateConstructor {
public ExtendedPrivateConstructor(String test){
super(test);
}
}
and a main class to test it
public class Main {
public static void main(String str[]) {
PrivateConstructor privateConstructor = new ExtendedPrivateConstructor("Gotcha");
System.out.println(privateConstructor);
}
}
Now compile the client folder's source files against the patch.jar
$ javac -cp ..\patch\patch.jar ExtendedPrivateConstructor.java Main.java
and now run it with both jars on the classpath and see what happens.
If the patch.jar comes before the private.jar than the PrivateConstructor class is loaded from the patch.jar, because the application class loader is a URLClassLoader.
$ java -cp .;..\patch\patch.jar;..\private\private.jar Main // This works
$ java -cp .;..\private\private.jar;..\patch\patch.jar Main // This will fail
The solution by #René Link was good enough, but not in my case: I wrote I'm hacking an Eclipse IDE plugin, and this means we're working under OSGi, and this means we cannot control the classpath resolving order (it will load our "hacked" class in our bundle, and vanilla victim class in another bundle, and it will do this with different classloaders, and then we would have problems with casting such objects one to another). Possibly OSGi has some tools to solve this problems, but I don't know it well enough, and also I found no info on this.
So we invented another solution. It is worse than previous one, but at least it works in our case (and so it's more flexible).
The solution is simple: javaagent. It's a standard tool, which allows to manipulate bytecode at the time it is loaded. So the task was solved by using it and java ASM library: the victim's bytecode was modified to make it's constructor public, the remaining was easy.
public class MyAgent {
public static void premain(String agentArguments, Instrumentation instrumentation) {
instrumentation.addTransformer(new ClassFileTransformer() {
#Override
public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer)
throws IllegalClassFormatException {
if (className.equals("org/victim/PrivateClass")) { //name of class you want to modify
try {
ClassReader cr = new ClassReader(classfileBuffer);
ClassNode cn = new ClassNode();
cr.accept(cn, 0);
for (Object methodInst : cn.methods) {
MethodNode method = (MethodNode) methodInst;
if (method.name.equals("<init>") && method.desc.equals("()V")) { //we get constructor with no arguments, you can filter whatever you want
method.access &= ~Opcodes.ACC_PRIVATE;
method.access |= Opcodes.ACC_PUBLIC; //removed "private" flag, set "public" flag
}
}
ClassWriter result = new ClassWriter(0);
cn.accept(result);
return result.toByteArray();
} catch (Throwable e) {
return null; //or you can somehow log failure here
}
}
return null;
}
});
}
}
Next this javaagent must be activated with JVM flag, and then everything just works: now you can have subclasses which can call super() constructor without any problem. Or this can blow your whole leg off.
EDIT: This clearly doesn't work with the newly posted code examples edited into the question above, but I will keep the answer here for future posterity should it help someone else.
One method available to you which may or may not work depending on your situation is to use the Delegation pattern. For example:
public class PrivateClass {
private PrivateClass instance = new PrivateClass();
private PrivateClass() {/*You can't subclass me!*/
public static PrivateClass getInstance() { return instance; }
public void doSomething() {}
}
public class WrapperClass {
private PrivateClass privateInstance = PrivateClass.getInstance();
public void doSomething() {
//your additional logic here
privateInstance.doSomething();
}
}
You now have a class, WrapperClass, which has the same API as PrivateClass but delegates all the functionality to PrivateClass (after doing some pre or post work itself). Obviously, WrapperClass is not associated with the type heirarchy of PrivateClass but can be setup to do everything PrivateClass can.
Related
I'm not a newbie of Java and Eclipse, this question is not as easy as Alt+Shift+R or Refactor>Rename
Assume there is a method in utils.jar.
public class A {
public void taste() {}
}
Then I used it in current project.
public class taste {
public static void taste() {
A taste = new A();
return taste.taste();
}
}
OK, now I found taste in utils.jar is not the word I want, then I changed the utils.jar to test:
public class A {
public void test() {}
}
So, after that, how could I change A.taste() to A.test() precisely just like use Alt+Shift+R?
public class taste {
public static void taste() {
A taste = new A();
return taste.test(); // only change function A.taste to test
}
}
I found that Search>Java can find the A.taste function precisely, but I have no idea how to replace all of it to test.
Alt + Shift + R might be useful in this case.
Put the old source code of A in your project. E.g. src/some_package/A.java
This overrides the class from the library utils.jar
Use the refactoring tool to rename the method.
You can do this now, because the source code of A is available
remove the source code of A from your project
add the updated lib utils.jar to your project
Say I am using a closed source java library with a known buggy class, say BuggyClass and this class is hardcoded throughout the rest of the library. So I would imagine that the java library looks something like this:
public class BuggyClass {
public T buggyMethod (...) {
// Buggy code here
}
}
with several other classes in the library that make use of this class:
public class Example {
private BuggyClass = new BuggyClass(); // No dependency injection possible
public Example (/* No way to pass in my own subclass of BuggyClass*/) {
// ...
}
}
etc...
Is there any hack, or workaround, possibly using the class loader so that I could subclass BuggyClass and get Example (and every other class in the library that has BuggyClass hardcoded in) to use my subclass?
You can't do a subclass, no, but you can write your own BuggyClass entirely and make sure it appears earlier in the classpath than the real one. I don't think it's documented, but the default classloader seems to typically use the first matching class it finds.
But obviously this is a Really Bad Option, so you want to exhaust every other avenue before trying to solve temporarily work around the underlying problem this way.
Example: Suppose we have this:
// The "buggy" class
package somepackage;
public class BuggyClass {
public String someMethod() {
return "I'm in the buggy class";
}
}
and this:
// Uses the "buggy" class
package somepackage;
public class BuggyClassUser {
public String useBuggyClass() {
BuggyClass c = new BuggyClass();
return c.someMethod();
}
}
compiled and the classes in buggy.jar. Then we have this test class:
import somepackage.*;
public class Test {
public static final void main(String[] args) {
BuggyClassUser u = new BuggyClassUser();
System.out.println(u.useBuggyClass());
}
}
If we run that (*nix format classpath):
java -cp .:buggy.jar Test
...we see
I'm in the buggy class
But if we create a somepackage directory and put this in it:
package somepackage;
public class BuggyClass {
public String someMethod() {
return "I'm in the fixed class"; // <== Difference here
}
}
...and compile that, since we have that in our classpath in front of the jar, this command:
java -cp .:buggy.jar Test
...now gives us this:
I'm in the fixed class
Again, this is very, very much a workaround, not a solution.
I have a class that extends from a package class that may or may not be in the classpath when the program is ran, it isn't called unless the dependency is met,
however it seems to annoy the java verifier that throws a NoClassDefFoundError on attempting to load the program,
Any way around this?
Any way around this?
In practice, no. The superclass has to be available on the classpath for the loading, linking and verification of the subclass to succeed. That has to happen before the class can be initialized, and instances of it created.
If you can't be sure that the superclass is going to be available, you need to remove all direct and indirect static dependencies on the subclass(es), and then load the subclasses dynamically using Class.forName(). That will fail if the superclass is "missing", but you will get a different exception (not an Error) and there is the possibility that your application can continue, if it is designed to cope with the missing classes.
Frameworks such as Spring which have "optionally used" code depending on other libraries, use a "Strategy pattern" to put that dependency-specific code into an "inner class" or into a separate class.
The outer class can be loaded & run fine; it's only when you try & instantiate the inner class that the NoClassDefFoundError will be thrown.
So the outer class typically tries (try-catch) instantiating one strategy to use, and then if that fails instantiates a fallback strategy.
public class MyService {
protected MyStrategy strategy;
// constructor;
// -- choose our strategy.
public MyService() {
try {
this.strategy = new ExternalLib_Strategy();
} catch (NoClassDefFoundError x) {
// external library not available.
this.strategy = new Standard_Strategy ();
}
}
// --------------------------------------------------------
protected interface MyStrategy {
public void doSomething();
}
protected static class ExternalLib_Strategy implements MyStrategy {
ExternalLib lib = org.thirdparty.ExternalLib.getInstance(); // linkage may
public void doSomething() {
// ... use the library for additional functionality.
}
}
protected static class Standard_Strategy {
public void doSomething() {
// ... basic/ fallback functionality.
}
}
}
As a work around to this problem, If your class (subclass) is available in the classpath, you can check whether the parent class is available in the classpath by loading the class file as a resource using the method ClassLoader.getResource(). This method will never throw a class not found exception. But this will return null if the class is not found. You can aviod using your class if the resource is null.
See this sample code below:
public class Test {
/**
* #param args
*/
public static void main(String[] args) {
Object instance = Test.class.getClassLoader().getResource("com/test/package/Base.class");
Derived derived = null;
if(instance !=null) {
derived = new Derived();
System.out.println(derived.getString()); // call the getString method in base class
}
else {
// The class is not available. But no Exception
System.out.println("No Hope");
}
}
}
The Code:
package com.keyoti.rapidSpell;
import java.util.Comparator;
// Referenced classes of package com.keyoti.rapidSpell:
// RapidSpellChecker
class RapidSpellChecker$CompareL
implements Comparator
{
public int compare(Object a, Object b)
{
return (int)(100D * (suggestionScore2b(topWord, (String)b) - suggestionScore2b(topWord, (String)a)));
}
public void with(String w)
{
topWord = w;
}
private String topWord;
RapidSpellChecker$CompareL()
{
}
}
This is the one the many classes in the application.
What does the $ sign in class RapidSpellChecker$CompareL implements Comparator signify?Is it simply the class name or has some significance?
I suspect this is decompiled code. (See at the bottom for more information.) The $ shows that it's a nested class within RapidSpellChecker. So the code would originally have looked something like this:
public class RapidSpellChecker
{
// Other code withing RapidSpellChecker
static class CompareL implements Comparator
{
// Code for compare, with etc
}
}
I've shown this as a static nested class, because the code you've shown doesn't have any implicit reference to an instance of RapidSpellChecker. If it did, the original code would have been like this:
public class RapidSpellChecker
{
// Other code withing RapidSpellChecker
class CompareL implements Comparator
{
// Code for compare, with etc
}
}
In this case it's an inner class.
See the Java tutorial on nested classes for more information.
EDIT: I originally thought this was invalid code; that you couldn't use $ in an identifier in Java to start with. It turns out I'm wrong. From the Java Language Specification, section 3.8:
The $ character should be used only in mechanically generated source code or, rarely, to access preexisting names on legacy systems.
So it's valid, just discouraged.
That's a nested class. When the Java compiler compiles a class with nested classes, it separates all of them in different .class files.
class A {
class B {
}
}
gives A.class and A$B.class
You can use $ in a variable name if you want. In a variable name it has no special significance.
$ is also typically used to indicate inner classes when you compile using javac
If you compile
class A {
class B {
}
}
You'll see A.class created and B.class.
For fun and amusement, you could create confusing looking "JQuery"-esque code in Java (you need the static import to use the $ static method). See the example below:
import static thisPackage.*;
public class $ {
public static $ $(String s) { return new $(s); }
public $ fadeIn(int fade) { return this; }
public $ slideUp(int slide) { return this; }
public $ delay(int ms) { return this; }
public $(String s) { }
public static void main(String[] args) {
$("#foo").slideUp(300).delay(800).fadeIn(400);
}
}
Implementing this with a DOM library underneath would be a fun project!
I'm trying to make a program that can load an unknown set of plugins from a sub-folder, "Plugins". All of these plugins implement the same interface. What I need to know is how do I find all of the classes in this folder so that I can instantiate and use them?
MyInterface.java
A stub interface.
package test;
public interface MyInterface {
public void printSomething();
}
TestClass.java
A test class to be loaded, implementing your interface.
import test.MyInterface;
public class TestClass implements MyInterface {
public void printSomething() {
System.out.println("Hello World, from TestClass");
}
}
(Compiled class file placed in "subfolder/".)
Test.java
A complete test program that loads all class files from "subfolder/" and instantiates and runs the interface method on it.
package test;
import java.io.File;
public class Test {
public static void main(String[] args) {
try {
ClassLoader cl = ClassLoader.getSystemClassLoader();
File subfolder = new File("subfolder");
for (File f : subfolder.listFiles()) {
String s = f.getName();
System.out.println("Loading " + s);
Class cls = cl.loadClass(s.substring(0, s.lastIndexOf('.')));
MyInterface o = (MyInterface) cls.newInstance();
o.printSomething();
}
} catch (ClassNotFoundException e) {
} catch (InstantiationException e) {
} catch (IllegalAccessException e) {
}
}
}
Output from Test program above:
Loading TestClass.class
Hello World, from TestClass
Check java.util.ServiceLoader
A service is a well-known set of interfaces and (usually abstract) classes. A service provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself. Service providers can be installed in an implementation of the Java platform in the form of extensions, that is, jar files placed into any of the usual extension directories. Providers can also be made available by adding them to the application's class path or by some other platform-specific means.
This article explains the details.
Look through the folder with File.listFiles() and use a JarClassLoader instance to load the classes in there.
Or, add a description.xml in each of those jars if they are on the classpath, and use getClass().getClassLoader().findResources("description.xml") to load all descriptions, and then you have all the plugin classes to load.
Annotate your implementation classes with a custom annotation and use scannotation it does byte code scanning of the class files, and is orders of magnitudes faster than anything else, you can use it to search the entirety of a very large classpath instantly.