I am a C++ dev, working in java technology for about a year. Forgive my ignorance, but I have tried to search for following two questions.
What is the best way to debug in console for a java application (ala gdb in good ol' C++).
It seems jdb is below par.
Eclipse is the way to go for its IDE. But Eclipse is a GUI and I do develop in console on unix servers.
What is the best way to tame huge jave open-source frameworks. eg, camel, hibernate, spring, logback, blah, blah
I do most of my debugging in the console.
I have found that for the majority of bugs, Java stack traces are sufficient to identify the bug and develop a fix. This of course means that it's critical to allow stack traces to be seen on the console. For most applications, I've found that it's best to allow unchecked exceptions to propagate until they terminate the thread, with a stack trace showing up in the console; unchecked exceptions should normally indicate programming errors or uncontrollable conditions where the thread should be terminated anyway.
In cases where the stack trace is not sufficient, I've found that using System.out.println() during the debugging process is actually more effective than using an interactive debugger. Having a full log of a run is for me more useful than running a debugger where I may easily step past an issue that later turns out to be important.
Wat is the problem in setting up the project in eclipse IDE, you can always get the source code and set up your workspace??
Using sysout is great for small java programs but as the code grows or for big application (according to my understanding you plan to debug something big :P) it would really be a headache placing all those sysout and then removing them once you are done with the debugging.
I would suggest you to set up your own workspace by choosing 'import existing project in workspace' option of IDE, though it would be tiring first but will help you in long run.
I would say that there is no need for such a tool, because Java supports remote debugging.
You need to start your (server) JVM with remote debugging enabled - this will work for newer JDKs:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
After that you connect to it from the IDE, and set breakpoints or conditional breakpoints wherever you like.
See this question for more details
Also, this is a personal preference, but I would say that IntelliJ IDEA is the way to go as far as Java IDEs go.
Related
I am new to this project and it's code doesn't have any logger statement. It is tedious and time consuming to follow any flow.Because of the application's exception handling framework all the exception fall into a common exception block and it is pretty cumbersome to track back from there.
Is there any Eclipse plugin which can help me to debug the issues? I am kind of looking for similar to XCode's debug feature where it stops the flow at the line which is causing exception. You can track back on that.
Updated my question.
Note: I am using Eclipse Juno and in the middle of developing AspectJ logging utility to help me with debug statements.
Himanshu, Eclipse has a full-fledged debugger which has withstood the test of time. You will need to give it a bit more time and explore it to realize it's full potential.
For instance, the feature that you miss from XCode has a counterpart in Eclipse in the form of Exception Breakpoints.
Setting them up (as Ajay George points out) is detailed in this question :
Break when exception is thrown
I am very interested in knowing the other things that you are looking for in the Eclipse Debugger.
Edit : The following might not be of great help to you if you already have experience with Eclipse but I shall leave them here for posterity :
This is a comprehensive tutorial on debugging with Eclipse.
Also, if you prefer watching and doing instead of reading then this is a good place to start ( OR directly checkout/download the videos from here )
Eclipse has an inbuilt debugger to debug java programs (http://www.ibm.com/developerworks/library/os-ecbug/), are you looking for something other than this?
Is there a way to log all exceptions happening within JVM?
A system is built from a big number of smaller components provided by different groups. All of them are running within the same JVM (under Weblogic).
Error reporting policies are rather different in those groups, so sometimes we have cases of suppressed exceptions, which makes troubleshooting very hard. At the same time, I noticed that JDB is able to intercept any exception happening in the code, no matter where.
I'd like to use the same facility JDB uses in DEV/SIT/UAT environment to shorten issue resolution time. In PTE and PROD though the facility shall not only be turned off, but
create no performance impact
require no code change for turning it off.
Of course, I can have JDB connected to every instance of server running in DEV/SIT. It's feasible, I guess... but there are two main downside:
it makes configuration more complex
JDB stops when an exception has occured; need a script or something to let it continue
So I wonder is there any method that does it, e.g. Runtime.traceExceptions(...)?
As far as I know there is no official Java API for this besides the debugging API which could be used also from inside the VM that is about to be 'debugged'.
An easier quick and dirty way to get notified of every exception that is created at runtime is to hack some tracing code directly into the constructor(s) of the Throwable class, compile it and put it into the bootclasspath before the rt.jar. This is of course nothing you should do in a release version but it can be very helpfull to analyse code that catches exceptions somewhere and doesn't report them properly.
In response to the comments:
Regarding the Debugger API: The last time I did something like this I used the JVMDI to build a native JNI/JVMDI dll and accessed it from inside the VM. It works and lets you do all sorts of wired things that Java normally doesn't offer but I would consider this even more of a hack than using a patched Throwable class. Besides that, the JVMDI has been deprecated and was replaced with JVM TI since Java 1.6. I don't know if and how you can do something like this with this new Debugger API as well.
Using a modified Throwable is fast, easy to get right, doesn't impose any performance degeneration by itself and also not even really hackish if you are in control over the execution environment. You could think of as some kind of AOP. ;) But I would still only use it to find otherwise hard to detect bugs and not in production code or only as a last resort. Something like this should surely not be considered as part of the design. The best long term approach would be to get all your development groups to agree on some common exception treatment.
Also FindBugs can help a lot if you decide to do a code review to find all these spots where exceptions get caught and not reported.
I would probably un-jar the JDK, modify "Exception" to log your exception and then re-jar it.
It's a pretty reasonable solution and won't cause any problems--the JDK classes are, for the most part, just standard java classes.
You might be able to do it without modifying the JDK by manipulating the class path to read your version of "Exception" before reading the JDK's version--that way it wouldn't be as difficult to distribute.
GDB is designed for GCC built programs, If you are debugging a Java application I suggest you use the Java Debugger in your IDE. It can be used to trap any exception thrown.
Note: some of the libraries throw exceptions during start up normally and imagine Weblogic has some of its own.
There's a project on Fedora - ABRT - automatic bug reporting tool.
It also reports uncaught JVM exceptions.
Right now (2013), an effort is started to make it also catch JBoss AS / EAP / WildFly exceptions.
Stay tuned to know when it comes: https://fedorahosted.org/abrt/milestone/Support_for_JAVA_exceptions
I've often found the debug mode of Eclipse useful over relying on print statements or logging. However, I've found that the debug mode's performance seems to be particularly sensitive to file I/O. Loading a file can be way slower (taking ~25 times as long), and since my workflow requires loading a rather large file before I get to anything interesting, this is particularly inconvenient for me.
Is there any sensible workaround for this issue? I don't actually need the debugging during the file loading part, so is there perhaps a way to only jump into debug mode at a certain point in the process?
Note that, unlike this question, I do not believe this is a problem with the state of my workspace.
You can hook into a running application with eclipse's remote debuging feature. You have to start your app with some parameters:
java -Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y suspend=y -jar yourapp.jar
Then in your debug configuration choose Remote Java Application using port 8001.
More detailed with pics here
It's possible you're doing IO in a slow way (reading in small pieces), and debugging is just amplifying that, since there's overhead for every function call.
NetBeans has a way to specify which functions to profile, so I'd look for a similar option in Eclipse, and then tell it not to profile anything in the java.* namespace, or any of your IO specific code if that doesn't help.
I'd also make sure you're reading your file in a fast way (using buffered input streams, not using Scanner, etc.). There may also be things in NIO that could help, but I'm not that familiar with it.
I mainly use vim, but I really like the debuggers used in modern IDEs such as Netbeans, Visual C++, and Eclipse and I am wondering if there were any debuggers like those except in a standalone program? I tried using gdb, but it seems that debugging will take a lot longer using a command line. I also tried ddd, but it was a little frustrating to use since it would not display some complex structures with arrays. I really like how the debuggers in the modern IDEs allow me to just click on the down arrow to view what are in my arrays something which I do not know how to do in gdb or ddd.
You could have a look at:
http://code.google.com/p/jswat/
It's a standalone java debugger. I'm afraid it doesn't support C++ debugging.
Try Nemiver, which is a standalone graphical debugger for C and C++. It is openly developed as part of the GNOME project and uses gdb underneath.
http://projects.gnome.org/nemiver/
For windows you can use windbg. It is very good.
Don't know about Java, but for C++ you don't need an IDE to use a debugger. It is perfectly possible to code with vim and use a standalone debugger, such as windbg or gdb. In fact, that's what I do all the time.
Use Eclipse. You can easily create an Eclipse project around existing code, and still use VIM to edit your files while using Eclipse to debug.
IntelliJ is free now so it should be a good choice, I've found it to be easier to use than Eclipse but I haven't used Eclipse too much. A few features like smart complete (Ctrl+Shift+Space that lets you import/complete constructors), independent run/debug consoles that can be viewed at the same time, hotswap debugging and autosave help me save time on day-to-day programming tasks. However, there's a lot of support and plug-ins for Eclipse since it's always been open source so it really depends on what you want to do.
All right, I've hit a bug that has simply confused the bejeebus out of me. I'm looking for ideas about what it could be that I can investigate, because right now, I got nothing. It goes something like this:
I have a standalone Java application that occasionally needs to twiddle the Line-In volume of the computer it's running on (a WinXP machine). It does this by calling a pair of external executables (written in VB6*) that can get and set various component volumes. (They can handle Line-In, Mic, Wave, CD, and the master volume control.)
There are several hundred units in the field, running on hardware (Dell machines) that my company provided and controls. At least several dozen clients are using this feature, and it works perfectly -- except for one instance.
For this one troublemaking machine, it simply doesn't work. I watch the volume sliders when the app is running, and when the volume is supposed to drop, they stay put. When I check the app's log file, it throws no errors, and appears to be executing the code that drops the volume. When I run the executables from the command line, they work perfectly.
I can't vouch for this machine being 100% identical to all the ones that are behaving properly, but we've been buying the same line of Dells for quite some time now; at a bare minimum, it's very, very similar.
So, turning my confusion into a bullet list:
If I'm doing something stupid in the Java code (i.e., not clearing my STDOUT/STDERR buffers), why is it only an issue on this machine?
If there's something broken in the VB6 executables, why do they work on every other machine and on this machine from the command line?
If there's some sort of hardware oddity on this machine, what sort of oddity could cause the volume control executables to fail only when called from within a Java application?
I am very confused. I do not like being confused. Anybody have any suggestions that may lead to my enlightenment?**
-* -- I know, I know, VB6, 1998 called and they want their obsolescent proprietary bug generator back, etc. Wasn't my decision. But the code works. Usually.
-** -- Insert Buddhism joke here.
Update Edit: Customer service may have stumbled onto something; it may be something to do with client configuration settings in the database. New evidence suggests that either something's misconfigured for that client or my software is doing something stupid in response to a specific configuration. And the problem may be more widespread than we thought, due to this particular feature not being as commonly used as I thought.
Responding to the comments:
Debugger: Theoretically possible, but looks like a massive headache given our setup.
High Verbosity Logging, Java: Good idea this, particularly given than the problem may be more widespread than I originally believed. Time to start revisiting some assumptions. And possibly clubbing them. Like baby seals.
High Verbosity Logging, VB6: A possibility; will need to be rolled-into the high-verbosity Java logging to trap the output, since my VB6-fu is so pitiably weak I don't know how to output text to a file. But, yeah, knowing whether or not the script is even getting called would be valuable.
Window Event Viewer: Not familiar with this tool. May have to correct that.
PATH problem: Doesn't feel likely; the Java code constructs a relative path to the executable that doesn't look like it's relying on any environment variables.
My thanks for the suggestions people have provided; at the very least, you've gotten my brain moving in directions that feel promising.
Solution Edit: And the winner is ... That's Not A Bug, That's A Feature! A feature gone horribly, horribly wrong. A feature that will now be neutered so as to stop bothering us.
A batch of invalid assumptions kept me from seeing it sooner, not the least of which was "I don't need to tool the code with more debug statements -- the statements already in there are telling me all I need to know!" DaDaDom, if you'd like to turn your comment into an answer, there's a shiny checkmark in it for you.
Thanks to everybody who chimed in with a suggestion. Now if you'll excuse me, my head is late for a meeting with my desk.
Here goes an answer:
Can you create a version of the software with verbose logging or could you even debug the code? At least then you can tell if it's in the java or the VB part.
Hmmmm. I've been told that executing programs from Java is either easy or hard. The easy part is starting them up. The hard part is dealing with the I/O streams (see my earlier question on using Runtime.exec()). Maybe the VB program is doing or expecting something weird on these particular machines that the Java code isn't working with properly.
edit: I also found a link to Jakarta Commons Exec:
Rationale
Executing external processes from Java is a well-known problem area. It is inheriently platform dependent and requires the developer to know and test for platform specific behaviors, for example using cmd.exe on Windows or limited buffer sizes causing deadlocks. The JRE support for this is very limited, albeit better with the new Java SE 1.5 ProcessBuilder class.
Reliably executing external processes can also require knowledge of the environment variables before or after the command is executed. In J2SE 1.1-1.4 there is not support for this, since the method, System.getenv(), for retriving environment variables is deprecated.
There are currently several different libraries that for their own purposes have implemented frameworks around Runtime.exec() to handle the various issues outlined above. The proposed project should aim at coordinating and learning from these initatives to create and maintain a simple, reusable and well-tested package. Since some of the more problematic platforms are not readily available, it is my hope that the broad Apache community can be a great help.
Have you considered the possibility that the authenticated user may not have permission to edit volume settings on the workstation? Does the program run correctly if you run as an 'Administrator'?