I am debugging a Java Application in NetBeans IDE 8.0.2.
When a Thread.start() method is called I am not able to reach the run() method of that thread (though I put the breakpoints in that method).
However, sometimes it is hitting the method but sometimes not.
How can I reach the run() method while debugging?
public class JavaApplication7 {
public static void main(String[] args) {
Mailthread1 mt1 = new Mailthread1();
Thread pt = new Thread(mt1);
pt.setName("Mailthread");
pt.start();
}
}
And the Thread class is :
class Mailthread1 implements Runnable {
public void run() {
System.out.println("Cant hit this line");
}
}
in the JDWP, there are 3 types of breakpoint: class, method and line.
If your IDE fails to intercept the line breakpoint in the println(), then you can try a method breakpoint on the run() reclaration.
If that fails, there is something out of sync between the byte code and the source. You can try adding lines, breakpointing another line above and below.
Other than that, change IDE and/or change JVM. This should work.
You don't have a t.join() nor a sleep in the main branch of your code so the new thread starts in theory but your main method also keeps running and exits. The application terminates before it even has a chance to do something in your other thread and the breakpoint is not reachable.
Related
Starting a java command line application is easy, you only have to write the following line in a command prompt (in the directory where the app is located).
java myApp.java
However, to stop the application in the right way, so that you ensure that all unmanaged resources are cleaned (and anything that must be done before stop, will be done) requires custom code.
The app will run in a debian system with no GUI as a daemon (it will run in background).
Here below I write the skeleton of the code.
public class MainClass {
public static void main(String[] args) throws Exception {
boolean stop = false;
while(!stop){
doSomething();
}
stop();
}
private static void doSomething(){
//Main code of app here
}
private static void stop(){
beforeStop();
System.exit(0);
}
private static void beforeStop(){
clean();
//Code to do anything you have to do before stop
}
private static void clean(){
//Code to clean unmanaged resources
}
}
As you can see, the app will run 24/24 and won't stop until you don't stop it.
Killing the process (as some people suggest) is not a good solution, because (for example) some unmanaged resources might not be cleaned properly.
I need a code which makes possible to alter the boolean variable "stop" from OUTSIDE.
The best solution is the one which makes possible to stop the app with a command similar to the start command, see pseudo code below (executed in a command prompt, in the directory where myApp.java is located).
myApp.java stop=true
But if it's not possible, the second option would be to have an other java command line app, which stops myApp.java, so that I could stop myApp.java with the following code
java stopMyApp.java
Is someone able to suggest a useful code example?
You can use a text file with one word. Your program reads it every x seconds and depending on that word it will autostop.
You can change the file text content by hand or with another program you can run whenever you want.
Even better you can use WatchService API (Java 7) or VFS API from Apache Commons to be notified when the file changes.
If you use a DB you can use it instead of a plain file.
I have a fairly simple Java executable jar that runs the main method, checks the availability of some services, and returns (i.e. terminates) normally if the services are up.
The executable jar is run repeatedly as monitor, and upon failure, an alarm is raised in an external alarm and reporting system.
If the services are down, the code throws a RuntimeException and on the command line, the java command throws the exception.
Does this count as a POSIX fail (i.e. return code 1)? Or, do I need to catch the exceptions and explicitly return 1?
Thanks
I don't think that it's guaranteed to return 1, and I'm not even certain it's guaranteed to return a non-zero value. I think your best bet is to catch that Exception and call System.exit(1).
It's not exactly your question, but they seem to have a better grasp of this than I do if you want to read more on those two diffirent approaches: System.exit(num) or throw a RuntimeException from main?
Yes it does. By testing the following code I was able to verify this.
TestDeath.java
public class TestDeath {
public static void main(String[] args) {
throw new RuntimeException("I'm dying");
}
}
JavaProcess.java
public class JavaProcess {
public static void main(String[] args) throws Exception {
ProcessBuilder builder = new ProcessBuilder("java", "TestDeath");
Process process = builder.start();
int exitValue = process.waitFor();
System.out.println("Exit Code: " + exitValue);
}
}
JavaProcess runs the TestDeath class in a separate process and prints the exit code.
Following is the output.
Exit Code: 1
I had compiled the first class by myself and put it in the current directory of the JavaProcess.
Platform
Windows 7 64 bit
Java 1.8.0_91-b14
In my eclipse plugin I use a ScheduledExecutorService for a repeating task. However this seems to lead to some unreachable code within the scheduled task because I can set a breakpoint in eclipse up to a certain line and it will be reached in the debugger but when I set it one line further it is not reached... Just nothing happens then, no exception just nothing.
When I try to overstep this respective line I land somewhere in the sources of the ScheduledThreadPoolExecutor and my stack shows this:
ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(FutureTask<V>).run() line: not available [local variables unavailable]
Whats going on here?
Okay the problem was that there was actually an exception being thrown but it seems like the ScheduledExecutorService swallows it without telling anything about it...
I foud this out by surrounding my code in the run-method with a generic try-catch-block like this:
#Override
public void run() {
try {
// Code
} catch (Exception e) {
e.printStackTrace();
}
}
I am running a Ruby script from Java using JRuby like so:
public class ScriptletRunnable implements Runnable {
#Override
public void run() {
ScriptingContainer scriptingContainer = new ScriptingContainer();
scriptingContainer.runScriptlet(/*My script*/); // this is a blocking call, never returns
}
}
I pass this runnable to a new thread and start the thread. When I want to stop the script from running, I can't seem to find any way to tell the ScriptingContainer to stop executing the script. Even if I make it a member and call terminate() on it, the script just doesn't stop. If you run the script from the command line you can cleanly shut it down with Ctrl+C. There must be a way to achieve this with JRuby.
I'm working with Threads in Java using Netbeans 6.9.1 on Ubuntu 10.04 x86_64. I have a problem using the method yield() because when I invoke this method the current thread keeps running instead of stopping and let other threads execution.
The code below it's an easy example to run 2 threads using yield. Instead of run the first thread, print one line and then stop the thread, the program finishes the thread 1 and then runs thread2, as the method yield is not called. I have tested this code on Windows and it works perfectly! so I wonder if there is any issue to use this method on Ubuntu or on 64bits platforms.
Any idea? Thanks in advance.
//ThreadTest.java
public class ThreadTest extends Thread{
public ThreadTest (String name){
super(name);
}
public void run(){
for (int i=0;i<5;i++){
System.out.println(getName()+" - "+i);
yield();
}
System.out.println(" END "+getName());
}
}
//Main.java
public class Main {
public static void main(String[] args) {
ThreadTest t1 =new ThreadTest("Thread1");
ThreadTest t2 =new ThreadTest("Thread2");
t1.start();
t2.start();
}
}
yield is simply a request for another thread to be scheduled. There is nothing that prevents the JVM or underlying OS from scheduling the same thread again.
The javadoc for yield() method in sun JDK 6 and JDK 7 is different, you may need to check the javadoc for the version of JVM you are using.