Mixing
Comparing Class objects
I have to compare a Class object against a list of pre-defined classes.
Is it safe to use == or should I use equals?
if (klass == KlassA.class) {
} else if (klass == KlassB.class) {
} else if (klass == KlassC.class) {
} else {
}
Note: I cannot use instanceof, I don't have an object, I just have the Class object. I (mis)use it like an enum in this situation!
java
edited Nov 19 '18 at 16:04
Lii
6,86044159
asked Apr 15 '10 at 16:43
reto
11.8k54158
add a comment |
I have to compare a Class object against a list of pre-defined classes.
Is it safe to use == or should I use equals?
if (klass == KlassA.class) {
} else if (klass == KlassB.class) {
} else if (klass == KlassC.class) {
} else {
}
Note: I cannot use instanceof, I don't have an object, I just have the Class object. I (mis)use it like an enum in this situation!
java
edited Nov 19 '18 at 16:04
Lii
6,86044159
asked Apr 15 '10 at 16:43
reto
11.8k54158
add a comment |
I have to compare a Class object against a list of pre-defined classes.
Is it safe to use == or should I use equals?
if (klass == KlassA.class) {
} else if (klass == KlassB.class) {
} else if (klass == KlassC.class) {
} else {
}
Note: I cannot use instanceof, I don't have an object, I just have the Class object. I (mis)use it like an enum in this situation!
java
edited Nov 19 '18 at 16:04
Lii
6,86044159
asked Apr 15 '10 at 16:43
reto
11.8k54158
I have to compare a Class object against a list of pre-defined classes.
Is it safe to use == or should I use equals?
if (klass == KlassA.class) {
} else if (klass == KlassB.class) {
} else if (klass == KlassC.class) {
} else {
}
Note: I cannot use instanceof, I don't have an object, I just have the Class object. I (mis)use it like an enum in this situation!
java
java
edited Nov 19 '18 at 16:04
Lii
6,86044159
asked Apr 15 '10 at 16:43
reto
11.8k54158
edited Nov 19 '18 at 16:04
Lii
6,86044159
asked Apr 15 '10 at 16:43
reto
11.8k54158
edited Nov 19 '18 at 16:04
Lii
6,86044159
edited Nov 19 '18 at 16:04
Lii
6,86044159
edited Nov 19 '18 at 16:04
Lii
6,86044159
6,86044159
asked Apr 15 '10 at 16:43
reto
11.8k54158
asked Apr 15 '10 at 16:43
reto
11.8k54158
asked Apr 15 '10 at 16:43
reto
11.8k54158
11.8k54158
add a comment |
add a comment |
6 Answers
6
active
oldest
votes
java.lang.Class does not override the equals method from java.lang.Object, which is implemented like this:
public boolean equals(Object obj) {
return (this == obj);
}
So a == b is the same as a.equals(b) (except if a is null).
answered Apr 15 '10 at 16:51
robinst
21.1k77091
add a comment |
For the most of the Java applications this is correct. However, comparing Java classes using the operator == is safe just if both the classes are loaded by the same classloader.
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
4
That shouldn't matter. Two classes with the same name but loaded by different class loaders will not have the same address nor will they be the same class. So==would be false and that would be correct. If the OP wanted to compare class names that would be different (and then useklass.getName().equals(xxxx.class.getName()).
– Kevin Brock
Apr 15 '10 at 20:50
add a comment |
I am not sure if this will work for your specific situation, but you could try Class.isAssignableFrom(Class).
KlassA.class.isAssignableFrom(klass)
answered Apr 15 '10 at 17:16
jt.
5,28841922
Or because types are reflexive you could also use klassA.isAssignableFrom(klasB) && klassB.isAssignableFrom(klasA) for equality
– Steiny
Mar 2 '15 at 20:36
@Steiny, that sounds like an overkill, for equality we can just compare class references.
– M. Prokhorov
Nov 26 '17 at 13:02
add a comment |
It's probably safe.
If the object doesn't override the Equals method it will make a comparison between the references. And if two variables point to the same object, their references match.
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
good point, missed that, thanks! :)
– reto
Apr 15 '10 at 16:49
add a comment |
I prefer to use == for comparison between class objects and enum constants because it results in compilation time errors in case of incompatible types.
For example:
Class<?> cls1 = Void.class;
String cls2 = "java.lang.String";
if (cls1 == cls2) doSomething(); // Won't compile
if (cls1.equals(cls2)) doSomething(); // Will compile
answered Oct 19 '17 at 11:13
polarfish
607
add a comment |
As mentioned in previous answers, to compare objects of Class type (or java.lang.Class objects) we should use == operator. However, It may be a bit confusing because always the result of comparison between objects through == operator can not cause right results (we usually use equal() method). For example, the result of this expression is false:
new String("book") == new String("book")//false
The reason is that,
The virtual machine manages a unique Class object for each type.
Therefore, you can use the == operator to compare java.lang.Class
objects. From Core Java for the Impatient - Page 153
Therefore:
new String("book").getClass() == new String("book").getClass()//true
or
Class.forName("java.lang.String") == Class.forName("java.lang.String")//true
result in true.
answered Nov 24 '17 at 15:50
MMKarami
28426
It's not strictly true that only one class will exist with a given name per virtual machine. Since ClassLoader is a part of Class object identity, several loaders which have concurrently loaded class with the same name will produce two classes that aren't equal.
– M. Prokhorov
Nov 24 '17 at 16:22
First, thanks for your comment. Your point is correct, according oracle doc: "A class is determined by its full name and the class loader". As I am sure you know, Class.forName(...) returns a Class object corresponding to a class package and name, which is located in caller or current class loader. As, classLoader.loadClass(className) is used for getting Class object to a special class loader. So, in current class loader we can use Class.forName(...) to comparison.
– MMKarami
Nov 24 '17 at 17:51
what I'm saying is - you indeed can compare result of severalClass.forNamecalls in single expression, but if you save theClassobject in a field somewhere and stored it, then it won't necessarily be always equal to results of later calls toClass.forNamefrom different classloading contexts. This was a problem for several pretty big libraries in the past, which is why I felt like it should be mentioned.
– M. Prokhorov
Nov 26 '17 at 12:59
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2647257%2fcomparing-class-objects%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
java.lang.Class does not override the equals method from java.lang.Object, which is implemented like this:
public boolean equals(Object obj) {
return (this == obj);
}
So a == b is the same as a.equals(b) (except if a is null).
answered Apr 15 '10 at 16:51
robinst
21.1k77091
add a comment |
java.lang.Class does not override the equals method from java.lang.Object, which is implemented like this:
public boolean equals(Object obj) {
return (this == obj);
}
So a == b is the same as a.equals(b) (except if a is null).
answered Apr 15 '10 at 16:51
robinst
21.1k77091
add a comment |
java.lang.Class does not override the equals method from java.lang.Object, which is implemented like this:
public boolean equals(Object obj) {
return (this == obj);
}
So a == b is the same as a.equals(b) (except if a is null).
answered Apr 15 '10 at 16:51
robinst
21.1k77091
java.lang.Class does not override the equals method from java.lang.Object, which is implemented like this:
public boolean equals(Object obj) {
return (this == obj);
}
So a == b is the same as a.equals(b) (except if a is null).
answered Apr 15 '10 at 16:51
robinst
21.1k77091
edited Sep 8 '14 at 14:19
answered Apr 15 '10 at 16:51
robinst
21.1k77091
answered Apr 15 '10 at 16:51
robinst
21.1k77091
answered Apr 15 '10 at 16:51
robinst
21.1k77091
21.1k77091
add a comment |
add a comment |
For the most of the Java applications this is correct. However, comparing Java classes using the operator == is safe just if both the classes are loaded by the same classloader.
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
4
That shouldn't matter. Two classes with the same name but loaded by different class loaders will not have the same address nor will they be the same class. So==would be false and that would be correct. If the OP wanted to compare class names that would be different (and then useklass.getName().equals(xxxx.class.getName()).
– Kevin Brock
Apr 15 '10 at 20:50
add a comment |
For the most of the Java applications this is correct. However, comparing Java classes using the operator == is safe just if both the classes are loaded by the same classloader.
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
4
That shouldn't matter. Two classes with the same name but loaded by different class loaders will not have the same address nor will they be the same class. So==would be false and that would be correct. If the OP wanted to compare class names that would be different (and then useklass.getName().equals(xxxx.class.getName()).
– Kevin Brock
Apr 15 '10 at 20:50
add a comment |
For the most of the Java applications this is correct. However, comparing Java classes using the operator == is safe just if both the classes are loaded by the same classloader.
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
For the most of the Java applications this is correct. However, comparing Java classes using the operator == is safe just if both the classes are loaded by the same classloader.
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
answered Apr 15 '10 at 16:50
Jonhnny Weslley
7062923
7062923
4
That shouldn't matter. Two classes with the same name but loaded by different class loaders will not have the same address nor will they be the same class. So==would be false and that would be correct. If the OP wanted to compare class names that would be different (and then useklass.getName().equals(xxxx.class.getName()).
– Kevin Brock
Apr 15 '10 at 20:50
add a comment |
4
That shouldn't matter. Two classes with the same name but loaded by different class loaders will not have the same address nor will they be the same class. So==would be false and that would be correct. If the OP wanted to compare class names that would be different (and then useklass.getName().equals(xxxx.class.getName()).
– Kevin Brock
Apr 15 '10 at 20:50
4
4
That shouldn't matter. Two classes with the same name but loaded by different class loaders will not have the same address nor will they be the same class. So
== would be false and that would be correct. If the OP wanted to compare class names that would be different (and then use klass.getName().equals(xxxx.class.getName()).– Kevin Brock
Apr 15 '10 at 20:50
That shouldn't matter. Two classes with the same name but loaded by different class loaders will not have the same address nor will they be the same class. So
== would be false and that would be correct. If the OP wanted to compare class names that would be different (and then use klass.getName().equals(xxxx.class.getName()).– Kevin Brock
Apr 15 '10 at 20:50
add a comment |
I am not sure if this will work for your specific situation, but you could try Class.isAssignableFrom(Class).
KlassA.class.isAssignableFrom(klass)
answered Apr 15 '10 at 17:16
jt.
5,28841922
Or because types are reflexive you could also use klassA.isAssignableFrom(klasB) && klassB.isAssignableFrom(klasA) for equality
– Steiny
Mar 2 '15 at 20:36
@Steiny, that sounds like an overkill, for equality we can just compare class references.
– M. Prokhorov
Nov 26 '17 at 13:02
add a comment |
I am not sure if this will work for your specific situation, but you could try Class.isAssignableFrom(Class).
KlassA.class.isAssignableFrom(klass)
answered Apr 15 '10 at 17:16
jt.
5,28841922
Or because types are reflexive you could also use klassA.isAssignableFrom(klasB) && klassB.isAssignableFrom(klasA) for equality
– Steiny
Mar 2 '15 at 20:36
@Steiny, that sounds like an overkill, for equality we can just compare class references.
– M. Prokhorov
Nov 26 '17 at 13:02
add a comment |
I am not sure if this will work for your specific situation, but you could try Class.isAssignableFrom(Class).
KlassA.class.isAssignableFrom(klass)
answered Apr 15 '10 at 17:16
jt.
5,28841922
I am not sure if this will work for your specific situation, but you could try Class.isAssignableFrom(Class).
KlassA.class.isAssignableFrom(klass)
answered Apr 15 '10 at 17:16
jt.
5,28841922
answered Apr 15 '10 at 17:16
jt.
5,28841922
answered Apr 15 '10 at 17:16
jt.
5,28841922
answered Apr 15 '10 at 17:16
jt.
5,28841922
5,28841922
Or because types are reflexive you could also use klassA.isAssignableFrom(klasB) && klassB.isAssignableFrom(klasA) for equality
– Steiny
Mar 2 '15 at 20:36
@Steiny, that sounds like an overkill, for equality we can just compare class references.
– M. Prokhorov
Nov 26 '17 at 13:02
add a comment |
Or because types are reflexive you could also use klassA.isAssignableFrom(klasB) && klassB.isAssignableFrom(klasA) for equality
– Steiny
Mar 2 '15 at 20:36
@Steiny, that sounds like an overkill, for equality we can just compare class references.
– M. Prokhorov
Nov 26 '17 at 13:02
Or because types are reflexive you could also use klassA.isAssignableFrom(klasB) && klassB.isAssignableFrom(klasA) for equality
– Steiny
Mar 2 '15 at 20:36
Or because types are reflexive you could also use klassA.isAssignableFrom(klasB) && klassB.isAssignableFrom(klasA) for equality
– Steiny
Mar 2 '15 at 20:36
@Steiny, that sounds like an overkill, for equality we can just compare class references.
– M. Prokhorov
Nov 26 '17 at 13:02
@Steiny, that sounds like an overkill, for equality we can just compare class references.
– M. Prokhorov
Nov 26 '17 at 13:02
add a comment |
It's probably safe.
If the object doesn't override the Equals method it will make a comparison between the references. And if two variables point to the same object, their references match.
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
good point, missed that, thanks! :)
– reto
Apr 15 '10 at 16:49
add a comment |
It's probably safe.
If the object doesn't override the Equals method it will make a comparison between the references. And if two variables point to the same object, their references match.
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
good point, missed that, thanks! :)
– reto
Apr 15 '10 at 16:49
add a comment |
It's probably safe.
If the object doesn't override the Equals method it will make a comparison between the references. And if two variables point to the same object, their references match.
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
It's probably safe.
If the object doesn't override the Equals method it will make a comparison between the references. And if two variables point to the same object, their references match.
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
answered Apr 15 '10 at 16:47
Paulo Santos
9,71033455
9,71033455
good point, missed that, thanks! :)
– reto
Apr 15 '10 at 16:49
add a comment |
good point, missed that, thanks! :)
– reto
Apr 15 '10 at 16:49
good point, missed that, thanks! :)
– reto
Apr 15 '10 at 16:49
good point, missed that, thanks! :)
– reto
Apr 15 '10 at 16:49
add a comment |
I prefer to use == for comparison between class objects and enum constants because it results in compilation time errors in case of incompatible types.
For example:
Class<?> cls1 = Void.class;
String cls2 = "java.lang.String";
if (cls1 == cls2) doSomething(); // Won't compile
if (cls1.equals(cls2)) doSomething(); // Will compile
answered Oct 19 '17 at 11:13
polarfish
607
add a comment |
I prefer to use == for comparison between class objects and enum constants because it results in compilation time errors in case of incompatible types.
For example:
Class<?> cls1 = Void.class;
String cls2 = "java.lang.String";
if (cls1 == cls2) doSomething(); // Won't compile
if (cls1.equals(cls2)) doSomething(); // Will compile
answered Oct 19 '17 at 11:13
polarfish
607
add a comment |
I prefer to use == for comparison between class objects and enum constants because it results in compilation time errors in case of incompatible types.
For example:
Class<?> cls1 = Void.class;
String cls2 = "java.lang.String";
if (cls1 == cls2) doSomething(); // Won't compile
if (cls1.equals(cls2)) doSomething(); // Will compile
answered Oct 19 '17 at 11:13
polarfish
607
I prefer to use == for comparison between class objects and enum constants because it results in compilation time errors in case of incompatible types.
For example:
Class<?> cls1 = Void.class;
String cls2 = "java.lang.String";
if (cls1 == cls2) doSomething(); // Won't compile
if (cls1.equals(cls2)) doSomething(); // Will compile
answered Oct 19 '17 at 11:13
polarfish
607
answered Oct 19 '17 at 11:13
polarfish
607
answered Oct 19 '17 at 11:13
polarfish
607
answered Oct 19 '17 at 11:13
polarfish
607
607
add a comment |
add a comment |
As mentioned in previous answers, to compare objects of Class type (or java.lang.Class objects) we should use == operator. However, It may be a bit confusing because always the result of comparison between objects through == operator can not cause right results (we usually use equal() method). For example, the result of this expression is false:
new String("book") == new String("book")//false
The reason is that,
The virtual machine manages a unique Class object for each type.
Therefore, you can use the == operator to compare java.lang.Class
objects. From Core Java for the Impatient - Page 153
Therefore:
new String("book").getClass() == new String("book").getClass()//true
or
Class.forName("java.lang.String") == Class.forName("java.lang.String")//true
result in true.
answered Nov 24 '17 at 15:50
MMKarami
28426
It's not strictly true that only one class will exist with a given name per virtual machine. Since ClassLoader is a part of Class object identity, several loaders which have concurrently loaded class with the same name will produce two classes that aren't equal.
– M. Prokhorov
Nov 24 '17 at 16:22
First, thanks for your comment. Your point is correct, according oracle doc: "A class is determined by its full name and the class loader". As I am sure you know, Class.forName(...) returns a Class object corresponding to a class package and name, which is located in caller or current class loader. As, classLoader.loadClass(className) is used for getting Class object to a special class loader. So, in current class loader we can use Class.forName(...) to comparison.
– MMKarami
Nov 24 '17 at 17:51
what I'm saying is - you indeed can compare result of severalClass.forNamecalls in single expression, but if you save theClassobject in a field somewhere and stored it, then it won't necessarily be always equal to results of later calls toClass.forNamefrom different classloading contexts. This was a problem for several pretty big libraries in the past, which is why I felt like it should be mentioned.
– M. Prokhorov
Nov 26 '17 at 12:59
add a comment |
As mentioned in previous answers, to compare objects of Class type (or java.lang.Class objects) we should use == operator. However, It may be a bit confusing because always the result of comparison between objects through == operator can not cause right results (we usually use equal() method). For example, the result of this expression is false:
new String("book") == new String("book")//false
The reason is that,
The virtual machine manages a unique Class object for each type.
Therefore, you can use the == operator to compare java.lang.Class
objects. From Core Java for the Impatient - Page 153
Therefore:
new String("book").getClass() == new String("book").getClass()//true
or
Class.forName("java.lang.String") == Class.forName("java.lang.String")//true
result in true.
answered Nov 24 '17 at 15:50
MMKarami
28426
It's not strictly true that only one class will exist with a given name per virtual machine. Since ClassLoader is a part of Class object identity, several loaders which have concurrently loaded class with the same name will produce two classes that aren't equal.
– M. Prokhorov
Nov 24 '17 at 16:22
First, thanks for your comment. Your point is correct, according oracle doc: "A class is determined by its full name and the class loader". As I am sure you know, Class.forName(...) returns a Class object corresponding to a class package and name, which is located in caller or current class loader. As, classLoader.loadClass(className) is used for getting Class object to a special class loader. So, in current class loader we can use Class.forName(...) to comparison.
– MMKarami
Nov 24 '17 at 17:51
what I'm saying is - you indeed can compare result of severalClass.forNamecalls in single expression, but if you save theClassobject in a field somewhere and stored it, then it won't necessarily be always equal to results of later calls toClass.forNamefrom different classloading contexts. This was a problem for several pretty big libraries in the past, which is why I felt like it should be mentioned.
– M. Prokhorov
Nov 26 '17 at 12:59
add a comment |
As mentioned in previous answers, to compare objects of Class type (or java.lang.Class objects) we should use == operator. However, It may be a bit confusing because always the result of comparison between objects through == operator can not cause right results (we usually use equal() method). For example, the result of this expression is false:
new String("book") == new String("book")//false
The reason is that,
The virtual machine manages a unique Class object for each type.
Therefore, you can use the == operator to compare java.lang.Class
objects. From Core Java for the Impatient - Page 153
Therefore:
new String("book").getClass() == new String("book").getClass()//true
or
Class.forName("java.lang.String") == Class.forName("java.lang.String")//true
result in true.
answered Nov 24 '17 at 15:50
MMKarami
28426
As mentioned in previous answers, to compare objects of Class type (or java.lang.Class objects) we should use == operator. However, It may be a bit confusing because always the result of comparison between objects through == operator can not cause right results (we usually use equal() method). For example, the result of this expression is false:
new String("book") == new String("book")//false
The reason is that,
The virtual machine manages a unique Class object for each type.
Therefore, you can use the == operator to compare java.lang.Class
objects. From Core Java for the Impatient - Page 153
Therefore:
new String("book").getClass() == new String("book").getClass()//true
or
Class.forName("java.lang.String") == Class.forName("java.lang.String")//true
result in true.
answered Nov 24 '17 at 15:50
MMKarami
28426
answered Nov 24 '17 at 15:50
MMKarami
28426
answered Nov 24 '17 at 15:50
MMKarami
28426
answered Nov 24 '17 at 15:50
MMKarami
28426
28426
It's not strictly true that only one class will exist with a given name per virtual machine. Since ClassLoader is a part of Class object identity, several loaders which have concurrently loaded class with the same name will produce two classes that aren't equal.
– M. Prokhorov
Nov 24 '17 at 16:22
First, thanks for your comment. Your point is correct, according oracle doc: "A class is determined by its full name and the class loader". As I am sure you know, Class.forName(...) returns a Class object corresponding to a class package and name, which is located in caller or current class loader. As, classLoader.loadClass(className) is used for getting Class object to a special class loader. So, in current class loader we can use Class.forName(...) to comparison.
– MMKarami
Nov 24 '17 at 17:51
what I'm saying is - you indeed can compare result of severalClass.forNamecalls in single expression, but if you save theClassobject in a field somewhere and stored it, then it won't necessarily be always equal to results of later calls toClass.forNamefrom different classloading contexts. This was a problem for several pretty big libraries in the past, which is why I felt like it should be mentioned.
– M. Prokhorov
Nov 26 '17 at 12:59
add a comment |
It's not strictly true that only one class will exist with a given name per virtual machine. Since ClassLoader is a part of Class object identity, several loaders which have concurrently loaded class with the same name will produce two classes that aren't equal.
– M. Prokhorov
Nov 24 '17 at 16:22
First, thanks for your comment. Your point is correct, according oracle doc: "A class is determined by its full name and the class loader". As I am sure you know, Class.forName(...) returns a Class object corresponding to a class package and name, which is located in caller or current class loader. As, classLoader.loadClass(className) is used for getting Class object to a special class loader. So, in current class loader we can use Class.forName(...) to comparison.
– MMKarami
Nov 24 '17 at 17:51
what I'm saying is - you indeed can compare result of severalClass.forNamecalls in single expression, but if you save theClassobject in a field somewhere and stored it, then it won't necessarily be always equal to results of later calls toClass.forNamefrom different classloading contexts. This was a problem for several pretty big libraries in the past, which is why I felt like it should be mentioned.
– M. Prokhorov
Nov 26 '17 at 12:59
It's not strictly true that only one class will exist with a given name per virtual machine. Since ClassLoader is a part of Class object identity, several loaders which have concurrently loaded class with the same name will produce two classes that aren't equal.
– M. Prokhorov
Nov 24 '17 at 16:22
It's not strictly true that only one class will exist with a given name per virtual machine. Since ClassLoader is a part of Class object identity, several loaders which have concurrently loaded class with the same name will produce two classes that aren't equal.
– M. Prokhorov
Nov 24 '17 at 16:22
First, thanks for your comment. Your point is correct, according oracle doc: "A class is determined by its full name and the class loader". As I am sure you know, Class.forName(...) returns a Class object corresponding to a class package and name, which is located in caller or current class loader. As, classLoader.loadClass(className) is used for getting Class object to a special class loader. So, in current class loader we can use Class.forName(...) to comparison.
– MMKarami
Nov 24 '17 at 17:51
First, thanks for your comment. Your point is correct, according oracle doc: "A class is determined by its full name and the class loader". As I am sure you know, Class.forName(...) returns a Class object corresponding to a class package and name, which is located in caller or current class loader. As, classLoader.loadClass(className) is used for getting Class object to a special class loader. So, in current class loader we can use Class.forName(...) to comparison.
– MMKarami
Nov 24 '17 at 17:51
what I'm saying is - you indeed can compare result of several
Class.forName calls in single expression, but if you save the Class object in a field somewhere and stored it, then it won't necessarily be always equal to results of later calls to Class.forName from different classloading contexts. This was a problem for several pretty big libraries in the past, which is why I felt like it should be mentioned.– M. Prokhorov
Nov 26 '17 at 12:59
what I'm saying is - you indeed can compare result of several
Class.forName calls in single expression, but if you save the Class object in a field somewhere and stored it, then it won't necessarily be always equal to results of later calls to Class.forName from different classloading contexts. This was a problem for several pretty big libraries in the past, which is why I felt like it should be mentioned.– M. Prokhorov
Nov 26 '17 at 12:59
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2647257%2fcomparing-class-objects%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
