From bradford.wetmore at sun.com  Mon Jun  2 23: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 20: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 20: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 11: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 12: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 20: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 23: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 22: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 22: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 22: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  Sat Jun  7 06: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 16: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 21: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 21: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 09: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 09: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 18: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 21: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 22: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 22: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  Mon Jun  9 05: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 07: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 17: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 18: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 19: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 22: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 11: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 08: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 16: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 14: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 14: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 18: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 21: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 21: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.html>

From charlie.hunt at sun.com  Mon Jun  9 22: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 23: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 20: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 21: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 17: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 14: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 15: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 16: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 16: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 16: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 10: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 22: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 10: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 21: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 23: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 
> 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 Ulf.Zibis at CoSoCo.de  Tue Jun 24 10:13:16 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 24 Jun 2008 12:13:16 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48602CE8.6060501@sun.com>
References: <48600F67.3040201@CoSoCo.de> <48602CE8.6060501@sun.com>
Message-ID: <4860C8BC.1040306@CoSoCo.de>

Hi Sherman,

/*
  I've overseen, that invoking the Reply button of my Thunderbird client doesn't include the lists 
address. So here the copy for the public list. Perhaps it's better NOT to CC to my personal address.
  */

Am 24.06.2008 01:08, Xueming Shen schrieb:
> 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 right, my formulation was imprecise. :-(
>   you are absolutely right that the nioCoder object is really
> not necessary, those getXYZ utility methods should be "static" instead.
... and they are absolutely superfluous, if the final static constants
are public.
>
> 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...
Yes, see my TODO-comment here:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/src/sun/nio/cs/ext/IBM037.java?rev=206&view=markup

Also you will see, that I have eliminated the char2byte mapping, and
calculate it by getc2b(b2cMap). IMO this calculating can't be slower,
then the classloader needs to instantiate and fill the String with it's
values from the class file.
> the only thing we need is to define a SingleByteCharset abstract class 
> and a set of data tables...
I have just done this:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/src/sun/nio/cs/SingleByteCharset.java?rev=206&view=markup

> this is actually what I'm doing in my new mapping based implementation.
How can we contribute? I'm getting afraid, that my work ends up on the
scrapheap.
>
> 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.
How did you eliminate the dependencies? E.g.:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/solaris/classes/sun/awt/motif/X11JIS0201.java?rev=201&view=markup
I see, my work on sun.io was for the scrapheap. :-(

very much thank for appreciating my work,

Ulf





From Ulf.Zibis at CoSoCo.de  Tue Jun 24 16:08:14 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 24 Jun 2008 18:08:14 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48602CE8.6060501@sun.com>
References: <48600F67.3040201@CoSoCo.de> <48602CE8.6060501@sun.com>
Message-ID: <48611BEE.7000508@CoSoCo.de>

I many cases I also could shorten the encoding mappings.

Example: 
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/src/sun/nio/cs/ext/IBM870.java?rev=223&view=markup

-Ulf




From david.lloyd at redhat.com  Tue Jun 24 16:15:06 2008
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 24 Jun 2008 11:15:06 -0500
Subject: Peculiar fruits in the JDK
In-Reply-To: <48611BEE.7000508@CoSoCo.de>
References: <48600F67.3040201@CoSoCo.de> <48602CE8.6060501@sun.com>
	<48611BEE.7000508@CoSoCo.de>
Message-ID: <48611D8A.4010304@redhat.com>

On 06/24/2008 11:08 AM, Ulf Zibis wrote:
> I many cases I also could shorten the encoding mappings.
> 
> Example: 
> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/src/sun/nio/cs/ext/IBM870.java?rev=223&view=markup 

Would a 'switch' statement not be more speed- and space-efficient for this 
type of lookup task?

- DML


From Ulf.Zibis at CoSoCo.de  Wed Jun 25 08:57:49 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 25 Jun 2008 10:57:49 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48611D8A.4010304@redhat.com>
References: <48600F67.3040201@CoSoCo.de>
	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>
	<48611D8A.4010304@redhat.com>
Message-ID: <4862088D.3010504@CoSoCo.de>

Hi David,

can you show an example using a 'switch' statement which is shorter or 
faster than:

            char c = c2bMap.charAt(c2bMapIndex[(current & MASK1) >> 
SHIFT] + (current & MASK2));

or more faster for special mappings:

            char c = (current < '\u0100') ? c2bMap.charAt(current) :
                c2bMap.charAt(c2bMapIndex[(current & MASK1) >> SHIFT] + 
(current & MASK2));

Regards,
Ulf


Am 24.06.2008 18:15, David M. Lloyd schrieb:
> On 06/24/2008 11:08 AM, Ulf Zibis wrote:
>> I many cases I also could shorten the encoding mappings.
>>
>> Example: 
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/src/sun/nio/cs/ext/IBM870.java?rev=223&view=markup 
>
>
> Would a 'switch' statement not be more speed- and space-efficient for 
> this type of lookup task?
>
> - DML
>
>
>



From Ulf.Zibis at CoSoCo.de  Wed Jun 25 15:39:07 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 25 Jun 2008 17:39:07 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <4861199E.4030706@sun.com>
References: <48600F67.3040201@CoSoCo.de> <48602CE8.6060501@sun.com>
	<4860C64F.8030106@CoSoCo.de> <4861199E.4030706@sun.com>
Message-ID: <4862669B.3040404@CoSoCo.de>

Hi Sherman,

Am 24.06.2008 17:58, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> How did you eliminate the dependencies? E.g.: 
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/solaris/classes/sun/awt/motif/X11JIS0201.java?rev=201&view=markup 
>>
>> I see, my work on sun.io was for the scrapheap. :-(
>>
>
> If you have the source code for 5.x, you would find those X11 
> converters were sun.io based, I rewrote
> all of them in JDK6 and modified all the places in awt/font to use the 
> java.nio.charset interface..
> fortunately I was the original font/motif guy who wrote them in the 
> first place, so not too difficult:-)

Sorry, class X11JIS0201 mistakenly is not an example for the 
dependencies of the sun.io package. It's just the only place, were I 
found an inner dependency (inheritance) to the 
sun.nio.cs.ext.JIS_X_0201.De/Encoder. Do you know about other such 
"inner" dependencies?
Please note, that in main I'm working on the refactoring and bugfixing 
of the JDBC bridge. From that work I came to enhance the sun.nio.cs 
package. On investigating to add methods to terminate the decoding on 
occurrence of exclusive cipher (see: Bug 6695386), I discovered, that 
the de/encoders of sun.nio.cs could be coded faster and less 
footprint-consuming.

>
> I did the same thing for all sun.io.XYZConverter usages to use the 
> java.nio.charset interface in J2SE
> workspace then actually removed the J2SE in JDK6 before beta, but had 
> to put them back because
> BIG licensee insisted they have their JDBC bridge drivers still using 
> sun.io and don't want to migrate.
>
> Yes, don't try to improve anything in sun.io package, our currently 
> policy is to keep it there but don't
> do anything. That said, in order to rewrite the sun.nio.cs/ext package 
> we might have to touch this
> package again, one of the ideas is to write a adaptor class to bridge 
> the sun.io.Converter to sun.nio.cs
> implementation, so we can eliminate all those CharToByte/ByteToChar 
> implementation, I have a
> draft implementation in one of my ws, but have not fully tested, will 
> dig it out later.

I see, an adaptor class might be better, than my refactoring (just 
making the 3 getters static and/or superfluous) on the interface between 
sun.io and sun.nio.cs.
... but I'm sure, my refactoring is faster and consumes less footprint.

BTW: Why not shipping the BIG licensee a separate sun.io-jar to include 
in his classpath?

>
>> very much thank for appreciating my work,
>>
>
> Really appreciate your work. The charset implementation work currently 
> is not my priority
> simply because I lost my main codereviewer Martin (though he is still 
> interested in this area
> after moving on to Google, I'm not so sure how much he can continue 
> spend on this), so it
> would be easy to work on my other interesting areas. But seems like we 
> now have a contributor
> who is very experienced and interested in charset:-)  we should give 
> it a try. I will send
> you some classes I was working on to share my thoughts/ideas later. 
> But I would "warn" you
> that all the changes might not make into JDK7, there are sill some 
> debates internally that whether
> or not we should spend our resource (very limited) on something that 
> works (don't break it if it
> works:-))

Yes, it works well. My aproach is just about performance an footprint.

I'm still waiting for your classes to share your thoughts/ideas later.

Regards,
Ulf






From david.lloyd at redhat.com  Wed Jun 25 15:55:33 2008
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Jun 2008 10:55:33 -0500
Subject: Peculiar fruits in the JDK
In-Reply-To: <4862088D.3010504@CoSoCo.de>
References: <48600F67.3040201@CoSoCo.de>	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>	<48611D8A.4010304@redhat.com>
	<4862088D.3010504@CoSoCo.de>
Message-ID: <48626A75.3050205@redhat.com>

On 06/25/2008 03:57 AM, Ulf Zibis wrote:
> Hi David,
> 
> can you show an example using a 'switch' statement which is shorter or 
> faster than:
> 
>            char c = c2bMap.charAt(c2bMapIndex[(current & MASK1) >> 
> SHIFT] + (current & MASK2));

Faster - maybe or maybe not; but the "c2bMap", being sparse, can be 
represented possibly more space-efficiently using a lookupswitch (I'm 
thinking of all the \u0000 entries, which can be handled with a "default" 
branch):

     public static final c2bMapper(int idx) {
         switch (idx) {
             case 1: return 1;
             case 2: return 2;
             ...
             default: return 0;
         }
     }

The primary disadvantage being, I guess, that the table cannot then be 
stored in e.g. a properties file.

- DML



