In my java project I use a third party library (jar) and call a function of that library at start.
public static void main(String args[]) {
long handle = Library.method(params);
if (0 == handle) {
// error
}
}
Use eclipse for the development. The question is, when I run the project (call the main) in RUN mode, I get the handle. But when I call with DEBUG mode (without any breakpoints attached), I do not get the handle. (The run/debug settings are the same, no additional VM or program parameters)
Question:
How can the library detect that it is called in the debug mode and
prevent returning the handle?
How can I debug this project (I need
some debug)
How can the library detect that it is called in the debug mode and prevent returning the handle?
There are ways, for instance:
How to find out if "debug mode" is enabled
But it is surely not possible to assemble the complete list of possibilities.
How can I debug this project (I need some debug)
You'll either need to find a debuggable version (maybe available from the developer of the library for additional fees?) or overcome the protection.
One-guy-I-know-who-isn't-me would for instance first try to disassemble the library to find out how is it actually protected. If disassembly succeeds then it might be even possible to remove the protection.
Related
As part of a multi tenant Android application I have a mechanism to self update the app (outside of Google Play) as for most tenants the application is not managed out of Google Play.
However, I need to support a Google Play variant. Google Play does not allow this update mechanism to be part of the app (Which is fine).
I have created a build config which acts a flag to disable this self-update mechanism which correctly works.
However, as the update code still exists inside the built APK, Google's automated App review process picks this up and does not approve the app.
Looking at the compiled APK I can see the compiler compiles the Build code like:
//BuildConfig.Java
public static final Boolean DISABLE_SELF_UPDATE = Boolean.valueOf(true);
//Application Code
if (!BuildConfig.DISABLE_SELF_UPDATE.booleanValue()) {
// Self Update method is seen here
}
Is there a way to cause the compiler to eliminate this unreachable code?
When debugging in eclipse, I believe you are able to change the value of a variable in the source and have it update in realtime without setting breakpoints or anything. I was wondering if the same was possible in intellij?
Same question but for eclipse.
You can reload classes while running your program in Debug mode and changes in code will apply if possible (there are limitations) without restarting the program.
To reload changed classes
Do one of the following:
On the main menu, choose Run -> Reload Changed Classes.
On the main menu, choose Build -> Compile "class_name" to recompile an altered class during debug.
Not aware about any other method to change the value of a variable "in real-time".
Yes, IntelliJ IDEA allows you to see real-time changes while debugging Java code. This feature is called HotSwap, and it allows you to modify your code while the program is running, without the need to stop and restart the debugger.
To use HotSwap in IntelliJ IDEA, you first need to enable it by going to the Run/Debug Configuration dialog and selecting the configuration for your application. Then, in the "Debug" tab, make sure the "Enable HotSwap" option is checked.
To use HotSwap, simply make your code changes in the editor and then press Ctrl+F9 (Windows/Linux) or Command+F9 (macOS) to compile and reload the code in the running program.
Note that not all changes can be applied using HotSwap. Some changes, such as changes to class hierarchies or changes to method signatures, will require a full restart of the debugger. Additionally, HotSwap is not supported in all Java virtual machines, so make sure to check the compatibility of your JVM if you encounter any issues
I'm one of those guys who step through their code a lot during development. Beginning with version 1.6.4 of the GAE Java development server, the server has been instrumented with calls to a function named Runtime.checkRestricted. This causes two inconveniences when I step through my code:
Whenever I step into a function, the debugger goes into the function Runtime.checkRestricted (for which there is no source code) at least once, often multiple times.
Whenever I step over a function call which has a large call tree underneath, it takes a very long time for the debugger to come back. (That's always a problem in the Eclipse Java debugger, but now it's really bad.)
For me, all this causes a serious drain on productivity. Is there any way to disable this instrumentation, or at least to prevent the debugger from stepping into it? I am using Eclipse with the GAE plugin.
Add a step filter to filter out all step breakpoints you are not interested in. The Eclipse documention provides a guide how to set up step filter.
In your specific case, you will want to add a package filter for com.google.appengine.tools.development.* , as this package and its subpackages contain GAE's Runtime class and RuntimeHelper class. Finally, don't forget to activate the option "Use Step Filters" (Shift + F5).
I'm using Google AppEngine with their built in web server. My development goes about in a simple way: I make changes to my .java sources or .jsp and compile using ant and to see the changes I have to restart the development server.
I'm wondering if there's a way I can avoid this last step of restarting my development server - somehow refresh the cached classes context of my web-server. The options provided by Google on this dev server are quite limited and am wondering if there's a better way.
I would like to avoid using something like JRebel which I could buy, but for this simple project I'm just wondering if I can remove the burden of restarting my web-server... otherwise I'll live with it.
I realized that you can just touch
appengine-web.xml to force server context reload. Also loading the
page under /_ah/reloadwebapp will reload the servers context - even if
it gives you a 404, it will still reload the context.
In debug mode, the JVM can perform some hot swapping - I know and Intellij IDEA does it, i m sure other debuggers in other IDE's does it too.
Start the app server with the debug flag (-Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000 for example), then connect the debugger to the app server.
Then, make a change to the source that is not a method signature or class field change. Recompile, and voila, the debugger hot swapped the class into the jvm being debugged!
This only really works semi-well. But it may just be enough.
I want to change the logging level depending if I'm debbugging or not, but I can't find a code snippet to check if the application is running in debug mode.
I'm using eclipse to debug the application, so if the solution only works within Eclipse it will be fine.
Found the answer on how-to-find-out-if-debug-mode-is-enabled
boolean isDebug = java.lang.management.ManagementFactory.getRuntimeMXBean().
getInputArguments().toString().contains("-agentlib:jdwp");
This will check if the Java Debug Wire Protocol agent is used.
You could modify the Debug Configuration. For example add a special VM argument only in the Debug Configuration. You can use System.getProperties() to read the supplied arguments.
Even better, modify the configurations (Run and Debug) to load a different logging configuration file. It isn't good if you need to write code to determine the logging level. This should only be a matter of configuration.
There is not an officially sanctioned way to reliably determine if any given JVM is in debug mode from inside the JVM itself, and relying on artifacts will just break your code some time in the future.
You will therefore need to introduce a methology yourself. Suggestions:
A system property.
An environment variable (shell variable like $HOME or %HOME%)
Ask the JVM about the physical location of a given resource - http://www.exampledepot.com/egs/java.lang/ClassOrigin.html - and based on it, make your decision (does the path contain the word "debug"? is it inside a jar or an unpacked class file? etc).
JNDI
The existance or content of a particular resource.
Have you tried add a vm argument in the eclipse run config?
Pass this as a VM Argument
-Ddebug=true
then you can do Boolean.getBoolean("debug") to check this.
If you are setting the debug level from your own program, may be a line like:
public static final boolean DEBUG_MODE = System.getProperty("java.vm.info", "").contains("sharing");
would do the trick.
Just tested it in eclipse3.5:
package test;
public class Test
{
/**
* #param args
*/
public static void main(String[] args)
{
System.out.println(System.getProperty("java.vm.info", ""));
}
}
will display:
mixed mode, sharing
if launched without debug
mixed mode
if executed with debug launcher
Joachim Sauer comments:
This is highly system depending.
I assume the "sharing" indicates that cross-VM class-sharing is active.
This is a very new feature and is only available on some platforms.
Furthermore there can be many possible reasons to en- or disable it, so I wouldn't use this for debug-mode detection.
(Note: I tested it with the latest jdk1.6b14. I leave this as a CW answer.)
Have a look here:
http://wiki.eclipse.org/FAQ_How_do_I_use_the_platform_debug_tracing_facility%3F
Moreover, I think you can't know if your app is run in debug mode. The only thing you can do is to pass an argument to your JVM when you debug.
Manu
If using socket (e.g. 9999) you can call netstat to check if connection was established:
Process p = new ProcessBuilder("netstat", "-n").start();
String stdout = IOUtils.toString(p.getInputStream(), Charset.defaultCharset());
Then scan in stdout for 127.0.0.1:9999.*ESTABLISHED