From bradford.wetmore at sun.com  Mon Jun  2 16:51:56 2008
From: bradford.wetmore at sun.com (bradford.wetmore at sun.com)
Date: Mon, 02 Jun 2008 23:51:56 +0000
Subject: hg: jdk7/tl/jdk: 7 new changesets
Message-ID: <20080602235329.642CC28E34@hg.openjdk.java.net>

Changeset: ca48d7cc3579
Author:    chegar
Date:      2008-05-15 10:26 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca48d7cc3579

6670408: testcase panics 1.5.0_12&_14 JVM when java.net.PlainSocketImpl trying to throw an exception
Summary: Replace select with poll
Reviewed-by: alanb, jccollet

! src/solaris/native/java/net/PlainSocketImpl.c

Changeset: 2ebefcea77a5
Author:    vinnie
Date:      2008-05-14 18:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ebefcea77a5

6383078: OCSP checking does not work on end-entity certificate
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/OCSPChecker.java

Changeset: 49f02cbe27b1
Author:    vinnie
Date:      2008-05-15 10:55 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49f02cbe27b1

Merge


Changeset: d3dfeb4295b3
Author:    wetmore
Date:      2008-05-17 00:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3dfeb4295b3

Merge


Changeset: f8049c6ff629
Author:    wetmore
Date:      2008-05-22 14:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8049c6ff629

6706358: jdk/test/sun/security/pkcs11/Cipher/TestSymmCiphers.java has the wrong copyright notice.
Reviewed-by: valeriep

! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java

Changeset: ead7a5f601d5
Author:    weijun
Date:      2008-05-27 14:29 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ead7a5f601d5

6705313: Incorrect exit $? in keytool's autotest.sh
Reviewed-by: valeriep

! test/sun/security/tools/keytool/autotest.sh

Changeset: 827f9f3d1031
Author:    wetmore
Date:      2008-06-02 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/827f9f3d1031

Merge



From jonathan.gibbons at sun.com  Tue Jun  3 13:29:30 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 03 Jun 2008 20:29:30 +0000
Subject: hg: jdk7/tl/jdk: 6708729: update jdk Makefiles for new javap
Message-ID: <20080603202951.7C07E28EBE@hg.openjdk.java.net>

Changeset: f494f33398f1
Author:    jjg
Date:      2008-06-03 13:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f494f33398f1

6708729: update jdk Makefiles for new javap
Reviewed-by: ohair

! make/common/Release.gmk
! make/common/internal/Defs-langtools.gmk


From jonathan.gibbons at sun.com  Tue Jun  3 13:30:55 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 03 Jun 2008 20:30:55 +0000
Subject: hg: jdk7/tl/langtools: 4075303: Use javap to enquire aboput a
	specific inner class; ...
Message-ID: <20080603203058.2069828EC3@hg.openjdk.java.net>

Changeset: 7708bd6d800d
Author:    jjg
Date:      2008-06-03 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7708bd6d800d

4075303: Use javap to enquire aboput a specific inner class
4348375: Javap is not internationalized
4459541: "javap -l" shows line numbers as signed short; they should be unsigned
4501660: change diagnostic of -help as 'print this help message and exit'
4776241: unused source file in javap...
4870651: javap should recognize generics, varargs, enum
4876942: javap invoked without args does not print help screen
4880663: javap could output whitespace between class name and opening brace
4975569: javap doesn't print new flag bits
6271787: javap dumps LocalVariableTypeTable attribute in hex, needs to print a table
6305779: javap: support annotations
6439940: Clean up javap implementation
6469569: wrong check of searchpath in JavapEnvironment
6474890: javap does not open .zip files in -classpath
6587786: Javap throws error : "ERROR:Could not find <classname>" for JRE classes
6622215: javap ignores certain relevant access flags
6622216: javap names some attributes incorrectly
6622232: javap gets whitespace confused
6622260: javap prints negative bytes incorrectly in hex
Reviewed-by: ksrini

! make/build.properties
! make/build.xml
! make/netbeans/common/standard-ide-actions-no-javadoc.ent
! make/netbeans/common/standard-ide-actions.ent
+ src/share/classes/com/sun/tools/classfile/AccessFlags.java
+ src/share/classes/com/sun/tools/classfile/Annotation.java
+ src/share/classes/com/sun/tools/classfile/AnnotationDefault_attribute.java
+ src/share/classes/com/sun/tools/classfile/Attribute.java
+ src/share/classes/com/sun/tools/classfile/AttributeException.java
+ src/share/classes/com/sun/tools/classfile/Attributes.java
+ src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java
+ src/share/classes/com/sun/tools/classfile/ClassFile.java
+ src/share/classes/com/sun/tools/classfile/ClassReader.java
+ src/share/classes/com/sun/tools/classfile/ClassTranslator.java
+ src/share/classes/com/sun/tools/classfile/ClassWriter.java
+ src/share/classes/com/sun/tools/classfile/Code_attribute.java
+ src/share/classes/com/sun/tools/classfile/CompilationID_attribute.java
+ src/share/classes/com/sun/tools/classfile/ConstantPool.java
+ src/share/classes/com/sun/tools/classfile/ConstantPoolException.java
+ src/share/classes/com/sun/tools/classfile/ConstantValue_attribute.java
+ src/share/classes/com/sun/tools/classfile/DefaultAttribute.java
+ src/share/classes/com/sun/tools/classfile/Deprecated_attribute.java
+ src/share/classes/com/sun/tools/classfile/Descriptor.java
+ src/share/classes/com/sun/tools/classfile/DescriptorException.java
+ src/share/classes/com/sun/tools/classfile/EnclosingMethod_attribute.java
+ src/share/classes/com/sun/tools/classfile/Exceptions_attribute.java
+ src/share/classes/com/sun/tools/classfile/Field.java
+ src/share/classes/com/sun/tools/classfile/InnerClasses_attribute.java
+ src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java
+ src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java
+ src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java
+ src/share/classes/com/sun/tools/classfile/Method.java
+ src/share/classes/com/sun/tools/classfile/ModuleExportTable_attribute.java
+ src/share/classes/com/sun/tools/classfile/ModuleMemberTable_attribute.java
+ src/share/classes/com/sun/tools/classfile/Module_attribute.java
+ src/share/classes/com/sun/tools/classfile/OpCodes.java
+ src/share/classes/com/sun/tools/classfile/RuntimeAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeInvisibleAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeInvisibleParameterAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeParameterAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeVisibleAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/RuntimeVisibleParameterAnnotations_attribute.java
+ src/share/classes/com/sun/tools/classfile/Signature.java
+ src/share/classes/com/sun/tools/classfile/Signature_attribute.java
+ src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java
+ src/share/classes/com/sun/tools/classfile/SourceFile_attribute.java
+ src/share/classes/com/sun/tools/classfile/SourceID_attribute.java
+ src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java
+ src/share/classes/com/sun/tools/classfile/StackMap_attribute.java
+ src/share/classes/com/sun/tools/classfile/Synthetic_attribute.java
+ src/share/classes/com/sun/tools/classfile/Type.java
+ src/share/classes/com/sun/tools/classfile/package.html
+ src/share/classes/com/sun/tools/javap/AnnotationWriter.java
+ src/share/classes/com/sun/tools/javap/AttributeWriter.java
+ src/share/classes/com/sun/tools/javap/BasicWriter.java
+ src/share/classes/com/sun/tools/javap/ClassWriter.java
+ src/share/classes/com/sun/tools/javap/CodeWriter.java
+ src/share/classes/com/sun/tools/javap/ConstantWriter.java
+ src/share/classes/com/sun/tools/javap/Context.java
+ src/share/classes/com/sun/tools/javap/DisassemblerTool.java
+ src/share/classes/com/sun/tools/javap/InternalError.java
+ src/share/classes/com/sun/tools/javap/JavapFileManager.java
+ src/share/classes/com/sun/tools/javap/JavapTask.java
+ src/share/classes/com/sun/tools/javap/Main.java
+ src/share/classes/com/sun/tools/javap/Options.java
+ src/share/classes/com/sun/tools/javap/overview.html
+ src/share/classes/com/sun/tools/javap/package.html
+ src/share/classes/com/sun/tools/javap/resources/javap.properties
+ src/share/classes/com/sun/tools/javap/resources/version.properties-template
! src/share/classes/sun/tools/javap/Main.java
+ test/tools/javap/4870651/T4870651.java
+ test/tools/javap/4870651/Test.java
+ test/tools/javap/ListTest.java
+ test/tools/javap/OptionTest.java
+ test/tools/javap/T4075403.java
+ test/tools/javap/T4459541.java
+ test/tools/javap/T4501660.java
+ test/tools/javap/T4876942.java
+ test/tools/javap/T4880663.java
+ test/tools/javap/T4975569.java
+ test/tools/javap/T6271787.java
+ test/tools/javap/T6305779.java
+ test/tools/javap/T6474890.java
+ test/tools/javap/T6587786.java
+ test/tools/javap/T6622216.java
+ test/tools/javap/T6622232.java
+ test/tools/javap/T6622260.java


From christopher.hegarty at sun.com  Thu Jun  5 04:10:53 2008
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Thu, 05 Jun 2008 11:10:53 +0000
Subject: hg: jdk7/tl/jdk: 6626677: Error: Unimplemented()/HPI sysMonitorExit
	is broken on linux
Message-ID: <20080605111113.C046528012@hg.openjdk.java.net>

Changeset: 38a4f11764c0
Author:    chegar
Date:      2008-06-05 04:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38a4f11764c0

6626677: Error: Unimplemented()/HPI sysMonitorExit is broken on linux
Summary: Remove the definition of NEED_DL_LOCK on platforms with GLIBC
Reviewed-by: dholmes, psoper

! src/solaris/hpi/src/linker_md.c


From eamonn.mcmanus at sun.com  Thu Jun  5 05:17:44 2008
From: eamonn.mcmanus at sun.com (eamonn.mcmanus at sun.com)
Date: Thu, 05 Jun 2008 12:17:44 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20080605121827.7853E28025@hg.openjdk.java.net>

Changeset: b715e82ef7e1
Author:    emcmanus
Date:      2008-06-05 13:40 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b715e82ef7e1

6701498: Change JMX query language to use * and ? as wildcards rather than % and _
Reviewed-by: dfuchs

! src/share/classes/javax/management/MatchQueryExp.java
! src/share/classes/javax/management/ObjectName.java
! src/share/classes/javax/management/Query.java
! src/share/classes/javax/management/QueryNotificationFilter.java
! src/share/classes/javax/management/QueryParser.java
! test/javax/management/query/QueryExpStringTest.java
! test/javax/management/query/QueryParseTest.java

Changeset: af0a68f46dde
Author:    emcmanus
Date:      2008-06-05 13:42 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/af0a68f46dde

6562936: Support custom type mappings in MXBeans
Reviewed-by: dfuchs

! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java
+ src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanProxy.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanSupport.java
! src/share/classes/com/sun/jmx/mbeanserver/NotificationMBeanSupport.java
- src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java
! src/share/classes/com/sun/jmx/mbeanserver/PerInterface.java
! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanSupport.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanServerInvocationHandler.java
! src/share/classes/javax/management/MXBean.java
! src/share/classes/javax/management/StandardMBean.java
- src/share/classes/javax/management/ToQueryString.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/management/openmbean/CompositeType.java
+ src/share/classes/javax/management/openmbean/MXBeanMapping.java
+ src/share/classes/javax/management/openmbean/MXBeanMappingClass.java
+ src/share/classes/javax/management/openmbean/MXBeanMappingFactory.java
+ src/share/classes/javax/management/openmbean/MXBeanMappingFactoryClass.java
! src/share/classes/javax/management/openmbean/OpenType.java
+ test/javax/management/mxbean/CustomTypeTest.java
+ test/javax/management/mxbean/customtypes/CustomLongMXBean.java
+ test/javax/management/mxbean/customtypes/CustomMXBean.java
+ test/javax/management/mxbean/customtypes/IntegerIsLongFactory.java
+ test/javax/management/mxbean/customtypes/IntegerIsStringFactory.java
+ test/javax/management/mxbean/customtypes/package-info.java


From jonathan.gibbons at sun.com  Thu Jun  5 13:47:36 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 05 Jun 2008 20:47:36 +0000
Subject: hg: jdk7/tl/langtools: 6711276: langtools has incorrect -Werror switch
Message-ID: <20080605204738.2B70928086@hg.openjdk.java.net>

Changeset: 12c9e612e9e3
Author:    jjg
Date:      2008-06-05 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/12c9e612e9e3

6711276: langtools has incorrect -Werror switch
Reviewed-by: ksrini

! make/build.properties


From xueming.shen at sun.com  Thu Jun  5 16:34:50 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Thu, 05 Jun 2008 23:34:50 +0000
Subject: hg: jdk7/tl/jdk: 6710199: SJIS_0213 does not handle "unmappable"
	encoding operation correctly; ...
Message-ID: <20080605233508.58916280BB@hg.openjdk.java.net>

Changeset: 657f24cdfc02
Author:    sherman
Date:      2008-06-05 16:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/657f24cdfc02

6710199: SJIS_0213 does not handle "unmappable" encoding operation correctly
6699038: sun/nio/cs/findencoderBugs.java fails
Summary: SJIS_0213 charset updates
Reviewed-by: okutsu

! src/share/classes/sun/nio/cs/CharsetMapping.java
! src/share/classes/sun/nio/cs/ext/SJIS_0213.java


From xueming.shen at sun.com  Fri Jun  6 15:05:42 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 06 Jun 2008 22:05:42 +0000
Subject: hg: jdk7/tl/jdk: 6706299: System property java.class.version should
	be 51 for jdk7
Message-ID: <20080606220602.D86C12824C@hg.openjdk.java.net>

Changeset: b53b79a164c2
Author:    sherman
Date:      2008-06-06 14:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b53b79a164c2

6706299: System property java.class.version should be 51 for jdk7
Summary: System property java.class.version should be 51 for jdk7
Reviewed-by: alanb

! src/share/native/java/lang/System.c
! test/java/lang/System/Versions.java


From tim.bell at sun.com  Fri Jun  6 15:33:25 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 06 Jun 2008 22:33:25 +0000
Subject: hg: jdk7/tl/jdk: 36 new changesets
Message-ID: <20080606224038.CB8312829A@hg.openjdk.java.net>

Changeset: 7971bbb6dc42
Author:    ohair
Date:      2008-05-15 13:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7971bbb6dc42

6590549: Cygwin build of OpenJDK has problems and not very well documented
Summary: Just the Makefile changes to fix a cygwin nawk BINMODE=w problem.
Reviewed-by: igor, tbell

! make/common/shared/Defs-utils.gmk
! make/java/java/Makefile
! make/java/nio/Makefile

Changeset: b6601ba7f6df
Author:    xdono
Date:      2008-05-27 17:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b6601ba7f6df

Merge


Changeset: 2d5d4282d0fa
Author:    tbell
Date:      2008-06-02 22:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2d5d4282d0fa

Merge


Changeset: 52f4ad84d5f0
Author:    prr
Date:      2008-03-07 12:13 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/52f4ad84d5f0

6640532: Graphics.getFontMetrics() throws NullPointerException
Summary: NIO usage needs to be robust against Thread.interrupt()
Reviewed-by: tdv

! src/share/classes/sun/font/FontManager.java
+ test/java/awt/font/Threads/FontThread.java