From Ulf.Zibis at CoSoCo.de  Wed Jun 25 16:33:46 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 25 Jun 2008 18:33:46 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48626A75.3050205@redhat.com>
References: <48600F67.3040201@CoSoCo.de>	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>	<48611D8A.4010304@redhat.com>	<4862088D.3010504@CoSoCo.de>
	<48626A75.3050205@redhat.com>
Message-ID: <4862736A.8070201@CoSoCo.de>

Hi David,

please don't CC to me. Otherwise I get your message twice. I read the list.

....

Am 25.06.2008 17:55, David M. Lloyd schrieb:
> On 06/25/2008 03:57 AM, Ulf Zibis wrote:
>> Hi David,
>>
>> can you show an example using a 'switch' statement which is shorter 
>> or faster than:
>>
>>            char c = c2bMap.charAt(c2bMapIndex[(current & MASK1) >> 
>> SHIFT] + (current & MASK2));
>
> Faster - maybe or maybe not; but the "c2bMap", being sparse, can be 
> represented possibly more space-efficiently using a lookupswitch (I'm 
> thinking of all the \u0000 entries, which can be handled with a 
> "default" branch):
>
>     public static final c2bMapper(int idx) {
>         switch (idx) {
>             case 1: return 1;
>             case 2: return 2;
>             ...
>             default: return 0;
>         }
>     }
>
> The primary disadvantage being, I guess, that the table cannot then be 
> stored in e.g. a properties file.
>
> - DML
>
>
Let me correct:

    public static final byte c2bMapper(char inChar) {
        int idx = (int)inChar;
        switch (idx) {
            case 0x0001: return (byte)0x01;
            case 0x0002: return (byte)0x02;
            ...
            case 0x015F: return (byte)0x8F;
            ...
            case 0x02DD: return (byte)0x64;
            default: return 0;
        }
    }

Internally this will be compiled as a looong if () else if () else if () 
.... chain, because the cases are NOT consecutive. Executing such a 
chain will never be faster, than calculating the index as I posted.

Additionally this code would not be space-efficient. Think about 256 
times {else if (idx == x) return (byte)y;}
Not to forget: each of the around 100 encoders will need such an 
individual custom switch-case block. :-(

- Ulf




From david.lloyd at redhat.com  Wed Jun 25 16:49:34 2008
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Jun 2008 11:49:34 -0500
Subject: Peculiar fruits in the JDK
In-Reply-To: <4862736A.8070201@CoSoCo.de>
References: <48600F67.3040201@CoSoCo.de>	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>	<48611D8A.4010304@redhat.com>	<4862088D.3010504@CoSoCo.de>	<48626A75.3050205@redhat.com>
	<4862736A.8070201@CoSoCo.de>
Message-ID: <4862771E.9050508@redhat.com>

On 06/25/2008 11:33 AM, Ulf Zibis wrote:
> Hi David,
> 
> please don't CC to me. Otherwise I get your message twice. I read the list.

Every poster on every list seems to have their own preference :-)  It would 
help if there were proper Reply-To: headers in messages from the mailing list.

> Internally this will be compiled as a looong if () else if () else if () 
> .... chain, because the cases are NOT consecutive. Executing such a 
> chain will never be faster, than calculating the index as I posted.

You mean in the JITed machine code?  In bytecode it should compile to a 
compact lookupswitch, but I admit I'm not familiar with how that would work 
on the JIT side.

- DML


From xueming.shen at sun.com  Wed Jun 25 20:14:03 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Wed, 25 Jun 2008 20:14:03 +0000
Subject: hg: jdk7/tl/jdk: 4752069: (cs spec) BOM should not be ignored in
	UTF-16 charsets
Message-ID: <20080625201414.BE07028344@hg.openjdk.java.net>

Changeset: c78fb2e96d8c
Author:    sherman
Date:      2008-06-25 08:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c78fb2e96d8c

4752069: (cs spec) BOM should not be ignored in UTF-16 charsets
Summary: API doc update regarding BOM hanlding in UTF-16 charsets
Reviewed-by: alanb

! src/share/classes/java/nio/charset/Charset.java



From xueming.shen at sun.com  Wed Jun 25 21:10:01 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Wed, 25 Jun 2008 21:10:01 +0000
Subject: hg: jdk7/tl/jdk: 6481955: Uncanonicalized absolute filepath with
	length 248-260 no longer works (win)
Message-ID: <20080625211013.324902834B@hg.openjdk.java.net>

Changeset: b212b96b3919
Author:    sherman
Date:      2008-06-25 13:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b212b96b3919

6481955: Uncanonicalized absolute filepath with length 248-260 no longer works (win)
Summary: Uncanonicalized absolute filepath with length 248-260 no longer works (win)
Reviewed-by: alanb

! src/windows/native/java/io/io_util_md.c
+ test/java/io/File/MaxPath.java



From jonathan.gibbons at sun.com  Wed Jun 25 21:26:22 2008
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 25 Jun 2008 21:26:22 +0000
Subject: hg: jdk7/tl/langtools: 6507179: javadoc -source 1.3 does not work
	with jdk6
Message-ID: <20080625212623.B441828354@hg.openjdk.java.net>

Changeset: 29d2485c1085
Author:    jjg
Date:      2008-06-25 14:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/29d2485c1085

6507179: javadoc -source 1.3 does not work with jdk6
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java
+ test/tools/javadoc/sourceOption/SourceOption.java
+ test/tools/javadoc/sourceOption/p/A.java



From tim.bell at sun.com  Thu Jun 26 06:11:07 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Thu, 26 Jun 2008 06:11:07 +0000
Subject: hg: jdk7/tl: 4 new changesets
Message-ID: <20080626061108.18CFB283D4@hg.openjdk.java.net>

Changeset: 8fc9d057bd12
Author:    xdono
Date:      2008-06-10 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/8fc9d057bd12

Added tag jdk7-b28 for changeset 56652b46f328

! .hgtags

Changeset: bf6ee1d9127e
Author:    martin
Date:      2008-06-10 16:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/bf6ee1d9127e

6710904: COMMON_BUILD_ARGUMENTS needs PREVIOUS_..._VERSION settings
Reviewed-by: ohair, tbell

! make/Defs-internal.gmk

Changeset: 31e08f70e88d
Author:    xdono
Date:      2008-06-12 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/31e08f70e88d

Merge


Changeset: 14c2c623d687
Author:    xdono
Date:      2008-06-20 08:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/14c2c623d687

Added tag jdk7-b29 for changeset 31e08f70e88d

! .hgtags



From tim.bell at sun.com  Thu Jun 26 06:12:13 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Thu, 26 Jun 2008 06:12:13 +0000
Subject: hg: jdk7/tl/corba: 4 new changesets
Message-ID: <20080626061216.AE036283D9@hg.openjdk.java.net>

Changeset: c4dd5b7198b0
Author:    xdono
Date:      2008-06-10 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/c4dd5b7198b0

Added tag jdk7-b28 for changeset 27509b7d21ed

! .hgtags

Changeset: 9eeb4966acae
Author:    ohair
Date:      2008-06-04 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/9eeb4966acae

6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles)
Summary: Changes to support building with SS12.
Reviewed-by: tbell

! make/common/shared/Compiler-sun.gmk
! make/jprt.config

Changeset: 8b71960f79ce
Author:    xdono
Date:      2008-06-12 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/8b71960f79ce

Merge


Changeset: 76600bc57421
Author:    xdono
Date:      2008-06-20 08:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/76600bc57421

Added tag jdk7-b29 for changeset 8b71960f79ce

! .hgtags



From tim.bell at sun.com  Thu Jun 26 06:14:25 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Thu, 26 Jun 2008 06:14:25 +0000
Subject: hg: jdk7/tl/hotspot: 45 new changesets
Message-ID: <20080626061548.8B5BA283DE@hg.openjdk.java.net>

Changeset: abe7181cbe8a
Author:    xdono
Date:      2008-06-10 10:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/abe7181cbe8a

Added tag jdk7-b28 for changeset c14dab40ed9b

! .hgtags

Changeset: c70a245cad3a
Author:    dcubed
Date:      2008-05-09 08:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c70a245cad3a

6670684: 4/5 SA command universe did not print out CMS space information
Summary: Forward port of Yumin's fix for 6670684 from HSX-11; Yumin verified the port was correct.
Reviewed-by: dcubed

! agent/make/Makefile
! agent/src/share/classes/sun/jvm/hotspot/HSDB.java
! agent/src/share/classes/sun/jvm/hotspot/SALauncherLoader.java
! agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/SAJDIClassLoader.java
+ agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java
! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
! agent/src/share/classes/sun/jvm/hotspot/memory/DefNewGeneration.java
+ agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java
+ agent/src/share/classes/sun/jvm/hotspot/memory/LinearAllocBlock.java
! agent/src/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java
! agent/src/share/classes/sun/jvm/hotspot/ui/CommandProcessorPanel.java
! agent/src/share/classes/sun/jvm/hotspot/ui/DebuggerConsolePanel.java
! agent/src/share/classes/sun/jvm/hotspot/ui/HighPrecisionJScrollBar.java
! agent/src/share/classes/sun/jvm/hotspot/ui/JFrameWrapper.java
! agent/src/share/classes/sun/jvm/hotspot/ui/treetable/JTreeTable.java
! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6ab92ec09f70
Author:    dcubed
Date:      2008-05-09 09:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6ab92ec09f70

Merge


Changeset: 09c2ba680204
Author:    kvn
Date:      2008-05-15 22:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09c2ba680204

6700102: c2 assertion "counter_changed,"failed dependencies, but counter didn't change")" with AggressiveOpts
Summary: Bytecode Escape Analyzer does not have the check for the case described in 6389127.
Reviewed-by: never

! src/share/vm/ci/bcEscapeAnalyzer.cpp

Changeset: 723be81c1212
Author:    kvn
Date:      2008-05-15 22:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/723be81c1212

