JDK-8158050 : Remove SA-JDI
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: svc-agent
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-04-13
  • Updated: 2020-05-08
  • Resolved: 2016-08-01
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.
9 b131Fixed
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8183550 :  
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

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.)

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?

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.

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

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.

Update FC extension request. Currently it says: "Risk : very low, test only changes" Also do you have answer to my question about bugs history?

This RFE is for removing the SA-JDI code. The SA-JDI tests will also be removed by the SQE.

Should RFE's subject be "Remove SA-JDI tests"? Any history of finding bugs with these tests before Jigsaw changes?