On 2014-02-27 22:33, Phil Race wrote:
Hi,
Leaving aside jigsaw, and regardless of whether they are modifiable,
the question as to whether at runtime they should live in rt.jar or
jre/lib
is a separate question than where they would live in the source tree
and one does not necessarily follow the other.
You seem to be touching on the runtime location, but this change
is only about the source location. Where it lives in the source tree
surely doesn't matter to a user.
You are correct that the current change only is about the source
location, not the runtime location.
However, I do not agree that the source location and the runtime
location are completely orthogonal. In fact, the current situation, that
source location and runtime location are somewhat loosely coupled is
*exactly* what we're trying to address here!
The problem here is that the JDK code base is filled with special cases
and exceptions, all of which needs to be handled and "corrected"
manually by the make files. With the old build system, where the
makefiles were distributed and every sub-part of the JDK had their own
makefiles with very little correlation or shared code, this was not so
obvious. Every single special case looked like it was the only one in
the world, and a single special case can always be accepted, right?
When we created the new build-infra system and integrated all of the
build, all the special cases and exceptions just added up. We need to
have a lot of extra, unnecessary build logic, just to handle the
exceptional, non-standard cases. As I said, we skipped doing anything
about that in the initial build-infra project (and instead aiming for a
bit-by-bit, bug-by-bug compatibility with the old build system), but we
have always planned to address this.
Now jigsaw has come, with the shuffling of source code. And suddenly all
the exceptions goes from a nuicanse to a big problem. Unless we can
unify the code base and get rid of the exceptions, we need to double all
the exception handling -- once for the current source location, and once
for the new location in the shuffled source code. And, on top of that,
we now have a historic chance to actually get the complete code base in
somewhat better shape.
In this case, the "anomaly" here is that we have a .properties file in
the source/*/classes tree, that is not supposed to be compiled into a
ResourceBundle, as the other 97% of the properties files are. Most of
the other non-ResourceBundle .properties files turned out to be better
placed elsewhere. We believe the same is true for these files.
/Magnus