6701887: JDK7 server VM in endless loop in Node::dominates
Summary: The method Node::dominates loops in the dead code which does not have a Region node.
Reviewed-by: jrose, never

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.cpp

Changeset: 5bba3366a9a2
Author:    dcubed
Date:      2008-05-16 13:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5bba3366a9a2

Merge

! agent/src/share/classes/sun/jvm/hotspot/HSDB.java
! src/share/vm/runtime/vmStructs.cpp

Changeset: a3e5744fafda
Author:    dcubed
Date:      2008-05-20 09:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a3e5744fafda

Merge


Changeset: a49545cab84a
Author:    ohair
Date:      2008-05-27 09:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a49545cab84a

6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles)
Summary: Allows for building with SS12, no longer requires SS11, warns if not SS11 for now. Once SS12 is validated and performance measurements look ok, SS12 will be the validated compiler.
Reviewed-by: sspitsyn, ikrylov

! make/jprt.config
! make/solaris/makefiles/debug.make
! make/solaris/makefiles/dtrace.make
! make/solaris/makefiles/fastdebug.make
! make/solaris/makefiles/jvmg.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/product.make
! make/solaris/makefiles/sparc.make
! make/solaris/makefiles/sparcWorks.make
! make/solaris/makefiles/sparcv9.make

Changeset: af059c49e677
Author:    ohair
Date:      2008-05-28 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/af059c49e677

6703308: Fix jprt.properties to allow for jdk6 and jdk7 builds
Summary: Allows for jprt submit -release option to select jdk version and proper build targets.
Reviewed-by: jcoomes

! make/jprt.properties

Changeset: 23a06eca8e83
Author:    jmasa
Date:      2008-05-27 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/23a06eca8e83

6706662: Remove workaround introduced in fix for 6624782
Summary: Remove workaround compiler options for instanceKlass.cpp and objArrayKlass.cpp.
Reviewed-by: ysr, jcoomes

! make/solaris/makefiles/amd64.make

Changeset: 27f13876aef3
Author:    iveresov
Date:      2008-05-30 03:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/27f13876aef3

Merge


Changeset: 8aa010f60e0f
Author:    rasbold
Date:      2008-05-20 06:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8aa010f60e0f

Merge


Changeset: 885ed790ecf0
Author:    kvn
Date:      2008-05-21 10:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/885ed790ecf0

6695810: null oop passed to encode_heap_oop_not_null
Summary: fix several problems in C2 related to Escape Analysis and Compressed Oops.
Reviewed-by: never, jrose

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
+ test/compiler/6689060/Test.java
+ test/compiler/6695810/Test.java

Changeset: c436414a719e
Author:    kvn
Date:      2008-05-21 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c436414a719e

6703890: Compressed Oops: add LoadNKlass node to generate narrow oops (32-bits) compare instructions
Summary: Add LoadNKlass and CMoveN nodes, use CmpN and ConN nodes to generate narrow oops compare instructions.
Reviewed-by: never, rasbold

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/relocInfo_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86_64.cpp
! src/cpu/x86/vm/assembler_x86_64.hpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/relocInfo_x86.hpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/includeDB_core
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 437d03ea40b1
Author:    kvn
Date:      2008-05-21 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/437d03ea40b1

6703888: Compressed Oops: use the 32-bits gap after klass in a object
Summary: Use the gap also for a narrow oop field and a boxing object value.
Reviewed-by: coleenp, never

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/gc_implementation/includeDB_gc_shared
! src/share/vm/oops/arrayOop.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/instanceOop.hpp

Changeset: aaa1137c5ef4
Author:    sgoldman
Date:      2008-05-28 12:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aaa1137c5ef4

6707485: bytecodeInterpreterWithChecks.xsl is malformed
Summary: xsl output tag not at top level
Reviewed-by: never, kvn, rasbold
Contributed-by: gnu_andrew at member.fsf.org

! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml
! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl

Changeset: feeb96a45707
Author:    coleenp
Date:      2008-05-28 21:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/feeb96a45707

6696264: assert("narrow oop can never be zero") for GCBasher & ParNewGC
Summary: decouple set_klass() with zeroing the gap when compressed.
Reviewed-by: kvn, ysr, jrose

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86_64.cpp
! src/cpu/x86/vm/assembler_x86_64.hpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_interface/collectedHeap.inline.hpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/memory/space.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp

Changeset: 7793bd37a336
Author:    kvn
Date:      2008-05-29 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7793bd37a336

6705887: Compressed Oops: generate x64 addressing and implicit null checks with narrow oops
Summary: Generate addresses and implicit null checks with narrow oops to avoid decoding.
Reviewed-by: jrose, never

! src/cpu/x86/vm/assembler_x86_32.hpp
! src/cpu/x86/vm/assembler_x86_64.hpp
! src/cpu/x86/vm/x86_64.ad
! src/os_cpu/linux_x86/vm/assembler_linux_x86_32.cpp
! src/os_cpu/linux_x86/vm/assembler_linux_x86_64.cpp
! src/os_cpu/solaris_x86/vm/assembler_solaris_x86_32.cpp
! src/os_cpu/solaris_x86/vm/assembler_solaris_x86_64.cpp
! src/os_cpu/windows_x86/vm/assembler_windows_x86_32.cpp
! src/os_cpu/windows_x86/vm/assembler_windows_x86_64.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.hpp

Changeset: 9148c65abefc
Author:    rasbold
Date:      2008-05-29 16:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9148c65abefc

6695049: (coll) Create an x86 intrinsic for Arrays.equals
Summary: Intrinsify java/util/Arrays.equals(char[], char[])
Reviewed-by: kvn, never

! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 02cc988a9fdc
Author:    rasbold
Date:      2008-05-30 07:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/02cc988a9fdc

Merge


Changeset: 0e13255adcb0
Author:    trims
Date:      2008-05-30 14:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e13255adcb0

Merge


Changeset: 3e4b7b5b2b4b
Author:    trims
Date:      2008-05-30 14:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3e4b7b5b2b4b

Merge


Changeset: 9077d695a1b0
Author:    trims
Date:      2008-05-30 14:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9077d695a1b0

6709213: Update Build number for HS13 b02
Summary: Bump up build number to 02
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 510f98a80563
Author:    rasbold
Date:      2008-06-03 13:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/510f98a80563

6709972: runThese failed with assert(false,"bad AD file")
Summary: guard AryEqNode construction with has_match_rule() test, set SpecialArraysEquals default off
Reviewed-by: kvn, never

! src/share/vm/opto/library_call.cpp
! src/share/vm/runtime/globals.hpp

Changeset: f2759c126e9d
Author:    rasbold
Date:      2008-06-03 15:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f2759c126e9d

Merge


Changeset: 6b648fefb395
Author:    kamg
Date:      2008-05-22 13:03 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6b648fefb395

6705523: Fix for 6695506 will violate spec when used in JDK6
Summary: Make max classfile version number dependent on JDK version
Reviewed-by: acorn, never

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/runtime/java.hpp

Changeset: 2a8ec427fbe1
Author:    kamg
Date:      2008-05-29 14:06 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2a8ec427fbe1

6706604: Copyright headers need to be changed to GPL.
Summary: Update the copyrights
Reviewed-by: ohair

! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml
! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl
! test/compiler/6659207/Test.java
! test/compiler/6661247/Test.java
! test/compiler/6663621/IVTest.java

Changeset: 6d172e3548cb
Author:    coleenp
Date:      2008-06-05 17:02 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6d172e3548cb

6695819: verify_oopx rax: broken oop in decode_heap_oop
Summary: Code in gen_subtype_check was encoding rax as an oop on a path where rax was not an oop.
Reviewed-by: never, kvn

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/x86/vm/assembler_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp

Changeset: 1f809e010142
Author:    kamg
Date:      2008-06-06 13:43 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1f809e010142

Merge

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/assembler_x86_64.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml
! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl

Changeset: b9ebd46331d2
Author:    kvn
Date:      2008-06-04 14:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b9ebd46331d2

6710654: SAJDI failures with Compressed Oops
Summary: Use correct offset for the java.lang.Class _klass field in SA.
Reviewed-by: jrose, never

! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java

Changeset: 823298b11afc
Author:    never
Date:      2008-06-04 21:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/823298b11afc

6709165: Tests hang or misbahve with HS 13.0-b01 on solaris-sparcv9
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/sparc.ad

Changeset: 44abbb0d4c18
Author:    kvn
Date:      2008-06-05 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/44abbb0d4c18

6709093: Compressed Oops: reduce size of compiled methods
Summary: exclude UEP size from nmethod code size and use narrow klass oop to load prototype header.
Reviewed-by: jrose, never

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86_64.cpp
! src/cpu/x86/vm/assembler_x86_64.hpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/opto/compile.cpp

Changeset: d4dbd9f91680
Author:    never
Date:      2008-06-05 15:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d4dbd9f91680

6711083: 64bit JVM crashes with Internal Error (type.cpp:763) - ShouldNotReachHere() with enabled COOPs
Summary: Add NarrowOop to various xmeet routines
Reviewed-by: kvn, sgoldman, jrose, rasbold

! src/share/vm/opto/type.cpp

Changeset: 65fe2bd88839
Author:    never
Date:      2008-06-05 21:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/65fe2bd88839

6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea
Reviewed-by: kvn, jrose, rasbold

! src/share/vm/opto/cfgnode.cpp

Changeset: 8759d37f2524
Author:    rasbold
Date:      2008-06-06 11:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8759d37f2524

6711701: disable compressed oops by default
Summary: comment out code that turns on compressed oops
Reviewed-by: never, phh

! src/share/vm/runtime/arguments.cpp

Changeset: cf1821c649d9
Author:    never
Date:      2008-06-06 14:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cf1821c649d9

Merge

! src/cpu/x86/vm/assembler_x86_64.cpp

