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
Related
I am developing a plugin for an RCP application.
Within the plugin.xml, I need to register certain classes at a given extension point.
One of these classes is an anonymous (?) class defined like this:
package de.me.mypackage;
import org.something.AnotherClass;
public class ClassOne {
...
public static AnotherClass<ClassOne> getThat() {
return new AnotherClass<ClassOne>() {
...
};
}
}
Is there any way to reference AnotherClass<ClassOne> within the plugin.xml?
I already tried something like de.me.mypackage.ClassOne$AnotherClass but that does not work. Do I have to declare that class within its own file to be able to reference it?
As far as I know, it would have a numeric index:
class Bla {
public static void main(String[] args) {
(new Runnable() {
public void run() {
System.out.println(getClass().getName()); // prints Bla$1
}
}).run();
}
}
After compiling, you get:
$ ls *.class
Bla$1.class Bla.class
That said, you can't rely on the numbering in case the source file is modified.
Can you instead define a static inner class, like:
public class ClassOne {
public static class MyClass extends AnotherClass<ClassOne> {
public MyClass(/* arguments you would pass in getThat()? */) {
...
}
...
}
public static AnotherClass<ClassOne> getThat() {
return new MyClass(...);
}
}
I need to say the obvious here - you should make it a named class if you want to refer to it. Whether you can access it otherwise is a technical curiosity (that I don't happen to know the answer to), not something you should actually do in production.
The dollar sign only comes into play in the class's binary name; in Java source, just use de.me.mypackage.ClassOne.AnotherClass.class.
How does this work?
EDIT: Being static is not a good explanation, because I can use non-static methods and it will all work. Updated the code to reflect that.
I have this in a file called Foo.java:
// This is in the Foo.java file
class Test {
public void printSomething() {
System.out.println("In Foo.Test");
}
};
and this in a file called Caller.java:
// This goes in the Caller.java file
public class Caller {
public static void main(String[] args) {
Test test = new Test();
test.printSomething();
}
}
I can execute my Caller and it will print In Foo.Test. How can this not be a compilation problem? I don't even have a Foo class created. I don't even have to define Foo.Test in the Caller.
This is on Eclipse Luna, Java8.
Java is weird like that. You could have a file without any lines of code and it would still compile. Go on try it.
Now, I think you are confusing Test with Foo.Test (I understand, it's Friday).
Intrinsically what you defined is this:
public class Foo {} // this is by default, but don't try to use it because you didn't define the scope
class Test {}
And your perplexity is "OMG, Test is the impure offspring of a non-existing class!!!", because you were expecting something like
public class Foo {
class Test {}
}
This has nothing to do with a method being static. It is about quirkiness in the javac.
Happy Friday everyone! Time for happy hour.
The main-Method of the Foo.java is declared static
calling static methods works without creating a object of the class.
E.g you can create following Method in Foo.java
class Test {
public static void test(String test) {
System.out.println(test);
}
};
Now you can call Test.test("No object will be created"); and there will be NO instance of Test
A java file could contain single public class, but it could have as much non-public classes (package-local in your case) as you wanted.
Foo.Test is for inner classes. The one you declared is top level type.
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.
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.
Well, that's a mouthful of a title. It gets my point across, though. Here's the gist of my code, inside the jar:
public class NetworkShared {
public static class LoginRequest {
public String Username;
//...
Then, to access it, I'm doing something like this:
NetworkShared.LoginRequest request = new NetworkShared.LoginRequest();
request.Username = "example"; //this is the problem line
It's when I try to access request.Username that I have a problem. Eclipse says the field NetworkShared.LoginRequest.Username is not visible. I'm puzzled because it's public all the way down. Java's not my main language, so I might be missing something. Does anyone know?
EDIT: I might add that this on Android. NetworkShared is in its own JAR and I've added it to the build path. Nothing else is wrong except for accessing request.Username.
Conclusion: Seems like this was an Eclipse refresh problem with a referenced JAR.
It should work. A top-level class is implicitly static so basically NetworkShared.LoginRequest is a correct way to identify the LoginRequest class. You are doing it the right way.
My answer is not to your eclipse problem -- it is to your Java question -- so at least you can get your Java related worries out of the way.
Outside the fact that your eclipse might have a bug (would not the first either), could you please compile the following code in your eclipse? You might have trimmed down your original code to something that actually works.
NetworkShared.java
public class NetworkShared {
public static class LoginRequest {
public String Username;
}
}
Test.java
public class Test {
public static void main(String[] args) {
NetworkShared.LoginRequest o = new NetworkShared.LoginRequest();
o.Username = null;
}
}