0

I know well, what is a class literal in java, I just wonder, what is the reason for the .class in the syntax. Is there any ambiguity removed by this? I mean, wouldn't an alternative Java syntax using

Class<String> c = String;

instead of

Class<String> c = String.class;

work? To me the class keyword looks like a boilerplate.

Community
  • 1
  • 1
maaartinus
  • 44,714
  • 32
  • 161
  • 320
  • the real question is why can't you do `Method m = String.toString` or so – KitsuneYMG Mar 01 '11 at 02:40
  • 3
    @Kitsune: uh, because Java doesn't support first-class functions. Incidentally, you _can_ do that like this: `Method m = String.class.getMethod("toString");` but it's slow, throws exceptions, and is ugly as sin (esp. when invoking it). – Matt Ball Mar 01 '11 at 02:42
  • @Kitsune you can - look into the reflection library. – corsiKa Mar 01 '11 at 02:43
  • 1
    @Matt - actually, it has nothing to do with the lack of first-class functions. it's just a lack of the relevant syntactic sugar. – jtahlborn Mar 01 '11 at 03:28

4 Answers4

3

Sure, you could make that the syntax. But using the .class suffix makes the compiler's job easier; it has to do less work to know that the code is syntactically correct.

Without the suffix, the compiler would have to work harder to understand the difference between this:

String.getName() // a method inherited from java.lang.Class<T>

and this:

String.valueOf(...) // a static method from java.lang.String

If you don't think that the .class suffix is needed, do you also think that the f and L suffices are useless (for float and long literals, respectively)?

Matt Ball
  • 354,903
  • 100
  • 647
  • 710
  • 2
    `L` is extraneous on large values but definitely needed if you do `50L * 1000000 * 1000000`; you will get overflow otherwise. `f` is necessary to disambiguate from doubles. – ide Mar 01 '11 at 02:38
  • Strange that I didn't see this ambiguity myself. @ide - agreed, that's a different thing. – maaartinus Mar 01 '11 at 03:38
  • @ide: of course you're right. Much of Java syntax is about giving the compiler "hints" — that is, being as explicit as is reasonably possible, and minimizing the guesswork. – Matt Ball Mar 01 '11 at 03:47
1

It's just not the same thing. String is a class of type string, and String.member is one of its member variables, String.method() would be one of its methods.

String.class is an object of type Class that defines String. It seems a lot more intuitive that you need to specify .class to indicate that you're trying to refer to an object of type Class.

Not to mention that it's easier to parse this kind of construct, and potentially prevents bugs where you're accidentally returning a Class object when you didn't mean to.

This is even more relevant when you're looking at inner classes, like OuterClass.InnerClass.class.

To work with Matt's example: How would you work on the class object without having to create a temporary variable first? Assuming your class Foo has a static method called getClasses, how would you differentiate between Foo.getClasses and Foo.class.getClasses?

EboMike
  • 76,846
  • 14
  • 164
  • 167
  • I think your first paragraph's argument doesn't hold any water. The OP asks _why_ this is the case. I agree with the rest, though, since it's similar to what I said in my answer. – Matt Ball Mar 01 '11 at 02:41
  • Yeah, but that's somewhat of an implicit conversion - one thing Java is very eager to avoid. String by itself is "a class of type String", not "a Class object defining String". I understand that it may sound appealing to just make it one and the same, but it isn't. – EboMike Mar 01 '11 at 02:44
  • @EboMike @Matt Ball I agree that there are cases when the disambiguation is needed. However, the most common use of `X.class` is for passing it as argument (and is getting more and more common, when using reflection, annotations, etc). So I'd prefer to have the possibility to omit it normally, and use something like `String.class.getName()` and `String.static.valueOf(....)` when necessary. – maaartinus Aug 17 '11 at 17:03
1

String is the String class pseudo-object which provides access to the classes static fields and methods, including class, which refers to the Class instance which describes the String class. So they are distinct, but because Java doesn't have the metaclass arrangement of (say) Smalltalk-80 this isn't very clear.

You could certainly make String and String.class synonymous if you wanted to, but I think there is a valid basis for the distinction.

tgdavies
  • 10,307
  • 4
  • 35
  • 40
0

Let's use integer as an example:

Class<Integer> c = Integer; // your proposal
int i = Integer.MAX_VALUE; // compare with below
int j = c.MAX_VALUE; // hmm, not a big fan, personally

It just doesn't seem to flow, in my opinion. But that's just my opinion :)

corsiKa
  • 81,495
  • 25
  • 153
  • 204
  • For that matter you can do `Integer i; i.MAX_VALUE;`. I don't find this convincing. – ide Mar 01 '11 at 02:34
  • You 'can', but it also produces a warning (for good reason - it just doesn't flow...) – corsiKa Mar 01 '11 at 02:36
  • 2
    @ide: that's only because of a (dubious) language decision which allows static methods to be called non-statically. – Matt Ball Mar 01 '11 at 02:39