Fwd: RFR [9] 8039362: Read content-types.properties as a resource

[Erik Joelsson]

Hello Chris,

The changes seem to do what you intend, but I have a couple of questions.

If this is a standard properties file, wouldn't it make sense to either 
"clean" or "compile" it like other properties files?

I note that there is a macosx version of this file but from what I can 
see of both the old and new makefile logic, it's not being used. Should 
it be? If not it should be removed.

In CopyIntoClasses.gmk, there is no need to declare explicit rules for 
files that follow standard patterns. For this file, you could add it to 
the list of CLEAN_FILES, if cleaning is ok in this case. Or if straight 
copying is preferred, adding a pattern to COPY_PATTERNS that includes 
this file is also possible. On the other hand, since there is the 
complication of the unused macosx version of the file, standard patterns 
may not apply. It would be good to resolve this and make 
content-types.properties fit better with an existing pattern.

/Erik

On 2014-04-07 16:33, Chris Hegarty wrote:
> Adding build-dev ( for the makefile changes ).
>
> -Chris.
>
> -------- Original Message --------
> Subject: RFR [9] 8039362: Read content-types.properties as a resource
> Date: Mon, 07 Apr 2014 15:27:43 +0100
> From: Chris Hegarty <chris.hegarty at oracle.com>
> To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
>
> Following JDK-8004963: "URLConnection, downgrade normative reference to
> ${java.home}/lib/content-types.properties", this bug [1] moves
> content-types.properties out of the image lib directory and into
> resources.jar ( to be loaded as a resources file ). This approach is
> acceptable, since the file is not expected to be user editable.
>
> Webrev:
>   http://cr.openjdk.java.net/~chegar/8039362/00/webrev/
>
> MimeTable.save(String) can be simply removed since it is never called,
> and editing the default table is not supported.
>
> The motive for this bug is the modular JDK where we need the flexibility
> to put anything that is module-private into a module-private location.
> In this case it would appear that the above files are not a supported
> interface and so should move to a location that should be read as
> resources.
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8039362
>
>