Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown

Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and java.util.Formatter multi-arg constructors that take a java.io.File or String filename (as well as one or more additional args) opens a FileIn/OutputStream to the given File/filename. If one of the other given args causes

hg: jdk7/tl/jdk: 6990106: FindBugs scan - Malicious code vulnerability Warnings in com.sun.java.util.jar.pack.*

Changeset: 6d3fb387da8e Author:ksrini Date: 2010-12-14 07:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6d3fb387da8e 6990106: FindBugs scan - Malicious code vulnerability Warnings in com.sun.java.util.jar.pack.* Reviewed-by: mduigou, briangoetz ! src/share/classes/com/s

hg: jdk7/tl/jdk: 7006704: (pack200) add missing file for 6990106

Changeset: 68cc30a3a1fd Author:ksrini Date: 2010-12-14 08:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/68cc30a3a1fd 7006704: (pack200) add missing file for 6990106 Reviewed-by: mduigou, briangoetz + src/share/classes/com/sun/java/util/jar/pack/FixedList.java

Re: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown

Chris Hegarty wrote: Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and java.util.Formatter multi-arg constructors that take a java.io.File or String filename (as well as one or more additional args) opens a FileIn/OutputStream to the given File/filename. If one of the ot

Re: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown

Chris, In src/share/classes/java/util/Formatter.java, shouldn't lines 1977 and 2084 also use wrapFileOutputStream? 1975 public Formatter(String fileName) throws FileNotFoundException { 1976 this(Locale.getDefault(Locale.Category.FORMAT), 1977 wrapFileOutputStream(new File

hg: jdk7/tl/langtools: 6999460: Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux

Changeset: a8d3eed8e247 Author:jjh Date: 2010-12-13 17:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a8d3eed8e247 6999460: Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux Summary: Fixed JavacFileManager to not treat a non-existant pathname

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

> I've also been concerned about performance. As I understand it, but maybe > I have > it wrong, is that the JLS [1] doesn't allow this when changing final > fields > after an object is constructed. But don't we have the same overhead at object construction time? I remember having read somewhere t

hg: jdk7/tl/jdk: 7006454: Typo in javadocs typo for Statement.executeBatch @since

Changeset: a72e7147816f Author:lancea Date: 2010-12-14 16:08 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a72e7147816f 7006454: Typo in javadocs typo for Statement.executeBatch @since Reviewed-by: alanb ! src/share/classes/java/sql/Statement.java

hg: jdk7/tl/langtools: 6999891: DefaultFileManager incorrect

Changeset: 0141f508b98d Author:jjg Date: 2010-12-14 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0141f508b98d 6999891: DefaultFileManager incorrect Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/processi

Re: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

Clemens Eisserer said the following on 12/15/10 06:37: I've also been concerned about performance. As I understand it, but maybe I have it wrong, is that the JLS [1] doesn't allow this when changing final fields after an object is constructed. But don't we have the same overhead at object const