Changeset: 790e66e5fbac
Author:    coleenp
Date:      2008-06-09 11:51 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/790e66e5fbac

6687581: Make CMS work with compressed oops
Summary: Make FreeChunk read markword instead of LSB in _klass pointer to indicate that it's a FreeChunk for compressed oops.
Reviewed-by: ysr, jmasa

! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Mark.java
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp
+ src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/oops/markOop.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: c0ecab83e6f3
Author:    never
Date:      2008-06-10 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c0ecab83e6f3

Merge

! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 0b27f3512f9e
Author:    jmasa
Date:      2008-06-04 13:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0b27f3512f9e

6629727: assertion in set_trap_state() in methodDataOop.hpp is too strong.
Summary: The assertion can failure due to race conditions.
Reviewed-by: never

! src/share/vm/oops/methodDataOop.hpp

Changeset: d1635bf93939
Author:    iveresov
Date:      2008-06-09 07:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d1635bf93939

6711930: NUMA allocator: ParOld can create a hole less than minimal object size in the lgrp chunk
Summary: The fix takes care of three issues that can create a hole less a minimal object in the lgrp chunk
Reviewed-by: ysr, apetrusenko

! src/share/vm/gc_implementation/shared/immutableSpace.cpp
! src/share/vm/gc_implementation/shared/immutableSpace.hpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp
! src/share/vm/gc_implementation/shared/mutableSpace.cpp
! src/share/vm/gc_implementation/shared/mutableSpace.hpp

Changeset: 3ad4bacbcdbe
Author:    jcoomes
Date:      2008-06-10 11:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3ad4bacbcdbe

Merge


Changeset: 6d13fcb3663f
Author:    kvn
Date:      2008-06-13 14:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6d13fcb3663f

6714404: Add UseStringCache switch to enable String caching under AggressiveOpts
Summary: Poke String.stringCacheEnabled during vm initialization
Reviewed-by: never

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp

Changeset: 44a553b2809d
Author:    kvn
Date:      2008-06-13 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/44a553b2809d

6714406: Node::dominates() does not always check for TOP
Summary: Add missed checks for TOP and missed checks for non-dominating cases
Reviewed-by: rasbold, jrose, never

! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.cpp

Changeset: 4f91c08b3e44
Author:    trims
Date:      2008-06-17 15:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4f91c08b3e44

Merge


Changeset: 93435819dba2
Author:    xdono
Date:      2008-06-20 08:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/93435819dba2

Added tag jdk7-b29 for changeset 4f91c08b3e44

! .hgtags



From tim.bell at sun.com  Thu Jun 26 06:17:56 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Thu, 26 Jun 2008 06:17:56 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20080626061759.C73F6283E3@hg.openjdk.java.net>

Changeset: 617ee8607cfd
Author:    xdono
Date:      2008-06-10 10:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/617ee8607cfd

Added tag jdk7-b28 for changeset b996318955c0

! .hgtags

Changeset: 4d8da2b3c124
Author:    xdono
Date:      2008-06-20 08:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/4d8da2b3c124

Added tag jdk7-b29 for changeset 617ee8607cfd

! .hgtags



From tim.bell at sun.com  Thu Jun 26 06:19:07 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Thu, 26 Jun 2008 06:19:07 +0000
Subject: hg: jdk7/tl/jaxws: 2 new changesets
Message-ID: <20080626061909.DCD1C283E8@hg.openjdk.java.net>

Changeset: 836c55713aba
Author:    xdono
Date:      2008-06-10 10:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/836c55713aba

Added tag jdk7-b28 for changeset eefcd5204500

! .hgtags

Changeset: 2c23d2441366
Author:    xdono
Date:      2008-06-20 08:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/2c23d2441366

Added tag jdk7-b29 for changeset 836c55713aba

! .hgtags



From Ulf.Zibis at CoSoCo.de  Thu Jun 26 10:17:17 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 26 Jun 2008 12:17:17 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <4862088D.3010504@CoSoCo.de>
References: <48600F67.3040201@CoSoCo.de>	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>	<48611D8A.4010304@redhat.com>
	<4862088D.3010504@CoSoCo.de>
Message-ID: <48636CAD.5030709@CoSoCo.de>

Also I've found out, that MASK1 is superfluous, because on implicit 
converting from char to int all upper bits are automaticlly 0. So we can 
code instead:

           char c = c2bMap.charAt(c2bMapIndex[current >> SHIFT] + 
(current & MASK));

           char c = (current < '\u0100') ? c2bMap.charAt(current) :
               c2bMap.charAt(c2bMapIndex[current >> SHIFT] + (current & 
MASK));


Am 25.06.2008 10:57, Ulf Zibis schrieb:
> Hi David,
>
> can you show an example using a 'switch' statement which is shorter or 
> faster than:
>
>            char c = c2bMap.charAt(c2bMapIndex[(current & MASK1) >> 
> SHIFT] + (current & MASK2));
>
> or more faster for special mappings:
>
>            char c = (current < '\u0100') ? c2bMap.charAt(current) :
>                c2bMap.charAt(c2bMapIndex[(current & MASK1) >> SHIFT] + 
> (current & MASK2));
>
> Regards,
> Ulf
>



From forax at univ-mlv.fr  Thu Jun 26 10:31:46 2008
From: forax at univ-mlv.fr (=?ISO-8859-15?Q?R=E9mi_Forax?=)
Date: Thu, 26 Jun 2008 12:31:46 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48636CAD.5030709@CoSoCo.de>
References: <48600F67.3040201@CoSoCo.de>	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>	<48611D8A.4010304@redhat.com>	<4862088D.3010504@CoSoCo.de>
	<48636CAD.5030709@CoSoCo.de>
Message-ID: <48637012.2060000@univ-mlv.fr>

Ulf Zibis a ?crit :
> Also I've found out, that MASK1 is superfluous, because on implicit 
> converting from char to int all upper bits are automaticlly 0. 
No, all upper bits are the value of the sign bit, you can remove the 
mask only if
you use unsigned values.
> So we can code instead:
>
>           char c = c2bMap.charAt(c2bMapIndex[current >> SHIFT] + 
> (current & MASK));
>
>           char c = (current < '\u0100') ? c2bMap.charAt(current) :
>               c2bMap.charAt(c2bMapIndex[current >> SHIFT] + (current & 
> MASK));
R?mi


From Ulf.Zibis at CoSoCo.de  Thu Jun 26 16:26:57 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 26 Jun 2008 18:26:57 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48637012.2060000@univ-mlv.fr>
References: <48600F67.3040201@CoSoCo.de>	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>	<48611D8A.4010304@redhat.com>	<4862088D.3010504@CoSoCo.de>	<48636CAD.5030709@CoSoCo.de>
	<48637012.2060000@univ-mlv.fr>
Message-ID: <4863C351.2000306@CoSoCo.de>

char's ARE ALWAYS unsigned. :-)


Am 26.06.2008 12:31, R?mi Forax schrieb:
> Ulf Zibis a ?crit :
>> Also I've found out, that MASK1 is superfluous, because on implicit 
>> converting from char to int all upper bits are automaticlly 0. 
> No, all upper bits are the value of the sign bit, you can remove the 
> mask only if
> you use unsigned values.
>> So we can code instead:
>>
>>           char c = c2bMap.charAt(c2bMapIndex[current >> SHIFT] + 
>> (current & MASK));
>>
>>           char c = (current < '\u0100') ? c2bMap.charAt(current) :
>>               c2bMap.charAt(c2bMapIndex[current >> SHIFT] + (current 
>> & MASK));
> R?mi
>
>
>



From forax at univ-mlv.fr  Thu Jun 26 18:58:40 2008
From: forax at univ-mlv.fr (=?ISO-8859-15?Q?R=E9mi_Forax?=)
Date: Thu, 26 Jun 2008 20:58:40 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <4863C351.2000306@CoSoCo.de>
References: <48600F67.3040201@CoSoCo.de>	<48602CE8.6060501@sun.com>	<48611BEE.7000508@CoSoCo.de>	<48611D8A.4010304@redhat.com>	<4862088D.3010504@CoSoCo.de>	<48636CAD.5030709@CoSoCo.de>
	<48637012.2060000@univ-mlv.fr> <4863C351.2000306@CoSoCo.de>
Message-ID: <4863E6E0.5060202@univ-mlv.fr>

Ulf Zibis a ?crit :
> char's ARE ALWAYS unsigned. :-)
my apologies :)
ok, read a mail twice before hitting the reply button :)

R?mi
>
>
> Am 26.06.2008 12:31, R?mi Forax schrieb:
>> Ulf Zibis a ?crit :
>>> Also I've found out, that MASK1 is superfluous, because on implicit 
>>> converting from char to int all upper bits are automaticlly 0. 
>> No, all upper bits are the value of the sign bit, you can remove the 
>> mask only if
>> you use unsigned values.
>>> So we can code instead:
>>>
>>>           char c = c2bMap.charAt(c2bMapIndex[current >> SHIFT] + 
>>> (current & MASK));
>>>
>>>           char c = (current < '\u0100') ? c2bMap.charAt(current) :
>>>               c2bMap.charAt(c2bMapIndex[current >> SHIFT] + (current 
>>> & MASK));
>> R?mi
>>
>>
>>



From tim.bell at sun.com  Fri Jun 27 01:33:52 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 27 Jun 2008 01:33:52 +0000
Subject: hg: jdk7/tl/jdk: 32 new changesets
Message-ID: <20080627014008.8C9832855E@hg.openjdk.java.net>

Changeset: 45e53cb21dad
Author:    xdono
Date:      2008-06-10 10:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45e53cb21dad

Added tag jdk7-b28 for changeset 02e4c5348592

! .hgtags

Changeset: 5a6c318329f2
Author:    son
Date:      2008-05-15 11:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5a6c318329f2

6644301: lightweight components can repaint outside request bounds
Summary: repaint() needs to adjust width and height if it receives negative x or y.
Reviewed-by: art

