Develop Reference

The printf method won't work

This is the second time I've tried to use the PrintWriter#printf method, and I get this error message:
The method printf(String, Object[]) in the type PrintStream is not applicable for the argument (String, String)
The code I'm using has two classes.
This is the first class:
class apples4 {
public static void main(String[] args) {
tuna4 tuna4Object = new tuna4("Kelsey");
tuna4Object.saying();
}
}
This is the second class:
public class tuna4 {
private String girlName;
public tuna4(String name) {
girlName=name;
}
public void setName(String name) {
girlName=name;
}
public String getName() {
return girlName;
}
public void saying(){
System.out.printf("Your first girlfriend was %s\n", getName() );
}
}

Check your compliance level...

PrintStream#printf method is available since Java SE 5. Looks like your code is being compiled/evaluated by Java 4 or prior.
Review your JDK installation and/or your IDE settings about how it is compiling/evaluating your code.
By the way, if using Eclipse and Java 8, Eclipse needs a plugin to recognize Java 8 applications, so by default the evaluator will downgrade your project to Java 1.4. This happened to me and I solved it by installing an update in Eclipse Kepler. Eclipse Luna (latest Eclipse version)says that it supports Java 8, but didn't work for me (not sure if I followed the right steps or did something wrong, but went back to Kepler and works fine).

It might sound weird, but you can cast the return value of your getName() method to Object:
System.out.printf("Your first girlfriend was %s\n", (Object) getName());
Or (to create the requested array) even
System.out.printf("Your first girlfriend was %s\n", new Object[] {(Object) getName()} );
could help.

I'm sorry about my previous post saying I had the same problem, I didn't read the "before you post read this" dialog box that says don't do that. Well, after a lot of time looking around for the answer, I figured it out myself. In Preferences->Java->Compiler box, there is a button in the top left corner called "Configure Project Specific Settings...". Click it and either change the compliance level to >= Java 1.5, or turn it off. Boom, fixed.

you might need to change the execution environment if it's not already java SE 1.8
it might be CDC or sth else , so u need to change it to java SE 1.8
details in picture 1.expand ur project then 2.right click on JRE System Library and choose properties finally 3. if the environment is not java SE 1.8 ,change it to become so

Eclipse, change compiler command (for JOMP)

I want to use JOMP API (equivalent to OpenMP in C) but I met some problems:
This is the code I want to run:
import jomp.runtime.*;
public class Hello
{
public static void main (String argv[])
{
int myid;
//omp parallel private(myid)
{
myid = OMP.getThreadNum();
System.out.println("Hello from " + myid);
}
}
}
It is just an hello worl but I have a problem with the compiler. Please have a quick look at this page to understand:
http://www2.epcc.ed.ac.uk/computing/research_activities/jomp/download.html
But I can't, I do not understand how it works... I can only compile it with eclipse default compiler (I guess) and then I have only one thread!
I understand I have to compile this code (in a .jomp file) with
java jomp.compiler.Jomp MyFile
and then compile normally but I can't do this in ecplise neither in the terminal (I do not know how to install this compiler!)
ps: I use Ubuntu 12.04 on a Intel® Core™ i7-3610QM CPU # 2.30GHz × 8.

You just need to add the JOMP parameters to your launch configuration, this example can help you:
JOMP eclipse workaround

Drop to frame feature disabled in Eclipse Debug while running testcases using JUnit

Environment:
Linux, Eclipse Juno, Java 7, JUnit
When a simple application (a java class with main method) is run in debug mode, 'Drop to Frame' feature works fine in Eclipse. However if the same method is invoked from a junit test case, 'Drop to Frame' feature is disabled in Eclipse. From the documentation
Note this command is only available if the current VM supports drop to
frame and the selected stackframe is not the top frame or a frame in a
native method.
As we can see from the stack frames in Debug window when a junit test case is run, there is a frame 'NativeMethodAccessorImpl.invoke' which is native. I'm assuming this is the reason for 'Drop to Frame' being disabled.
Let me know if this reasoning is correct and if yes, any workarounds available to overcome this.