Changeset: 73d443d6c863
Author:    prr
Date:      2008-04-09 13:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/73d443d6c863

6683472: Incorrect handling of translation component of font transform.
Reviewed-by: igor, campbell

! src/share/classes/sun/font/AttributeValues.java
+ test/java/awt/Graphics2D/DrawString/RotTransText.java

Changeset: cae9799d0810
Author:    prr
Date:      2008-04-10 09:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cae9799d0810

6684056: SUPERSCRIPT TextAttribute on font needs to trigger layout.
Reviewed-by: igor, campbell

! src/share/classes/java/awt/Font.java
+ test/java/awt/Graphics2D/DrawString/DrawStrSuper.java

Changeset: e4abdd4c2303
Author:    jgodinez
Date:      2008-04-09 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e4abdd4c2303

6633656: Cross platform print dialog doesn't check for orientation being unsupported.
Reviewed-by: prr, tdv

! src/share/classes/sun/print/ServiceDialog.java
! src/solaris/classes/sun/print/AttributeClass.java
! src/solaris/classes/sun/print/IPPPrintService.java

Changeset: 929bf1062f64
Author:    jgodinez
Date:      2008-04-10 10:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/929bf1062f64

Merge


Changeset: 9785a8218fd2
Author:    prr
Date:      2008-04-10 10:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9785a8218fd2

6638477: Two external URLS referenced in 2D documentation are no longer functioning.
Reviewed-by: jgodinez

! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java

Changeset: bda7549ac1d0
Author:    prr
Date:      2008-04-10 10:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bda7549ac1d0

Merge


Changeset: 91087975bff7
Author:    prr
Date:      2008-04-10 16:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/91087975bff7

6662775: Move imaging and color classes from closed to open
Reviewed-by: tdv, campbell

! make/common/internal/BinaryPlugs.gmk
! make/java/awt/Makefile
+ src/share/classes/java/awt/color/CMMException.java
+ src/share/classes/java/awt/color/ColorSpace.java
+ src/share/classes/java/awt/color/ICC_ColorSpace.java
+ src/share/classes/java/awt/color/ICC_Profile.java
+ src/share/classes/java/awt/color/ICC_ProfileGray.java
+ src/share/classes/java/awt/color/ICC_ProfileRGB.java
+ src/share/classes/java/awt/image/BandedSampleModel.java
+ src/share/classes/java/awt/image/ColorConvertOp.java
+ src/share/classes/java/awt/image/ComponentSampleModel.java
+ src/share/classes/java/awt/image/DataBuffer.java
+ src/share/classes/java/awt/image/DataBufferByte.java
+ src/share/classes/java/awt/image/DataBufferInt.java
+ src/share/classes/java/awt/image/DataBufferShort.java
+ src/share/classes/java/awt/image/DataBufferUShort.java
+ src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
+ src/share/classes/java/awt/image/Raster.java
+ src/share/classes/java/awt/image/RenderedImage.java
+ src/share/classes/java/awt/image/SampleModel.java
+ src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
+ src/share/classes/java/awt/image/WritableRaster.java
+ src/share/classes/java/awt/image/WritableRenderedImage.java
+ src/share/classes/java/awt/image/renderable/ContextualRenderedImageFactory.java
+ src/share/classes/java/awt/image/renderable/RenderContext.java
+ src/share/classes/java/awt/image/renderable/RenderableImage.java
+ src/share/classes/java/awt/image/renderable/RenderableImageOp.java
+ src/share/classes/java/awt/image/renderable/RenderableImageProducer.java
+ src/share/classes/java/awt/image/renderable/RenderedImageFactory.java

Changeset: 7148e1f2d7c7
Author:    lana
Date:      2008-04-10 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7148e1f2d7c7

Merge


Changeset: aaa5637a841d
Author:    lana
Date:      2008-04-10 18:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aaa5637a841d

Merge


Changeset: 99f3a382f574
Author:    jgodinez
Date:      2008-04-10 13:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99f3a382f574

6678161: Printing to remote non-Postscript printer does not work in Linux
Reviewed-by: prr, tdv

! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java

Changeset: 90e1f09ce553
Author:    jgodinez
Date:      2008-04-14 11:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90e1f09ce553

Merge


Changeset: 804b0757d801
Author:    prr
Date:      2008-04-24 11:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/804b0757d801

6523403: Need to provide lcms library with PYCC and LINEAR_RGB OS ICC profiles
Summary: Add two contributed profiles and a fix to GRAY.pf, all from Redhat, keiths at redhat.com contributed the GRAY.pf fix.
Reviewed-by: jgodinez, avu, prr
Contributed-by: aph at redhat.com

! make/sun/cmm/Makefile
! src/share/lib/cmm/lcms/GRAY.pf
+ src/share/lib/cmm/lcms/LINEAR_RGB.pf
+ src/share/lib/cmm/lcms/PYCC.pf
! test/sun/java2d/cmm/ProfileOp/ReadProfileTest.java

Changeset: ff8302a9936b
Author:    prr
Date:      2008-04-25 10:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff8302a9936b

6687298: Reg testcase java/awt/Graphics2D/DrawString/RotTransText.java fails on windows
Reviewed-by: igor, tdv

! test/java/awt/Graphics2D/DrawString/RotTransText.java

Changeset: 94d65e427402
Author:    prr
Date:      2008-04-25 10:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94d65e427402

6692979: VM Crash when shearing text + rect over a range of values
Reviewed-by: igor, tdv

! src/share/classes/sun/font/FileFontStrike.java
+ test/java/awt/font/Rotate/Shear.java

Changeset: 48b7638b8e69
Author:    prr
Date:      2008-04-28 09:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48b7638b8e69

6694480: Two small inefficiencies in getting font strikes for transformed fonts
Reviewed-by: igor, tdv

! src/share/classes/java/awt/Font.java
! src/share/classes/sun/font/Font2D.java

Changeset: f50304904b8f
Author:    prr
Date:      2008-04-28 11:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f50304904b8f

6664915: SecurityException using javax.print APIs when queuePrintJob permission is granted.
Reviewed-by: tdv, jgodinez

! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
+ test/javax/print/PrintSE/PrintSE.java
+ test/javax/print/PrintSE/PrintSE.sh

Changeset: d7accc312aec
Author:    prr
Date:      2008-04-28 15:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d7accc312aec

6679308: Poor text rendering on translucent image.
Reviewed-by: flar, campbell

! src/share/native/sun/java2d/loops/AlphaMacros.h
! src/share/native/sun/java2d/loops/ByteGray.h
! src/share/native/sun/java2d/loops/FourByteAbgr.h
! src/share/native/sun/java2d/loops/FourByteAbgrPre.h
! src/share/native/sun/java2d/loops/Index12Gray.h
! src/share/native/sun/java2d/loops/Index8Gray.h
! src/share/native/sun/java2d/loops/IntArgb.h
! src/share/native/sun/java2d/loops/IntArgbBm.h
! src/share/native/sun/java2d/loops/IntArgbPre.h
! src/share/native/sun/java2d/loops/IntBgr.h
! src/share/native/sun/java2d/loops/IntRgb.h
! src/share/native/sun/java2d/loops/IntRgbx.h
! src/share/native/sun/java2d/loops/LoopMacros.h
! src/share/native/sun/java2d/loops/ThreeByteBgr.h
! src/share/native/sun/java2d/loops/Ushort4444Argb.h
! src/share/native/sun/java2d/loops/Ushort555Rgb.h
! src/share/native/sun/java2d/loops/Ushort555Rgbx.h
! src/share/native/sun/java2d/loops/Ushort565Rgb.h
! src/share/native/sun/java2d/loops/UshortGray.h
! src/solaris/native/sun/java2d/loops/vis_FourByteAbgr.c
! src/solaris/native/sun/java2d/loops/vis_FourByteAbgrPre.c
! src/solaris/native/sun/java2d/loops/vis_IntArgb.c
! src/solaris/native/sun/java2d/loops/vis_IntArgbPre.c
+ test/java/awt/Graphics2D/DrawString/AlphaSurfaceText.java

Changeset: 55e6548451df
Author:    prr
Date:      2008-04-30 13:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/55e6548451df

6656651: Windows Look and Feel LCD glyph images have some differences from native applications.
Reviewed-by: igor, tdv

! make/sun/font/FILES_c.gmk
! make/sun/font/Makefile
! src/share/classes/sun/font/FileFontStrike.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
+ src/windows/native/sun/font/lcdglyph.c
+ test/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java

Changeset: fb61ff1cc5fd
Author:    prr
Date:      2008-05-13 16:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fb61ff1cc5fd

6699843: IllegalArgumentException when using Graphics.drawString( "", 0, 0 )
Reviewed-by: igor, tdv

! src/share/classes/sun/java2d/SunGraphics2D.java
+ test/java/awt/Graphics2D/DrawString/EmptyAttrString.java

Changeset: 11a35970b90e
Author:    tdv
Date:      2008-05-13 16:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/11a35970b90e

6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above
Summary: improve the check for full exclusive screen support by analyzing RANDR extension version
Reviewed-by: tdv, prr
Contributed-by: Dan Munckton <lists at munckfish.net>

! src/solaris/native/sun/awt/awt_GraphicsEnv.c

Changeset: 57bcfeb3d8d8
Author:    prr
Date:      2008-05-13 16:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/57bcfeb3d8d8

6696292: Printing transformed images accuracy problems
Reviewed-by: jgodinez, igor

! src/share/classes/sun/print/PSPathGraphics.java
! src/windows/classes/sun/awt/windows/WPathGraphics.java

Changeset: 4092c04aeae7
Author:    prr
Date:      2008-05-13 16:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4092c04aeae7

6697721: OpenJDK: rotated text baseline different between TextLayout and drawString
Reviewed-by: prr, igor
Contributed-by: dougfelt at yahoo.com

! src/share/native/sun/font/freetypeScaler.c
! test/java/awt/Graphics2D/DrawString/RotTransText.java

Changeset: be7daefad89f
Author:    prr
Date:      2008-05-13 16:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be7daefad89f

Merge


Changeset: ed68352f7e42
Author:    tdv
Date:      2008-05-14 09:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ed68352f7e42

6604044: java crashes talking to second X screen
Reviewed-by: prr

! src/solaris/native/sun/awt/awt_GraphicsEnv.c

Changeset: 4af4867ed787
Author:    tdv
Date:      2008-05-14 16:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4af4867ed787

6675596: SurfaceManagerFactory should allow plugging in different implementations
Reviewed-by: tdv, campbell
Contributed-by: Roman Kennke <roman.kennke at aicas.com>

! src/share/classes/sun/awt/image/SunVolatileImage.java
+ src/share/classes/sun/java2d/SurfaceManagerFactory.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
- src/solaris/classes/sun/java2d/SurfaceManagerFactory.java
+ src/solaris/classes/sun/java2d/UnixSurfaceManagerFactory.java
! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
- src/windows/classes/sun/java2d/SurfaceManagerFactory.java
+ src/windows/classes/sun/java2d/WindowsSurfaceManagerFactory.java

Changeset: bf2c66511d1b
Author:    igor
Date:      2008-05-16 03:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf2c66511d1b

6630501: CRASH: JCK test eats much memory and jvm crashes
Reviewed-by: bae, prr

! src/share/classes/sun/font/Type1Font.java

Changeset: 075152aa892e
Author:    prr
Date:      2008-05-19 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/075152aa892e

6611637: NullPointerException in sun.font.GlyphLayout$EngineRecord.init
Reviewed-by: tdv, jgodinez

! src/share/classes/sun/font/GlyphLayout.java

Changeset: 41470017e42f
Author:    prr
Date:      2008-05-19 15:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/41470017e42f

Merge

! src/share/classes/sun/font/FileFontStrike.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java

Changeset: 7fba83f5f5e0
Author:    igor
Date:      2008-05-21 10:59 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fba83f5f5e0

6703377: freetype: glyph vector outline is not translated correctly
Reviewed-by: bae, prr

! src/share/native/sun/font/freetypeScaler.c
+ test/java/awt/font/Rotate/TranslatedOutlineTest.java

Changeset: 02e4c5348592
Author:    lana
Date:      2008-06-03 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/02e4c5348592

Merge


Changeset: 49c3399ca7b8
Author:    tbell
Date:      2008-06-05 17:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49c3399ca7b8

Merge

- src/solaris/classes/sun/java2d/SurfaceManagerFactory.java
- src/windows/classes/sun/java2d/SurfaceManagerFactory.java

Changeset: ffc554348922
Author:    tbell
Date:      2008-06-06 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ffc554348922

Merge

- src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java
- src/share/classes/javax/management/ToQueryString.java


From tim.bell at sun.com  Fri Jun  6 15:44:43 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 06 Jun 2008 22:44:43 +0000
Subject: hg: jdk7/tl/langtools: 4 new changesets
Message-ID: <20080606224450.8E20F2829F@hg.openjdk.java.net>

Changeset: 4ef4bd318569
Author:    xdono
Date:      2008-05-22 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4ef4bd318569

Added tag jdk7-b27 for changeset a17265993253

! .hgtags

Changeset: ff3d4fdf9c63
Author:    tbell
Date:      2008-05-28 00:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ff3d4fdf9c63

Merge


Changeset: fc780e96a16a
Author:    tbell
Date:      2008-06-02 22:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc780e96a16a

Merge


Changeset: c2abfb92ba69
Author:    tbell
Date:      2008-06-06 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c2abfb92ba69

Merge



From martinrb at google.com  Fri Jun  6 23:09:33 2008
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Jun 2008 23:09:33 -0700
Subject: Append-mode I/O on Windows and process I/O redirection
Message-ID: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>

Sun folk, please add this commentary to Bugtraq:

I made append mode on windows atomic by calling CreateFile
with FILE_APPEND_DATA but not FILE_WRITE_DATA

6631352 File{OutputStream,Writer} should implement atomic append mode
using FILE_APPEND_DATA