! src/share/classes/java/awt/Component.java

Changeset: abb08b9028f4
Author:    yan
Date:      2008-05-16 04:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abb08b9028f4

Merge

! src/share/classes/java/awt/Component.java

Changeset: 5e39937cf4ce
Author:    yan
Date:      2008-05-21 10:28 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e39937cf4ce

6253172: Some key characters on none US keyboard cannot be typed since JDK 1.4
Summary: Windows-only problem fixed by applying 4737679/4623376 fix to navigation keys only.
Reviewed-by: son

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Component.h

Changeset: addb8a23ad24
Author:    yan
Date:      2008-05-23 02:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/addb8a23ad24

Merge


Changeset: d8f9efc21477
Author:    dav
Date:      2008-05-29 13:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8f9efc21477

6691328: DragSourceContext returns unexpected cursor
Summary: make the code to be executed if other options don't suit
Reviewed-by: dcherepanov

! src/share/classes/java/awt/dnd/DragSourceContext.java

Changeset: bb99fb855bdc
Author:    yan
Date:      2008-05-30 03:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bb99fb855bdc

Merge


Changeset: 9ab7e41b205b
Author:    yan
Date:      2008-06-09 06:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ab7e41b205b

Merge

- src/solaris/classes/sun/java2d/SurfaceManagerFactory.java
- src/windows/classes/sun/java2d/SurfaceManagerFactory.java
- test/javax/management/Introspector/LegacyIntrospectorTest.java

Changeset: 906a396bff74
Author:    yan
Date:      2008-06-10 13:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/906a396bff74

Merge


Changeset: b6c42daa86d5
Author:    tbell
Date:      2008-06-12 13:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b6c42daa86d5

Merge


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

Merge


Changeset: f9467b4496dc
Author:    ohair
Date:      2008-06-04 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9467b4496dc

6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles)
Summary: Changes to support building with SS12.
Reviewed-by: tbell

! make/common/Defs-solaris.gmk
! make/common/shared/Compiler-sun.gmk
! make/jdk_generic_profile.sh
! make/jprt.config

Changeset: a5c908deb70f
Author:    martin
Date:      2008-06-10 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5c908deb70f

6710907: vestigial MOTIF references from Makefiles
Reviewed-by: ohair, tbell

! make/sun/jawt/Makefile

Changeset: a0d703b249f0
Author:    martin
Date:      2008-06-10 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a0d703b249f0

6704165: JDK_DEBUG_IMAGE_DIR used in jdk/make/common/Release.gmk but not defined
Reviewed-by: ohair, tbell

! make/common/Release.gmk

Changeset: e21f4266466c
Author:    xdono
Date:      2008-06-12 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e21f4266466c

Merge

- src/solaris/classes/sun/java2d/SurfaceManagerFactory.java
- src/windows/classes/sun/java2d/SurfaceManagerFactory.java
- test/javax/management/Introspector/LegacyIntrospectorTest.java

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

Merge

! make/common/Release.gmk

Changeset: 584f643321b7
Author:    tbell
Date:      2008-06-16 22:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/584f643321b7

Merge


Changeset: 0a5b87833562
Author:    xdono
Date:      2008-06-20 08:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0a5b87833562

Added tag jdk7-b29 for changeset e21f4266466c

! .hgtags

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

Merge


Changeset: e733eea7d585
Author:    peterz
Date:      2008-05-22 15:06 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e733eea7d585

6606443: Infinite loop in FlowView.layout when using HTML tables in JEditorPane
Summary: FlowStrategy.damageStart now tracks position changes
Reviewed-by: gsm

! src/share/classes/javax/swing/text/FlowView.java

Changeset: e0951cd6e7b9
Author:    malenkov
Date:      2008-05-23 20:14 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0951cd6e7b9

6668273: Example given in java.beans.EventHandler shows incorrect order of parameters
Summary: Very simple misprint
Reviewed-by: peterz, loneid

! src/share/classes/java/beans/EventHandler.java

Changeset: 5e0172d58a1c
Author:    mlapshin
Date:      2008-05-26 17:58 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e0172d58a1c

6694823: A popup menu can be partially hidden under the task bar in applets
Summary: In applets popup menu is shifted above the task bar
Reviewed-by: peterz

! src/share/classes/javax/swing/JPopupMenu.java
! src/share/classes/javax/swing/PopupFactory.java
+ test/javax/swing/JPopupMenu/6694823/bug6694823.java

Changeset: be7d7a297c3d
Author:    rupashka
Date:      2008-06-02 19:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be7d7a297c3d

6709530: There are unnecessary code in slider classes, such as in JSlider and SliderUIs
Summary: Removed unnecessary code like unused variables, castings, imports etc
Reviewed-by: peterz

! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java

Changeset: af37dad9022d
Author:    rupashka
Date:      2008-06-03 18:00 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/af37dad9022d

4987336: JSlider doesn't show label's animated icon
Summary: JSlider registers as an image observer of label's icon
Reviewed-by: alexp

! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
+ test/javax/swing/JSlider/4987336/box.gif
+ test/javax/swing/JSlider/4987336/bug4987336.html
+ test/javax/swing/JSlider/4987336/bug4987336.java
+ test/javax/swing/JSlider/4987336/cupanim.gif

Changeset: f36f0f189064
Author:    rupashka
Date:      2008-06-04 18:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f36f0f189064

6571802: 'Shared Documents' listed in-between C,D drives in the JFileChooser, does not match with native
Summary: now sun.awt.shell.ShellFolder#sort uses system sorting instead of alphabetical
Reviewed-by: loneid, peterz

! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java
! src/share/classes/sun/awt/shell/ShellFolder.java
! src/share/classes/sun/awt/shell/ShellFolderManager.java
! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java

Changeset: e26917dd7b7c
Author:    rupashka
Date:      2008-06-05 13:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e26917dd7b7c

6688110: JSlider has incorrect javadoc for the setValueIsAdjusting method
Summary: The sentence about ChangeEvents generation was removed
Reviewed-by: peterz

! src/share/classes/javax/swing/JSlider.java

Changeset: 5083f5c15103
Author:    rupashka
Date:      2008-06-06 13:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5083f5c15103

5035693: "Open" button should be a default one in JFileChooser under Windows XP LAF
Summary: The "Open" button was made default button of FileChooser dialog windows
Reviewed-by: loneid, peterz

! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/plaf/FileChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java

Changeset: ec9c8e73ae53
Author:    malenkov
Date:      2008-06-18 19:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec9c8e73ae53

6708550: LTP: XMLEncoder does not encode instances of the File class
Reviewed-by: peterz, loneid

! src/share/classes/java/io/File.java
+ test/java/beans/XMLEncoder/java_io_File.java

Changeset: 3570562846ef
Author:    lana
Date:      2008-06-18 13:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3570562846ef

Merge


Changeset: fbb75a5c25ff
Author:    lana
Date:      2008-06-25 08:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fbb75a5c25ff

Merge


Changeset: 0e1d82bbcb2c
Author:    tbell
Date:      2008-06-25 16:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e1d82bbcb2c

Merge


Changeset: 4edf07b01e29
Author:    tbell
Date:      2008-06-25 23:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4edf07b01e29

Merge




From tim.bell at sun.com  Fri Jun 27 01:41:19 2008
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 27 Jun 2008 01:41:19 +0000
Subject: hg: jdk7/tl/langtools: 7 new changesets
Message-ID: <20080627014130.E424228563@hg.openjdk.java.net>

Changeset: dec081837b01
Author:    xdono
Date:      2008-06-10 10:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dec081837b01

Added tag jdk7-b28 for changeset 4ef4bd318569

! .hgtags

Changeset: 5ee49b24d378
Author:    tbell
Date:      2008-06-12 13:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5ee49b24d378

Merge


Changeset: 700b17652ef6
Author:    tbell
Date:      2008-06-16 22:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/700b17652ef6

Merge

- src/share/classes/com/sun/tools/javac/util/BaseFileObject.java
- src/share/classes/com/sun/tools/javac/util/JavacFileManager.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

Changeset: 3cb4fb6e0720
Author:    jjg
Date:      2008-06-18 16:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3cb4fb6e0720

6715767: javap on java.lang.ClassLoader crashes
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/share/classes/com/sun/tools/javap/ClassWriter.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
+ test/tools/javap/T6715767.java

Changeset: c3f2b8992300
Author:    xdono
Date:      2008-06-20 08:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c3f2b8992300

Added tag jdk7-b29 for changeset dec081837b01

! .hgtags

Changeset: 0c66311205c2
Author:    tbell
Date:      2008-06-20 16:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0c66311205c2

Merge


Changeset: a0de486e86a1
Author:    tbell
Date:      2008-06-25 23:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a0de486e86a1

Merge

- src/share/classes/com/sun/tools/javac/file/ZipFileIndexEntry.java



From xueming.shen at sun.com  Fri Jun 27 16:14:14 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 27 Jun 2008 16:14:14 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20080627161437.E0130285DF@hg.openjdk.java.net>

Changeset: 496cb56af58d
Author:    sherman
Date:      2008-06-27 08:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/496cb56af58d

6645197: (so) Timed read with socket adaptor throws ClosedSelectorException if temporary selector GC'ed
Summary: Temporary selector for timeout is not protected from possilbe GC when used first time
Reviewed-by: alanb

! src/share/classes/sun/nio/ch/Util.java

Changeset: d20c51803e8b
Author:    sherman
Date:      2008-06-27 09:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d20c51803e8b

Merge




From xueming.shen at sun.com  Fri Jun 27 19:21:30 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 27 Jun 2008 19:21:30 +0000
Subject: hg: jdk7/tl/jdk: 6541631: (fc)
	java/nio/channels/Filechannel/LongTransferTest.java should
	clean up after itself
