We Keep Coding

The method format(String, Object[]) in the type String is not applicable [duplicate]

Here is my code:
int hoursFormat = 1, minsFormat = 2, secsFormat = 3;
String timeFormat = String.format("%02d:%02d:%02d",hoursFormat, minsFormat, secsFormat);
This gives a compilation error:
Unresolved compilation problem:
The method format(String, Object[]) in the type String is not applicable for the
arguments (String, int, int, int)
Why am I getting this error here and how can I fix it?

I had a similar problem with printf. I am using JDK 1.6.0_27. Setting the compliance level to 1.6 solved my issue. This can be set in the following way.
Project > Properties > Java Compiler
You can also refer to the following thread:
Why am I getting a compilation errors with a simple printf?

Are you using Java version 1.4 or below? Autoboxing wasn't introduced until Java 5. Try manually boxing ints to Integers.

Are you using eclipse?
If so sometimes, issues like this appear, when everything seems to be correct. Here is how I just solved it:
Right click on project and go to properties->Java Compiler
You would be seeing a recent Compiler compliance level (1.7 in my case) set in the drop down ("compiler compliance level"). Also same version is seen set below in "Generated .class files compatibility" and "Source compatibility".
Now:
Select the Checkbox: "Use default compliance settings"
Notice that a lower version (in my case 1.1) got set for: "Generated .class files compatibility" and "Source compatibility". This is the issue, although eclipse is showing that it is compiling using a higher compiler it is not.
In the drop down "compiler compliance level" choose some other level and then select the one you want. The changes would be reflected below in "Generated .class files compatibility" and "Source compatibility".
This should have resolved the issue.

You have jdk 1.4 or below version. The method String.format() is introduce in Jdk 1.5.
Take a look at coderanch post.

I'm gonna vote for a clean build. There's no reason it should be failing like this, especially when you try manually boxing to Integer. Are you using Eclipse? Sometimes it gets confused, and you just have to rebuild everything.

The signature of format is:
public static String format(String format, Object ... args) {
return new Formatter().format(format, args).toString();
}
and it seems no any mistakes in your code, for my suggestion try to run this with console application without using any IDE (For test purpose).

type does not take parameters in generics

