> On Oct 4, 2018, at 9:27 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: >> That all assumes that static build actually works at all; it doesn’t look >> like we >> test that configuration these days, so who knows what bit rot may have set >> in. >> > > No, we don't test static build, and never have. I'd be surprised if it's > still possible to build a static build. > > This was a feature developed for the mobile project. The static build part > was merged, somewhat hastily, into mainline, but the rest of the mobile code > is still lingering in the mobile project fork. > > The entire "static build" concept was somewhat artificially injected in some > parts of the build code. It is for instance not possible to build all modules > with a static build. At the very least you need to build without > java.desktop, if I remember correctly. > > The motivation for the static build is that on iOS, apps are not allowed to > load dynamic libraries (for some reason only Apple knows). So a developer > that wants to build a Java app needs to have a static library version of the > entire JDK to link with into a single executable Java launcher. So in this > perspective, the entire use of dlopen in a static build smells funny, and > might be just a left-over from static build being more of a hack than a > properly supported build option. > > /Magnus
The "static build" doesn't build anymore. We're all shocked that this untested configuration has bit-rotted. :) LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the workaround is superfluous in that case. Given that, I'm going to delete the workaround and file an RFE [1] to fix or remove the currently broken "static build" support, with a comment there referring to this workaround code as possibly being relevant to fixing the static build. [1] https://bugs.openjdk.java.net/browse/JDK-8211732 New webrev: http://cr.openjdk.java.net/~kbarrett/8211296/open.01/