Message-ID: <20080627192142.593EA28614@hg.openjdk.java.net>

Changeset: 267da79ad5d8
Author:    sherman
Date:      2008-06-27 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/267da79ad5d8

6541631: (fc) java/nio/channels/Filechannel/LongTransferTest.java should clean up after itself
Summary: Should close the channel before delete the file
Reviewed-by: alanb

! test/java/nio/channels/FileChannel/LongTransferTest.java



From martinrb at google.com  Sat Jun 28 02:39:59 2008
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Jun 2008 19:39:59 -0700
Subject: Peculiar fruits in the JDK
In-Reply-To: <48611D8A.4010304@redhat.com>
References: <48600F67.3040201@CoSoCo.de> <48602CE8.6060501@sun.com>
	<48611BEE.7000508@CoSoCo.de> <48611D8A.4010304@redhat.com>
Message-ID: <1ccfd1c10806271939o7f5dae1clfaa2b4d8da3200ea@mail.gmail.com>

Optimizing the decoder lookup tables is equivalent to
the C switch statement optimization problem.

Determined humans are likely to do better than javac at producing bytecode
that will JIT well because
- javac is not designed to be an optimizing compiler.
  javac will generate complicated code that the hotspot optimizer
  may have a hard time with.
- humans have special knowledge about the frequency of particular characters.
  E.g. they may know that the euro character is relatively rare.

I've considered (but not seriously) writing a special compiler
that takes as input the conversion tables and the empirical
frequency of characters in text in various encodings
and outputs a combination of table lookups and nested ifs that
will perform very well in practice.

Martin

On Tue, Jun 24, 2008 at 9:15 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> On 06/24/2008 11:08 AM, Ulf Zibis wrote:
>>
>> I many cases I also could shorten the encoding mappings.
>>
>> Example:
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/src/sun/nio/cs/ext/IBM870.java?rev=223&view=markup
>
> Would a 'switch' statement not be more speed- and space-efficient for this
> type of lookup task?
>
> - DML
>


From Ulf.Zibis at CoSoCo.de  Sat Jun 28 03:18:33 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Sat, 28 Jun 2008 05:18:33 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48651AE6.5070806@sun.com>
References: <48600F67.3040201@CoSoCo.de> <48602CE8.6060501@sun.com>
	<4860C64F.8030106@CoSoCo.de> <4861199E.4030706@sun.com>
	<486518D5.8010804@CoSoCo.de> <48651AE6.5070806@sun.com>
Message-ID: <4865AD89.6040000@CoSoCo.de>

Very much thanks.  :-)

New calculator for playing around with map page sizes (corrected link):
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/test/sun/nio/cs/MapCalculator.java?rev=&view=log

-Ulf


Am 27.06.2008 18:52, Xueming Shen schrieb:
> Ulf, my apology for the belated response, I have been kept buzy in something else
> the last couple days and don't have time to dig into my "old" workspace to pick the
> files. Will do it next week or so...
>
> But in fact the first piece, or say the most import block, of my idea/plan has been
> already putback intot the JDK7 workspace with my fix for Japanese JIS0213 work.
> The JIS0213 charset is implemented by using the "new idea", instead of embedding
> the c2b/b2c mapping table into huge static String object into the class file, the impl
> generates a binary mapping data file from a text based b2c mapping file during the
> build-time, then initialize the b2c and c2bIndex/Table from this data file during its
> init-time...
>
> take a look at the newly added sun.nio.cs.CharsetMapping.java and the stuff
> under make/tool/Charsetmap...
>
> I'm in hurry, send you more later...
>
> sherman
>
>
> Ulf Zibis wrote:
>> Hi Sherman,
>>
>> I am waiting for an answer from you. I myself only answered to the 
>> list 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-June/thread.html#511 
>>
>>
>> Don't you read the list regularly?
>>
>> Regards,
>> Ulf
>>
>>
>> Am 24.06.2008 17:58, Xueming Shen schrieb:
>>> Ulf Zibis wrote:
>>>>>
>>>>> 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.
>>>> How did you eliminate the dependencies? E.g.: 
>>>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/solaris/classes/sun/awt/motif/X11JIS0201.java?rev=201&view=markup 
>>>>
>>>> I see, my work on sun.io was for the scrapheap. :-(
>>>>
>>>
>>> If you have the source code for 5.x, you would find those X11 
>>> converters were sun.io based, I rewrote
>>> all of them in JDK6 and modified all the places in awt/font to use 
>>> the java.nio.charset interface..
>>> fortunately I was the original font/motif guy who wrote them in the 
>>> first place, so not too difficult:-)
>>>
>>> I did the same thing for all sun.io.XYZConverter usages to use the 
>>> java.nio.charset interface in J2SE
>>> workspace then actually removed the J2SE in JDK6 before beta, but 
>>> had to put them back because
>>> BIG licensee insisted they have their JDBC bridge drivers still 
>>> using sun.io and don't want to migrate.
>>>
>>> Yes, don't try to improve anything in sun.io package, our currently 
>>> policy is to keep it there but don't
>>> do anything. That said, in order to rewrite the sun.nio.cs/ext 
>>> package we might have to touch this
>>> package again, one of the ideas is to write a adaptor class to 
>>> bridge the sun.io.Converter to sun.nio.cs
>>> implementation, so we can eliminate all those CharToByte/ByteToChar 
>>> implementation, I have a
>>> draft implementation in one of my ws, but have not fully tested, 
>>> will dig it out later.
>>>
>>>> very much thank for appreciating my work,
>>>>
>>>
>>> Really appreciate your work. The charset implementation work 
>>> currently is not my priority
>>> simply because I lost my main codereviewer Martin (though he is 
>>> still interested in this area
>>> after moving on to Google, I'm not so sure how much he can continue 
>>> spend on this), so it
>>> would be easy to work on my other interesting areas. But seems like 
>>> we now have a contributor
>>> who is very experienced and interested in charset:-)  we should give 
>>> it a try. I will send
>>> you some classes I was working on to share my thoughts/ideas later. 
>>> But I would "warn" you
>>> that all the changes might not make into JDK7, there are sill some 
>>> debates internally that whether
>>> or not we should spend our resource (very limited) on something that 
>>> works (don't break it if it
>>> works:-))
>>>
>>> Sherman
>>>
>>>
>>>
>>>
>>
>
>
>





From Harsha.Godugu at Sun.COM  Mon Jun 23 19:43:28 2008
From: Harsha.Godugu at Sun.COM (Harsha Godugu)
Date: Mon, 23 Jun 2008 12:43:28 -0700
Subject: java.util.zip throws-  oversubscribed dynamic bit lengths tree
In-Reply-To: <485D32A1.7000308@sun.com>
References: <485C44BF.8030004@sun.com> <485D32A1.7000308@sun.com>
Message-ID: <485FFCE0.3000601@sun.com>

Joseph D. Darcy wrote:
>> Any idea who can help me with this exception..
>
> If there isn't anything sensitive in your inquiry, you could send 
> email to core-libs-dev at openjdk.java.net.
Thanks Joe. 


Could  anybody help me why we get into the following issue on/off.  This 
(exception) happens when we try to read a large file during the build 
(of Glassfish v3).
This problem is very difficult to reproduce and random in nature.  (this 
is with both 1.5_xx and 1.6xx JDK).

I will file bug against JDK after any insight here.

thanks,
Harsha
>
> -Joe
>
>> thanks,
>> Harsha
>>
>>
>> Problem: When reading large jar files programatically, we get the 
>> following exception.
>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error 
>> assembling JAR
>>    at 
>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183) 
>>
>>    at 
>> com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193) 
>>
>>    at 
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 
>>
>>    at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 
>>
>>    ... 16 more
>> Caused by: java.util.zip.ZipException: oversubscribed dynamic bit 
>> lengths tree
>>    at 
>> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
>>    at java.io.DataInputStream.readFully(DataInputStream.java:176)
>>    at java.util.jar.JarFile.getBytes(JarFile.java:364)
>>    at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157)
>>    at java.util.jar.JarFile.getManifest(JarFile.java:145)
>>    at 
>> com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172) 
>>
>>    at 
>> com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126) 
>>
>>    at 
>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168) 
>>
>



From Ulf.Zibis at CoSoCo.de  Mon Jun 30 17:07:11 2008
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 30 Jun 2008 19:07:11 +0200
Subject: Peculiar fruits in the JDK
In-Reply-To: <48651AE6.5070806@sun.com>
References: <48600F67.3040201@CoSoCo.de> <48602CE8.6060501@sun.com>
	<4860C64F.8030106@CoSoCo.de> <4861199E.4030706@sun.com>
	<486518D5.8010804@CoSoCo.de> <48651AE6.5070806@sun.com>
Message-ID: <486912BF.4040100@CoSoCo.de>

Hi Sherman,

I had a closer look to your code. Thanks for your hints. Looks interesting.
Also I see some chances for optimization, but more exactly ...later.

Can you tell me something about memory consuming in the current Sun JVM?
How much bytes do byte arrays consume per byte?
... or in other words: is it less memory-consuming using byte arrays 
than int arrays, if these are large?
Same question about short and char arrays?

Thanks for a short answer.

-Ulf



