[OpenJDK 2D-Dev] RFR: JDK-8035821: Move psfont properties files from src/share/classes to src/share/lib

[Magnus Ihse Bursie]

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