I use Eclipse Luna, Java 7 under Windows.
The situation is still as described: "Drop to frame" is disabled for the test method which immediately follows the 'NativeMethodAccessorImpl.invoke' frame.
The disabled state of the "Drop to frame" is bound to method canDropToFrame() respective supportsDropToFrame() in class org.eclipse.jdt.internal.debug.core.model.JDIStackFrame,
(in my distribution) part of plugins/org.eclipse.jdt.debug_3.8.102.v20150115-1323/jdimodel.jar.
Method supportsDropToFrame() checks if a specific frame can be dropped, and tests
the JVM must support to drop frames
the frame must not be the top most frame
the frame must not be native
the prior frame must not native
So the assumption of Ramesh was right.
This is the original code snippet for tests 3 + 4:
int index = 0;
JDIStackFrame frame = null;
while (index < frames.size()) {
frame = (JDIStackFrame) frames.get(index);
index++;
if (frame.isNative()) {
return false;
}
if (frame.equals(this)) {
if (jdkSupport) {
// JDK 1.4 VMs are currently unable to pop the
// frame directly above a native frame
if (index < frames.size()
&& ((JDIStackFrame) frames.get(index))
.isNative()) {
return false;
}
}
return true;
}
}
The comment suggests that it was written in JDK 1.4 times, so maybe in the meantime the JVM can now also drop frames above native frames.
I created a patched version of JDIStackFrame, which skips test 4.
Now when pausing in a Junit test method, "Drop to frame" was enabled, as expected.
But when actually dropping the frame, I received an error message box which stated
"com.sun.jdi.InternalException: Got error code in reply: 32 occurred popping stack frame".
I assume that this is a JDWP error code.
Therefore it seems that such a "Drop to frame" does not work in JDK 1.7 (don't know about 1.8), and it's not a Eclipse thing.

This is an old one, but for the time being this is still an issue with Eclipse 2018-09, Java 1.8 and testng as test runner. The workaround (simple and obvious) is to extract the contents of the test into another method, debug it and then inline it back. E.g.:
#Test
public void test() {
// test goes here
assertTrue(true);
}
One may use refactoring shortcuts to speed up things: select the body of the test, press Alt+Shift+M, enter name 'inner', and the result is:
#Test
public void test() {
inner();
}
private void inner() {
// test goes here and 'drop-to-frame' works well
assertTrue(true);
}
When done debugging, inline it back by pressing Alt+Shift+I while inside inner().

I've always dealt with this problem by splitting between the #Test function and a thunk that I can drop frames into.
Pre JDK-8, I'd do this:
#Test
public void testSomeFooInBar() {
drop_to_frame_testSomeFooInBar();
}
private void drop_to_frame_testSomeFooInBar() {
assertTrue(somethingOrWhatever);
}
Even though it's verbose, I insist/insisted in calling my thunks after the test functions, with the name indicating what they are for (to "jump/drop to frame"). This is always necessary because there's always someone who does "refactoring" without reading comments and start removing the thunks as "unnecessary."
With JDK 8 and above, I do this:
#Test
public void testSomeFooInBar() {
final Runnable drop_to_frame = () -> {
assertTrue(somethingOrWhatever);
};
jump_to_frame.run();
}
Simpler. Eclipse will allow you to set a breakpoint inside the runnable lambda and drop to frame as many times as you needed (assuming your logic is sufficiently re-entrant.)

Prevent “Send error report to Microsoft”

I'm working on java application which perform some Runtime sub-process on files, for some files I got error cause the Send error report to Microsoft window to appear ,I need to handle this error programmatically, without showing this window to user. Please can anyone help ?

To Suppress windows error reporting the .exe that is being invoked should not terminate with an unhandled exception. This only works if you have access to the source of the application.
Based on the WER Reference - you should use the Win32 API call WerAddExcludedApplication to add the specific .exe files that you are intending to ignore to the per-user ignore list - you could create a simple stub-application that allows you to add applications by name to the ignore list. Then when you invoke the application it does not trigger the error.
Similarly you could create another application to remove them using the WerRemoveExcludedApplication.
Alternatives are to use JNI/JNA to make a class to encapsulate this functionality rather than using Runtime.exec
Here is a simple example using Java Native Access (JNA), which is a simpler version of JNI (no C++ needed for the most part). Download the jna.jar and make it part of your project.
import com.sun.jna.Native;
import com.sun.jna.WString;
import com.sun.jna.win32.StdCallLibrary;
public class JNATest {
public interface CLibrary extends StdCallLibrary {
CLibrary INSTANCE = (CLibrary) Native.loadLibrary("wer.dll",
CLibrary.class);
int WerAddExcludedApplication(WString name, boolean global);
int WerRemoveExcludedApplication(WString name, boolean global);
}
public static void main(String[] args) {
CLibrary.INSTANCE.WerAddExcludedApplication(new WString("C:\\foo.exe"), false);
CLibrary.INSTANCE.WerRemoveExcludedApplication(new WString("C:\\foo.exe"), false);
}
}
Basically, replace the new WString(...) value with the name of the application that you are intending to ignore. It should be ignored for the purposes of windows error reporting at that point.
Bear in mind that the wer.dll is only on Windows Vista and newer, so if this is a problem, then you may need to edit the registry entries manually.

You can always use try-catch-finally statement:
try
{
some code here (the code that is causing the error);
}
catch (Exception x)
{
handle exception here;
}
It works for me...
EDIT Here is the link that can help you a little bit more:
http://www.exampledepot.com/egs/Java%20Language/TryCatch.html

java hashmap nullpointer outside of netbeans

I have the following code in netbeans (using javafx in the same project):
public class ExperimentControler {
public static HashMap<String,Double> userInput = null;
public static ObservableMapWrapper<String,Double> userInputObservable = null;
}
and
static final String totalDistance = "Total distance";
public static void main(String[] args) {
ExperimentControler.userInput = new HashMap<String,Double>();
ExperimentControler.userInput.put(totalDistance, 300.0);
ExperimentControler.userInputObservable = new ObservableMapWrapper<String,Double>(ExperimentControler.userInput);
Application.launch(PhysicsGui.class, args);
}
#Override
public void start(Stage primaryStage) {
ExperimentControler.userInput.get(totalDistance);
//...
}
This is working perfectly inside netbeans.
If I "clean and build" the project, the resulted .jar file throws a null pointer exception on this line:
ExperimentControler.userInput.get(totalDistance);
Also, this is my java version outside of netbeans:
>java -version
java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)
I also tried with jre 1.7.0 but the results were exactly the same..
In netbeans I have jdk 1.6.0_26.