Am 27.06.2008 18:52, Xueming Shen schrieb:
> Ulf, my apology for the belated response, I have been kept buzy in 
> something else
> the last couple days and don't have time to dig into my "old" 
> workspace to pick the
> files. Will do it next week or so...
>
> But in fact the first piece, or say the most import block, of my 
> idea/plan has been
> already putback intot the JDK7 workspace with my fix for Japanese 
> JIS0213 work.
> The JIS0213 charset is implemented by using the "new idea", instead of 
> embedding
> the c2b/b2c mapping table into huge static String object into the 
> class file, the impl
> generates a binary mapping data file from a text based b2c mapping 
> file during the
> build-time, then initialize the b2c and c2bIndex/Table from this data 
> file during its
> init-time...
>
> take a look at the newly added sun.nio.cs.CharsetMapping.java and the 
> stuff
> under make/tool/Charsetmap...
>
> I'm in hurry, send you more later...
>
> sherman
>
>
> Ulf Zibis wrote:
>> Hi Sherman,
>>
>> I am waiting for an answer from you. I myself only answered to the 
>> list 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-June/thread.html#511 
>>
>>
>> Don't you read the list regularly?
>>
>> Regards,
>> Ulf
>>
>>
>> Am 24.06.2008 17:58, Xueming Shen schrieb:
>>> Ulf Zibis wrote:
>>>>>
>>>>> 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.
>>>> How did you eliminate the dependencies? E.g.: 
>>>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/solaris/classes/sun/awt/motif/X11JIS0201.java?rev=201&view=markup 
>>>>
>>>> I see, my work on sun.io was for the scrapheap. :-(
>>>>
>>>
>>> If you have the source code for 5.x, you would find those X11 
>>> converters were sun.io based, I rewrote
>>> all of them in JDK6 and modified all the places in awt/font to use 
>>> the java.nio.charset interface..
>>> fortunately I was the original font/motif guy who wrote them in the 
>>> first place, so not too difficult:-)
>>>
>>> I did the same thing for all sun.io.XYZConverter usages to use the 
>>> java.nio.charset interface in J2SE
>>> workspace then actually removed the J2SE in JDK6 before beta, but 
>>> had to put them back because
>>> BIG licensee insisted they have their JDBC bridge drivers still 
>>> using sun.io and don't want to migrate.
>>>
>>> Yes, don't try to improve anything in sun.io package, our currently 
>>> policy is to keep it there but don't
>>> do anything. That said, in order to rewrite the sun.nio.cs/ext 
>>> package we might have to touch this
>>> package again, one of the ideas is to write a adaptor class to 
>>> bridge the sun.io.Converter to sun.nio.cs
>>> implementation, so we can eliminate all those CharToByte/ByteToChar 
>>> implementation, I have a
>>> draft implementation in one of my ws, but have not fully tested, 
>>> will dig it out later.
>>>
>>>> very much thank for appreciating my work,
>>>>
>>>
>>> Really appreciate your work. The charset implementation work 
>>> currently is not my priority
>>> simply because I lost my main codereviewer Martin (though he is 
>>> still interested in this area
>>> after moving on to Google, I'm not so sure how much he can continue 
>>> spend on this), so it
>>> would be easy to work on my other interesting areas. But seems like 
>>> we now have a contributor
>>> who is very experienced and interested in charset:-)  we should give 
>>> it a try. I will send
>>> you some classes I was working on to share my thoughts/ideas later. 
>>> But I would "warn" you
>>> that all the changes might not make into JDK7, there are sill some 
>>> debates internally that whether
>>> or not we should spend our resource (very limited) on something that 
>>> works (don't break it if it
>>> works:-))
>>>
>>> Sherman
>>>
>>>
>>>
>>>
>>
>
>
>



From bradford.wetmore at sun.com  Mon Jun 30 19:36:55 2008
From: bradford.wetmore at sun.com (bradford.wetmore at sun.com)
Date: Mon, 30 Jun 2008 19:36:55 +0000
Subject: hg: jdk7/tl/jdk: 6 new changesets
Message-ID: <20080630193806.44FA6286F4@hg.openjdk.java.net>

Changeset: 2f21c9f8136a
Author:    mullan
Date:      2008-06-17 10:34 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2f21c9f8136a

6673277: Thread unsafe lazy initialization code in sun.security.provider.certpath.*Checker classes
Summary: make supportedExts variable non-static
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java
! src/share/classes/sun/security/provider/certpath/KeyChecker.java
! src/share/classes/sun/security/provider/certpath/PolicyChecker.java

Changeset: bc5159dc2a81
Author:    mullan
Date:      2008-06-17 10:53 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc5159dc2a81

Merge


Changeset: 4be8dfa19e27
Author:    mullan
Date:      2008-06-19 14:20 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4be8dfa19e27

6714842: CertPathBuilder returns incorrect CertPath for BasicConstraints in builderParams
Summary: Do not consider CA target certificates if selector.getBasicConstraints() == -2
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
+ test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java
+ test/java/security/cert/CertPathBuilder/targetConstraints/anchor.cer
+ test/java/security/cert/CertPathBuilder/targetConstraints/ca.cer
+ test/java/security/cert/CertPathBuilder/targetConstraints/ee.cer

Changeset: 3a7345910333
Author:    weijun
Date:      2008-06-20 12:05 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3a7345910333

6716534: Krb5LoginModule has not cleaned temp info between authentication attempts
Reviewed-by: valeriep

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java

Changeset: 9cf5011bfe38
Author:    wetmore
Date:      2008-06-26 00:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cf5011bfe38

Merge


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

Merge




From David.Bristor at Sun.COM  Mon Jun 30 20:10:52 2008
From: David.Bristor at Sun.COM (Dave Bristor)
Date: Mon, 30 Jun 2008 13:10:52 -0700
Subject: java.util.zip throws-  oversubscribed dynamic bit lengths tree
In-Reply-To: <485FFCE0.3000601@sun.com>
References: <485C44BF.8030004@sun.com> <485D32A1.7000308@sun.com>
	<485FFCE0.3000601@sun.com>
Message-ID: <48693DCC.4080405@sun.com>

Hi Harsha,

Do you have a reproducible testcase?  This appeared years before my time, see 
4188883, "java.util.zip.ZipException: oversubscribed dynamic bit lengths 
tree", and was closed with the note "Irreproducible - probably fixed some time 
ago."

Sahoo has filed 6713913, "Fatal errors during jar file processing", but I'm 
unable to reproduce the problem.

Thanks,
	Dave

Harsha Godugu wrote:
> Joseph D. Darcy wrote:
>>> Any idea who can help me with this exception..
>>
>> If there isn't anything sensitive in your inquiry, you could send 
>> email to core-libs-dev at openjdk.java.net.
> Thanks Joe.
> 
> Could  anybody help me why we get into the following issue on/off.  This 
> (exception) happens when we try to read a large file during the build 
> (of Glassfish v3).
> This problem is very difficult to reproduce and random in nature.  (this 
> is with both 1.5_xx and 1.6xx JDK).
> 
> I will file bug against JDK after any insight here.
> 
> thanks,
> Harsha
>>
>> -Joe
>>
>>> thanks,
>>> Harsha
>>>
>>>
>>> Problem: When reading large jar files programatically, we get the 
>>> following exception.
>>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error 
>>> assembling JAR
>>>    at 
>>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183) 
>>>
>>>    at 
>>> com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193) 
>>>
>>>    at 
>>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 
>>>
>>>    at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 
>>>
>>>    ... 16 more
>>> Caused by: java.util.zip.ZipException: oversubscribed dynamic bit 
>>> lengths tree
>>>    at 
>>> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
>>>    at java.io.DataInputStream.readFully(DataInputStream.java:176)
>>>    at java.util.jar.JarFile.getBytes(JarFile.java:364)
>>>    at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157)
>>>    at java.util.jar.JarFile.getManifest(JarFile.java:145)
>>>    at 
>>> com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172) 
>>>
>>>    at 
>>> com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126) 
>>>
>>>    at 
>>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168) 
>>>
>>
> 


From xueming.shen at sun.com  Mon Jun 30 21:14:01 2008
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Mon, 30 Jun 2008 21:14:01 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20080630211425.3484E28703@hg.openjdk.java.net>

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

6675856: Open charset tests
Summary: Moved non-confidiential test cased from closed repo to open repo
Reviewed-by: martin

