I want to disable the stack trace getting generated when an exception is thrown.
I have used,
Runtime.getRuntime().traceInstructions(false);
Runtime.getRuntime().traceMethodCalls(false);
but still i could see the trace getting generated. How can you do that? Also i need to detect whether some one is debugging my class.
I want to disable all exception traces. I cannot use obfuscation since my product is an SDK which will be used in development. I am offering a Runtime also which is used when people want to deploy their applications built using my SDK. My requirement is that anyone using my Runtime jars should not be able to debug the code that is written…or atleast i will make it tough to debug by avoiding the stack trace generation from my runtime jars.
One way that i have found is that all the exceptions that are originating from my runtime jars, i would just catch them and set an empty StackTraceElement array on the exception object and re-throw it…
Why such requirement?
Suppose you a develop an application using my SDK.(SDK jars cannot bundled with your application..i have restricted it and thats final 🙂 !!) Now to run your application on your client’s machine you(or client) needs to install the Runtime on client’s machine and run your application. Now what if your client starts developing his own applications using my Runtime jars!! Thats a threat to my business….Thats why the horrible requirement.
Why disable stack trace?
By disabling the stack trace generation or method call trace generation i wanted to make developing code with my Runtime jars difficult and thats why i started my question in that way…do suggest some other solution to achieve such a requirement…
There are a few intricate parts of the JVM (at least, Sun’s implementation of the JVM) which do not work if stack trace generation is disabled (I saw this in the implementation of some support methods for reflection). So I do not think that stack trace generation can be disabled at all. The
Runtime.trace*()methods are about something else (a debugging tool much more thorough than stack traces).In all generality, any Java code can be transparently analyzed, if only through bytecode instrumentation (bytecode modified with extra instructions when it is loaded). The only known defense against such analysis (I am assuming that you are trying to keep your code internals confidential) is obfuscation. See for instance ProGuard. Obfuscation will make stack traces useless to any over-inquisitive user (and, sadly, it also makes debugging very difficult, for the same reasons).