I have not looked at the changes in detail yet, but I think it is going in the
right direction. Just a few comments:
> On 9 May 2015, at 00:00, Patrick Reinhart <patr...@reini.net> wrote:
>
> diff -r 7101bcceb43d make/src/classes/build/tools/module/ModuleArchive.java
> --- a/make/src/classes/build/tools/module/ModuleArchive.java Thu May 07
> 10:19:34 2015 -0700
> +++ b/make/src/classes/build/tools/module/ModuleArchive.java Sat May 09
> 00:45:32 2015 +0200
> @@ -186,7 +186,7 @@
> switch (section) {
> case CLASSES:
> if (!filename.startsWith("_the.") &&
> !filename.equals("javac_state"))
> - writeEntry(in);
> + in.transferTo(out);
> break;
> case LIBS:
> writeEntry(in, destFile(nativeDir(filename),
> filename));
> @@ -218,13 +218,6 @@
> Files.copy(in, dstFile);
> }
>
> - private void writeEntry(InputStream in) throws IOException {
> - byte[] buf = new byte[8192];
> - int n;
> - while ((n = in.read(buf)) > 0)
> - out.write(buf, 0, n);
> - }
> -
> private static String nativeDir(String filename) {
> if (System.getProperty("os.name").startsWith("Windows")) {
> if (filename.endsWith(".dll") || filename.endsWith(".diz”)
This is an internal build tool, and compiles with the boot JDK, 8, so cannot
use a new 9 API.
> diff -r 7101bcceb43d
> src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java
> --- a/src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java Thu May
> 07 10:19:34 2015 -0700
> +++ b/src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java Sat May
> 09 00:45:32 2015 +0200
> @@ -829,11 +829,7 @@
> target.createDirectory();
> } else {
> try (InputStream is = jrtfs.newInputStream(getResolvedPath());
> OutputStream os = target.newOutputStream()) {
> - byte[] buf = new byte[8192];
> - int n;
> - while ((n = is.read(buf)) != -1) {
> - os.write(buf, 0, n);
> - }
> + is.transferTo(os);
> }
> }
> if (copyAttrs) {
The JRT file system needs to be able to run against 8, so should not use a new
9 API.
-Chris.
