Normally, compiler should auto-box or wrap the primitive argument to an object of Integer type automatically. But in your case, it is not working. I have not tried 1.7, so can not tell. But for the time-being, pass Integer object yourself, like
Its giving you error because the compiler is unable to auto-box or wrap up the primitive to an Integer object automatically.
The biggest gamble will be to ask a question whose answer you know in that it will challenge your theory | www.TechAspire.blogspot.in
Note it is using British conventions for the commas and the leading space is there, but I had to add ‍ to the beginning of the line in the quote tags to make it appear. If you used 10000000000, it wouldn’t compile because that number is a long and needs a terminal L.
It says nothing about boxing in the Formatter documentation. It specifically says %d can be applied to an int (link as before, “Conversions” section part 2.1).
Rajdeep Biswas wrote: . . . Its giving you error because the compiler is unable to auto-box or wrap up the primitive to an Integer object automatically.
That doesn’t sound right. The argument to the %d tag is an integer, so an int should be acceptable
Yeah obviously. The method signature the argument is of type Object, so we can expect primitives will work (onyl after auto-boxing, compiler's headache). But OP got an Can not find symbol error that specifies int as the argument. This is unusual, and clearly indicating compiler's failure.
Joined: Oct 13, 2005
No, the method signature for format is (String, Object...)
Because the compiler can see that you can box 123 into Integer.valueOf(123), the int 123 is acceptable as a parameter. That does not mean it is actually boxed when the method is executed, only that it can be boxed. You would have to find the JVM code and the code of the Formatter class to verify what actually happens. But that is an implementation detail which you don’t need to know.
In your Java installation folder there is a file called src.zip. Unzip that, go into its java folder, then lang, then the String class, and you find the format method says new Formatter(). So you look in the util folder for the Formatter class and look in its constructor and see what it says.
Joined: Oct 13, 2005
Alexander McDougall wrote:Hi,
I am running version 1.7 of Java
Try the following instructions at the command line/terminalThe only explanations for your suffering such an error message are
1: You have somehow got an old version of javac
2: You have got a spelling error in the post you quoted
3: You have created your own String class, in which case prefixing the instruction with the package name java.lang. should sort it out.
I think no 3 is the most likely.
Joined: Jan 08, 2013
Thanks for all the help.
I checked the versions for javac and java, both are Java 1.7.
I checked through the various steps that you provided. I then checked the classpath. I do have an older version of the java compiler running on my machine. I had to change the classpath to point to the directory I am currently using. There is another directory set up for the older version.
It is running now without having to make any changes. The autoboxing does work as well. I tried to pass it in as an int, and as an Integer object and both worked.
Joined: Oct 13, 2005
Are you sure it is the classpath you changed? You usually change the path to get different versions of Java. You should not usually set a classpath at all; if you created all the classpath yourself, you would probably be better off deleting it (but record it just in case something goes wrong).
How do you know that passing an int or an Integer to format() represents boxing or unboxing? An Integer, being an Object, has a toString() method and maybe that is being called. Maybe String.valueOf(i) is being called. I don’t know, and I don’t need to know.
This is how you can verify boxing and unboxing:-But you should not use boxing for arithmetic if at all avoidable; its execution is much slower.
Are you sure you didn’t have a String class of your own somewhere?