+ test/sun/nio/cs/BufferUnderflowEUCTWTest.java
+ test/sun/nio/cs/CheckCaseInsensitiveEncAliases.java
+ test/sun/nio/cs/CheckHistoricalNames.java
+ test/sun/nio/cs/ConvertSingle.java
+ test/sun/nio/cs/Decode.java
+ test/sun/nio/cs/DecoderOverflow.java
+ test/sun/nio/cs/EUCJPUnderflowDecodeTest.java
+ test/sun/nio/cs/EucJpLinux0212.java
+ test/sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java
+ test/sun/nio/cs/EuroConverter.java
+ test/sun/nio/cs/FindASCIICodingBugs.java
+ test/sun/nio/cs/FindASCIIRangeCodingBugs.java
+ test/sun/nio/cs/FindCanEncodeBugs.java
+ test/sun/nio/cs/FindDecoderBugs.java
+ test/sun/nio/cs/FindEncoderBugs.java
+ test/sun/nio/cs/FindOneCharEncoderBugs.java
+ test/sun/nio/cs/HWKatakanaMS932EncodeTest.java
+ test/sun/nio/cs/ISCIITest.java
+ test/sun/nio/cs/ISO2022JP.trailEsc
+ test/sun/nio/cs/ISO8859x.java
+ test/sun/nio/cs/JISAutoDetectTest.java
+ test/sun/nio/cs/LatinCharReplacementTWTest.java
+ test/sun/nio/cs/LeftOverSurrogate.java
+ test/sun/nio/cs/MalformedSurrogates.java
+ test/sun/nio/cs/NIOJISAutoDetectTest.java
+ test/sun/nio/cs/ReadZero.java
+ test/sun/nio/cs/SJISCanEncode.java
+ test/sun/nio/cs/StreamEncoderClose.java
+ test/sun/nio/cs/SurrogateGB18030Test.java
+ test/sun/nio/cs/SurrogateTestEUCTW.java
+ test/sun/nio/cs/SurrogateTestEUCTW.plane15.surrogates
+ test/sun/nio/cs/SurrogateTestEUCTW.plane3.surrogates
+ test/sun/nio/cs/SurrogateTestEUCTW.plane4.surrogates
+ test/sun/nio/cs/SurrogateTestEUCTW.plane5.surrogates
+ test/sun/nio/cs/SurrogateTestEUCTW.plane6.surrogates
+ test/sun/nio/cs/SurrogateTestEUCTW.plane7.surrogates
+ test/sun/nio/cs/SurrogateTestHKSCS.java
+ test/sun/nio/cs/Test4200310.sh
+ test/sun/nio/cs/Test4206507.java
+ test/sun/nio/cs/Test6254467.java
+ test/sun/nio/cs/Test6275027.java
+ test/sun/nio/cs/Test6392804.java
+ test/sun/nio/cs/TestCompoundTest.java
+ test/sun/nio/cs/TestConverterDroppedCharacters.java
+ test/sun/nio/cs/TestCp834_SBCS.java
+ test/sun/nio/cs/TestCp93xSISO.java
+ test/sun/nio/cs/TestIBMBugs.java
+ test/sun/nio/cs/TestISCII91.java
+ test/sun/nio/cs/TestISO2022CNDecoder.java
+ test/sun/nio/cs/TestISO2022JP.java
+ test/sun/nio/cs/TestISO2022JPEncoder.java
+ test/sun/nio/cs/TestISO2022JPSubBytes.java
+ test/sun/nio/cs/TestIllegalISO2022Esc.java
+ test/sun/nio/cs/TestIllegalSJIS.java
+ test/sun/nio/cs/TestJIS0208Decoder.java
+ test/sun/nio/cs/TestJIS0212Decoder.java
+ test/sun/nio/cs/TestMS5022X.java
+ test/sun/nio/cs/TestMiscEUC_JP.java
+ test/sun/nio/cs/TestSJIS0213.java
+ test/sun/nio/cs/TestTrailingEscapesISO2022JP.java
+ test/sun/nio/cs/TestUTF8BOM.java
+ test/sun/nio/cs/TestUTF_16.java
+ test/sun/nio/cs/TestUTF_32.java
+ test/sun/nio/cs/TestUni2HKSCS.java
+ test/sun/nio/cs/TestX11JIS0201.java
+ test/sun/nio/cs/UkrainianIsNotRussian.java
+ test/sun/nio/cs/ZeroedByteArrayEUCTWTest.java

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

Merge




From David.Bristor at Sun.COM  Mon Jun 30 23:49:43 2008
From: David.Bristor at Sun.COM (Dave Bristor)
Date: Mon, 30 Jun 2008 16:49:43 -0700
Subject: java.util.zip throws-  oversubscribed dynamic bit lengths tree
In-Reply-To: <4869598B.3090302@sun.com>
References: <485C44BF.8030004@sun.com> <485D32A1.7000308@sun.com>
	<485FFCE0.3000601@sun.com> <48693DCC.4080405@sun.com>
	<4869598B.3090302@sun.com>
Message-ID: <48697117.7090700@sun.com>

Harsha Godugu wrote:
> Dave Bristor wrote:
>> Hi Harsha,
> Hi Dave,
> 
> Unfortunately there is no stand alone reproducible test case.  It 
> appears that 6713913 and the issue  I brought up here are related.  Out 
> of curiosity, I was looking into inflater / deflater code to see what it 
> means to get the ' oversubscribed dynamic bit lengths tree'.  According 
> to the code, it's due to the jar file being not in the right format when 
> the error occurred.  The one thing that's suspicious here is, the jar 
> file creation.  Their build uses maven's internal code to create a jar 
> file on the fly. (this problem happens consistently on Solaris & mac.. 

Is it possible to alter the build to use some other form of jar file creation?

Googling shows that there was a  problem with zlib 1.1.2 that could cause the 
particular "oversubscribed dynamic bit lengths tree" message, but that this 
was fixed in zlib 1.1.3, which is what the JDK uses.  Is it possible that 
maven has its own implementation of zip code?  I know that ant does; they rely 
on some of the java.util.zip API but have their own code to read and write ZIP 
files.  I see that maven's sources include "maven-ant-tasks-2.0.8.jar".  If 
maven is using ant's ZIP code, perhaps the problem lies there.  Could you check?

> with that build.)  If there is a jar file (format) verifier to examine 
> each bit of the (created) jar, then that would help nail down this 

% zip
Copyright (C) 1990-1999 Info-ZIP
Type 'zip "-L"' for software license.
Zip 2.3 (November 29th 1999). Usage:
...
   -T   test zipfile integrity

% unzip
UnZip 5.52 of 28 February 2005, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir]
   Default action is to extract files in list, except those in xlist, to exdir;
   file[.zip] may be a wildcard.  -Z => ZipInfo mode ("unzip -Z" for usage).
...
   -t  test compressed archive data

However, Sahoo provided a jar that caused a failure during build, and it 
passes the above checks.  So I don't know how thorough the above are. 
Googling shows a few integrity checking tools, mostly for Windows.

> problem. Would it also be a problem, if multiple threads accessing 

As long as they're all reading, I believe it should not be a problem.  If 
there is a writer and N readers which are using the stream classes, and they 
are properly synchronized, this should also work.

Thanks,
	Dave

> (reading ) the same jar?  (Or any other jar related flags that could be 
> enabled to check the integrity of the jar would be of help here.)
> 
> I will add the stack traces  to the same bug report.
> thanks,
> Harsha
> 
> One data point to not
>>
>> Do you have a reproducible testcase?  This appeared years before my 
>> time, see 4188883, "java.util.zip.ZipException: oversubscribed dynamic 
>> bit lengths tree", and was closed with the note "Irreproducible - 
>> probably fixed some time ago."
>>
>> Sahoo has filed 6713913, "Fatal errors during jar file processing", 
>> but I'm unable to reproduce the problem.
>>
>> Thanks,
>>     Dave
>>
>>>>> thanks,
>>>>> Harsha
>>>>>
>>>>>
>>>>> Problem: When reading large jar files programatically, we get the 
>>>>> following exception.
>>>>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error 
>>>>> assembling JAR
>>>>>    at 
>>>>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183) 
>>>>>
>>>>>    at 
>>>>> com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193) 
>>>>>
>>>>>    at 
>>>>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 
>>>>>
>>>>>    at 
>>>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 
>>>>>
>>>>>    ... 16 more
>>>>> Caused by: java.util.zip.ZipException: oversubscribed dynamic bit 
>>>>> lengths tree
>>>>>    at 
>>>>> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
>>>>>    at java.io.DataInputStream.readFully(DataInputStream.java:176)
>>>>>    at java.util.jar.JarFile.getBytes(JarFile.java:364)
>>>>>    at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157)
>>>>>    at java.util.jar.JarFile.getManifest(JarFile.java:145)
>>>>>    at 
>>>>> com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172) 
>>>>>
>>>>>    at 
>>>>> com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126) 
>>>>>
>>>>>    at 
>>>>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168) 
>>>>>
>>>>
>>>
> 


From Harsha.Godugu at Sun.COM  Mon Jun 30 22:09:15 2008
From: Harsha.Godugu at Sun.COM (Harsha Godugu)
Date: Mon, 30 Jun 2008 15:09:15 -0700
Subject: java.util.zip throws-  oversubscribed dynamic bit lengths tree
In-Reply-To: <48693DCC.4080405@sun.com>
References: <485C44BF.8030004@sun.com> <485D32A1.7000308@sun.com>
	<485FFCE0.3000601@sun.com> <48693DCC.4080405@sun.com>
Message-ID: <4869598B.3090302@sun.com>

Dave Bristor wrote:
> Hi Harsha,
Hi Dave,

Unfortunately there is no stand alone reproducible test case.  It 
appears that 6713913 and the issue  I brought up here are related.  Out 
of curiosity, I was looking into inflater / deflater code to see what it 
means to get the ' oversubscribed dynamic bit lengths tree'.  According 
to the code, it's due to the jar file being not in the right format when 
the error occurred.  The one thing that's suspicious here is, the jar 
file creation.  Their build uses maven's internal code to create a jar 
file on the fly. (this problem happens consistently on Solaris & mac.. 
with that build.)  If there is a jar file (format) verifier to examine 
each bit of the (created) jar, then that would help nail down this 
problem. Would it also be a problem, if multiple threads accessing 
(reading ) the same jar?  (Or any other jar related flags that could be 
enabled to check the integrity of the jar would be of help here.)

I will add the stack traces  to the same bug report. 

thanks,
Harsha

One data point to not
>
> Do you have a reproducible testcase?  This appeared years before my 
> time, see 4188883, "java.util.zip.ZipException: oversubscribed dynamic 
> bit lengths tree", and was closed with the note "Irreproducible - 
> probably fixed some time ago."
>
> Sahoo has filed 6713913, "Fatal errors during jar file processing", 
> but I'm unable to reproduce the problem.
>
> Thanks,
>     Dave
>
>>>> thanks,
>>>> Harsha
>>>>
>>>>
>>>> Problem: When reading large jar files programatically, we get the 
>>>> following exception.
>>>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error 
>>>> assembling JAR
>>>>    at 
>>>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183) 
>>>>
>>>>    at 
>>>> com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193) 
>>>>
>>>>    at 
>>>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 
>>>>
>>>>    at 
>>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 
>>>>
>>>>    ... 16 more
>>>> Caused by: java.util.zip.ZipException: oversubscribed dynamic bit 
>>>> lengths tree
>>>>    at 
>>>> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
>>>>    at java.io.DataInputStream.readFully(DataInputStream.java:176)
>>>>    at java.util.jar.JarFile.getBytes(JarFile.java:364)
>>>>    at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157)
>>>>    at java.util.jar.JarFile.getManifest(JarFile.java:145)
>>>>    at 
>>>> com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172) 
>>>>
>>>>    at 
>>>> com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126) 
>>>>
>>>>    at 
>>>> com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168) 
>>>>
>>>
>>