Community
Participate
Working Groups
It would be nice to move JDT debug to a 1.5 BREE. Aside from the obvious language benefits, we could investigate using JVMTI alongside JVMDI. This investigation would require: 1. updating the source to use Java 5 constructs 2. investigate JVMTI to determine if there are new debugger hooks we can use with or without adding a separate agent.
>1. updating the source to use Java 5 constructs Please talk to Markus about that. He can give useful tips here.
(In reply to comment #0) > 2. investigate JVMTI to determine if there are new debugger hooks we can use > with or without adding a separate agent. There is really nothing we would gain debugger-wise from creating our own agent to use JVMTI directly since we don't plan to provide profiling / instrumentation / etc support in the Java debugger. Also, the overhead of creating / maintaining native agent libraries for all supported platforms is much more work than the debug team has resources to do.
(In reply to comment #1) > >1. updating the source to use Java 5 constructs > Please talk to Markus about that. He can give useful tips here. See http://wiki.eclipse.org/Generify_A_Java_Project
I have created a new branch to track the migration work called generify_debug. So far the branch contains changes to the bulk of the JDI interfaces
The code changes are complete and committed to the generify_debug branch (http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/log/?h=generify_debug). All tests pass (so far). I will run a test build that we can use for testing.
The changes have been in the N-builds all week and all tests / testing pass. Marking fixed.
(In reply to comment #6) > The changes have been in the N-builds all week and all tests / testing pass. > There are still compile warnings in the official builds: http://download.eclipse.org/eclipse/downloads/drops/N20120118-2000/testResults.php They need to get fixed or suppressed.
There are multiple problems at work here: - "javacWarnings..=-unavoidableGenericProblems" only works for source that is compiled into "." (the bundle JAR). E.g. in /org.eclipse.jdt.debug/build.properties, you need to have "javacWarnings.jdimodel.jar=-unavoidableGenericProblems", and maybe the same for jdi.jar. - @SuppressWarnings("<xxx>") are marked as unnecessary if the suppressed warning is not enabled in the build (e.g. potential null access, field declaration hides another field, ...). See "Java development user guide > Tasks > Compiling Java code > Using the batch compiler" in the help for the compiler options that have to be added to the "javacWarnings" entries if they are are also enabled in the build. These problems could be avoided in batch by adding "javacProjectSettings = true" to build.properties, but we tried to avoid overriding all options so far to keep control of this in the SDK build (and only override the defaults where really necessary). We could add -warningToken to the SDK build to avoid the @SuppressedWarnings problems globally. These will show up more and more as projects start to enable specific warnings and then suppress some false positives.
(In reply to comment #8) > There are multiple problems at work here: > > - "javacWarnings..=-unavoidableGenericProblems" only works for source that is > compiled into "." (the bundle JAR). > E.g. in /org.eclipse.jdt.debug/build.properties, you need to have > "javacWarnings.jdimodel.jar=-unavoidableGenericProblems", and maybe the same > for jdi.jar. > I added the following: jdt.debug.core javacWarnings..=-unavoidableGenericProblems javacWarnings.jdimodel.jar=-unavoidableGenericProblems javacWarnings.jdi.jar=-unavoidableGenericProblems jdt.debug.tests javacWarnings..=-unavoidableGenericProblems javacWarnings.javadebugtests.jar=-unavoidableGenericProblems jdt.debug.ui javacWarnings..=-unavoidableGenericProblems javacWarnings.snippersupport.jar=-unavoidableGenericProblems jdt.launching javacWarnings..=-unavoidableGenericProblems javacWarnings.launchingsupport.jar=-unavoidableGenericProblems jdt.launching.macosx.core javacWarnings..=-unavoidableGenericProblems jdt.launching.macosx.ui javacWarnings..=-unavoidableGenericProblems > - @SuppressWarnings("<xxx>") are marked as unnecessary if the suppressed > warning is not enabled in the build (e.g. potential null access, field > declaration hides another field, ...). See "Java development user guide > I changed the project specific settings to ignore the warnings the annotations are suppressing and removed the annotations. Also committed a bit of code clean-up. pushed changes to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=e9d411f03fb789569e481bc4c3d5b5e342328b89
Verified in N20120119-2000.
Compiling the launchingsupport.jar against 1.5 breaks 1.4 JRE detection, see bug 369480.
*** Bug 319743 has been marked as a duplicate of this bug. ***
