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!
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.
So I thought I understood packages, but turns out I don't.
Classes inside a package: I have this folder structure: mypackage/mysubpackage. Inside mysubpackage folder I have 2 classes:
package mypackage.mysubpackage;
public class Class1 {...}
and
package mypackage.mysubpackage;
public class Class2 {...}
However, when I compile Class1 (which uses methods from Class2) using javac Class1.java inside the directory mypackage/mysubpackage, it can't see Class2:
Class1.java: error: cannot find symbol
Class2 c = new Class2();
^
symbol: class Class2
location: class Class1
It works fine if I run javac Class1.java in the directory that contains mypackage/mysubpackage. Shouldn't the compilation work inside mysubpackage folder?
Classes in another package: Now, I have another class with methods that I want to be accesible to all the subpackages, so I create a final Commons.java inside mypackage/commons:
package mypackage.commons;
public final class Commons {
public static double method() {...}
...
}
And then I update Class2 importing that class so that I can use its methods inside the class:
package mypackage.mysubpackage;
import mypackage.commons.*;
public class Class2 {...}
Now it doesn't find the method I defined in the final class:
./mypackage/mysubpackage/Class2.java: error: cannot find symbol
double var = method();
^
symbol: method method()
location: class Class2
Shouldn't if find it? I think I'm importing it correctly, the methods are static and the class is final. Why doesn't it recognize it?
Cheers!
Looks like your problem is with where you set your working directory when you launch the Java compiler from the command line.
I would recommend that you pick up an integrated development environment -- Eclipse is a good one. Using the IDE you run into no such problems. Here are the classes I just created in Eclipse, which compile correclty.
Commons
package com.example.packagecommons;
public class Commons {
public static double method() {
return 0;}
}
Class1
package com.example.packages;
public class Class1 {
private Class2 c2;
public Class1() {
c2 = new Class2();
}
}
Class2
package com.example.packages;
import com.example.packagecommons.Commons;
public class Class2 {
private double initialValue;
public Class2() {
initialValue = Commons.method();
}
public double getValue() {
return initialValue;
}
}
Suppose your two classes Demo01 and Demo03 are in package pack1.subpack and your Demo02 is in pack2
So the hierarchy is like
someDrive/pack1/subpack/Demo01
someDrive/pack1/subpack/Demo03
someDrive/pack2/Demo02
someDrive/pack1/common/Demo04
where Demo01 is
package pack1.subpack;
import pack2.Demo02; // need to add this if calling class of different package
import pack1.common.Demo04; // if you are going to use Demo04 class in Demo01 class
public class Demo01 {
public void run() {
System.out.println("--running Demo01-");
}
public static void main(String[] args){
Demo01 demo01 = new Demo01();
demo01.run();
Demo02 demo02 = new Demo02();
demo02.run();
Demo03 demo03 = new Demo03();
demo03.run();
Demo04.run();
}
}
Demo02 is
package pack2;
public class Demo02 {
public void run() {
System.out.println("--running Demo02--");
}
}
Demo03 is
package pack1.subpack;
public class Demo03 {
public void run() {
System.out.println("--running Demo03--");
}
}
Demo04 is
package pack1.common;
public final class Demo04 {
public void run() {
System.out.println("--running Demo04--");
}
}
Then just compile it using javac pack1/subpack/Demo01.java
and execute it using java pack1/subpack.Demo01
I know this thread is old but I'd like to clarify things so as to help future viewers.
Your first question basically is, how does the Java run-time system know where to look for packages that you create? Remember these 3 rules (one of them must apply):
Your main package must be in a subdirectory of the current working directory to be found.
You can specify a directory path or paths by setting the CLASSPATH environmental variable.
You can use the -classpath option with java and javac to specify the path to your classes when you are executing your code via the terminal/cmd.
To answer your first question, you are executing your code from mypackage/mysubpackage. For Java run-time to recognise Class2, you must execute from mypackage.
Coming to the second question, when you import all the contents of a package using *, you need to refer to static class members by explicitly writing the class name before them, as Java does not know which class in the package you are referring to. Hence, in your code, you must write
Commons.method() instead of just method(). If you do not want to prefix the name of the class time and again, you can explicitly import the specific class you want. In your case, this would be mypackage.commons.Commons. Then you can call method() directly (provided it is static).
sh$ cd package/subpackage
sh$ javac Class1.java
Will lead to an error as the compiler will try to locate Class2 in the package/subpackage subdirectory of the current directory.
You have to compile that way:
sh$ javac package/subpackage/Class1.java
Here is a complete working example:
sh$ cat pkg/subpackage/Class1.java
package pkg.subpackage;
import pkg.commons.Class2;
public class Class1 {
public static void main(String args[]) {
Class2.doSomething();
}
}
sh$ cat pkg/commons/Class2.java
package pkg.commons;
public class Class2 {
public static void doSomething() {
System.out.println("hello");
}
}
sh$ javac pkg/subpackage/Class1.java
sh$ java pkg.subpackage.Class1
hello
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.
The following snippet (abstracted from real-world code) compiles and runs in Eclipse.
package1/Outer.java:
package package1;
import package1.Outer.Mid.Inner;
import package2.Bar;
public class Outer {
final Mid mid = new Mid();
public Outer() {
mid.setInner(new Inner() {
#Override public void foo() {
System.out.println("In Outer.foo()");
}
});
}
public static class Mid implements Bar {
private Inner inner;
public void setInner(Inner inner) {
this.inner = inner;
}
public Inner getInner() {
return this.inner;
}
#Override
public void bar() {}
interface Inner {
void foo();
}
}
}
package2/Bar.java:
package package2;
public interface Bar {
void bar();
}
However, it fails with this error when compiling using javac:
package1\Outer.java:31: cannot find symbol
symbol : class Bar
location: class package1.Outer
public static class Mid implements Bar {
^
package1\Outer.java:42: method does not override or implement a method from a supertype
#Override
^
2 errors
Now, if I switch the order of the import statements, like so:
import package2.Bar;
import package1.Outer.Mid.Inner;
...then it compiles in both Eclipse and javac. Clearly the order of the import statements seems to matter...but why?
Notes:
I tested this using Java JDK 1.6.0_30, and also Java JDK 1.7.0_21. If this is a bug that has since been fixed, that would be good to know.
It seems strange to me that the package1.Outer.Mid.Inner import is even necessary, given the Inner interface is nested within Outer.java, but both Eclipse and javac seem to require it
I discovered this problem trying to run an Ant build of production code that had a similar structure. Everything was building fine in Eclipse, but the Ant script just refused to go through.
This looks like a bug, as reported on Oracle's bug database here.
According to the JLS §7.5, the order of import-statements should not matter.