I have an interface that takes a generic argument:
package com.lbv.itf;
public interface Segment<T extends Object> {...}
and this was written couple of years back, compiled in 1.6 and built into a jar, say segment.jar
Now, I have a new project using segment.jar and in this new project, I have a class implementing this interface:
package com.lbv.impl;
import com.lbv.itf.Segment;
public class TreeSegment implements Segment<Tree> {...}
compiling this newer class in 1.7 gives this error:
type com.lbv.itf.Segment does not take parameters
It looks so obvious that Segment interface takes the parameter but somehow, that is not visible while compiling the newer class. Is this a known JDK compatibility issue or is there something I am missing? Any help will be of great help.
UPDATE:
It works only if I compile the newer code 1.6 :(. Is there a compatibility issue from 1.6 to 1.7 on generics type parameters?
I am using
Java 1.6 Update 45 64 bit
and
Java 1.7 Update 60 64 bit

This has happend because the legacy code was compiled with the option `
'target=jsr14'
` which stripped off the type parameters so that generated code will stay compatible with older java versions. Unfortunately, 1.7 has stopped supporting this flag resulting in the issue that caught me.

identifiers in java with different versions?

as we "No keyword should be used as an Identifier in java". But there will be some words like asser or enum or any other which have been added as keyword in version 1.4, 1.5 resp. So if any older version code is used to compile with new javac, what happens if that code contains these words as an identifier?

When older code uses an identifier that is a keyword in the current version you are trying to compile the code with, you will simply get an error. The compiler won't be able to tell from the code what version it was written for.

You'll get a compile error. But you can use already compiled classes if you aren't going to make changes in your legacy code.

Thanks for your answer, After searching i got to know the answer as, if any keyword is used as an identifier then we have to compile it with its compliant compiler otherwise it gives a compiler error. So to do that say suppose if my code has a assert as an identifier which works fine with java 1.3. So i can compile it as
javac -source 1.3 example.java
which compiles fine.

Why is javac failing on #Override annotation

Eclipse is adding #Override annotations when I implement methods of an interface. Eclipse seems to have no problem with this. And our automated build process from Cruise Control seems to have no problem with this. But when I build from the command-line, with ant running javac, I get this error:
[javac] C:\path\project\src\com\us\MyClass.java:70: method does not override a method from its superclass
[javac] #Override
[javac] ^
[javac] 1 error
Eclipse is running under Java 1.6. Cruise Control is running Java 1.5. My ant build fails regardless of which version of Java I use.

The #Override annotation spec changed in Java 1.6. In Java 1.5, the compiler did not allow the #Override annotation on implemented interface methods, but in 1.6 it does. First search result I found is a blog post here.. It was not well documented, but it did change.
Eclipse is adding it because your Eclipse is set for 1.6 compliance. You should try to keep your build and eclipse environments on the same version of Java. It's unclear to me by your specifying Cruise Control is running Java 5 on whether or not it is compiling using a separate JDK6 or not.
Separate from the above 1.5 vs 1.6 #Override annotation rules, remember that Eclipse has its own compiler implementation (not javac) and will occasionally have different behavior. Whenever something compiles in Eclipse, but not Ant or Maven, you will need to find a way to make both compilers happy.

I can't really explain the problem you're seeing but it seems to be related to the fact that JDK 5 will not allow #Override on implemented methods of an interface, only on overridden methods present in a super class.
JDK 6 will allow #Override on any of them.
If your ant build fails it may be passing a source parameter to javac, asking for JDK 5 compliance.

The direct answer to the question "Why" an error is raised by javac when #Override is used in the context of a method implementation is actually in the java specifications:
"The rationale for this is that a concrete class that implements an interface will necessarily override all the interface's methods irrespective of the #Override annotation, and so it would be confusing to have the semantics of this annotation interact with the rules for implementing interfaces."
See http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6.1.4
But apparently someone changed his mind for java 1.6 and 1.5 u21...

#Override tags for implemented methods are new to Java 1.6. In Java 1.5 #Override is only correct when overriding a method in a base class. Read more here and here.

A lot of people, including me, got busted by this. See here for a bigger SO discussion

Eclipse would be pointing to 1.6 version of Java rather than 1.5.
See here for configuring java version in eclipse.

Ensure that there is only one definition of that interface.
Example:
HttpServletRequest
This is an interface with different specs depending on provider.
Compare pax-web-jetty and apache-felix-jetty. They have different methods.

I have had the same problem when building a project with ANT. The solution to the problem was to change the following property inside the build.properties file:
javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
to:
javac.compiler=modern
That solved the problem and the project got compiled and deployed successfully.

How to tell Java which StringEscapeUtils.escapeXML() to use?

I'm trying to use the StringEscapeUtils.escapeXML() function from org.apache.commons.lang...
There are two versions of that function, one which expects (Writer, String) and one which just expects (String)....
http://commons.apache.org/lang/api/org/apache/commons/lang/StringEscapeUtils.html#escapeXml(java.lang.String)
I'm trying to use the version that just expects the String parameter without the Writer, but Java is complaining that I've not given it a Writer.
How do I use this in my program so that I don't need a Writer?
String escXml = StringEscapeUtils.escapeXml(attr.get());
xml = xml.concat("<"+attr.getID()+">"+escXml+"</"+attr.getID()+">");
I've also tried just doing it inline in the string itself.
xml = xml.concat("<"+attr.getID()+">"+StringEscapeUtils.escapeXml(attr.get())+"</"+attr.getID()+">");
Both of these attempts have given me the error about it expecting the Writer though. Can anyone help me with this?
Thanks,
Matt

The error message is telling you that you are passing an Object into the method, not a String.
If you are sure that the Object is a String, then you'll need to cast it to a String first.
If this doesn't work, please post the actual code that is giving you trouble.

You should compile the java class with the specify version if you have install the more than one version of java in you system.
You should compile your file using this way.
javac -target -source
E.g H:>javac -target 1.6 -source 1.6 Testt.java
So your target and Source version is tell to the java so it will call the particular version class at run time..

What exactly is the compiler error message?
is it possible that you're using a different version of the commons library that does not have the 1-parameter method?