winFileHandleOpen(JNIEnv *env, jstring path, int flags)
{
    /* To implement O_APPEND, we use the strategy from
       http://msdn2.microsoft.com/en-us/library/aa363858.aspx
       "You can get atomic append by opening a file with
       FILE_APPEND_DATA access and _without_ FILE_WRITE_DATA access.
       If you do this then all writes will ignore the current file
       pointer and be done at the end-of file." */

This was used to implement process I/O redirection in append mode

4960438 (process) Need IO redirection API for subprocesses

Unfortunately, the removal of FILE_WRITE_DATA permissions
causes file locking and file truncation to fail.

6709457 (fc) lock/tryLock() throws IOException "Access is denied" when
file opened for writing open [win]

What to do?  I'll only play consultant, not engineer, on this myself,
because I no longer have access to a Windows system,
and for testing this may require access to several.

I suppose we'll sadly have to back out all the changes for 6631352.
Another strategy is to open the file in FILE_WRITE_DATA mode as before,
but to make each individual write work in append mode.
Another look at the msdn documentation suggests that this is possible
(did I miss this when I explored the docs a year ago?)

http://msdn.microsoft.com/en-us/library/aa365747(VS.85).aspx

Use WriteFile with a non-null OVERLAPPED, with Offset = OffsetHigh = 0xffffffff

"To write to the end of file, specify both the Offset and OffsetHigh
members of the OVERLAPPED structure as 0xFFFFFFFF. This is
functionally equivalent to previously calling the CreateFile function
to open hFile using FILE_APPEND_DATA access."

The above has a good chance of properly fixing 6631352.

What should the process code do, given that it doesn't control
how the subprocess will perform individual writes?

Well, we could simply set the file position at the end of the file,
which is "pretty good", but not quite right (concurrent writes
may cause one of the writes to be lost).  Perhaps the ReOpenFile function
http://msdn.microsoft.com/en-us/library/aa365497(VS.85).aspx
can be used to create a new HANDLE with FILE_APPEND_DATA and
without FILE_WRITE_DATA and passing that to the subprocess.
Will someone then in turn complain
that the child process can't truncate its standard output??!
Hmmm....

Good luck!

Martin

From Alan.Bateman at Sun.COM  Sat Jun  7 09:12:24 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sat, 07 Jun 2008 17:12:24 +0100
Subject: Append-mode I/O on Windows and process I/O redirection
In-Reply-To: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>
References: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>
Message-ID: <484AB368.5060804@sun.com>

Martin Buchholz wrote:
> :
>
> I suppose we'll sadly have to back out all the changes for 6631352.
> Another strategy is to open the file in FILE_WRITE_DATA mode as before,
> but to make each individual write work in append mode.
> Another look at the msdn documentation suggests that this is possible
> (did I miss this when I explored the docs a year ago?)
>
> http://msdn.microsoft.com/en-us/library/aa365747(VS.85).aspx
>
> Use WriteFile with a non-null OVERLAPPED, with Offset = OffsetHigh = 0xffffffff
>
> "To write to the end of file, specify both the Offset and OffsetHigh
> members of the OVERLAPPED structure as 0xFFFFFFFF. This is
> functionally equivalent to previously calling the CreateFile function
> to open hFile using FILE_APPEND_DATA access."
>
> The above has a good chance of properly fixing 6631352.
>   
I agree this is the approach to try. I've used WriteFile for append mode 
using this approach in another context and it worked although I don't 
recall ever checking its atomicity. The MSDN documentation is never 
clear on such topics but the AtomicAppend test that you included with 
these changes can quickly check.

> What should the process code do, given that it doesn't control
> how the subprocess will perform individual writes?
>   
Maybe ProcessBuilder can open the file itself in append mode rather than 
using FileOutputStream.

-Alan.

From martinrb at google.com  Sat Jun  7 14:13:59 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 7 Jun 2008 14:13:59 -0700
Subject: Append-mode I/O on Windows and process I/O redirection
In-Reply-To: <484AB368.5060804@sun.com>
References: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>
	<484AB368.5060804@sun.com>
Message-ID: <1ccfd1c10806071413k20bace4u9f95bc332e8dcd4f@mail.gmail.com>

On Sat, Jun 7, 2008 at 9:12 AM, Alan Bateman <Alan.Bateman at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> :
>>
>> I suppose we'll sadly have to back out all the changes for 6631352.
>> Another strategy is to open the file in FILE_WRITE_DATA mode as before,
>> but to make each individual write work in append mode.
>> Another look at the msdn documentation suggests that this is possible
>> (did I miss this when I explored the docs a year ago?)
>>
>> http://msdn.microsoft.com/en-us/library/aa365747(VS.85).aspx
>>
>> Use WriteFile with a non-null OVERLAPPED, with Offset = OffsetHigh =
>> 0xffffffff
>>
>> "To write to the end of file, specify both the Offset and OffsetHigh
>> members of the OVERLAPPED structure as 0xFFFFFFFF. This is
>> functionally equivalent to previously calling the CreateFile function
>> to open hFile using FILE_APPEND_DATA access."
>>
>> The above has a good chance of properly fixing 6631352.
>>
>
> I agree this is the approach to try. I've used WriteFile for append mode
> using this approach in another context and it worked although I don't recall
> ever checking its atomicity. The MSDN documentation is never clear on such
> topics but the AtomicAppend test that you included with these changes can
> quickly check.

OK.  I'm not currently volunteering to implement this,
but I'm willing to be a reviewer.

>> What should the process code do, given that it doesn't control
>> how the subprocess will perform individual writes?
>>
>
> Maybe ProcessBuilder can open the file itself in append mode rather than
> using FileOutputStream.

When I first implemented this, keeping track of append mode throughout
various software layers was a burden.  I guess the output streams
and channels will have to know whether they are in append mode or not.

Perhaps it is easiest to implement append mode by using the current
code that uses FileOutputStream and extracts the HANDLE from that,
but at the last moment replacing the HANDLE with a new HANDLE
that has FILE_WRITE_DATA turned off before calling CreateProcess.

Martin

> -Alan.
>

From martinrb at google.com  Sat Jun  7 14:18:42 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 7 Jun 2008 14:18:42 -0700
Subject: Append-mode I/O on Windows and process I/O redirection
In-Reply-To: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>
References: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>
Message-ID: <1ccfd1c10806071418v5d498281pdb20694dbf0fe673@mail.gmail.com>

In the below, I suggested someone might complain if
process redirection in APPEND mode failed to allow subprocesses
to do non-appending I/O operations.
But.... process I/O redirection is a new feature,
so it would not be an incompatible change,
so I now think it is the Right Thing to do.
You don't want subprocesses to be able to truncate log files
that they've been politely asked only to append to.

Martin

On Fri, Jun 6, 2008 at 11:09 PM, Martin Buchholz <martinrb at google.com> wrote:
> What should the process code do, given that it doesn't control
> how the subprocess will perform individual writes?
>
> Well, we could simply set the file position at the end of the file,
> which is "pretty good", but not quite right (concurrent writes
> may cause one of the writes to be lost).  Perhaps the ReOpenFile function
> http://msdn.microsoft.com/en-us/library/aa365497(VS.85).aspx
> can be used to create a new HANDLE with FILE_APPEND_DATA and
> without FILE_WRITE_DATA and passing that to the subprocess.
> Will someone then in turn complain
> that the child process can't truncate its standard output??!
> Hmmm....

From alan.bateman at sun.com  Sun Jun  8 02:35:27 2008
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Sun, 08 Jun 2008 09:35:27 +0000
Subject: hg: jdk7/tl/jdk: 6 new changesets
Message-ID: <20080608093646.45BF628381@hg.openjdk.java.net>

Changeset: f570cbc8d4ff
Author:    alanb
Date:      2008-06-05 14:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f570cbc8d4ff

4939819: File.canWrite() returns false for the "My Documents" directory (win)
Reviewed-by: iris

! src/windows/native/java/io/WinNTFileSystem_md.c
! test/java/io/File/SetReadOnly.java

Changeset: eac5c4ead3ca
Author:    alanb
Date:      2008-06-05 14:47 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eac5c4ead3ca

6652379: File.setLastModified fails on large files (lnx only)
Reviewed-by: iris

! src/solaris/native/java/io/UnixFileSystem_md.c
! test/java/io/File/SetLastModified.java

Changeset: 28522137c831
Author:    alanb
Date:      2008-06-05 14:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/28522137c831

6596323: (fc) ClosedByInterruptException not thrown by the interrupt method (lnx)
Reviewed-by: sherman

! src/share/classes/sun/nio/ch/NativeThreadSet.java
! src/solaris/classes/sun/nio/ch/NativeThread.java
! src/windows/classes/sun/nio/ch/NativeThread.java
! test/java/nio/channels/AsyncCloseAndInterrupt.java

Changeset: 8619f18330b5
Author:    alanb
Date:      2008-06-05 14:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8619f18330b5

6710579: (ch) test/java/nio/channels/AsyncCloseAndInterrupt fails (lnx)
Reviewed-by: chegar

! test/java/nio/channels/AsyncCloseAndInterrupt.java

Changeset: 21650cc54180
Author:    alanb
Date:      2008-06-06 11:40 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21650cc54180

Merge


Changeset: 513d733e571d
Author:    alanb
Date:      2008-06-07 16:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/513d733e571d

Merge



From Alan.Bateman at Sun.COM  Sun Jun  8 02:46:18 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 08 Jun 2008 10:46:18 +0100
Subject: Append-mode I/O on Windows and process I/O redirection
In-Reply-To: <1ccfd1c10806071413k20bace4u9f95bc332e8dcd4f@mail.gmail.com>
References: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>
	<484AB368.5060804@sun.com>
	<1ccfd1c10806071413k20bace4u9f95bc332e8dcd4f@mail.gmail.com>
Message-ID: <484BAA6A.3020902@sun.com>

Martin Buchholz wrote:
> :
> When I first implemented this, keeping track of append mode throughout
> various software layers was a burden.  I guess the output streams
> and channels will have to know whether they are in append mode or not.
>   
FileOutputStream and FileChannelImpl used to know this before the 
changes but you are right that will now impact right down to the code 
that does the I/O. Furthermore, it impacts all platforms so careful 
testing needed.

> Perhaps it is easiest to implement append mode by using the current
> code that uses FileOutputStream and extracts the HANDLE from that,
> but at the last moment replacing the HANDLE with a new HANDLE
> that has FILE_WRITE_DATA turned off before calling CreateProcess.
>   
Assuming you are thinking of ReOpenFile then we would still need a 
solution for Windows XP because that Win32 needs Windows Server 2003 or 
newer.

-Alan.

From martinrb at google.com  Sun Jun  8 11:02:16 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 8 Jun 2008 11:02:16 -0700
Subject: Append-mode I/O on Windows and process I/O redirection
In-Reply-To: <484BAA6A.3020902@sun.com>
References: <1ccfd1c10806062309u35dc6975n782a4145c9f8c57f@mail.gmail.com>
	<484AB368.5060804@sun.com>
	<1ccfd1c10806071413k20bace4u9f95bc332e8dcd4f@mail.gmail.com>
	<484BAA6A.3020902@sun.com>
Message-ID: <1ccfd1c10806081102j149323d0o55d2171db59e23ee@mail.gmail.com>

On Sun, Jun 8, 2008 at 2:46 AM, Alan Bateman <Alan.Bateman at sun.com> wrote:
> Martin Buchholz wrote:
>> Perhaps it is easiest to implement append mode by using the current
>> code that uses FileOutputStream and extracts the HANDLE from that,
>> but at the last moment replacing the HANDLE with a new HANDLE
>> that has FILE_WRITE_DATA turned off before calling CreateProcess.
>>
>
> Assuming you are thinking of ReOpenFile then we would still need a solution
> for Windows XP because that Win32 needs Windows Server 2003 or newer.

Obviously my memory is not what it used to me.
Your comment rings a bell.  I now recall having come
to a similar conclusion when I investigated this originally.

Perhaps we should have a hybrid of the two append mode
implementations where
opening a FileOutputStream in append mode works as
it did in JDK 6, but we provide an extra non-public
way to construct a FileOutputStream that would open
using FILE_APPEND_DATA as in current JDK7.  This secret
constructor would only be used by the process creation
code.  That would result in minimal changes to the
process code.

Martin

From martinrb at google.com  Sun Jun  8 14:30:48 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 8 Jun 2008 14:30:48 -0700
Subject: NavigableMap implementation bugs
Message-ID: <1ccfd1c10806081430u361ccc58y9d423aca49c09057@mail.gmail.com>

Doug and Josh and Chris,

(Chris, please file a bug)

TreeMap.navigableKeySet().subSet(x,y).remove(o)
fails because TreeMap.KeySet.subset calls the
TreeSet(NavigableMap<E,Object>)
constructor, and that requires an argument map
not containing arbitrary value objects for correctness.
This correctness is probably only
noticed in the return value from remove being incorrect.

In the case of ConcurrentSkipListMap, the correctness
issue is even more serious, since remove(existing element)
fails to remove it.

It's not obvious how to best fix it.  The TreeSet(NavigableMap)
and ConcurrentSkipListMap(NavigableMap) constructors
simply cannot be used to get views of non-empty maps.
It's clear that the usual straightforward but tedious solution
will work, but is there an elegant solution?

(Curiously, this is one of the rare times where
generics compiler warnings caught a genuine bug!
It's a mistake in this case to force a NavigableMap<K,V>
into a NavigableMap<K,Object>)

Most of the hits below are bugs:

 $ find -name '*Map.java' | xargs grep -E 'new (TreeSet|ConcurrentSkipListSet)'
./TreeMap.java:            return new TreeSet<E>(m.subMap(fromElement,
fromInclusive,
./TreeMap.java:            return new TreeSet<E>(m.headMap(toElement,
inclusive));
./TreeMap.java:            return new
TreeSet<E>(m.tailMap(fromElement, inclusive));
./TreeMap.java:            return new TreeSet(m.descendingMap());
./concurrent/ConcurrentSkipListMap.java:            return new
ConcurrentSkipListSet<E>
./concurrent/ConcurrentSkipListMap.java:            return new
ConcurrentSkipListSet<E>(m.headMap(toElement, inclusive));
./concurrent/ConcurrentSkipListMap.java:            return new
ConcurrentSkipListSet<E>(m.tailMap(fromElement, inclusive));
./concurrent/ConcurrentSkipListMap.java:            return new
ConcurrentSkipListSet(m.descendingMap());

Test case follows:

/*
 * Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
 * CA 95054 USA or visit www.sun.com if you need additional information or
 * have any questions.
 */

/*
 * @test
 * @summary navigableMap.keyset().subSet().remove(x)
 * @author  Martin Buchholz
 */

import java.util.Collection;
import java.util.NavigableMap;
import java.util.TreeMap;
import java.util.concurrent.ConcurrentSkipListMap;

public class Bug12 {
    void test(String[] args) throws Throwable {
        testNavigableMap(new TreeMap<Integer,Integer>());
        testNavigableMap(new ConcurrentSkipListMap<Integer,Integer>());
    }

    void checkEmpty(Collection<?> c) {
        check(c.isEmpty());
        check(c.size() == 0);
        check(! c.iterator().hasNext());
    }

    void checkEmpty(NavigableMap<?,?> m) {
        check(m.isEmpty());
        check(m.size() == 0);
        checkEmpty(m.keySet());
        checkEmpty(m.values());
        checkEmpty(m.entrySet());
    }

    void testNavigableMap(NavigableMap<Integer,Integer> m) {
        System.out.printf("Testing %s%n", m.getClass());
        checkEmpty(m);
        equal(m.put(1,2),null);
        equal(m.put(1,3),2);
        equal(m.remove(1),3);
        checkEmpty(m);
        equal(m.put(1,2),null);
        check(m.navigableKeySet().remove(1));
        checkEmpty(m);
        equal(m.put(1,2),null);
        check(m.navigableKeySet().headSet(3).remove(1));
        checkEmpty(m);
        equal(m.put(1,2),null);
        check(m.navigableKeySet().tailSet(-3).remove(1));
        checkEmpty(m);
        equal(m.put(1,2),null);
        check(m.navigableKeySet().subSet(-3,3).remove(1));
        checkEmpty(m);
        equal(m.put(1,2),null);
        check(m.isEmpty());
    }

    //--------------------- Infrastructure ---------------------------
    volatile int passed = 0, failed = 0;
    void pass() {passed++;}
    void fail() {failed++; Thread.dumpStack();}
    void fail(String msg) {System.err.println(msg); fail();}
    void unexpected(Throwable t) {failed++; t.printStackTrace();}
    void check(boolean cond) {if (cond) pass(); else fail();}
    void equal(Object x, Object y) {
	if (x == null ? y == null : x.equals(y)) pass();
	else fail(x + " not equal to " + y);}
    public static void main(String[] args) throws Throwable {
        Class<?> k = new Object(){}.getClass().getEnclosingClass();
        try {k.getMethod("instanceMain",String[].class)
                .invoke( k.newInstance(), (Object) args);}
        catch (Throwable e) {throw e.getCause();}}
    public void instanceMain(String[] args) throws Throwable {
	try {test(args);} catch (Throwable t) {unexpected(t);}
	System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed);
	if (failed > 0) throw new AssertionError("Some tests failed");}
}

From martinrb at google.com  Sun Jun  8 15:13:44 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 8 Jun 2008 15:13:44 -0700
Subject: HashMap implementations and Integer specializations
Message-ID: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>

JavaOne 2008 technical session PDFs are now available

http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008

I was surprised to discover a discussion of
HashMap optimization at the JavaOne talk
http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf

Did I miss an announcement of that?

A comment on that talk:

It is easy to make the mistake of thinking that HashMap does not
have to store the actual Integer key in the call to put.
Unfortunately, Java's evil semantics (everything is an Object,
everything is a Lock, everything has an Identity) require
that the exact same objects inserted into a HashMap can be
removed later.  This means that specialized submaps will have
a harder time optimizing for footprint.  (I do think the
algorithm presented in the talk is correct, since the front cache
is likely only used for get(), and not, e.g. for entrySet().iterator())

I intend to check in a test case modification that will ensure
that future optimizations do not violate the current compatibility guarantees.

diff --git a/test/java/util/Collection/MOAT.java
b/test/java/util/Collection/MOAT.java
--- a/test/java/util/Collection/MOAT.java
+++ b/test/java/util/Collection/MOAT.java
@@ -544,6 +544,27 @@ public class MOAT {
         check(m.size() != 0 ^ m.isEmpty());
     }

+    private static void testPutPreversesObjectIdentity(Map<?,?> m,
+                                                       Object key,
+                                                       Object val) {
+        try {
+            Map<Object,Object> m2 = m.getClass().newInstance();
+            m2.put(key, val);
+            Map.Entry<Object,Object> e = m2.entrySet().iterator().next();
+            check(e.getKey()   == key);
+            check(e.getValue() == val);
+            check(m2.keySet().iterator().next() == key);
+            check(m2.values().iterator().next() == val);
+        } catch (Throwable t) { unexpected(t); }
+    }
+
+    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
+        testPutPreversesObjectIdentity(m, new Integer(42),  new Integer(43));
+        testPutPreversesObjectIdentity(m, new Long(42L),    new Long(43L));
+        testPutPreversesObjectIdentity(m, new Double(42.0), new Double(43.0));
+        testPutPreversesObjectIdentity(m, new String("42"), new String("43"));
+    }
+
     private static void testMap(Map<Integer,Integer> m) {
         System.out.println("\n==> " + m.getClass().getName());

@@ -572,6 +593,7 @@ public class MOAT {
         }

         if (supportsPut(m)) {
+            testPutPreversesObjectIdentity(m);
             try {
                 check(m.put(3333, 77777) == null);
                 check(m.put(9134, 74982) == null);

From mlists at juma.me.uk  Sun Jun  8 15:54:28 2008
From: mlists at juma.me.uk (Ismael Juma)
Date: Sun, 8 Jun 2008 22:54:28 +0000 (UTC)
Subject: HashMap implementations and Integer specializations
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
Message-ID: <loom.20080608T225224-466@post.gmane.org>

Martin Buchholz <martinrb at ...> writes:
> I was surprised to discover a discussion of
> HashMap optimization at the JavaOne talk
> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
> 
> Did I miss an announcement of that?

I noticed a commit related to that a few weeks ago[1], but would also be
interested in more details.

Regards,
Ismael

[1] http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/ff5961f4c095


From peter.arrenbrecht at gmail.com  Sun Jun  8 22:59:59 2008
From: peter.arrenbrecht at gmail.com (Peter Arrenbrecht)
Date: Mon, 9 Jun 2008 07:59:59 +0200
Subject: HashMap implementations and Integer specializations
In-Reply-To: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
Message-ID: <16fff4530806082259t6291cc83u441e504625c91c5c@mail.gmail.com>

Typo: testPutPreversesObjectIdentity

On Mon, Jun 9, 2008 at 12:13 AM, Martin Buchholz <martinrb at google.com> wrote:
> JavaOne 2008 technical session PDFs are now available
>
> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>
> I was surprised to discover a discussion of
> HashMap optimization at the JavaOne talk
> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>
> Did I miss an announcement of that?
>
> A comment on that talk:
>
> It is easy to make the mistake of thinking that HashMap does not
> have to store the actual Integer key in the call to put.
> Unfortunately, Java's evil semantics (everything is an Object,
> everything is a Lock, everything has an Identity) require
> that the exact same objects inserted into a HashMap can be
> removed later.  This means that specialized submaps will have
> a harder time optimizing for footprint.  (I do think the
> algorithm presented in the talk is correct, since the front cache
> is likely only used for get(), and not, e.g. for entrySet().iterator())
>
> I intend to check in a test case modification that will ensure
> that future optimizations do not violate the current compatibility guarantees.
>
> diff --git a/test/java/util/Collection/MOAT.java
> b/test/java/util/Collection/MOAT.java
> --- a/test/java/util/Collection/MOAT.java
> +++ b/test/java/util/Collection/MOAT.java
> @@ -544,6 +544,27 @@ public class MOAT {
>         check(m.size() != 0 ^ m.isEmpty());
>     }
>
> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
> +                                                       Object key,
> +                                                       Object val) {
> +        try {
> +            Map<Object,Object> m2 = m.getClass().newInstance();
> +            m2.put(key, val);
> +            Map.Entry<Object,Object> e = m2.entrySet().iterator().next();
> +            check(e.getKey()   == key);
> +            check(e.getValue() == val);
> +            check(m2.keySet().iterator().next() == key);
> +            check(m2.values().iterator().next() == val);
> +        } catch (Throwable t) { unexpected(t); }
> +    }
> +
> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
> +        testPutPreversesObjectIdentity(m, new Integer(42),  new Integer(43));
> +        testPutPreversesObjectIdentity(m, new Long(42L),    new Long(43L));
> +        testPutPreversesObjectIdentity(m, new Double(42.0), new Double(43.0));
> +        testPutPreversesObjectIdentity(m, new String("42"), new String("43"));
> +    }
> +
>     private static void testMap(Map<Integer,Integer> m) {
>         System.out.println("\n==> " + m.getClass().getName());
>
> @@ -572,6 +593,7 @@ public class MOAT {
>         }
>
>         if (supportsPut(m)) {
> +            testPutPreversesObjectIdentity(m);
>             try {
>                 check(m.put(3333, 77777) == null);
>                 check(m.put(9134, 74982) == null);
>

From martinrb at google.com  Mon Jun  9 00:26:04 2008
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Jun 2008 00:26:04 -0700
Subject: HashMap implementations and Integer specializations
In-Reply-To: <16fff4530806082259t6291cc83u441e504625c91c5c@mail.gmail.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
	<16fff4530806082259t6291cc83u441e504625c91c5c@mail.gmail.com>
Message-ID: <1ccfd1c10806090026u1c4f0a06wcf0fd23ba771083@mail.gmail.com>

Peter, Thanks.  Fixed.

Martin

On Sun, Jun 8, 2008 at 10:59 PM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> Typo: testPutPreversesObjectIdentity
>
> On Mon, Jun 9, 2008 at 12:13 AM, Martin Buchholz <martinrb at google.com> wrote:
>> JavaOne 2008 technical session PDFs are now available
>>
>> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>>
>> I was surprised to discover a discussion of
>> HashMap optimization at the JavaOne talk
>> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>>
>> Did I miss an announcement of that?
>>
>> A comment on that talk:
>>
>> It is easy to make the mistake of thinking that HashMap does not
>> have to store the actual Integer key in the call to put.
>> Unfortunately, Java's evil semantics (everything is an Object,
>> everything is a Lock, everything has an Identity) require
>> that the exact same objects inserted into a HashMap can be
>> removed later.  This means that specialized submaps will have
>> a harder time optimizing for footprint.  (I do think the
>> algorithm presented in the talk is correct, since the front cache
>> is likely only used for get(), and not, e.g. for entrySet().iterator())
>>
>> I intend to check in a test case modification that will ensure
>> that future optimizations do not violate the current compatibility guarantees.
>>
>> diff --git a/test/java/util/Collection/MOAT.java
>> b/test/java/util/Collection/MOAT.java
>> --- a/test/java/util/Collection/MOAT.java
>> +++ b/test/java/util/Collection/MOAT.java
>> @@ -544,6 +544,27 @@ public class MOAT {
>>         check(m.size() != 0 ^ m.isEmpty());
>>     }
>>
>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
>> +                                                       Object key,
>> +                                                       Object val) {
>> +        try {
>> +            Map<Object,Object> m2 = m.getClass().newInstance();
>> +            m2.put(key, val);
>> +            Map.Entry<Object,Object> e = m2.entrySet().iterator().next();
>> +            check(e.getKey()   == key);
>> +            check(e.getValue() == val);
>> +            check(m2.keySet().iterator().next() == key);
>> +            check(m2.values().iterator().next() == val);
>> +        } catch (Throwable t) { unexpected(t); }
>> +    }
>> +
>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
>> +        testPutPreversesObjectIdentity(m, new Integer(42),  new Integer(43));
>> +        testPutPreversesObjectIdentity(m, new Long(42L),    new Long(43L));
>> +        testPutPreversesObjectIdentity(m, new Double(42.0), new Double(43.0));
>> +        testPutPreversesObjectIdentity(m, new String("42"), new String("43"));
>> +    }
>> +
>>     private static void testMap(Map<Integer,Integer> m) {
>>         System.out.println("\n==> " + m.getClass().getName());
>>
>> @@ -572,6 +593,7 @@ public class MOAT {
>>         }
>>
>>         if (supportsPut(m)) {
>> +            testPutPreversesObjectIdentity(m);
>>             try {
>>                 check(m.put(3333, 77777) == null);
>>                 check(m.put(9134, 74982) == null);
>>
>

From martinrb at google.com  Mon Jun  9 10:50:28 2008
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Jun 2008 10:50:28 -0700
Subject: HashMap implementations and Integer specializations
In-Reply-To: <484D44C6.3030504@sun.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
	<484D44C6.3030504@sun.com>
Message-ID: <1ccfd1c10806091050m3bf281fby489798edbfe04288@mail.gmail.com>

Charlie,

Hotspot engineers throughout the ages
have been tempted to optimize away
object identity semantics of Integer and String,
but I'm pretty sure that for e.g. new Integer(x)
and new String(y) hotspot will certainly continue
to return _new_ objects (unless of course
the application can be proven to not tell the
difference), and there are sufficient
regression tests to keep all of us in line.

Martin

On Mon, Jun 9, 2008 at 7:57 AM, charlie hunt <charlie.hunt at sun.com> wrote:
> wrt the Integer & Long values you use in your test case ...
>
> You might consider using larger Integer & Long values, ones that lie outside
> the range of Integer.IntegerCache & Long.LongCache to avoid any potential
> confusion about whether the values you are putting into the Map might get
> grabbed from the IntegerCache or LongCache via some "magic" of the HotSpot
> compiler, i.e it's conceivable a call to 'new Integer()' could be
> transformed into Integer.valueOf()'.
>
> charlie ...
>
> Martin Buchholz wrote:
>>
>> JavaOne 2008 technical session PDFs are now available
>>
>>
>> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>>
>> I was surprised to discover a discussion of
>> HashMap optimization at the JavaOne talk
>> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>>
>> Did I miss an announcement of that?
>>
>> A comment on that talk:
>>
>> It is easy to make the mistake of thinking that HashMap does not
>> have to store the actual Integer key in the call to put.
>> Unfortunately, Java's evil semantics (everything is an Object,
>> everything is a Lock, everything has an Identity) require
>> that the exact same objects inserted into a HashMap can be
>> removed later.  This means that specialized submaps will have
>> a harder time optimizing for footprint.  (I do think the
>> algorithm presented in the talk is correct, since the front cache
>> is likely only used for get(), and not, e.g. for entrySet().iterator())
>>
>> I intend to check in a test case modification that will ensure
>> that future optimizations do not violate the current compatibility
>> guarantees.
>>
>> diff --git a/test/java/util/Collection/MOAT.java
>> b/test/java/util/Collection/MOAT.java
>> --- a/test/java/util/Collection/MOAT.java
>> +++ b/test/java/util/Collection/MOAT.java
>> @@ -544,6 +544,27 @@ public class MOAT {
>>         check(m.size() != 0 ^ m.isEmpty());
>>     }
>>
>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
>> +                                                       Object key,
>> +                                                       Object val) {
>> +        try {
>> +            Map<Object,Object> m2 = m.getClass().newInstance();
>> +            m2.put(key, val);
>> +            Map.Entry<Object,Object> e = m2.entrySet().iterator().next();
>> +            check(e.getKey()   == key);
>> +            check(e.getValue() == val);
>> +            check(m2.keySet().iterator().next() == key);
>> +            check(m2.values().iterator().next() == val);
>> +        } catch (Throwable t) { unexpected(t); }
>> +    }
>> +
>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
>> +        testPutPreversesObjectIdentity(m, new Integer(42),  new
>> Integer(43));
>> +        testPutPreversesObjectIdentity(m, new Long(42L),    new
>> Long(43L));
>> +        testPutPreversesObjectIdentity(m, new Double(42.0), new
>> Double(43.0));
>> +        testPutPreversesObjectIdentity(m, new String("42"), new
>> String("43"));
>> +    }
>> +
>>     private static void testMap(Map<Integer,Integer> m) {
>>         System.out.println("\n==> " + m.getClass().getName());
>>
>> @@ -572,6 +593,7 @@ public class MOAT {
>>         }
>>
>>         if (supportsPut(m)) {
>> +            testPutPreversesObjectIdentity(m);
>>             try {
>>                 check(m.put(3333, 77777) == null);
>>                 check(m.put(9134, 74982) == null);
>>
>
> --
>
> Charlie Hunt
> Java Performance Engineer
>
> <http://java.sun.com/docs/performance/>
>
>

From martinrb at google.com  Mon Jun  9 11:39:15 2008
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Jun 2008 11:39:15 -0700
Subject: HashMap implementations and Integer specializations
In-Reply-To: <484D75E0.3060500@sun.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
	<484D44C6.3030504@sun.com>
	<1ccfd1c10806091050m3bf281fby489798edbfe04288@mail.gmail.com>
	<484D75E0.3060500@sun.com>
Message-ID: <1ccfd1c10806091139h3e06a6cdj7e23aba81ccf0ec0@mail.gmail.com>

Charlie,

Test case code is different from regular code
in that bad practice is often a good idea.
People should know better than to "fix" test cases
using their IDE.

But I added this comment:

        // This code intentionally uses the denigrated constructors
        // that are guaranteed to return a unique object!

Martin

On Mon, Jun 9, 2008 at 11:26 AM, charlie hunt <charlie.hunt at sun.com> wrote:
> Martin,
>
> I'm rather shocked at your response!
>
> Consider for example, there's a very popular tool out their that integrates
> very well into NetBeans  IDE and Eclipse IDE which suggests changing all
> 'new Integer(), new Long()' calls into 'Integer.valueOf() & Long.valueOf()'.
>  Take a quick look at how new Integer() contrasts with Integer.valueOf().
>
> Suppose in the future as Martin moves on to bigger and better things beyond
> OpenJDK and a future maintainer looks at your test case and updates it to
> use Integer.valueOf() and Long.valueOf() as result of such a tool mentioned
> above.   Should that happen, I don't think your test case would test what it
> was intended to test.
>
> Would not your test case be improved by choosing values well outside the
> values contained in the IntegerCache & LongCache?
>
> charlie ...
>
> Martin Buchholz wrote:
>>
>> Charlie,
>>
>> Hotspot engineers throughout the ages
>> have been tempted to optimize away
>> object identity semantics of Integer and String,
>> but I'm pretty sure that for e.g. new Integer(x)
>> and new String(y) hotspot will certainly continue
>> to return _new_ objects (unless of course
>> the application can be proven to not tell the
>> difference), and there are sufficient
>> regression tests to keep all of us in line.
>>
>> Martin
>>
>> On Mon, Jun 9, 2008 at 7:57 AM, charlie hunt <charlie.hunt at sun.com> wrote:
>>
>>>
>>> wrt the Integer & Long values you use in your test case ...
>>>
>>> You might consider using larger Integer & Long values, ones that lie
>>> outside
>>> the range of Integer.IntegerCache & Long.LongCache to avoid any potential
>>> confusion about whether the values you are putting into the Map might get
>>> grabbed from the IntegerCache or LongCache via some "magic" of the
>>> HotSpot
>>> compiler, i.e it's conceivable a call to 'new Integer()' could be
>>> transformed into Integer.valueOf()'.
>>>
>>> charlie ...
>>>
>>> Martin Buchholz wrote:
>>>
>>>>
>>>> JavaOne 2008 technical session PDFs are now available
>>>>
>>>>
>>>>
>>>> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>>>>
>>>> I was surprised to discover a discussion of
>>>> HashMap optimization at the JavaOne talk
>>>> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>>>>
>>>> Did I miss an announcement of that?
>>>>
>>>> A comment on that talk:
>>>>
>>>> It is easy to make the mistake of thinking that HashMap does not
>>>> have to store the actual Integer key in the call to put.
>>>> Unfortunately, Java's evil semantics (everything is an Object,
>>>> everything is a Lock, everything has an Identity) require
>>>> that the exact same objects inserted into a HashMap can be
>>>> removed later.  This means that specialized submaps will have
>>>> a harder time optimizing for footprint.  (I do think the
>>>> algorithm presented in the talk is correct, since the front cache
>>>> is likely only used for get(), and not, e.g. for entrySet().iterator())
>>>>
>>>> I intend to check in a test case modification that will ensure
>>>> that future optimizations do not violate the current compatibility
>>>> guarantees.
>>>>
>>>> diff --git a/test/java/util/Collection/MOAT.java
>>>> b/test/java/util/Collection/MOAT.java
>>>> --- a/test/java/util/Collection/MOAT.java
>>>> +++ b/test/java/util/Collection/MOAT.java
>>>> @@ -544,6 +544,27 @@ public class MOAT {
>>>>        check(m.size() != 0 ^ m.isEmpty());
>>>>    }
>>>>
>>>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
>>>> +                                                       Object key,
>>>> +                                                       Object val) {
>>>> +        try {
>>>> +            Map<Object,Object> m2 = m.getClass().newInstance();
>>>> +            m2.put(key, val);
>>>> +            Map.Entry<Object,Object> e =
>>>> m2.entrySet().iterator().next();
>>>> +            check(e.getKey()   == key);
>>>> +            check(e.getValue() == val);
>>>> +            check(m2.keySet().iterator().next() == key);
>>>> +            check(m2.values().iterator().next() == val);
>>>> +        } catch (Throwable t) { unexpected(t); }
>>>> +    }
>>>> +
>>>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
>>>> +        testPutPreversesObjectIdentity(m, new Integer(42),  new
>>>> Integer(43));
>>>> +        testPutPreversesObjectIdentity(m, new Long(42L),    new
>>>> Long(43L));
>>>> +        testPutPreversesObjectIdentity(m, new Double(42.0), new
>>>> Double(43.0));
>>>> +        testPutPreversesObjectIdentity(m, new String("42"), new
>>>> String("43"));
>>>> +    }
>>>> +
>>>>    private static void testMap(Map<Integer,Integer> m) {
>>>>        System.out.println("\n==> " + m.getClass().getName());
>>>>
>>>> @@ -572,6 +593,7 @@ public class MOAT {
>>>>        }
>>>>
>>>>        if (supportsPut(m)) {
>>>> +            testPutPreversesObjectIdentity(m);
>>>>            try {
>>>>                check(m.put(3333, 77777) == null);
>>>>                check(m.put(9134, 74982) == null);
>>>>
>>>>
>>>
>>> --
>>>
>>> Charlie Hunt
>>> Java Performance Engineer
>>>
>>> <http://java.sun.com/docs/performance/>
>>>
>>>
>>>
>
> --
>
> Charlie Hunt
> Java Performance Engineer
>
> <http://java.sun.com/docs/performance/>
>
>

From dl at cs.oswego.edu  Mon Jun  9 12:02:48 2008
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 09 Jun 2008 15:02:48 -0400
Subject: [concurrency-interest] NavigableMap implementation bugs
In-Reply-To: <1ccfd1c10806081430u361ccc58y9d423aca49c09057@mail.gmail.com>
References: <1ccfd1c10806081430u361ccc58y9d423aca49c09057@mail.gmail.com>
Message-ID: <484D7E58.8020500@cs.oswego.edu>

Martin Buchholz wrote:

> TreeMap.navigableKeySet().subSet(x,y).remove(o)
> fails because TreeMap.KeySet.subset calls the
> TreeSet(NavigableMap<E,Object>)
> constructor

Thanks for finding this!

> In the case of ConcurrentSkipListMap, the correctness
> issue is even more serious, since remove(existing element)
> fails to remove it.
> 
> It's not obvious how to best fix it.  The TreeSet(NavigableMap)
> and ConcurrentSkipListMap(NavigableMap) constructors
> simply cannot be used to get views of non-empty maps.
> It's clear that the usual straightforward but tedious solution
> will work, but is there an elegant solution?

I don't think so. Relaying the subset methods to the *Set classes
was just an implementation expediency under the mis-thought that they
would take care of recursive subsets etc rather than needing
special implementations for KeySets. But the byproduct for remove()
is clearly wrong so they do need separate implementations.

-Doug




From martinrb at google.com  Mon Jun  9 15:01:05 2008
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Jun 2008 15:01:05 -0700
Subject: [concurrency-interest] NavigableMap implementation bugs
In-Reply-To: <484D9C20.3070607@visionnaire.com.br>
References: <1ccfd1c10806081430u361ccc58y9d423aca49c09057@mail.gmail.com>
	<484D7E58.8020500@cs.oswego.edu> <484D9C20.3070607@visionnaire.com.br>
Message-ID: <1ccfd1c10806091501k2048a202ha37c2f3c5255cf22@mail.gmail.com>

Osvaldo, I fundamentally agree with you that
optimizing HashSet in the manner you describe
is worthwhile, but because the implementation
needs to "parallel" HashMap, it would be good
to do this after the current hacking activity on
HashMap quiesces.

Unfortunately, this kind of programming
is pure tedium - who will volunteer?

Martin

On Mon, Jun 9, 2008 at 2:09 PM, Osvaldo Pinali Doederlein
<osvaldo at visionnaire.com.br> wrote:
> Doug Lea wrote:
>>
>> I don't think so. Relaying the subset methods to the *Set classes
>> was just an implementation expediency under the mis-thought that they
>> would take care of recursive subsets etc rather than needing
>> special implementations for KeySets. But the byproduct for remove()
>> is clearly wrong so they do need separate implementations.
>>
>
> This remembers me from an old pet peeve, the fact that java.util.HashSet is
> implemented as a wrapper over java.util.HashMap. This sucks
> performance-wise, due to the additional indirections everywhere, and even
> more important, because every entry single object is larger than necessary -
> it contains a key and a value fields, but a single field would be necessary
> for HashSet. If you have a Set with millions of entries, the overhead of one
> useless pointer per entry is significant. Plus, the wrapping implementation
> uses a dummy, fixed Object instance as the value for all entries - and this
> may create another subtle performance problem: large numbers of
> "cross-space" references in the heap. I know that in most GCs only
> old-to-young refs are evil, but it seems that in some GCs any cross-space
> reference is bad (requires remset tracking), like Detlef et al's new
> "Garbage-First" collector (if I understood it).
>
> Back in J2SE1.2 time, the runtime savings from the wrapping implementation
> could be significant... but, today? The HashMap* classes inside the latest
> rt.jar are 18,5Kb total (uncompressed), versus 3Kb from HashSet. That's a
> 12Kb of space saving, plus some small saving in JIT time too. I'd say that
> this is an irrelevant advantage, even in JavaME. The performance bonus of a
> tuned HashSet, however modest, would certainly be much more significant. I
> know it's ugly from a maintenance POV to have two large classes that will be
> 90% identical, but to paraphrase the movie Some Like It Hot, nothing is
> perfect...
>
> A+
> Osvaldo
>
> --
> -----------------------------------------------------------------------
> Osvaldo Pinali Doederlein                   Visionnaire Inform?tica S/A
> osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
> Arquiteto de Tecnologia                          +55 (41) 337-1000 #223
>
>

From luis-miguel.alventosa at sun.com  Tue Jun 10 04:56:03 2008
From: luis-miguel.alventosa at sun.com (luis-miguel.alventosa at sun.com)
Date: Tue, 10 Jun 2008 11:56:03 +0000
Subject: hg: jdk7/tl/jdk: 6711106: REGRESSION: Bad usage of
	SnapshotMBeanServerConnection in MBeans tab and JConsole plugins.
Message-ID: <20080610115622.ED7D22878C@hg.openjdk.java.net>

Changeset: 7e5e83dfd285
Author:    lmalvent
Date:      2008-06-10 13:50 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e5e83dfd285

6711106: REGRESSION: Bad usage of SnapshotMBeanServerConnection in MBeans tab and JConsole plugins.
Reviewed-by: jfdenise

! src/share/classes/sun/tools/jconsole/MBeansTab.java
! src/share/classes/sun/tools/jconsole/ProxyClient.java
! src/share/classes/sun/tools/jconsole/inspector/XMBean.java
! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java


From luis-miguel.alventosa at sun.com  Fri Jun 13 01:49:22 2008
From: luis-miguel.alventosa at sun.com (luis-miguel.alventosa at sun.com)
Date: Fri, 13 Jun 2008 08:49:22 +0000
Subject: hg: jdk7/tl/jdk: 6714244: Plotters in MBeans tab should use
	SnapshotMBeanServerConnection too
Message-ID: <20080613084933.E8DF128A21@hg.openjdk.java.net>

Changeset: e49bf258e60c
Author:    lmalvent
Date:      2008-06-13 10:45 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e49bf258e60c

6714244: Plotters in MBeans tab should use SnapshotMBeanServerConnection too
Reviewed-by: jfdenise

! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java


From xueming.shen at sun.com  Sat Jun 14 09:35:26 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Sat, 14 Jun 2008 16:35:26 +0000
Subject: hg: jdk7/tl/jdk: 6501089:
	test/java/nio/channels/SocketChannel/AsyncCloseChannel.java
	failing (timeout) on Linux
Message-ID: <20080614163545.CE22228ABB@hg.openjdk.java.net>

Changeset: ab1bc6850b6e
Author:    sherman
Date:      2008-06-14 09:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ab1bc6850b6e

6501089: test/java/nio/channels/SocketChannel/AsyncCloseChannel.java failing (timeout) on Linux
Summary: test/java/nio/channels/SocketChannel/AsyncCloseChannel.java failing (timeout) on Linux
Reviewed-by: alanb

! test/java/nio/channels/SocketChannel/AsyncCloseChannel.java


From Paul.Hohensee at Sun.COM  Mon Jun  9 07:22:32 2008
From: Paul.Hohensee at Sun.COM (Paul Hohensee)
Date: Mon, 09 Jun 2008 10:22:32 -0400
Subject: HashMap implementations and Integer specializations
In-Reply-To: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
Message-ID: <484D3CA8.7040008@sun.com>

wrt ts-6434, the abstract just talked about performance case studies.  
We didn't
know what the cases would be when we filed the abstract.

Paul

Martin Buchholz wrote:
> JavaOne 2008 technical session PDFs are now available
>
> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>
> I was surprised to discover a discussion of
> HashMap optimization at the JavaOne talk
> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>
> Did I miss an announcement of that?
>
> A comment on that talk:
>
> It is easy to make the mistake of thinking that HashMap does not
> have to store the actual Integer key in the call to put.
> Unfortunately, Java's evil semantics (everything is an Object,
> everything is a Lock, everything has an Identity) require
> that the exact same objects inserted into a HashMap can be
> removed later.  This means that specialized submaps will have
> a harder time optimizing for footprint.  (I do think the
> algorithm presented in the talk is correct, since the front cache
> is likely only used for get(), and not, e.g. for entrySet().iterator())
>
> I intend to check in a test case modification that will ensure
> that future optimizations do not violate the current compatibility guarantees.
>
> diff --git a/test/java/util/Collection/MOAT.java
> b/test/java/util/Collection/MOAT.java
> --- a/test/java/util/Collection/MOAT.java
> +++ b/test/java/util/Collection/MOAT.java
> @@ -544,6 +544,27 @@ public class MOAT {
>          check(m.size() != 0 ^ m.isEmpty());
>      }
>
> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
> +                                                       Object key,
> +                                                       Object val) {
> +        try {
> +            Map<Object,Object> m2 = m.getClass().newInstance();
> +            m2.put(key, val);
> +            Map.Entry<Object,Object> e = m2.entrySet().iterator().next();
> +            check(e.getKey()   == key);
> +            check(e.getValue() == val);
> +            check(m2.keySet().iterator().next() == key);
> +            check(m2.values().iterator().next() == val);
> +        } catch (Throwable t) { unexpected(t); }
> +    }
> +
> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
> +        testPutPreversesObjectIdentity(m, new Integer(42),  new Integer(43));
> +        testPutPreversesObjectIdentity(m, new Long(42L),    new Long(43L));
> +        testPutPreversesObjectIdentity(m, new Double(42.0), new Double(43.0));
> +        testPutPreversesObjectIdentity(m, new String("42"), new String("43"));
> +    }
> +
>      private static void testMap(Map<Integer,Integer> m) {
>          System.out.println("\n==> " + m.getClass().getName());
>
> @@ -572,6 +593,7 @@ public class MOAT {
>          }
>
>          if (supportsPut(m)) {
> +            testPutPreversesObjectIdentity(m);
>              try {
>                  check(m.put(3333, 77777) == null);
>                  check(m.put(9134, 74982) == null);
>   

From charlie.hunt at sun.com  Mon Jun  9 07:57:10 2008
From: charlie.hunt at sun.com (charlie hunt)
Date: Mon, 09 Jun 2008 09:57:10 -0500
Subject: HashMap implementations and Integer specializations
In-Reply-To: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
Message-ID: <484D44C6.3030504@sun.com>

wrt the Integer & Long values you use in your test case ...

You might consider using larger Integer & Long values, ones that lie 
outside the range of Integer.IntegerCache & Long.LongCache to avoid any 
potential confusion about whether the values you are putting into the 
Map might get grabbed from the IntegerCache or LongCache via some 
"magic" of the HotSpot compiler, i.e it's conceivable a call to 'new 
Integer()' could be transformed into Integer.valueOf()'.

charlie ...

Martin Buchholz wrote:
> JavaOne 2008 technical session PDFs are now available
>
> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>
> I was surprised to discover a discussion of
> HashMap optimization at the JavaOne talk
> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>
> Did I miss an announcement of that?
>
> A comment on that talk:
>
> It is easy to make the mistake of thinking that HashMap does not
> have to store the actual Integer key in the call to put.
> Unfortunately, Java's evil semantics (everything is an Object,
> everything is a Lock, everything has an Identity) require
> that the exact same objects inserted into a HashMap can be
> removed later.  This means that specialized submaps will have
> a harder time optimizing for footprint.  (I do think the
> algorithm presented in the talk is correct, since the front cache
> is likely only used for get(), and not, e.g. for entrySet().iterator())
>
> I intend to check in a test case modification that will ensure
> that future optimizations do not violate the current compatibility guarantees.
>
> diff --git a/test/java/util/Collection/MOAT.java
> b/test/java/util/Collection/MOAT.java
> --- a/test/java/util/Collection/MOAT.java
> +++ b/test/java/util/Collection/MOAT.java
> @@ -544,6 +544,27 @@ public class MOAT {
>          check(m.size() != 0 ^ m.isEmpty());
>      }
>
> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
> +                                                       Object key,
> +                                                       Object val) {
> +        try {
> +            Map<Object,Object> m2 = m.getClass().newInstance();
> +            m2.put(key, val);
> +            Map.Entry<Object,Object> e = m2.entrySet().iterator().next();
> +            check(e.getKey()   == key);
> +            check(e.getValue() == val);
> +            check(m2.keySet().iterator().next() == key);
> +            check(m2.values().iterator().next() == val);
> +        } catch (Throwable t) { unexpected(t); }
> +    }
> +
> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
> +        testPutPreversesObjectIdentity(m, new Integer(42),  new Integer(43));
> +        testPutPreversesObjectIdentity(m, new Long(42L),    new Long(43L));
> +        testPutPreversesObjectIdentity(m, new Double(42.0), new Double(43.0));
> +        testPutPreversesObjectIdentity(m, new String("42"), new String("43"));
> +    }
> +
>      private static void testMap(Map<Integer,Integer> m) {
>          System.out.println("\n==> " + m.getClass().getName());
>
> @@ -572,6 +593,7 @@ public class MOAT {
>          }
>
>          if (supportsPut(m)) {
> +            testPutPreversesObjectIdentity(m);
>              try {
>                  check(m.put(3333, 77777) == null);
>                  check(m.put(9134, 74982) == null);
>   

-- 

Charlie Hunt
Java Performance Engineer

<http://java.sun.com/docs/performance/>


From charlie.hunt at sun.com  Mon Jun  9 11:26:40 2008
From: charlie.hunt at sun.com (charlie hunt)
Date: Mon, 09 Jun 2008 13:26:40 -0500
Subject: HashMap implementations and Integer specializations
In-Reply-To: <1ccfd1c10806091050m3bf281fby489798edbfe04288@mail.gmail.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
	<484D44C6.3030504@sun.com>
	<1ccfd1c10806091050m3bf281fby489798edbfe04288@mail.gmail.com>
Message-ID: <484D75E0.3060500@sun.com>

Martin,

I'm rather shocked at your response!

Consider for example, there's a very popular tool out their that 
integrates very well into NetBeans  IDE and Eclipse IDE which suggests 
changing all 'new Integer(), new Long()' calls into 'Integer.valueOf() & 
Long.valueOf()'.  Take a quick look at how new Integer() contrasts with 
Integer.valueOf().

Suppose in the future as Martin moves on to bigger and better things 
beyond OpenJDK and a future maintainer looks at your test case and 
updates it to use Integer.valueOf() and Long.valueOf() as result of such 
a tool mentioned above.   Should that happen, I don't think your test 
case would test what it was intended to test.

Would not your test case be improved by choosing values well outside the 
values contained in the IntegerCache & LongCache?

charlie ...

Martin Buchholz wrote:
> Charlie,
>
> Hotspot engineers throughout the ages
> have been tempted to optimize away
> object identity semantics of Integer and String,
> but I'm pretty sure that for e.g. new Integer(x)
> and new String(y) hotspot will certainly continue
> to return _new_ objects (unless of course
> the application can be proven to not tell the
> difference), and there are sufficient
> regression tests to keep all of us in line.
>
> Martin
>
> On Mon, Jun 9, 2008 at 7:57 AM, charlie hunt <charlie.hunt at sun.com> wrote:
>   
>> wrt the Integer & Long values you use in your test case ...
>>
>> You might consider using larger Integer & Long values, ones that lie outside
>> the range of Integer.IntegerCache & Long.LongCache to avoid any potential
>> confusion about whether the values you are putting into the Map might get
>> grabbed from the IntegerCache or LongCache via some "magic" of the HotSpot
>> compiler, i.e it's conceivable a call to 'new Integer()' could be
>> transformed into Integer.valueOf()'.
>>
>> charlie ...
>>
>> Martin Buchholz wrote:
>>     
>>> JavaOne 2008 technical session PDFs are now available
>>>
>>>
>>> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>>>
>>> I was surprised to discover a discussion of
>>> HashMap optimization at the JavaOne talk
>>> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>>>
>>> Did I miss an announcement of that?
>>>
>>> A comment on that talk:
>>>
>>> It is easy to make the mistake of thinking that HashMap does not
>>> have to store the actual Integer key in the call to put.
>>> Unfortunately, Java's evil semantics (everything is an Object,
>>> everything is a Lock, everything has an Identity) require
>>> that the exact same objects inserted into a HashMap can be
>>> removed later.  This means that specialized submaps will have
>>> a harder time optimizing for footprint.  (I do think the
>>> algorithm presented in the talk is correct, since the front cache
>>> is likely only used for get(), and not, e.g. for entrySet().iterator())
>>>
>>> I intend to check in a test case modification that will ensure
>>> that future optimizations do not violate the current compatibility
>>> guarantees.
>>>
>>> diff --git a/test/java/util/Collection/MOAT.java
>>> b/test/java/util/Collection/MOAT.java
>>> --- a/test/java/util/Collection/MOAT.java
>>> +++ b/test/java/util/Collection/MOAT.java
>>> @@ -544,6 +544,27 @@ public class MOAT {
>>>         check(m.size() != 0 ^ m.isEmpty());
>>>     }
>>>
>>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
>>> +                                                       Object key,
>>> +                                                       Object val) {
>>> +        try {
>>> +            Map<Object,Object> m2 = m.getClass().newInstance();
>>> +            m2.put(key, val);
>>> +            Map.Entry<Object,Object> e = m2.entrySet().iterator().next();
>>> +            check(e.getKey()   == key);
>>> +            check(e.getValue() == val);
>>> +            check(m2.keySet().iterator().next() == key);
>>> +            check(m2.values().iterator().next() == val);
>>> +        } catch (Throwable t) { unexpected(t); }
>>> +    }
>>> +
>>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
>>> +        testPutPreversesObjectIdentity(m, new Integer(42),  new
>>> Integer(43));
>>> +        testPutPreversesObjectIdentity(m, new Long(42L),    new
>>> Long(43L));
>>> +        testPutPreversesObjectIdentity(m, new Double(42.0), new
>>> Double(43.0));
>>> +        testPutPreversesObjectIdentity(m, new String("42"), new
>>> String("43"));
>>> +    }
>>> +
>>>     private static void testMap(Map<Integer,Integer> m) {
>>>         System.out.println("\n==> " + m.getClass().getName());
>>>
>>> @@ -572,6 +593,7 @@ public class MOAT {
>>>         }
>>>
>>>         if (supportsPut(m)) {
>>> +            testPutPreversesObjectIdentity(m);
>>>             try {
>>>                 check(m.put(3333, 77777) == null);
>>>                 check(m.put(9134, 74982) == null);
>>>
>>>       
>> --
>>
>> Charlie Hunt
>> Java Performance Engineer
>>
>> <http://java.sun.com/docs/performance/>
>>
>>
>>     

-- 

Charlie Hunt
Java Performance Engineer

<http://java.sun.com/docs/performance/>


From osvaldo at visionnaire.com.br  Mon Jun  9 14:09:52 2008
From: osvaldo at visionnaire.com.br (Osvaldo Pinali Doederlein)
Date: Mon, 09 Jun 2008 18:09:52 -0300
Subject: [concurrency-interest] NavigableMap implementation bugs
In-Reply-To: <484D7E58.8020500@cs.oswego.edu>
References: <1ccfd1c10806081430u361ccc58y9d423aca49c09057@mail.gmail.com>
	<484D7E58.8020500@cs.oswego.edu>
Message-ID: <484D9C20.3070607@visionnaire.com.br>

Doug Lea wrote:
> I don't think so. Relaying the subset methods to the *Set classes
> was just an implementation expediency under the mis-thought that they
> would take care of recursive subsets etc rather than needing
> special implementations for KeySets. But the byproduct for remove()
> is clearly wrong so they do need separate implementations.
>    
This remembers me from an old pet peeve, the fact that java.util.HashSet 
is implemented as a wrapper over java.util.HashMap. This sucks 
performance-wise, due to the additional indirections everywhere, and 
even more important, because every entry single object is larger than 
necessary - it contains a key and a value fields, but a single field 
would be necessary for HashSet. If you have a Set with millions of 
entries, the overhead of one useless pointer per entry is significant. 
Plus, the wrapping implementation uses a dummy, fixed Object instance as 
the value for all entries - and this may create another subtle 
performance problem: large numbers of "cross-space" references in the 
heap. I know that in most GCs only old-to-young refs are evil, but it 
seems that in some GCs any cross-space reference is bad (requires remset 
tracking), like Detlef et al's new "Garbage-First" collector (if I 
understood it).

Back in J2SE1.2 time, the runtime savings from the wrapping 
implementation could be significant... but, today? The HashMap* classes 
inside the latest rt.jar are 18,5Kb total (uncompressed), versus 3Kb 
from HashSet. That's a 12Kb of space saving, plus some small saving in 
JIT time too. I'd say that this is an irrelevant advantage, even in 
JavaME. The performance bonus of a tuned HashSet, however modest, would 
certainly be much more significant. I know it's ugly from a maintenance 
POV to have two large classes that will be 90% identical, but to 
paraphrase the movie Some Like It Hot, nothing is perfect...

A+
Osvaldo

-- 
-----------------------------------------------------------------------
Osvaldo Pinali Doederlein                   Visionnaire Inform?tica S/A
osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223


From josh at bloch.us  Mon Jun  9 14:43:07 2008
From: josh at bloch.us (Joshua Bloch)
Date: Mon, 9 Jun 2008 14:43:07 -0700
Subject: [concurrency-interest] NavigableMap implementation bugs
In-Reply-To: <484D9C20.3070607@visionnaire.com.br>
References: <1ccfd1c10806081430u361ccc58y9d423aca49c09057@mail.gmail.com>
	<484D7E58.8020500@cs.oswego.edu> <484D9C20.3070607@visionnaire.com.br>
Message-ID: <b097ac510806091443m27ca7e2ftc4e44c6e88b6de3d@mail.gmail.com>

Osvaldo,

Yes, I must say that I'm surprised that my original implementation of
HashSet still stands.  It would be interesting to see what sort of
performance improvement (time and space) we could get with a freestanding
HashSet implementation.

     Josh

On Mon, Jun 9, 2008 at 2:09 PM, Osvaldo Pinali Doederlein <
osvaldo at visionnaire.com.br> wrote:

> Doug Lea wrote:
> > I don't think so. Relaying the subset methods to the *Set classes
> > was just an implementation expediency under the mis-thought that they
> > would take care of recursive subsets etc rather than needing
> > special implementations for KeySets. But the byproduct for remove()
> > is clearly wrong so they do need separate implementations.
> >
> This remembers me from an old pet peeve, the fact that java.util.HashSet
> is implemented as a wrapper over java.util.HashMap. This sucks
> performance-wise, due to the additional indirections everywhere, and
> even more important, because every entry single object is larger than
> necessary - it contains a key and a value fields, but a single field
> would be necessary for HashSet. If you have a Set with millions of
> entries, the overhead of one useless pointer per entry is significant.
> Plus, the wrapping implementation uses a dummy, fixed Object instance as
> the value for all entries - and this may create another subtle
> performance problem: large numbers of "cross-space" references in the
> heap. I know that in most GCs only old-to-young refs are evil, but it
> seems that in some GCs any cross-space reference is bad (requires remset
> tracking), like Detlef et al's new "Garbage-First" collector (if I
> understood it).
>
> Back in J2SE1.2 time, the runtime savings from the wrapping
> implementation could be significant... but, today? The HashMap* classes
> inside the latest rt.jar are 18,5Kb total (uncompressed), versus 3Kb
> from HashSet. That's a 12Kb of space saving, plus some small saving in
> JIT time too. I'd say that this is an irrelevant advantage, even in
> JavaME. The performance bonus of a tuned HashSet, however modest, would
> certainly be much more significant. I know it's ugly from a maintenance
> POV to have two large classes that will be 90% identical, but to
> paraphrase the movie Some Like It Hot, nothing is perfect...
>
> A+
> Osvaldo
>
> --
> -----------------------------------------------------------------------
> Osvaldo Pinali Doederlein                   Visionnaire Inform?tica S/A
> osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
> Arquiteto de Tecnologia                          +55 (41) 337-1000 #223
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20080609/ca58ae9a/attachment-0001.html 

From charlie.hunt at sun.com  Mon Jun  9 15:38:56 2008
From: charlie.hunt at sun.com (charlie hunt)
Date: Mon, 09 Jun 2008 17:38:56 -0500
Subject: HashMap implementations and Integer specializations
In-Reply-To: <1ccfd1c10806091139h3e06a6cdj7e23aba81ccf0ec0@mail.gmail.com>
References: <1ccfd1c10806081513k2399c694p7be56c83c9778e21@mail.gmail.com>
	<484D44C6.3030504@sun.com>
	<1ccfd1c10806091050m3bf281fby489798edbfe04288@mail.gmail.com>
	<484D75E0.3060500@sun.com>
	<1ccfd1c10806091139h3e06a6cdj7e23aba81ccf0ec0@mail.gmail.com>
Message-ID: <484DB100.6000309@sun.com>

Martin,

I'll accept your adding of the comment as a solution to my suggested 
improvement.

charlie ...

P.S.  I sense you did not like my feedback / comments, or were somehow 
offended. I was trying to offer you a suggestion to improve to your test 
case.

Martin Buchholz wrote:
> Charlie,
>
> Test case code is different from regular code
> in that bad practice is often a good idea.
> People should know better than to "fix" test cases
> using their IDE.
>
> But I added this comment:
>
>         // This code intentionally uses the denigrated constructors
>         // that are guaranteed to return a unique object!
>
> Martin
>
> On Mon, Jun 9, 2008 at 11:26 AM, charlie hunt <charlie.hunt at sun.com> wrote:
>   
>> Martin,
>>
>> I'm rather shocked at your response!
>>
>> Consider for example, there's a very popular tool out their that integrates
>> very well into NetBeans  IDE and Eclipse IDE which suggests changing all
>> 'new Integer(), new Long()' calls into 'Integer.valueOf() & Long.valueOf()'.
>>  Take a quick look at how new Integer() contrasts with Integer.valueOf().
>>
>> Suppose in the future as Martin moves on to bigger and better things beyond
>> OpenJDK and a future maintainer looks at your test case and updates it to
>> use Integer.valueOf() and Long.valueOf() as result of such a tool mentioned
>> above.   Should that happen, I don't think your test case would test what it
>> was intended to test.
>>
>> Would not your test case be improved by choosing values well outside the
>> values contained in the IntegerCache & LongCache?
>>
>> charlie ...
>>
>> Martin Buchholz wrote:
>>     
>>> Charlie,
>>>
>>> Hotspot engineers throughout the ages
>>> have been tempted to optimize away
>>> object identity semantics of Integer and String,
>>> but I'm pretty sure that for e.g. new Integer(x)
>>> and new String(y) hotspot will certainly continue
>>> to return _new_ objects (unless of course
>>> the application can be proven to not tell the
>>> difference), and there are sufficient
>>> regression tests to keep all of us in line.
>>>
>>> Martin
>>>
>>> On Mon, Jun 9, 2008 at 7:57 AM, charlie hunt <charlie.hunt at sun.com> wrote:
>>>
>>>       
>>>> wrt the Integer & Long values you use in your test case ...
>>>>
>>>> You might consider using larger Integer & Long values, ones that lie
>>>> outside
>>>> the range of Integer.IntegerCache & Long.LongCache to avoid any potential
>>>> confusion about whether the values you are putting into the Map might get
>>>> grabbed from the IntegerCache or LongCache via some "magic" of the
>>>> HotSpot
>>>> compiler, i.e it's conceivable a call to 'new Integer()' could be
>>>> transformed into Integer.valueOf()'.
>>>>
>>>> charlie ...
>>>>
>>>> Martin Buchholz wrote:
>>>>
>>>>         
>>>>> JavaOne 2008 technical session PDFs are now available
>>>>>
>>>>>
>>>>>
>>>>> http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2008
>>>>>
>>>>> I was surprised to discover a discussion of
>>>>> HashMap optimization at the JavaOne talk
>>>>> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6434.pdf
>>>>>
>>>>> Did I miss an announcement of that?
>>>>>
>>>>> A comment on that talk:
>>>>>
>>>>> It is easy to make the mistake of thinking that HashMap does not
>>>>> have to store the actual Integer key in the call to put.
>>>>> Unfortunately, Java's evil semantics (everything is an Object,
>>>>> everything is a Lock, everything has an Identity) require
>>>>> that the exact same objects inserted into a HashMap can be
>>>>> removed later.  This means that specialized submaps will have
>>>>> a harder time optimizing for footprint.  (I do think the
>>>>> algorithm presented in the talk is correct, since the front cache
>>>>> is likely only used for get(), and not, e.g. for entrySet().iterator())
>>>>>
>>>>> I intend to check in a test case modification that will ensure
>>>>> that future optimizations do not violate the current compatibility
>>>>> guarantees.
>>>>>
>>>>> diff --git a/test/java/util/Collection/MOAT.java
>>>>> b/test/java/util/Collection/MOAT.java
>>>>> --- a/test/java/util/Collection/MOAT.java
>>>>> +++ b/test/java/util/Collection/MOAT.java
>>>>> @@ -544,6 +544,27 @@ public class MOAT {
>>>>>        check(m.size() != 0 ^ m.isEmpty());
>>>>>    }
>>>>>
>>>>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m,
>>>>> +                                                       Object key,
>>>>> +                                                       Object val) {
>>>>> +        try {
>>>>> +            Map<Object,Object> m2 = m.getClass().newInstance();
>>>>> +            m2.put(key, val);
>>>>> +            Map.Entry<Object,Object> e =
>>>>> m2.entrySet().iterator().next();
>>>>> +            check(e.getKey()   == key);
>>>>> +            check(e.getValue() == val);
>>>>> +            check(m2.keySet().iterator().next() == key);
>>>>> +            check(m2.values().iterator().next() == val);
>>>>> +        } catch (Throwable t) { unexpected(t); }
>>>>> +    }
>>>>> +
>>>>> +    private static void testPutPreversesObjectIdentity(Map<?,?> m) {
>>>>> +        testPutPreversesObjectIdentity(m, new Integer(42),  new
>>>>> Integer(43));
>>>>> +        testPutPreversesObjectIdentity(m, new Long(42L),    new
>>>>> Long(43L));
>>>>> +        testPutPreversesObjectIdentity(m, new Double(42.0), new
>>>>> Double(43.0));
>>>>> +        testPutPreversesObjectIdentity(m, new String("42"), new
>>>>> String("43"));
>>>>> +    }
>>>>> +
>>>>>    private static void testMap(Map<Integer,Integer> m) {
>>>>>        System.out.println("\n==> " + m.getClass().getName());
>>>>>
>>>>> @@ -572,6 +593,7 @@ public class MOAT {
>>>>>        }
>>>>>
>>>>>        if (supportsPut(m)) {
>>>>> +            testPutPreversesObjectIdentity(m);
>>>>>            try {
>>>>>                check(m.put(3333, 77777) == null);
>>>>>                check(m.put(9134, 74982) == null);
>>>>>
>>>>>
>>>>>           
>>>> --
>>>>
>>>> Charlie Hunt
>>>> Java Performance Engineer
>>>>
>>>> <http://java.sun.com/docs/performance/>
>>>>
>>>>
>>>>
>>>>         
>> --
>>
>> Charlie Hunt
>> Java Performance Engineer
>>
>> <http://java.sun.com/docs/performance/>
>>
>>
>>     

-- 

Charlie Hunt
Java Performance Engineer

<http://java.sun.com/docs/performance/>


From josh at bloch.us  Mon Jun  9 16:20:53 2008
From: josh at bloch.us (Joshua Bloch)
Date: Mon, 9 Jun 2008 16:20:53 -0700
Subject: [concurrency-interest] NavigableMap implementation bugs
In-Reply-To: <1ccfd1c10806091501k2048a202ha37c2f3c5255cf22@mail.gmail.com>
References: <1ccfd1c10806081430u361ccc58y9d423aca49c09057@mail.gmail.com>
	<484D7E58.8020500@cs.oswego.edu> <484D9C20.3070607@visionnaire.com.br>
	<1ccfd1c10806091501k2048a202ha37c2f3c5255cf22@mail.gmail.com>
Message-ID: <b097ac510806091620t576a915dg38403d4d95739b96@mail.gmail.com>

Oooh, ooh, pick me!

       Josh

P.S. It isn't as tedious as you think.  Doing the obvious transformation on
HashMap gives you a benchmark.  Then you try to beat it.



On Mon, Jun 9, 2008 at 3:01 PM, Martin Buchholz <martinrb at google.com> wrote:

> Osvaldo, I fundamentally agree with you that
> optimizing HashSet in the manner you describe
> is worthwhile, but because the implementation
> needs to "parallel" HashMap, it would be good
> to do this after the current hacking activity on
> HashMap quiesces.
>
> Unfortunately, this kind of programming
> is pure tedium - who will volunteer?
>
> Martin
>
> On Mon, Jun 9, 2008 at 2:09 PM, Osvaldo Pinali Doederlein
> <osvaldo at visionnaire.com.br> wrote:
>  > Doug Lea wrote:
> >>
> >> I don't think so. Relaying the subset methods to the *Set classes
> >> was just an implementation expediency under the mis-thought that they
> >> would take care of recursive subsets etc rather than needing
> >> special implementations for KeySets. But the byproduct for remove()
> >> is clearly wrong so they do need separate implementations.
> >>
> >
> > This remembers me from an old pet peeve, the fact that java.util.HashSet
> is
> > implemented as a wrapper over java.util.HashMap. This sucks
> > performance-wise, due to the additional indirections everywhere, and even
> > more important, because every entry single object is larger than
> necessary -
> > it contains a key and a value fields, but a single field would be
> necessary
> > for HashSet. If you have a Set with millions of entries, the overhead of
> one
> > useless pointer per entry is significant. Plus, the wrapping
> implementation
> > uses a dummy, fixed Object instance as the value for all entries - and
> this
> > may create another subtle performance problem: large numbers of
> > "cross-space" references in the heap. I know that in most GCs only
> > old-to-young refs are evil, but it seems that in some GCs any cross-space
> > reference is bad (requires remset tracking), like Detlef et al's new
> > "Garbage-First" collector (if I understood it).
> >
> > Back in J2SE1.2 time, the runtime savings from the wrapping
> implementation
> > could be significant... but, today? The HashMap* classes inside the
> latest
> > rt.jar are 18,5Kb total (uncompressed), versus 3Kb from HashSet. That's a
> > 12Kb of space saving, plus some small saving in JIT time too. I'd say
> that
> > this is an irrelevant advantage, even in JavaME. The performance bonus of
> a
> > tuned HashSet, however modest, would certainly be much more significant.
> I
> > know it's ugly from a maintenance POV to have two large classes that will
> be
> > 90% identical, but to paraphrase the movie Some Like It Hot, nothing is
> > perfect...
> >
> > A+
> > Osvaldo
> >
> > --
> > -----------------------------------------------------------------------
> > Osvaldo Pinali Doederlein                   Visionnaire Inform?tica S/A
> > osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
> > Arquiteto de Tecnologia                          +55 (41) 337-1000 #223
> >
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20080609/83c4f281/attachment.html 

From jonathan.gibbons at sun.com  Mon Jun 16 13:29:57 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 16 Jun 2008 20:29:57 +0000
Subject: hg: jdk7/tl/langtools: 6714364: refactor javac File handling code
	into new javac.file package
Message-ID: <20080616202959.36F7528B4E@hg.openjdk.java.net>

Changeset: b9bcea8bbe24
Author:    jjg
Date:      2008-06-16 13:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b9bcea8bbe24

6714364: refactor javac File handling code into new javac.file package
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
! src/share/classes/com/sun/tools/apt/main/Main.java
! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/api/JavacTool.java
+ src/share/classes/com/sun/tools/javac/file/BaseFileObject.java
+ src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
+ src/share/classes/com/sun/tools/javac/file/Old199.java
+ src/share/classes/com/sun/tools/javac/file/Paths.java
+ src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
+ src/share/classes/com/sun/tools/javac/file/ZipFileIndexEntry.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
- src/share/classes/com/sun/tools/javac/util/BaseFileObject.java
! src/share/classes/com/sun/tools/javac/util/DiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
- src/share/classes/com/sun/tools/javac/util/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/util/Log.java
- src/share/classes/com/sun/tools/javac/util/Old199.java
- src/share/classes/com/sun/tools/javac/util/Paths.java
- src/share/classes/com/sun/tools/javac/zip/ZipFileIndex.java
- src/share/classes/com/sun/tools/javac/zip/ZipFileIndexEntry.java
! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! src/share/classes/com/sun/tools/javap/JavapFileManager.java
! test/tools/javac/6304921/TestLog.java
! test/tools/javac/6589361/T6589361.java
! test/tools/javac/T6358024.java
! test/tools/javac/T6358166.java
! test/tools/javac/T6358168.java
! test/tools/javac/T6705935.java
! test/tools/javac/api/T6358786.java
! test/tools/javac/api/TestResolveIdent.java
! test/tools/javac/util/filemanager/TestName.java


From bradford.wetmore at sun.com  Mon Jun 16 14:42:51 2008
From: bradford.wetmore at sun.com (bradford.wetmore at sun.com)
Date: Mon, 16 Jun 2008 21:42:51 +0000
Subject: hg: jdk7/tl/jdk: 9 new changesets
Message-ID: <20080616214437.D949C28B92@hg.openjdk.java.net>

Changeset: e8201036fc65
Author:    xuelei
Date:      2008-06-04 09:56 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8201036fc65

6690018: RSAClientKeyExchange NullPointerException
Summary: checking certificate key length for RSA_EXPORT key exchange
Reviewed-by: wetmore, mullan

! src/share/classes/sun/security/ssl/ClientHandshaker.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java

Changeset: da1eb844871c
Author:    wetmore
Date:      2008-06-09 00:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da1eb844871c

Merge


Changeset: e3de7e7bafcf
Author:    weijun
Date:      2008-06-10 10:51 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e3de7e7bafcf

6711509: PolicyTool is misspelling Runtime permission - 'setSecurityManager' entry in the policy file
Reviewed-by: wetmore, mullan

! src/share/classes/sun/security/tools/PolicyTool.java

Changeset: 2058f3daec43
Author:    weijun
Date:      2008-06-10 11:03 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2058f3daec43

6711435: console.sh uses incompatible ==
Reviewed-by: xuelei

! test/sun/security/tools/keytool/console.sh

Changeset: 93dce0e374de
Author:    chegar
Date:      2008-06-12 17:25 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93dce0e374de

6698625: InetAddress.getLocalHost() failed in returning chinese local host name
Summary: Remove unnecessary and incorrect NewStringUTF
Reviewed-by: michaelm

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c

Changeset: 4d1d84792fd0
Author:    chegar
Date:      2008-06-12 17:26 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d1d84792fd0

6630348: Invalid html tags (extra double quote)
Summary: Remove extra quote
Reviewed-by: michaelm

! src/share/classes/java/net/CookieHandler.java
! src/share/classes/java/net/ResponseCache.java
! src/share/classes/java/net/URI.java
! src/share/classes/java/net/URL.java

Changeset: 56993d795f7a
Author:    chegar
Date:      2008-06-12 17:28 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/56993d795f7a

6628569: api/java_net/MulticastSocket/descriptions.html#setTTL fails is ipv6 configured
Summary: failover to IPv6 socket if IPv4 fails
Reviewed-by: michaelm

! src/solaris/native/java/net/NetworkInterface.c

Changeset: 7c9d632e7323
Author:    jccollet
Date:      2008-06-13 17:43 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c9d632e7323

6483406: new ServerSocket() sometimes takes more than 3 minutes on Suse Linux
Summary: Switch to socketpair() call to create marker fd
Reviewed-by: alanb

! src/solaris/native/java/net/PlainSocketImpl.c

Changeset: 6471947b1ffc
Author:    wetmore
Date:      2008-06-16 10:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6471947b1ffc

Merge



From jonathan.gibbons at sun.com  Tue Jun 17 10:46:13 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 17 Jun 2008 17:46:13 +0000
Subject: hg: jdk7/tl/langtools: 6625520: javac handles missing entries on
	classpath badly
Message-ID: <20080617174616.31B8628CA6@hg.openjdk.java.net>

Changeset: f9a4b9e1a521
Author:    jjg
Date:      2008-06-17 10:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f9a4b9e1a521

6625520: javac handles missing entries on classpath badly
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javap/JavapFileManager.java
+ test/tools/javac/T6625520.java


From jonathan.gibbons at sun.com  Wed Jun 18 07:24:44 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 18 Jun 2008 14:24:44 +0000
Subject: hg: jdk7/tl/langtools: 6714365: refactor JavacFileManager to move
	nested classes to top level
Message-ID: <20080618142447.52D6728D30@hg.openjdk.java.net>

Changeset: aa67a5da66e3
Author:    jjg
Date:      2008-06-18 07:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aa67a5da66e3

6714365: refactor JavacFileManager to move nested classes to top level
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
+ src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
+ src/share/classes/com/sun/tools/javac/file/SymbolArchive.java
+ src/share/classes/com/sun/tools/javac/file/ZipArchive.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
+ src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java
- src/share/classes/com/sun/tools/javac/file/ZipFileIndexEntry.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java


From david.lloyd at redhat.com  Wed Jun 18 08:50:47 2008
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 18 Jun 2008 10:50:47 -0500
Subject: Embedded HTTP server
In-Reply-To: <483C5DC5.5060704@sun.com>
References: <483C3EEF.8050800@redhat.com>
	<869257980805271129k6ba8e22fqf4c9b0edb8f9063b@mail.gmail.com>
	<483C5DC5.5060704@sun.com>
Message-ID: <48592ED7.5070209@redhat.com>

On 05/27/2008 02:15 PM, Alan Bateman wrote:
> Juha Lindfors wrote:
>>
>>
>> On Tue, May 27, 2008 at 7:03 PM, David M. Lloyd 
>> <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>>
>>
>>     If not... does anyone besides me think this is a good idea?
>>
>>
>> I think it would be a great idea...  the only reason I've shied away 
>> from using the current embedded one is its unclear status in the 
>> com.sun.* package.
> Michael explains the status of this API in this blog entry:
>  http://blogs.sun.com/michaelmcm/entry/http_server_api_in_java

To revive this thread - The blog entry in question is around 18 months old 
(with no more recent entries to be found), and it does not touch on this 
subject at all.  Is Michael presently in charge of this piece of software 
from Sun's perspective?  Is he subscribed to this list?

- DML

From Christopher.Hegarty at Sun.COM  Wed Jun 18 09:03:50 2008
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Wed, 18 Jun 2008 17:03:50 +0100
Subject: Embedded HTTP server
In-Reply-To: <48592ED7.5070209@redhat.com>
References: <483C3EEF.8050800@redhat.com>
	<869257980805271129k6ba8e22fqf4c9b0edb8f9063b@mail.gmail.com>
	<483C5DC5.5060704@sun.com> <48592ED7.5070209@redhat.com>
Message-ID: <485931E6.2050305@sun.com>

I think that this thread should be moved to the net-dev alias.

I know that Michael is certainly a member of net-dev and is currently 
the owner of the HTTP server.

-Chris.

David M. Lloyd wrote:
> On 05/27/2008 02:15 PM, Alan Bateman wrote:
>> Juha Lindfors wrote:
>>>
>>>
>>> On Tue, May 27, 2008 at 7:03 PM, David M. Lloyd 
>>> <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>>>
>>>
>>>     If not... does anyone besides me think this is a good idea?
>>>
>>>
>>> I think it would be a great idea...  the only reason I've shied away 
>>> from using the current embedded one is its unclear status in the 
>>> com.sun.* package.
>> Michael explains the status of this API in this blog entry:
>>  http://blogs.sun.com/michaelmcm/entry/http_server_api_in_java
> 
> To revive this thread - The blog entry in question is around 18 months 
> old (with no more recent entries to be found), and it does not touch on 
> this subject at all.  Is Michael presently in charge of this piece of 
> software from Sun's perspective?  Is he subscribed to this list?
> 
> - DML

From Alan.Bateman at Sun.COM  Wed Jun 18 09:08:02 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 18 Jun 2008 17:08:02 +0100
Subject: Embedded HTTP server
In-Reply-To: <48592ED7.5070209@redhat.com>
References: <483C3EEF.8050800@redhat.com>
	<869257980805271129k6ba8e22fqf4c9b0edb8f9063b@mail.gmail.com>
	<483C5DC5.5060704@sun.com> <48592ED7.5070209@redhat.com>
Message-ID: <485932E2.3000402@sun.com>

David M. Lloyd wrote:

> Is Michael presently in charge of this piece of software from Sun's 
> perspective?  Is he subscribed to this list?
I've cc'ed the networking group as that is where he HTTP server is 
maintained. Micahel is a member of that group. It may be worth 
re-sending your original proposal.

-Alan.

From david.lloyd at redhat.com  Wed Jun 18 09:11:40 2008
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 18 Jun 2008 11:11:40 -0500
Subject: Embedded HTTP server
In-Reply-To: <485931E6.2050305@sun.com>
References: <483C3EEF.8050800@redhat.com>
	<869257980805271129k6ba8e22fqf4c9b0edb8f9063b@mail.gmail.com>
	<483C5DC5.5060704@sun.com> <48592ED7.5070209@redhat.com>
	<485931E6.2050305@sun.com>
Message-ID: <485933BC.3070807@redhat.com>

On 06/18/2008 11:03 AM, Christopher Hegarty - Sun Microsystems Ireland wrote:
> I think that this thread should be moved to the net-dev alias.
> 
> I know that Michael is certainly a member of net-dev and is currently 
> the owner of the HTTP server.

OK, great.  To restate the original subject of this thread (which has been 
lost): What about an effort to make a standard web server API in the JDK 
(javax.net.httpserver perhaps)?  I for one would be interested in such an 
effort, based on the API for com.sun.httpserver.

- DML

From Michael.McMahon at Sun.COM  Thu Jun 19 03:11:49 2008
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Thu, 19 Jun 2008 11:11:49 +0100
Subject: Embedded HTTP server
In-Reply-To: <485933BC.3070807@redhat.com>
References: <483C3EEF.8050800@redhat.com>
	<869257980805271129k6ba8e22fqf4c9b0edb8f9063b@mail.gmail.com>
	<483C5DC5.5060704@sun.com> <48592ED7.5070209@redhat.com>
	<485931E6.2050305@sun.com> <485933BC.3070807@redhat.com>
Message-ID: <485A30E5.2080209@sun.com>

David M. Lloyd wrote:
> On 06/18/2008 11:03 AM, Christopher Hegarty - Sun Microsystems Ireland 
> wrote:
>> I think that this thread should be moved to the net-dev alias.
>>
>> I know that Michael is certainly a member of net-dev and is currently 
>> the owner of the HTTP server.
>
> OK, great.  To restate the original subject of this thread (which has 
> been lost): What about an effort to make a standard web server API in 
> the JDK (javax.net.httpserver perhaps)?  I for one would be interested 
> in such an effort, based on the API for com.sun.httpserver.
>
> - DML
David,

It was originally intended that the httpserver API would be part of the 
platform
(actually in the package suggested above) but some members of the 
umbrella JSR for
jdk 6 didn't agree with including a http server API in Java SE. So, it 
was dropped from the platform.
And that is why we put it in com.sun.

Personally, I wouldn't have any problem with putting it back in the 
platform, though presumably
this question of whether it blurs the line between Java SE and EE would 
have to be addressed.

- Michael.

(I suggest we continue the conversation exlcusively on net-dev)

From jonathan.gibbons at sun.com  Thu Jun 19 15:53:58 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 19 Jun 2008 22:53:58 +0000
Subject: hg: jdk7/tl/langtools: 6716866: some javac regression tests fail to
	compile with re-orged file manager
Message-ID: <20080619225400.1195828F01@hg.openjdk.java.net>

Changeset: 8bc2ca2a3b0a
Author:    jjg
Date:      2008-06-19 15:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8bc2ca2a3b0a

6716866: some javac regression tests fail to compile with re-orged file manager
Reviewed-by: darcy

! test/tools/javac/T6358024.java
! test/tools/javac/T6358166.java
! test/tools/javac/T6358168.java
! test/tools/javac/T6625520.java


From maurizio.cimadamore at sun.com  Fri Jun 20 03:26:44 2008
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Fri, 20 Jun 2008 10:26:44 +0000
Subject: hg: jdk7/tl/langtools: 6294779: Problem with interface inheritance
	and covariant return types
Message-ID: <20080620102646.8D2D928F54@hg.openjdk.java.net>

Changeset: 4a3b9801f7a0
Author:    mcimadamore
Date:      2008-06-20 11:25 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4a3b9801f7a0

6294779: Problem with interface inheritance and covariant return types
Summary: Problematic overriding check when two methods defined in two distinct superinterfaces are overriden by an interface
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/6294779/T6294779a.java
+ test/tools/javac/generics/6294779/T6294779b.java
+ test/tools/javac/generics/6294779/T6294779c.java


From Ulf.Zibis at CoSoCo.de  Mon Jun 23 14:02:31 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 23 Jun 2008 23:02:31 +0200
Subject: Peculiar fruits in the JDK
Message-ID: <48600F67.3040201@CoSoCo.de>


In original code of the JDK you find the following:

package sun.io;
import sun.nio.cs.MS1252;
public class ByteToCharCp1252 extends ByteToCharSingleByte {
 
    private final static MS1252 nioCoder = new MS1252();
 
    public String getCharacterEncoding() {
        return "Cp1252";
    }
    public ByteToCharCp1252() {
        super.byteToCharTable = nioCoder.getDecoderSingleByteMappings();
    }
}

At every instantiation of ByteToCharCp1252 every time a MS1252-object 
will be instantiated, just only to get the byteToCharTable. Afterwards 
the garbage collector may take care about it.
The MS1252 class looks correspondingly:

package sun.nio.cs;
import java.nio.charset.*;
public class MS1252 extends Charset {
 
    public CharsetDecoder newDecoder() {
        return new Decoder(this);
    }
    public String getDecoderSingleByteMappings() {
        return Decoder.byteToCharTable;
    }
 
    private static class Decoder extends SingleByteDecoder {
        public Decoder(Charset cs) {
            super(cs, byteToCharTable);
        }
        private static final String byteToCharTable =
            "\u20AC\uFFFD\u201A\u0192\u201E\u2026\u2020\u2021" +     // 
0x80 - 0x87
            "\u02C6\u2030\u0160\u2039\u0152\uFFFD\u017D\uFFFD" +     // 
0x88 - 0x8F
        .......
    }
}

I think, we can code this like the following:

package sun.io;
public class ByteToCharCp1252 extends ByteToCharSinglebyte {
 
    public String getCharacterEncoding() {
        return "Cp1252";
    }
    public ByteToCharCp1252() {
        super(sun.nio.cs.MS1252.byteToCharTable);
    }
    .......
}
 
package sun.nio.cs;
import java.nio.charset.*;
public class MS1252 extends US_ASCII {
 
    public static final String byteToCharTable =
        "\u20AC\uFFFD\u201A\u0192\u201E\u2026\u2020\u2021" +     // 0x80 
- 0x87
        "\u02C6\u2030\u0160\u2039\u0152\uFFFD\u017D\uFFFD" +     // 0x88 
- 0x8F
        .......
 
    public CharsetDecoder newDecoder() {
        return new Decoder(this, byteToCharTable);
    }
 
    private static class Decoder extends SingleByteDecoder {
        public Decoder(Charset cs, String byteToCharTable) {
            super(cs, byteToCharTable);
        }
        .......
    }
    .......
}

... and if we look closely a 2nd time, we will see, that the internal 
static Decoder class could be saved also:
 
package sun.nio.cs;
import java.nio.charset.*;
public class MS1252 extends US_ASCII {
 
    public static final String byteToCharTable =
        "\u20AC\uFFFD\u201A\u0192\u201E\u2026\u2020\u2021" +     // 0x80 
- 0x87
        "\u02C6\u2030\u0160\u2039\u0152\uFFFD\u017D\uFFFD" +     // 0x88 
- 0x8F
        .......
 
    public CharsetDecoder newDecoder() {
        return new SingleByteDecoder(this, byteToCharTable);
    }
    .......
}

If we consider, that in each Charset class that way a static Decoder and 
a Encoder class could be saved, the amount of classes can be saved to 
1/3. This would save both startup-time and footprint of the JVM.

You can watch the progress of my work here:
https://java-nio-charset-enhanced.dev.java.net/

Regards

Ulf Zibis



From Xueming.Shen at Sun.COM  Mon Jun 23 16:08:24 2008
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 23 Jun 2008 16:08:24 -0700
Subject: Peculiar fruits in the JDK
In-Reply-To: <48600F67.3040201@CoSoCo.de>
References: <48600F67.3040201@CoSoCo.de>
Message-ID: <48602CE8.6060501@sun.com>

Ulf,   though it is not accurate to say "At every instantiation of 
ByteToCharCp1252 every time a
MS1252-object will be instantiated" (the nioCoder is  final static, so 
it is only instantiated once
for each ByteToCharCp1252 class),  you are absolutely right that the 
nioCoder object is really
not necessary, those getXYZ utility methods should be "static" instead.

You are also on the right direction regarding those inner Decoder and 
Encoder classes... we can
actually go a littler further to even eliminate the class def of those 
singlebyte charsets, given the
only differences among them are a chartobyte mapping, a bytetochar 
mapping, their nam, aliases...
the only thing we need is to define a SingleByteCharset abstract class 
and a set of data tables...
this is actually what I'm doing in my new mapping based implementation.

Btw,  we are not going to do anything for the sun.io.XYZ classes, except 
removing them. I had once
removed them from the J2SE but had to put them back for some reasons, 
but we are absolutely not
going to do anything for that package. I've already eliminatred any use 
of that package in J2SE in
JDK6.

Regards,
Sherman

Ulf Zibis wrote:
>
> In original code of the JDK you find the following:
>
> package sun.io;
> import sun.nio.cs.MS1252;
> public class ByteToCharCp1252 extends ByteToCharSingleByte {
>
>    private final static MS1252 nioCoder = new MS1252();
>
>    public String getCharacterEncoding() {
>        return "Cp1252";
>    }
>    public ByteToCharCp1252() {
>        super.byteToCharTable = nioCoder.getDecoderSingleByteMappings();
>    }
> }
>
> At every instantiation of ByteToCharCp1252 every time a MS1252-object 
> will be instantiated, just only to get the byteToCharTable. Afterwards 
> the garbage collector may take care about it.
> The MS1252 class looks correspondingly:
>
> package sun.nio.cs;
> import java.nio.charset.*;
> public class MS1252 extends Charset {
>
>    public CharsetDecoder newDecoder() {
>        return new Decoder(this);
>    }
>    public String getDecoderSingleByteMappings() {
>        return Decoder.byteToCharTable;
>    }
>
>    private static class Decoder extends SingleByteDecoder {
>        public Decoder(Charset cs) {
>            super(cs, byteToCharTable);
>        }
>        private static final String byteToCharTable =
>            "\u20AC\uFFFD\u201A\u0192\u201E\u2026\u2020\u2021" +     // 
> 0x80 - 0x87
>            "\u02C6\u2030\u0160\u2039\u0152\uFFFD\u017D\uFFFD" +     // 
> 0x88 - 0x8F
>        .......
>    }
> }
>
> I think, we can code this like the following:
>
> package sun.io;
> public class ByteToCharCp1252 extends ByteToCharSinglebyte {
>
>    public String getCharacterEncoding() {
>        return "Cp1252";
>    }
>    public ByteToCharCp1252() {
>        super(sun.nio.cs.MS1252.byteToCharTable);
>    }
>    .......
> }
>
> package sun.nio.cs;
> import java.nio.charset.*;
> public class MS1252 extends US_ASCII {
>
>    public static final String byteToCharTable =
>        "\u20AC\uFFFD\u201A\u0192\u201E\u2026\u2020\u2021" +     // 
> 0x80 - 0x87
>        "\u02C6\u2030\u0160\u2039\u0152\uFFFD\u017D\uFFFD" +     // 
> 0x88 - 0x8F
>        .......
>
>    public CharsetDecoder newDecoder() {
>        return new Decoder(this, byteToCharTable);
>    }
>
>    private static class Decoder extends SingleByteDecoder {
>        public Decoder(Charset cs, String byteToCharTable) {
>            super(cs, byteToCharTable);
>        }
>        .......
>    }
>    .......
> }
>
> ... and if we look closely a 2nd time, we will see, that the internal 
>