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.
At runtime, a resource file like say a font, really should live in
jre/lib (or the jigsaw equivalent thereof). For starters it needs
to be filesystem accessible so the native platform can see it,
and secondly its used by lots of code.
Also users might want to tweak them.
In the source tree because its not associated with a particular
java class then something like src/share makes sense.
The '*psfont* files by contrast, are parsed once by one class
they live alongside. They aren't a general resource for the
rest of the system. So no matter where they go at runtime
they are better co-located with the source.
Where they go at runtime is something we can discuss later,
when that kind of change is ready. As I hinted I hope we
don't just blithely copy all src/share/lib files regardless of
module, and I do hope the jigsaw teams
will discuss this sort of thing long before we see code reviews ..
Since much of it is passed into distant history, its not easy to
say if particular files in jre/lib were there by design, convenience, or
following existing custom. Same goes for where they originate
in the source tree.
Some of the files you list there - notably fontconfig - may be
both user modifiable and start up sensitive.
Others like the cmm ones are not modifiable, but may be startup
sensitive and you are allowed to do some customisation of which
ones are present.
Then there are the cursors. Potentially start-up sensitive,
probably not intended to be user modifiable/replaceable
but it wouldn't surprise me if people have done it ..
The "psfont" ones are not expected to be user modifiable,
but its a very useful 'just in case', to have them in jre/lib.
Where they live at runtime is likely not a big deal for startup
(time to first print isn't something we ever measured :-)),
but they are useful for users to see sometimes.
-phil.
On 02/27/2014 12:58 PM, Mandy Chung wrote:
Hi Phil,
Is psfont*.properties* file more of a resource file? Is there any
reason (or specification) that psfont*.properties has to be in JRE/lib
directory? One potential reason might be the startup performance (warm
start/cold start) to avoid opening a jar file? They don't look like a
user-editable properties file and that could be the reason why they
live in src/share/classes.
As part of the modularization effort, we want to separate the
user-editable configuration file from the non-modifiable resource
files. For the non-modifiable resource files, does it make sense to
move them together with the classes like other java resources?
What Erik is doing to prepare for the source restructuring to enable
the module build such that we can build one module at a time (i.e. you
can just build the desktop module + its dependencies and skip the rest
of JDK build).
Here are the list of files under JRE/lib directory. Do you see any
reason any of these can be moved to a different directory e.g.
together with the classses?
lib/cmm/CIEXYZ.pf
lib/cmm/GRAY.pf
lib/cmm/LINEAR_RGB.pf
lib/cmm/PYCC.pf
lib/cmm/sRGB.pf
lib/content-types.properties
lib/flavormap.properties
lib/fontconfig.bfc
lib/fontconfig.properties.src
lib/images/cursors/cursors.properties
lib/images/cursors/invalid32x32.gif
lib/images/cursors/motif_CopyDrop32x32.gif
lib/images/cursors/motif_CopyNoDrop32x32.gif
lib/images/cursors/motif_LinkDrop32x32.gif
lib/images/cursors/motif_LinkNoDrop32x32.gif
lib/images/cursors/motif_MoveDrop32x32.gif
lib/images/cursors/motif_MoveNoDrop32x32.gif
lib/psfont.properties.ja
lib/psfontj2d.properties
lib/sound.properties
Mandy
[1]
http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/share/classes/sun/print/PSPrinterJob.java
On 2/27/14 12:32 PM, Phil Race wrote:
Magnus,
I completely understand that the content of the files and the runtime
behaviour aren't affected, but logically you'd want to put things
together,
not spread out across the source tree. Then its much easier for
people to
understand what uses what.
If a jigsaw build somehow can't cope with this, then maybe the
problem is there ?
I'd have to understand that.
Those files are only relevant to the 'client' module. In a jigsaw
world, where will they live ?
Is there even a concept of an installed jre/lib, or a source tree's
src/share/lib ?
And FWIW I presume you need a src/<platform>/lib too .. ?
-phil.
On 2/27/2014 12:03 AM, Magnus Ihse Bursie wrote:
Phil,
First of all, note that this is a change in build only. This change
will not affect the source code in question, nor how it is executed.
The properties files will end up in the very same location as a
result of the build, wether with or without this patch. Hence, there
is no need to run any printing tests.
We can of course just as well integrate this patch using
jdk9/client, if you prefer.
Some background here might be useful, so you can understand what
Erik is trying to achieve. Most files are stored in a suitable
location: java files that should be compiled in src/*/classes. Files
that should be copied to the lib directory in the resulting image
are in src/share/lib. However, there are a few files that are stored
elsewhere. This has been handled using hard-coded exception rules in
the build system. Erik has spent some serious effort lately on
cleaning up those idiosyncrasies.
That normalization was something that we have been planning to do
all along, but it has become urgent due to the jigsaw project. While
we can handle the exceptions, even if its ugly, it has turned into a
blocker to handle all those misplaced files when we need to
reshuffle all source code.
So, to summarize:
* The code using those files will not be affected.
* This is needed for the jigsaw project.
With that information, I hope you can reconsider your position.
/Magnus
26 feb 2014 kl. 19:48 skrev Phil Race <philip.r...@oracle.com>:
PS the same goes for other things like font property changes if you
have such in mind.
And unless you intend to run the printing test suite before you push,
then changes like this *must* go into jdk9/client. Not jdk9/dev.
Moot however, since I don't agree with the change.
-phil.
On 2/26/2014 10:46 AM, Phil Race wrote:
Adding 2d-dev as 2d owns this file and might like to know where it
went.
My 2p : the files are however interpreted solely by the code with
which it is co-located.
So unless the build will come crashing down around us, I'd very
much prefer that these
files stay exactly where I put them ...
-phil.
On 2/26/2014 7:38 AM, Tim Bell wrote:
Hi Erik:
Here is another simple file move to bring more order to the
sources. This time it's the psfont properties files that are
being moved from src/share/classes to src/share/lib since in the
build, they are just copied to the lib directory, so should not
be confused with java resource files.
Bug: https://bugs.openjdk.java.net/browse/JDK-8035821
Webrev: http://cr.openjdk.java.net/~erikj/8035821/webrev.jdk.01/
Looks good to me.
Tim
