0

As claimed here, placing an L after an integer constant turns it into a Long object whereas using l would supposedly turn it into its primitive counterpart long, but Oracle claims here that "An integer literal is of type long if it is suffixed with an ASCII letter L or l".

So is the former making things up, or is the latter lying to me?

And if Oracle is lying to me, would the memory and / or performance difference of Long vs long ever actually matter or even be detectable?

In other words, does the case of a Java IntegerTypeSuffix actually matter?

Community
  • 1
  • 1
captainroxors
  • 718
  • 7
  • 18
  • 3
    I don't think that is what that answer is claiming; the poster there is merely differentiating between the object `Long` (capital _L_) and the primitive `long` (lowercase _l_), not making claims about how those characters in the literal declaration affect the type. – Reinstate Monica -- notmaynard Jul 17 '14 at 20:19
  • oooooohhhhhhhhh you're totally right. – captainroxors Jul 17 '14 at 20:21
  • 1
    Yeah, after reading the reference 3 times, it looks like he was distinguishing between `long` and `Long` as a data type, not a literal suffix. – Hot Licks Jul 17 '14 at 20:21

2 Answers2

1

No it doesn't. L is generally chosen since l can be mistaken for a 1.

It seems that the answer you're linking to has a flaw in it.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • I thought so too. It's just I've recently been learning some crazy deep and dirty secrets of Java's inner workings and was wondering if I'd encountered yet another interesting quirk. – captainroxors Jul 17 '14 at 20:18
  • E.g. 0.7 + 0.1 != 0.8 – captainroxors Jul 17 '14 at 20:29
  • @captainroxors FYI, that last quirk is not a "quirk" of Java, it's a quirk of every language and every machine that uses IEEE 64-bit floats, which is pretty much everything these days. Read [What Every Computer Scientist Should Know About Floating-Point Arithmetic](http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html). – ajb Jul 17 '14 at 20:38
  • Yes that's true. So ok then the part where Java's floating points may or may not be actual IEEE 32 and 64 bit floating points unless you force them to be with `strictfp`. – captainroxors Jul 17 '14 at 20:44
0

Placing the suffix l or L on the end of a numeric literal indicates a long literal, and not a Long object.

Section 3.10.1 of the JLS specifies the data type of a numeric literal with an l or L suffix:

An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (§4.2.1).

The type can matter when specifying literals of large quantity that are too large to fit in an int literal.

// 10 billion is illegal; too big to fit in an int,
// even if later assigned to a long
long tooBigInt = 10000000000;  

// 10 billion here is a legal long literal
long justRight = 10000000000L;
rgettman
  • 176,041
  • 30
  • 275
  • 357
  • lol. Nice quote and link. Almost like those totally aren't in the original post. :-P – captainroxors Jul 17 '14 at 20:19
  • So basically you and Kayaman are telling me I should trust Oracle over a couple of random characters on SO? – captainroxors Jul 17 '14 at 20:20
  • You can trust Oracle, but you can also test this out for yourself by attempting to compile code with the test lines above. – rgettman Jul 17 '14 at 20:21
  • Well sure. You can't have a literal int over 2147483647, but there's really no way to tell what class is being used for 1000l vs 1000L. If you said Long l = 1000l, well it's obviously a Long no matter how you slice it, but by just saying System.out.println(1000l) would that call a different method than System.out.println(1000L); Wow. having just said that I could've just tested that instead of wasting SO's time. lol. – captainroxors Jul 17 '14 at 20:23
  • `int tooBigInt = 10000000000L;`, with a valid `long` literal, will fail when assigned to an `int` but not to a `long`. `long tooBigInt = 10000000000;` and `int tooBigInt = 10000000000;` will each fail to compile, with an invalid `int` literal error. – rgettman Jul 17 '14 at 20:26