Java Software Development

It has been observed an application can have a significant amount of unnoticed Exception swallowing occurring. These exceptions are of a benign nature that are not flaws in the functionality, however they are bad practices to leave occurring unnoticed. Unless monitored, it can grow unnoticed until it becomes significant enough to notice. By the time it is noticed it can be prolific in the code and will be a major job to deal with. Exceptions have been observered with malformed URLs, XML parsers, Logging, JAXB, etc. Everytime an exception is created a collection is created and the stack trace is filled-in. Recommend instrumenting Throwable to track swallowed exceptions.

To figure out how to identify swallowed Exceptions/Errors I wrote a test in Eclipse. I added conditional breakpoints on all Throwable constructors and printed out all stacktraces whenever any Throwable is constructed. It works, but you couldn't get at the message to print it since it is set as the last line of the Throwable constructor and the constructor message argument is not available to conditional breakpoint code. If you don't care about Exception/Error messages, just call this.printStackTrace() in conditional breakpoints on all Throwable constructors and look for Exceptions/Errors that reported the Throwable constructor but not logged later. These are possible swallowed exception/error candidates. As an alternative, copy the Throwable source code and instrument the constructor implementations. Then simply -Xbootclasspath/p: the implementation into the VM ahead of the default Java Throwable implementation. This would allow you to print the message and report all exception...

Greg Kedge documentation mailto:gkedge@gmail.com

See how to get pid in previous post See the article about how to get main class and program args via JMX from anywhere in app, not passed from main which would require clients to make them available. public class RuntimeInfo { private static volatile RuntimeInfo instance; private String host; private String pid; private String mainClass; private String args; private RuntimeInfo() { } public static synchronized RuntimeInfo getInstance() { if (instance != null) { return instance; } instance = new RuntimeInfo(); instance.acquireHostAndPid(); instance.acquireMainClassAndArgs(); return instance; } private void acquireMainClassAndArgs() { for (VirtualMachineDescriptor vd : VirtualMachine.list()) { final String[] virtualMachineNameTokens = vd.toString().split(" "); if (!virtualMachineNameTokens[1].equals(pid)) { continue; } ...

Java OpenSource Solutions

Returns pid@hostname RuntimeMXBean r = ManagementFactory.getRuntimeMXBean(); System.out.println("RuntimeMXBean=" + r.getName()); On linux java -Dpid=$$ yourclass Then java expression System.getProperty("pid") will give you the process id.

JVM Lies: The OutOfMemory Myth

Part 1, " Classes and class loading " (April 2003) Part 2, " Introducing reflection " (June 2003) Part 3, " Applied reflection " (July 2003) Part 5, " Transforming classes on-the-fly " (February 2004) Part 6, " Aspect-oriented changes with Javassist " (March 2004) Part 7, " Bytecode engineering with BCEL " (April 2004) Part 8, " Replacing reflection with code generation " (June 2004)