We Keep Coding

Is it possible to change buggy class in a closed source library that was not built to support dependency injection?

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.

Extending class with only private constructors

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.

AIDL interface can't find import for Parcelable class

My issue seems to be similar to this question and this one but it is a bit different.
I am making an AIDL service that is in a Library project and using it in my application. I have a class Vehicle that is in my application that I have made parcelable so that I can use it in my interface. (I would like to get a List of vehicles from my service that is in the library to my application)
Do I need a Vehicle.java in both the application and the library?
Do I need a Vehicle.aidl in both?
I had Vehicle.java AND Vehicle.aidl in both application and library and I began running into a problem in my application that when I called a method from my interface eclipse wanted me to define it as the Vehicle of the library class and not the application(although they are the same and both parcelable).
public List<Vehicle> getVehicles(){...code... }
In an effort to resolve this, I tried to make it the application's vehicle class rather than the library's vehicle class in my IRemoteInterface.aidl(in the listed variation below, i get an error that it can't find the import. In other variations like having it be List and no import, it says unknown return type).
package LIBRARY;
import LIBRARY.RelPoint;
import LIBRARY.IRemoteServiceCallback;
import LIBRARY.FleetStatus;
import APPLICATION.Vehicle;
interface IRemoteInterface {
int getPid();
void registerCallback(IRemoteServiceCallback callback);
void unregisterCallback(IRemoteServiceCallback callback);
List<Vehicle> getVehicles();
}
Here is my parcelable Vehicle class from the application :
package APPLICATION;
import java.util.Date;
import android.os.Parcel;
import android.os.Parcelable;
public class Vehicle implements Parcelable {
public static final String TAG = "Vehicle";
long vehicleID;
long trackID;
String vehicleName;
public static final Parcelable.Creator<Vehicle> CREATOR = new Parcelable.Creator<Vehicle>() {
public Vehicle createFromParcel(Parcel src) {
return new Vehicle(src);
}
public Vehicle[] newArray(int size) {
return new Vehicle[size];
}
};
public Vehicle(Parcel src) {
readFromParcel(src);
}
public void writeToParcel(Parcel dest, int flags) {
dest.writeLong(vehicleID);
dest.writeLong(trackID);
dest.writeString(vehicleName);
}
public void readFromParcel(Parcel src) {
vehicleID = src.readLong();
trackID = src.readLong();
vehicleName = src.readString();
}
public int describeContents() {
// nothing special
return 0;
}
public Vehicle() {
}
//getter and setter methods below that I removed
}

I'm reasonably certain you need to have the Parcelable classes in the same package on both ends (which is what you end up with by using the one from APPLICATION on the library side, I would just do it the other way around). This package has to also be the one declared in the corresponding aidl file.
I'd suggest to use a subpackage like com.example.interop to make this cleaner (i.e., separate the shared objects in their own package). Both sides should then have a Java file in that package + an aidl file that declares it.

I had the same issue and got it working with the following folder and file structure:
Under src/main create a directory named "aidl". This is where Android by default looks for .aidl files
Under "aidl/" create a directory "com/mypackage/util"
Then under "src/main/aidl/com/mypackage/util" put the .aidl file of your service and a separate .aidl file of your Parcelable. If the service is called IGetCards then the aidl file must be named IGetCards.aidl and if you Parcelable is called Cards then it must be in its own file named Cards.aidl.
In src/main/aidl/com/mypackage/util/IGetCards.aidl:
package com.mypackage.util;
import com.mypackage.util.Cards;
/** Example service interface */
interface IGetCards {
/** Demonstrates some basic types that you can use as parameters
* and return values in AIDL.
*/
Cards getCards();
}
In src/main/aidl/com/mypackage/util/Cards.aidl:
package com.mypackage.util;
parcelable Cards;
Check each file has a package statement at the top and that the service file IGetCards has an import statement at the top importing the Cards class.
Now in the Java directory src/main/java/com/mypackage/util, put a corresponding Cards.kt file which implements the interface. Make sure Cards.kt has a package statement at the top that matches Cards.aidl.
In src/main/java/com/mypackage/util/Cards.kt:
package com.mypackage.util;
class Cards() : Parcelable {
//implement members
...
}

Is it safe to OSGi export API containing reference to implementation code?

Let's imagine I implement the following:
public enum ExportAPIForOSGi {
;
public static SpecialObject newSpecialObject() {
return new SpecialObjectImplv1();
}
}
public abstract class SpecialObject {
public abstract String specialMethod(String s);
}
public class SpecialObjectImplv1 extends SpecialObject {
#Override
public String specialMethod(String s) {
return "33" + s;
}
}
Each class is declared in its own separate file. Only ExportAPIForOSGi and SpecialObject are to be OSGi exported.
My question: is it safe to export ExportAPIForOSGi since it contains an explicit reference to implementation code (i.e., SpecialObjectImplv1)? Is the implementation code going to be exposed?
Let's imagine that later, I use SpecialObjectImplv2 in ExportAPIForOSGi instead of v1? Is this going to be an issue?

You need to export the package(s) containing ExportAPIForOSGi and SpecialObject since they are your public API. SpecialObjectImplv1 should be in another package which is not exported. You are then free to change the implementation of newSpecialObject to use another impl class since the impl class is not visible in the signature of the public API.

Same class name in different packages

Can same class exist in multiple packages?
In other words, can I have Foo.java class in com.test.package1 and com.test.package2?
Update
Now I copied class from package 1 and placed in to package 2 and now I am creating an instance of that class, I want this instance to point to class present in package 1 but currently it points to package1 path, how can i modify it?
Oh so I cannot do something like:
Foo = new Foo() // pointing to Foo class in package 1
Foo = new Foo() // pointing to Foo class in package 2

Yes, you can have two classes with the same name in multiple packages. However, you can't import both classes in the same file using two import statements. You'll have to fully qualify one of the class names if you really need to reference both of them.
Example: Suppose you have
pkg1/SomeClass.java
package pkg1;
public class SomeClass {
}
pkg2/SomeClass.java
package pkg2;
public class SomeClass {
}
and Main.java
import pkg1.SomeClass; // This will...
import pkg2.SomeClass; // ...fail
public class Main {
public static void main(String args[]) {
new SomeClass();
}
}
If you try to compile, you'll get:
$ javac Main.java
Main.java:2: pkg1.SomeClass is already defined in a single-type import
import pkg2.SomeClass;
^
1 error
This however does compile:
import pkg1.SomeClass;
public class Main {
public static void main(String args[]) {
new SomeClass();
new pkg2.SomeClass(); // <-- not imported.
}
}

Sure can but you'll need to distinguish which one you want when calling them in other packages if both are included within a source file.
Response to Comment:
com.test.package1.Foo myFoo = new com.test.package1.Foo();
com.test.package2.Foo myOtherFoo = new com.test.package2.Foo();

i was taken to this page by google when i had the error a type with the same simple name is already defined by the single-type-import. i fixed this error (AFTER A VERY LONG TIME) by realising the line import com.sun.org.apache.xerces.internal.impl.dv.util.Base64; had snuck into the very top of my imports whilst i had the line import org.apache.commons.codec.binary.Base64; at the bottom of my imports.

So I was looking for a smarter solution than just using fully qualified names on one or both of the implemented classes.
If you create a private class, and extend your class, you are free to use the class, without writing the full package name each time.
Package 1
namespace namespace1.Logger
{
public class Log
{
public void Foo1(){}
}
}
Package 2
namespace namespace2.Logger
{
public class Log
{
public void Foo2(){}
}
}
My class implementation
//using namespace1.Logger;
//using namespace2.Logger;
namespace MyProject
{
public class MyClass
{
public MyClass()
{
LoggerA a = new LoggerA();
LoggerB b = new LoggerB();
a.Foo1();
b.Foo2();
}
private class LoggerA : namespace1.Logger.Log { }
private class LoggerB : namespace2.Logger.Log { }
}
}