|What If Home | Product Overview | Intel® TM ABI specification | Technical Requirements
FAQ | Primary Technology Contacts | Discussion Forum | Blog
There may be cases where Java applications cannot be written entirely in the Java language and therefore usually use Java Native Interface (JNI) to access native code. Traditional Java debuggers based on the Java Platform Debugging Architecture (JPDA), such as Eclipse JDT debugger, can not satisfy all developer needs, because they do not effectively support debugging native code written in other languages, e.g., C/C++.
We’ve plugged the user interface into an Eclipse IDE and provided seamless switching CDT and JDT perspectives for Java and native code debugging.
Features and Benefits:
Publishing this solution, we’ve discussed a lot about technical values and limitations of agent-based and classical debugger-centric debugging model:
Positive (agent-based native debugging):
- In-VM debugger extremely close to JVM internal structure
- Usually JNI libraries are wrappers to solid well tested part of native code so limitation of in-process debugging (e.g. blocking breakpoints ) shouldn’t affect debugging session.
Negative (agent-based native debugger):
- VM should provide corresponding debugging interface.
- Blocking breakpoint
- Signal handling is very complex.
- Context saving restoring is very complex.
The target audience is tool developers, Java developers.
- Integrates into Eclipse as a plug-in
- Includes debug agent with platform/language extensions
- Uses extended JVM runtime support
- JVM Tools Interface extension for JNI code
- Implemented on top of Harmony (http://harmony.apache.org)
- In-process debugging for native code
- For both Java and C/C++ is currently able to
- Set breakpoints and step in/over
- Show threads and stack frames
- View and edit variable values of primitive and structured types
Developed and Tested on x86
Microsoft Windows XP Pro* + Microsoft Visual Studio 2005*/ (Red Hat Enterprise Linux 4* and Novell Suse 9*)
Eclipse* (Tested and developed on Eclipse 3.2)
Apache Harmony (r567700 + patch from NCAI jira-4689)
The above images shows Java frame, break point hit in Java source and Java variables.
The above image shows JNI frames, C/C++ sources invoking Java method and C/C++ variables.
Why do I need a special JVM?
Integrated Debugger for Java*/JNI Environments is agent based debugging approach for native code, so JVM should provide some interface for agent which could manage and handle events in debug session. Fortunately this interface (JVMTI like interface NCAI) was introduced in experimental branch of Harmony JVM prebuilt for x86 windows at http://people.apache.org/~gshimansky/NCAI/win_ia32_msvc_debug_nodebug.zip and prebuilt for x86 Linux at http://people.apache.org/~gshimansky/NCAI/lnx_ia32_gcc_debug_nodebug.tar.gz
Why doesn't this work with Eclipse 3.3?
During development of Integrated Debugger for Java*/JNI Environments, XDI module used and implemented the debugging interface of Eclipse 3.2, which has some differences with Eclipse 3.3. Currently, we need developers' feedback about the debugger and limitations of an agent-based solution before migrating or developing debugger-centric solution with migrating GUI part on Eclipse 3.3 or later.
I can't get it to work. Now what do I do?
You are welcome to join the What If forum, with description of your issue. Possibly your issue will be in FAQ.
I got it to work. Now what do I do?
Wonderful! Well, try to debug your application and let us know if you need some improvements.
Vasily Levchenko is a software engineer at Intel Corporation and concentrates mostly on various technology directions. Vasily joins Intel Corporation in 2003. Sphere of interests is binary translation and ELF processing static and run-time, and kernel technologies L4, NetBSD and Linux. Vasily started at Intel with solving double JIT’ing problem on ia64 and 32-bit JVM and virtualization related projects before transition to Eclipse team. Vasily in his free time tries to hack NetBSD a little bit or helps his wife Olga with photography (more frequently then hacking NetBSD :) ) -->
Chris Elford is a principal engineer at Intel Corporation and concentrates primarily on analysis and optimization of emerging technology applications. Chris joined Intel Corporation in 1998 after receiving his Ph.D. at the University of Illinois/Urbana-Champaign (concentrating on automatic optimization of parallel file system policies). Chris started at Intel analyzing how database applications intersect the underlying platform before transitioning to a team that works to ensure that Java applications work well on Intel processor based platforms. Chris and his wife spend their free time spoiling their pet bird.