I knew that when a class has an inner class then this class will be compiled to two class files. Today I have codes as below
public class GenericDeserializer {
public static void main(String[] args) {
String cityPageLoadJson = "{\"count\":2,\"pageLoad\":[{\"id\":4,\"name\":\"HAN\"},{\"id\":8,\"name\":\"SGN\"}]}";
Type type = new TypeToken<GenericResult<City>>() {
}.getType();
Gson gson = new GsonBuilder().setPrettyPrinting().create();
GenericResult<City> cityPageLoad = gson.fromJson(cityPageLoadJson, type);
for (City city : cityPageLoad.getPageLoad()) {
System.out.println(gson.toJson(city));
}
}
}
Although the above one has no inner class, java compiler still creates two class files:
GenericDeserializer.class
GenericDeserializer$1.class
Using Java Decompiler tool, I see content of the second
package net.tuandn.training.lesson.gson;
import com.google.gson.reflect.TypeToken;
import net.tuandn.training.model.City;
import net.tuandn.training.model.GenericResult;
final class GenericDeserializer$1 extends TypeToken<GenericResult<City>>
{
}
Could anybody please explain why this class is created?
And when are multiple class files created on compiling?
Thank a lot!
Two class files are generated because you are using an anonymous class in the following statement:
TypeToken<GenericResult<City>>() {
.....
}
Each anonymous class file uses the same name as of the container class and appends a $1/$2 and so on.
new TypeToken<GenericResult<City>>() {
}
creates an anonymous inner class. Anonymous inner classes, just like inner classes are compiled to separate class files. Since anonymous class don't have name, that is why numbers are used to generate unique names for each such classes. The number you see there after $ is the numbering for that anonymous class, as they come in order in your enclosing class.
If you use more anonymous classes like that, the number will increment by 1. So for more anonymous classes, the generated class files would look like:
GenericDeserializer$1.class
GenericDeserializer$2.class
GenericDeserializer$3.class
GenericDeserializer$4.class
....
For inner classes however, the value after the $ is the name of the inner class, as you already would have noticed.
And when are multiple class files created on compiling?
Yes, those classes are generated, when you compile your top-level class.
Simple enough, your decompiled class shows
final class GenericDeserializer$1 extends TypeToken<GenericResult<City>>
So you have a TypeToken<GenericResult<City>> somewhere.
Looking through your code we see
Type type = new TypeToken<GenericResult<City>>() { /* anonymous inner class */ }.getType();
There's an anonymous inner class declaration there which will therefore get its own class file with $X suffix.
Related
I am converting a Java Android project to Kotlin.
I am using API.AI's client, which has two AIConfiguration classes:
Superclass
package ai.api;
public class AIConfiguration implements Cloneable {
public static enum SupportedLanguages {
English("en"),
//...
}
//...
}
Subclass
package ai.api.android;
public class AIConfiguration extends ai.api.AIConfiguration {
public enum RecognitionEngine {
//...
}
In my Java code, I was creating an instance of the subclass, as recommended in the api guide:
final AIConfiguration config = new AIConfiguration("TOKEN",
AIConfiguration.SupportedLanguages.English,
AIConfiguration.RecognitionEngine.System);
Once converted to Kotlin, it looks like this:
val config = AIConfiguration("TOKEN",
AIConfiguration.SupportedLanguages.English,
AIConfiguration.RecognitionEngine.System)
...which causes an Unresolved reference: SupportedLanguages.
I can update the reference to ai.api.AIConfiguration.SupportedLanguages.English, which compiles successfully.
I could import the superclass with import ai.api.AIConfiguration as SuperAIConfiguration and use SuperAIConfiguration.SupportedLanguages, but I would rather reference the enum directly on the subclass.
I don't get it: why is this reference valid in Java but not in Kotlin?
The visibility rules in Kotlin are different from those in Java. Kotlin classes do not "inherit" static nested classes from supertypes, because the rules get too complicated when companion objects come into play. We are trying to keep the rules as simple as possible, and normally there's no issue accessing a nested class through a supertype name, but in your case the short names of the subclass and superclass clash. This is not typical, so you have the options you listed in the question: a fully-qualified name or a rename on import.
Have got two projects javaapplication2 and javaapplication1. The same being their package names. In javaapplication2 ive imported javaapplication1 using
import javaapplication1.*;
i need to list all classses in the packeage. How to achieve this? I tried a simple code but it gets a null exception.
Package pck;
pck = Package.getPackage("javaapplication1");
System.out.println(pck.getClass());
I don't have enough rep to comment on this question or to mark it as such, but it is a duplicate of:
Getting all Classes from a Package
There are many good answers listed on that question - for instance the top is looking for classes that implement ICommand, so to implement this all you need to do is remove:
if (ICommand.class.isAssignableFrom(cls)) {
commands.add((Class<ICommand>) cls);
}
from the for loop and you have what you want.
I guess the jar containing package javaapplication1 is not in classpath as
Package.getPackage("javaapplication1");
is returning null for you.
Also,
You can have a look at the following link:
http://dzone.com/snippets/get-all-classes-within-package
or can explore the Reflection library from Google in order to get the required information, below is a sample code.
e.g.
Reflections reflections = new Reflections("javaapplication1");
Set<Class<? extends Object>> allClasses = reflections.getSubTypesOf(Object.class);
If you go throgh the object class API it is written as:
//Object API
getClass
public final Class getClass()Returns the runtime class of an object. That Class object is the object that is locked by static synchronized methods of the represented class.
Returns:
the object of type Class that represents the runtime class of the object.
It's clearly written as it represents the run time class of an object.
Suppose if you have class called as "Helloworld" in side "javaapplication1" package
create object of the class as:
Helloworld world=new Helloworld();
and then try to run as
System.out.println(wolrld.getClass());
It will return the class path of current object.
I have a program called MyProgram.java. I want to run it from different directory which will be run on another machine. So I made a directory and copied MyProgram.class file and made a .bat file that runs it (Run.bat) which includes the command: #java MyProgram.
This didn't work, I had to copy SPVerification$1.class that was generated from Eclipse in order to make it work.
What is this XXX$1.class files and why do I need them beside the XXX.class file in order to run an application?
If your .java file have inner/nested classes , post compilation those are generated as Yourclass$xxx.class files by the java compiler.
Inner class definitions produce additional class files. These class
files have names combining the inner and outer class names, such as
MyClass$MyInnerClass.class. - Source
Example (edit)
Considering following Class definition
// MyClass class
public class MyClass{
// Inner class Test1
class Inner1 {
}
// Inner class Test2
class Inner2{
}
public static void main(String [] args) {
// Anonymous inner class 1
new Object() {
};
// Anonymous inner class 2
new Object() {
};
System.out.println("Bunch of $ files :)");
}
}
Will generate these following Files
MyClass.class
MyClass$Inner1.class
MyClass$Inner2.class
MyClass$1.class
MyClass$2.class
They are anonymous inner classes. In other words, when you have a piece like
class OuterClass {
// ...
void method() {
Thread t = new Thread(new Runnable() {
// ... code implementing Runnable interface ...
});
// ... code to use t or whatever
}
}
That generates anonymous inner class, in this case implementing the Runnable interface, and compiled code of that class goes to a OuterClass$<number>.class file. You can have more than one such class, with increasing number in the .class file name.
Note that syntax is exactly the same even if you extend a class with the anonymous inner class, instead of implementing an interface. This is a slightly different from creating named classes, where you need to use implements and extends as appropriate.
When decompiling a specific jar using java decompiler (http://java.decompiler.free.fr/) I got some strange code I cannot identify what is. can someone help me? the code is something like:
Foo.access$004(Foo.this);
or this
Bar.access$006(Bar.this);
or else
Baz.access$102(Baz.this, true)
What are these methods access$004, access$006 and access$102?
Synthetic methods like this get created to support acessing private methods of inner classes. Since inner classes were not part of the initial jvm version, the access modifiers could not really handle this case. The solution was to create additional package-visible methods that delegate to the private implementation.
public class Example {
private static class Inner {
private void innerMethod() { ... }
}
public void test() {
Inner inner = ...
inner.innerMethod():
}
}
The compile would create a new method of the Inner class like this:
static void access$000(Inner inner) {
inner.innerMethod();
}
And replace the call in the test method like this:
Inner.access$000(inner);
The static access$000 is package visible and so accessible from the outer class, and being inside the same Inner class it can delegate to the private innerMethod.
These are auto-generated methods which are created by the compiler in some cases (for example when accessing private fields of another class directly, e.g., in case of nested classes).
See also What is the meaning of "static synthetic"? and Synthetic Class in Java.
If you get the relevant .class file (run jar through unzip), and run the .class file through JAD
JAD MyClass.class
then you may find that the output JAD file has decompiled that particular line in a more meaningful way, e.g.
Baz.access$102(Baz.this, true)
shows up in the JAD output as simply
myMemberVaiable = true
where myMemberVaiable is a member of class Baz that you will recognise.
I have a nested static class like:
package a.b
public class TopClass {
public static class InnerClass {
}
}
I want to instantiate with Class.forName() but it raises a ClassNotFoundException .
Class.forName("a.b.TopClass"); // Works fine.
Class.forName("a.b.TopClass.InnerClass"); // raises exception
TopClass.InnerClass instance = new TopClass.InnerClass(); // works fine
What is wrong in my code?
Udo.
Nested classes use "$" as the separator:
Class.forName("a.b.TopClass$InnerClass");
That way the JRE can use dots to determine packages, without worrying about nested classes. You'll spot this if you look at the generated class file, which will be TopClass$InnerClass.class.
(EDIT: Apologies for the original inaccuracy. Head was stuck in .NET land until I thought about the filenames...)
try
Class.forName("a.b.TopClass$InnerClass");
Inner classes are accessed via dollar sign:
Class.forName("a.b.TopClass");
Class.forName("a.b.TopClass$InnerClass");
Inner class is always accessed via dollar sign because when java compiler compile the java source code file it generates .class file(byte code).
if there is only one class for example Hello.java and this class is an outer class then java compiler on compilation generate Hello.class file but if this class has an inner class HelloInner then java compiler generates d Hello$HelloInner.class(byte code).
so bytecode always looks like for following snippet with name Outer.java:
public class Outer
{
public var;//member variable
Outer()//constructor
{
}
class Inner1
{
class Inner2
{
}
}
}
so byte code is:Outer$Inner1$Inner2.class
that's why we use $ sign to access inner class .:)