On Mon, 17 Mar 2025 09:10:50 GMT, Alan Bateman <al...@openjdk.org> wrote:
> The discussion on jdk-dev was useful but I don't think adding > --with-import-jvms is the right direction. It's too fragile and loose to > import from a build created somewhere else. Why's that? It's more loose than just "importing" a jtreg jar from "somewhere else". Nor is it any more fragile than any other part of the build system. In fact, I think you seriously underestimate how fragile the *current* solution is, where we have to manage multiple hotspot builds. I've lost count on how many times we've had to solve bugs related to this. That is a very weird quirk in the build system, that has ramifications all over, and making all changes related to hotspot being much harder and riskier. Also, to quote what I just wrote in a JBS issue: This is all not really about removing any functionality. It is just about shifting the cost of doing this odd combinations to the distributors who still want to support them, instead of letting the entire JDK build ecosystem pay the price. Any distributor who wants to build a JDK with both minimal and server will still be able to do that. But since that is a niche case, it stands to reason that they must add just a tiny bit of complexity to their build scripts to achieve this. But as a result of removing this complexity from the build system in the JDK, it will allow us to unlock a lot of well-needed functionality, such as decoupling the gtest build from the hotspot build. This in turn will lead to faster builds, and the ability to use gtest for testing of native libs (outside Hotspot) in the JDK. I can't see how it is by any mean worth paying the price of missing out on this functionality, just to keep distributors from having to modify their build scripts, for a combination that I think everyone agrees are at least on its way out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733044671
