Bug ID: JDK-8158050 Remove SA-JDI

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9 b131Fixed

After Jigsaw, many SA-JDI tests fail. While we can fix the problem, we have also discussed taking this as an opportunity to remove SA-JDI.

SA-JDI has very little (0?) usage among our customers.
Sustaining agrees that it has little value for them.
SA-JDI does have a number of tests that are useful for exercising SA, so removing SA-JDI will get us lower test coverage. But many of these tests are quarantined anyway.

Yes, Sustaining is fine with this
28-06-2016
OK, I'm more calm about this now. I thought it related to (which?) classes in sa-jdi.jar, which I don't think is the case, and the jar itself is gone anyway. So the classes required for our familiar SA tools are still there. It's just that sa-jdi does not mean "sa-jdi.jar", although more than just JDI-related files were in that .jar. (And I have an idea about using -Xpatch:appmodules.jimage=... to access them from a separate JDK, which is maybe the modern equivalent of bootclasspath.) - Kevin (Sustaining person saying OK, I think things we rely on will still work.)
27-06-2016
What is the new jdk9 way to create an SA based tool, which does not live inside the JDK? With sa-jdi.jar not being there, I see the classes are in the JDK still, but I haven't looked into the module magic to let another app, running using a different JDK, use them. Previously, an app running with one JDK, could use the sa-jdi.jar from another, and run successfully. Can we choose to run with appmodules.jimage from another arbitrary location?
27-06-2016
Thank you, Sharath for explanation. Do you have link to mailing thread or other communication to confirm that Sustaining and SQE are agree to these changes? I see Aleksey [~avoytilo] is on watch list - he can conform SQE agreement.
23-06-2016
FC Extension Request Justification : The JDI option for SA (SA-JDI) is not widely used. Hence it has been decided to remove it from the codebase. Risk : very low, code removal Remaining work : some coding + review Due date : In 3w
23-06-2016
In JBS I got 417 hits for sajdi. Of these 108 have been fixed �� 60 in JDK and 48 in INTJDK. Out of these 60 JDK bugs, there are some fixed in the tests. Currently there are around 37 bugs in open state. I will modify the FC extension request.
23-06-2016
Update FC extension request. Currently it says: "Risk : very low, test only changes" Also do you have answer to my question about bugs history?
22-06-2016
This RFE is for removing the SA-JDI code. The SA-JDI tests will also be removed by the SQE.
22-06-2016
Should RFE's subject be "Remove SA-JDI tests"? Any history of finding bugs with these tests before Jigsaw changes?
22-06-2016

Blocks :	JDK-8160817 - Add jsadebugd functionality to jhsdb
Relates :	JDK-8182119 - jdk.hotspot.agent's META-INF/services/com.sun.jdi.connect.Connector no longer needed
Relates :	CODETOOLS-7901796 - Use Java SA without sa-jdi.jar in JDK 9b131+
Relates :	JDK-8163289 - Remove SA-JDI from tests
Relates :	JDK-8194874 - SA: Remove scripts with sa-jdi.jar dependencies.