OK... thanks to Kal's comment:
How are you running this program? Have you tried putting
System.out.printlns() in your main method to make sure that they are
called before the app crashes with a NPE?
I figured out that the following (javafx) code (must be this.. there is no other entry point):
#Override
public void start(Stage primaryStage) {
bypasses the main() when I run it as standalone. Maybe the root cause is totally different I don't know..
The fact is that in netbeans, main() is running and on the standalone is not..
I also checked the jar's manifest and the main-class is correct. (just in case)
My mind could not go to the fact that main is not running at all !
So, I moved the code I had in main() to the overrided start method and it works.
The specification says that the start() method is the main entry point for javafx applications.
But, in my understanding, main() should still be called before start().. this could be a bug on javafx.

I had something like this before.
Hashmap auto-boxing might be the problem here.
I think you are trying to autounbox a null value.
Try
ExperimentControler.userInput.put(totalDistance, new Double(300.0));
\EDIT OK thanks #hovercraft, If this doesn't work, you must be storing a null in your hash map somewhere else in your code. Remember that get(totalDistance) is replaced by get(totalDistance).doubleValue(); if you are assigning to an double.
As to why it doesn't work out of the jar... no idea sorry.
PS What is the exact line for ExperimentControler.userInput.get(totalDistance);? are you assigning it to an Double or a double? that can make all the difference.