From Ulf.Zibis at gmx.de  Sat Aug  1 15:20:34 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 01 Aug 2009 17:20:34 +0200
Subject: New smart class FastCharset
Message-ID: <4A745D42.10104@gmx.de>

Martin, Sherman, Dalibor,

I'm proud to present a new patch, which could dramatically improve the 
memory-footprint and instantiation performance of charsets usage, so 
Charset instances could directly be hold in cache.
The footprint of the code is again little smaller than before.

Provided patch fixes:
6862158 Make sun.nio.cs.* charset objects light-weight
6850361 Avoid 2-step lookup in sun.nio.cs charset providers
6790402 Speed-up FastCharsetProvider
6795536 No system start for file.encoding=x-SJIS_0213
6792535 NoClassDefFoundError after failed new StreamEncoder(out, lock, 
Charset.defaultCh
6850337 Hasher.java interprets given option value badly
6853677 Provide names of supported charsets -> now superfluous

Do you like to review and/or sponsor my CR ?

See:
https://bugs.openjdk.java.net/show_bug.cgi?id=100098

As the code of the new FastCharset is so tiny and flexible, I paste it 
here directly...
Using it's De/Encoders in general would make interfaces ArrayDecoder ad 
ArrayEncoder superfluous.
For charsets with huge mappings it is foreseen to split class Mapping 
for decoders and encoders.

Thanks,

Ulf



package sun.nio.cs;

import java.nio.charset.Charset;
import java.nio.charset.CharsetDecoder;
import java.nio.charset.CharsetEncoder;
import java.nio.charset.UnsupportedCharsetException;

class FastCharset extends Charset implements HistoricallyNamedCharset {

    private final String pkgName;
    final String mappingClsName; // package private for 
ExternalCharsetProvider
    private transient Decoder decoder;
    private transient Encoder encoder;

    FastCharset(String className, String canonicalName, String... aliases) {
        super(canonicalName, aliases);
        pkgName = getClass().getPackage().getName();
        mappingClsName = className;
    }
    FastCharset(String packageName, String className, String 
canonicalName, String[] aliases) {
        super(canonicalName, aliases);
        pkgName = packageName;
        mappingClsName = className;
    }

    public String historicalName() {
        return mapping().historicalName;
    }

    public boolean contains(Charset cs) {
        return cs.name().equals(name()) ||
                mapping().isASCII && cs.name().equals("US-ASCII");
    }

    public Decoder newDecoder() {
        return decoder().clone();
    }

    public Encoder newEncoder() {
        if (encoder == null)
            encoder = decoder().newEncoder();
        return encoder.clone();
    }

    private final Decoder decoder() {
        if (decoder == null)
            decoder = mapping().newDecoder(this);
        return decoder;
    }

    final Mapping mapping() {
        try {
            return ((Class<Mapping>) Class.forName(
                pkgName+'.'+mappingClsName)).newInstance();
        } catch (ClassNotFoundException ex) {
            throw new NoClassDefFoundError(ex.getMessage());
        } catch (ReflectiveOperationException ex) {
            Error error = new InternalError("Can't instantiate class 
["+pkgName+'.'+mappingClsName+"]");
            error.initCause(ex);
            throw error;
        }
    }


    static abstract class Decoder<M extends Mapping>
            extends CharsetDecoder implements Cloneable, ArrayDecoder {

        M mapping;

        Decoder(FastCharset cs, M mapping,
                float averageCharsPerByte, float maxCharsPerByte) {
            super(cs, 1.0f, 1.0f);
            this.mapping = mapping;
        }

        protected Decoder<M> clone() {
            try {
                return (Decoder<M>)super.clone();
            } catch (CloneNotSupportedException ex) {
                return null;
            }
        }

        Encoder<M> newEncoder() {
            return mapping.newEncoder(this);
        }
    }


    static abstract class Encoder<M extends Mapping>
            extends CharsetEncoder implements Cloneable, ArrayEncoder {

        M mapping;

        Encoder(Decoder<M> decoder,
                   float averageBytesPerChar, float maxBytesPerChar) {
            super(decoder.charset(), 1.0f, 1.0f);
            mapping = decoder.mapping;
            mapping.initEncoderMaps();
        }

        protected Encoder<M> clone() {
            try {
                return (Encoder<M>)super.clone();
            } catch (CloneNotSupportedException ex) {
                return null;
            }
        }
    }
}




From weijun.wang at sun.com  Sun Aug  2 05:47:22 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Sun, 02 Aug 2009 05:47:22 +0000
Subject: hg: jdk7/tl/jdk: 6867687: keytool's standard.sh test timeout sometimes
Message-ID: <20090802054805.E5801EF05@hg.openjdk.java.net>

Changeset: 2536ab04dc68
Author:    weijun
Date:      2009-08-02 13:40 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2536ab04dc68

6867687: keytool's standard.sh test timeout sometimes
Reviewed-by: xuelei

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



From tim.bell at sun.com  Mon Aug  3 05:34:27 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 03 Aug 2009 05:34:27 +0000
Subject: hg: jdk7/tl: 5 new changesets
Message-ID: <20090803053427.75227EF2E@hg.openjdk.java.net>

Changeset: 5dc862ec024e
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/5dc862ec024e

Added tag jdk7-b66 for changeset 6bad5e3fe503

! .hgtags

Changeset: fbc75d7ed6dc
Author:    tbell
Date:      2009-07-27 23:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/fbc75d7ed6dc

Merge


Changeset: c4523c6f8204
Author:    xdono
Date:      2009-07-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/c4523c6f8204

6862919: Update copyright year
Summary: Update copyright for files that have been modified in 2009, up to 07/09
Reviewed-by: tbell, ohair

! make/deploy-rules.gmk
! make/jprt.properties
! make/sanity-rules.gmk

Changeset: cab520b37e9a
Author:    xdono
Date:      2009-07-30 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/cab520b37e9a

Added tag jdk7-b67 for changeset c4523c6f8204

! .hgtags

Changeset: e1b972ff53cd
Author:    tbell
Date:      2009-07-30 23:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/e1b972ff53cd

Merge




From tim.bell at sun.com  Mon Aug  3 05:39:48 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 03 Aug 2009 05:39:48 +0000
Subject: hg: jdk7/tl/corba: 5 new changesets
Message-ID: <20090803053953.B74E3EF3F@hg.openjdk.java.net>

Changeset: d5e36cb83d8c
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/d5e36cb83d8c

Added tag jdk7-b66 for changeset a821e059a961

! .hgtags

Changeset: ad500347ebc8
Author:    tbell
Date:      2009-07-27 23:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/ad500347ebc8

Merge


Changeset: a12ea7c7b497
Author:    xdono
Date:      2009-07-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/a12ea7c7b497

6862919: Update copyright year
Summary: Update copyright for files that have been modified in 2009, up to 07/09
Reviewed-by: tbell, ohair

! make/Makefile
! make/common/Library.gmk
! make/common/Rules.gmk
! make/common/shared/Compiler-gcc.gmk
! make/common/shared/Defs-java.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Platform.gmk
! make/jprt.properties
! make/org/omg/idl/Makefile
! make/tools/logutil/Makefile
! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerReadStream.java
! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java
! src/share/classes/com/sun/corba/se/impl/oa/poa/POAFactory.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBSingleton.java
! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java
! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java
! src/share/classes/com/sun/corba/se/impl/resolver/INSURLOperationImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java
! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc
! src/share/classes/com/sun/tools/corba/se/idl/Parser.java
! src/share/classes/com/sun/tools/corba/se/idl/first.set
! src/share/classes/com/sun/tools/corba/se/idl/follow.set
! src/share/classes/com/sun/tools/corba/se/idl/grammar.idl
! src/share/classes/com/sun/tools/corba/se/idl/grammar3.idl
! src/share/classes/com/sun/tools/corba/se/idl/idl.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/logutil/Input.java
! src/share/classes/com/sun/tools/corba/se/logutil/InputCode.java
! src/share/classes/com/sun/tools/corba/se/logutil/InputException.java
! src/share/classes/com/sun/tools/corba/se/logutil/MC.java
! src/share/classes/org/omg/CORBA/ORB.java
! src/windows/resource/version.rc

Changeset: ec55ebb18a61
Author:    xdono
Date:      2009-07-30 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/ec55ebb18a61

Added tag jdk7-b67 for changeset a12ea7c7b497

! .hgtags

Changeset: 5182bcc9c60c
Author:    tbell
Date:      2009-07-30 23:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/5182bcc9c60c

Merge

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



From tim.bell at sun.com  Mon Aug  3 05:46:43 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 03 Aug 2009 05:46:43 +0000
Subject: hg: jdk7/tl/hotspot: 25 new changesets
Message-ID: <20090803054738.79D7AEF44@hg.openjdk.java.net>

Changeset: 96e4ccadd5f6
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/96e4ccadd5f6

Added tag jdk7-b66 for changeset 57c71ad0341b

! .hgtags

Changeset: bd02caa94611
Author:    xdono
Date:      2009-07-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bd02caa94611

6862919: Update copyright year
Summary: Update copyright for files that have been modified in 2009, up to 07/09
Reviewed-by: tbell, ohair

! agent/src/os/linux/Makefile
! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java
! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/MonitorValue.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeValue.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ObjectReferenceImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ThreadReferenceImpl.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/InterpretedVFrame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/MonitorInfo.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/StackValue.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/StubRoutines.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/classes/sun/jvm/hotspot/ui/tree/OopTreeNodeAdapter.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaThread.java
! make/jprt.properties
! make/linux/makefiles/jsig.make
! make/linux/makefiles/saproc.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/sparcWorks.make
! make/windows/build_vm_def.sh
! make/windows/create.bat
! make/windows/get_msc_ver.sh
! make/windows/makefiles/adlc.make
! make/windows/makefiles/compile.make
! make/windows/makefiles/makedeps.make
! make/windows/makefiles/rules.make
! make/windows/makefiles/sa.make
! make/windows/makefiles/sanity.make
! make/windows/makefiles/vm.make
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/x86/vm/interpreterRT_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.hpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/jhelper.d
! src/os/solaris/dtrace/libjvm_db.c
! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp
! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp
! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp
! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp
! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp
! src/share/tools/MakeDeps/BuildConfig.java
! src/share/tools/MakeDeps/WinGammaPlatformVC7.java
! src/share/tools/MakeDeps/WinGammaPlatformVC8.java
! src/share/tools/MakeDeps/WinGammaPlatformVC9.java
! src/share/tools/hsdis/Makefile
! src/share/tools/hsdis/hsdis-demo.c
! src/share/tools/hsdis/hsdis.c
! src/share/vm/adlc/adlc.hpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciMethodBlocks.cpp
! src/share/vm/ci/ciStreams.cpp
! src/share/vm/ci/ciStreams.hpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp
! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp
! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp
! src/share/vm/gc_interface/gcCause.hpp
! src/share/vm/includeDB_compiler1
! src/share/vm/includeDB_jvmti
! src/share/vm/interpreter/bytecode.cpp
! src/share/vm/interpreter/bytecode.hpp
! src/share/vm/interpreter/bytecodeStream.hpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/bytecodes.cpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/interpreter/invocationCounter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/interpreter/templateTable.cpp
! src/share/vm/interpreter/templateTable.hpp
! src/share/vm/memory/blockOffsetTable.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/gcLocker.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/oops/cpCacheOop.cpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/oops/methodDataOop.cpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/superword.hpp
! src/share/vm/prims/jvm_misc.hpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/methodComparator.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/dtraceJSDT.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/hpi.hpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/orderAccess.cpp
! src/share/vm/runtime/orderAccess.hpp
! src/share/vm/runtime/stackValue.cpp
! src/share/vm/runtime/stackValue.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframe_hp.cpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/bitMap.inline.hpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/globalDefinitions_visCPP.hpp
! src/share/vm/utilities/macros.hpp
! test/compiler/6772683/InterruptedTest.java
! test/compiler/6832293/Test.java
! test/runtime/6819213/TestBootNativeLibraryPath.java

Changeset: df6caf649ff7
Author:    ysr
Date:      2009-07-14 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/df6caf649ff7

6700789: G1: Enable use of compressed oops with G1 heaps
Summary: Modifications to G1 so as to allow the use of compressed oops.
Reviewed-by: apetrusenko, coleenp, jmasa, kvn, never, phh, tonyp

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_implementation/g1/satbQueue.cpp
! src/share/vm/gc_implementation/g1/satbQueue.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/includeDB_core
! src/share/vm/includeDB_features
! src/share/vm/memory/barrierSet.cpp
! src/share/vm/memory/barrierSet.hpp
! src/share/vm/memory/barrierSet.inline.hpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/genOopClosures.hpp
! src/share/vm/memory/genOopClosures.inline.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/utilities/taskqueue.cpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 42d84bbbecf4
Author:    tonyp
Date:      2009-07-15 12:22 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/42d84bbbecf4

6859911: G1: assert(Heap_lock->owner() = NULL, "Should be owned on this thread's behalf")
Summary: The used() method assumes that the heap lock is held when it is called. However, when used() is called from print_on(), this is not the case.
Reviewed-by: ysr, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp

Changeset: f0a1cbbaf3c0
Author:    ysr
Date:      2009-07-16 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f0a1cbbaf3c0

Merge


Changeset: fe95187e8882
Author:    never
Date:      2009-07-13 14:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fe95187e8882

6859338: amd64 native unverified entry point pushes values before implicit null check
Reviewed-by: kvn, twisti

! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
+ test/compiler/6859338/Test6859338.java

Changeset: 83906a156fc0
Author:    never
Date:      2009-07-13 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/83906a156fc0

Merge


Changeset: fd50a67f97d1
Author:    never
Date:      2009-07-15 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fd50a67f97d1

6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post
Reviewed-by: never, kvn
Contributed-by: yamauchi at google.com, rasbold at google.com

! src/share/vm/opto/loopopts.cpp
+ test/compiler/6860469/Test.java

Changeset: fc4be448891f
Author:    kvn
Date:      2009-07-16 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc4be448891f

6851742: (EA) allocation elimination doesn't work with UseG1GC
Summary: Fix eliminate_card_mark() to eliminate G1 pre/post barriers.
Reviewed-by: never

! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/type.hpp

Changeset: 84770322b304
Author:    never
Date:      2009-07-16 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/84770322b304

6861513: correct copyright attribution in test for 6837094 and 6860469
Reviewed-by: rasbold

! test/compiler/6837094/Test.java
! test/compiler/6860469/Test.java

Changeset: 64219d2a6493
Author:    kvn
Date:      2009-07-16 16:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/64219d2a6493

6851282: JIT miscompilation results in null entry in array when using CompressedOops
Summary: Get type for new Phi from non dead path.
Reviewed-by: never

! src/share/vm/opto/cfgnode.cpp
+ test/compiler/6851282/Test.java

Changeset: 606c988ff684
Author:    kvn
Date:      2009-07-17 00:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/606c988ff684

Merge


Changeset: f9094a5e1c8a
Author:    never
Date:      2009-07-21 16:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f9094a5e1c8a

6857159: local schedule failed with checkcast of Thread.currentThread()
Reviewed-by: kvn

! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
+ test/compiler/6857159/Test6857159.java
+ test/compiler/6857159/Test6857159.sh

Changeset: 75596850f863
Author:    jrose
Date:      2009-07-21 16:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75596850f863

6862576: vmIntrinsics needs cleanup in order to support JSR 292 intrinsics
Summary: remove useless lazy evaluation of intrinsics; add LAST_COMPILER_INLINE to help categorize them
Reviewed-by: kvn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/library_call.cpp

Changeset: 17173cb6e48d
Author:    jrose
Date:      2009-07-21 21:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/17173cb6e48d

Merge


Changeset: 5314d85ffd54
Author:    kvn
Date:      2009-07-22 15:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5314d85ffd54

6826736: CMS: core dump with -XX:+UseCompressedOops
Summary: Fix deoptimization code and OopMapSet::all_do() to check for oop = narrow_oop_base.
Reviewed-by: jcoomes, phh, ysr, never

! src/share/vm/compiler/oopMap.cpp
! src/share/vm/compiler/oopMap.hpp
! src/share/vm/memory/universe.hpp
! src/share/vm/runtime/stackValue.cpp
+ test/compiler/6826736/Test.java

Changeset: ea3f9723b5cf
Author:    kvn
Date:      2009-07-23 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ea3f9723b5cf

6860599: nodes limit could be reached during Output phase
Summary: Bailout compilation if nodes limit could be reached during Output phase.
Reviewed-by: never, twisti

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/output.cpp

Changeset: 433f394ab509
Author:    kvn
Date:      2009-07-24 09:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/433f394ab509

Merge

! src/share/vm/memory/universe.hpp
! src/share/vm/opto/cfgnode.cpp

Changeset: 45d97a99715b
Author:    apetrusenko
Date:      2009-07-22 02:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/45d97a99715b

6862661: G1: _gc_alloc_region_counts is not updated properly after 6604422
Summary: Implementation of RFE 6604422 (G1: re-use half-promoted regions) introduced incorrect _gc_alloc_region_counts updates which effectively disabled survivor spaces.
Reviewed-by: johnc, jmasa, tonyp

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 36b5611220a7
Author:    ysr
Date:      2009-07-22 18:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/36b5611220a7

6863216: Clean up debugging debris inadvertently pushed with 6700789
Summary: Anti-delta for debugging debris that was inadvertently pushed.
Reviewed-by: kvn, tonyp

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/opto/cfgnode.cpp

Changeset: 0a83664f978b
Author:    ysr
Date:      2009-07-24 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0a83664f978b

Merge

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

Changeset: 1c2487639400
Author:    trims
Date:      2009-07-24 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1c2487639400

Merge


Changeset: 3c0f72981560
Author:    trims
Date:      2009-07-24 16:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3c0f72981560

6864901: Bump the HS16 build number to 07
Summary: Update the HS16 build number to 07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 18f526145aea
Author:    trims
Date:      2009-07-29 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/18f526145aea

Merge

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/stackValue.cpp

Changeset: d07e68298d4e
Author:    xdono
Date:      2009-07-30 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d07e68298d4e

Added tag jdk7-b67 for changeset 18f526145aea

! .hgtags



From tim.bell at sun.com  Mon Aug  3 05:56:49 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 03 Aug 2009 05:56:49 +0000
Subject: hg: jdk7/tl/jaxp: 5 new changesets
Message-ID: <20090803055657.81F45EF49@hg.openjdk.java.net>

Changeset: f8f9c0186d87
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/f8f9c0186d87

Added tag jdk7-b66 for changeset 22f9d5d5b5fe

! .hgtags

Changeset: ef9c2dee8a40
Author:    tbell
Date:      2009-07-27 23:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ef9c2dee8a40

Merge


Changeset: a033af8d824a
Author:    xdono
Date:      2009-07-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/a033af8d824a

6862919: Update copyright year
Summary: Update copyright for files that have been modified in 2009, up to 07/09
Reviewed-by: tbell, ohair

! make/build.properties
! make/build.xml
! make/jprt.properties
! src/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java
! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java
! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl.java
! src/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java

Changeset: c77f6ec0bd9b
Author:    xdono
Date:      2009-07-30 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c77f6ec0bd9b

Added tag jdk7-b67 for changeset a033af8d824a

! .hgtags

Changeset: 83b2a9331383
Author:    tbell
Date:      2009-07-30 23:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/83b2a9331383

Merge

! make/build.properties



From tim.bell at sun.com  Mon Aug  3 06:02:20 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 03 Aug 2009 06:02:20 +0000
Subject: hg: jdk7/tl/jaxws: 5 new changesets
Message-ID: <20090803060227.5FE5DEF4E@hg.openjdk.java.net>

Changeset: 58f51e3cc0fa
Author:    xdono
Date:      2009-07-24 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/58f51e3cc0fa

Added tag jdk7-b66 for changeset fa8712c099ed

! .hgtags

Changeset: a98e41351006
Author:    tbell
Date:      2009-07-27 23:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/a98e41351006

Merge


Changeset: faa13cd4d6cd
Author:    xdono
Date:      2009-07-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/faa13cd4d6cd

6862919: Update copyright year
Summary: Update copyright for files that have been modified in 2009, up to 07/09
Reviewed-by: tbell, ohair

! make/Makefile
! make/build.properties
! make/build.xml

Changeset: b70ce5b02bbc
Author:    xdono
Date:      2009-07-30 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/b70ce5b02bbc

Added tag jdk7-b67 for changeset faa13cd4d6cd

! .hgtags

Changeset: 845fa487f0f7
Author:    tbell
Date:      2009-07-30 23:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/845fa487f0f7

Merge

! make/build.properties



From tim.bell at sun.com  Mon Aug  3 06:09:29 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 03 Aug 2009 06:09:29 +0000
Subject: hg: jdk7/tl/jdk: 26 new changesets
Message-ID: <20090803061540.EEB4EEF55@hg.openjdk.java.net>

Changeset: 043c7100a752
Author:    anthony
Date:      2009-07-07 17:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/043c7100a752

6853916: java.awt.Window.setBackground(null) throws NullPointerException
Summary: Window.setBackground() should check for null.
Reviewed-by: art, dcherepanov

! src/share/classes/java/awt/Window.java
+ test/java/awt/Window/SetBackgroundNPE/SetBackgroundNPE.java

Changeset: 99cdc0268e4b
Author:    dcherepanov
Date:      2009-07-09 15:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99cdc0268e4b

6855323: Robot(GraphicsDevice) constructor initializes LEGAL_BUTTON_MASK variable improperly
Reviewed-by: art

! src/share/classes/java/awt/Robot.java
+ test/java/awt/Robot/CtorTest/CtorTest.java

Changeset: 9b1e640af25e
Author:    dcherepanov
Date:      2009-07-09 15:18 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b1e640af25e

6759726: TrayIcon constructor throws NPE instead of documented IAE
Reviewed-by: art

! src/share/classes/java/awt/TrayIcon.java
+ test/java/awt/TrayIcon/CtorTest/CtorTest.java

Changeset: df34ec9f3e26
Author:    dcherepanov
Date:      2009-07-09 15:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df34ec9f3e26

6847958: MouseWheel event is getting triggered for the disabled Textarea in jdk7 b60 pit build.
Reviewed-by: art

! src/solaris/classes/sun/awt/X11/XBaseWindow.java
+ test/java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java

Changeset: c27d7c1d1918
Author:    dcherepanov
Date:      2009-07-09 15:53 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c27d7c1d1918

6847149: test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java fails
Reviewed-by: art

! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java

Changeset: 6d92ce5fe15b
Author:    yan
Date:      2009-07-12 23:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6d92ce5fe15b

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: 4cd623432e7d
Author:    anthony
Date:      2009-07-14 14:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4cd623432e7d

6837446: Introduce Window.isOpaque() method
Reviewed-by: art, alexp

! src/share/classes/com/sun/awt/AWTUtilities.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/Window.java
! src/share/classes/javax/swing/DefaultDesktopManager.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/SunToolkit.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: fc869bc0cd63
Author:    yan
Date:      2009-07-14 22:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fc869bc0cd63

Merge


Changeset: bccc4d5e8d6a
Author:    malenkov
Date:      2009-07-02 19:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bccc4d5e8d6a

6380849: RFE: Automatic discovery of PersistanceDelegates
Reviewed-by: rupashka, alexp

+ src/share/classes/com/sun/beans/finder/BeanInfoFinder.java
+ src/share/classes/com/sun/beans/finder/InstanceFinder.java
+ src/share/classes/com/sun/beans/finder/PersistenceDelegateFinder.java
+ src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java
! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PropertyEditorManager.java
+ test/java/beans/Introspector/6380849/TestBeanInfo.java
+ test/java/beans/Introspector/6380849/beans/FirstBean.java
+ test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java
+ test/java/beans/Introspector/6380849/beans/SecondBean.java
+ test/java/beans/Introspector/6380849/beans/ThirdBean.java
+ test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java
+ test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java
+ test/java/beans/PropertyEditor/6380849/FirstBean.java
+ test/java/beans/PropertyEditor/6380849/FirstBeanEditor.java
+ test/java/beans/PropertyEditor/6380849/SecondBean.java
+ test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java
+ test/java/beans/PropertyEditor/6380849/ThirdBean.java
+ test/java/beans/PropertyEditor/6380849/editors/SecondBeanEditor.java
+ test/java/beans/PropertyEditor/6380849/editors/ThirdBeanEditor.java
+ test/java/beans/XMLEncoder/6380849/Bean.java
+ test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java
+ test/java/beans/XMLEncoder/6380849/TestPersistenceDelegate.java

Changeset: 7720d6c079ca
Author:    malenkov
Date:      2009-07-03 16:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7720d6c079ca

6329581: RFE: LTP: java.beans.XMLEncoder does not manage ClassLoader.
Reviewed-by: rupashka, alexp

! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/Statement.java
+ test/java/beans/XMLEncoder/6329581/Test6329581.java

Changeset: ef20a15b3569
Author:    malenkov
Date:      2009-07-06 14:32 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ef20a15b3569

6723447: Introspector doesn't check return type for indexed property setters
Reviewed-by: rupashka

! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/Introspector/Test6723447.java

Changeset: 0407df5a768e
Author:    rupashka
Date:      2009-07-07 14:11 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0407df5a768e

6489447: Apply the more robust fix for 6449933 to dolphin and 6ux
Reviewed-by: malenkov

! src/windows/native/sun/windows/ShellFolder2.cpp

Changeset: 913ad033bb37
Author:    yan
Date:      2009-07-12 06:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/913ad033bb37

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- src/share/classes/sun/swing/AccessibleMethod.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: c8da3750c7ca
Author:    yan
Date:      2009-07-14 22:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c8da3750c7ca

Merge


Changeset: f88379effbcf
Author:    yan
Date:      2009-07-21 23:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f88379effbcf

Merge


Changeset: bd31b30a5b21
Author:    dcherepanov
Date:      2009-07-23 11:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bd31b30a5b21

6857870: Regression tests are failing with ExceptionInInitializerError
Reviewed-by: art

! src/windows/classes/sun/awt/windows/WToolkit.java

Changeset: 11a8f0936228
Author:    xdono
Date:      2009-07-24 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/11a8f0936228

Added tag jdk7-b66 for changeset bd31b30a5b21

! .hgtags

Changeset: 8eddead6a701
Author:    yhuang
Date:      2009-07-02 20:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8eddead6a701

6606396: Notepad and Stylepad demos don't run in Japanese locale.
Reviewed-by: peytoia, ogino

! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties

Changeset: d8ff2f23a8fc
Author:    yhuang
Date:      2009-07-26 19:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8ff2f23a8fc

Merge


Changeset: aed3ce4ba35b
Author:    tbell
Date:      2009-07-27 23:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aed3ce4ba35b

Merge


Changeset: 03b4ab24cd2a
Author:    jjg
Date:      2009-07-29 12:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03b4ab24cd2a

6865753: 6854244 breaks partial (jdk-only) builds
Summary: Makefiles which set -target 5 now need to set -source 5 as well.
Reviewed-by: wetmore, tbell

! make/com/sun/crypto/provider/Makefile
! make/javax/crypto/Makefile

Changeset: a952aafd5181
Author:    xdono
Date:      2009-07-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a952aafd5181

6862919: Update copyright year
Summary: Update copyright for files that have been modified in 2009, up to 07/09
Reviewed-by: tbell, ohair

! make/common/Defs-linux.gmk
! make/common/Release.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Sanity.gmk
! make/java/redist/Makefile
! make/sun/Makefile
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
! src/share/classes/java/awt/Robot.java
! src/share/classes/java/awt/TrayIcon.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java
! src/share/classes/java/lang/System.java
! src/share/classes/javax/swing/DefaultDesktopManager.java
! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/lang/java_props_md.c
! test/demo/jvmti/hprof/HelloWorld.java
! test/demo/jvmti/hprof/StackMapTableTest.java
! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java
! test/tools/jar/index/MetaInf.java

Changeset: 5c52dcbde260
Author:    xdono
Date:      2009-07-30 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c52dcbde260

Added tag jdk7-b67 for changeset a952aafd5181

! .hgtags

Changeset: 18fee5159090
Author:    tbell
Date:      2009-07-30 23:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/18fee5159090

Merge


Changeset: 358ec67d3252
Author:    tbell
Date:      2009-07-31 17:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/358ec67d3252

Merge

- test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java
- test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java

Changeset: 1c9cfd050949
Author:    tbell
Date:      2009-08-02 10:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1c9cfd050949

Merge




From tim.bell at sun.com  Mon Aug  3 06:26:49 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 03 Aug 2009 06:26:49 +0000
Subject: hg: jdk7/tl/langtools: 6 new changesets
Message-ID: <20090803062702.6834DEF5A@hg.openjdk.java.net>

Changeset: 0695e8ebae88
Author:    xdono
Date:      2009-07-24 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0695e8ebae88

Added tag jdk7-b66 for changeset 634f519d6f9a

! .hgtags

Changeset: e4ce529b2249
Author:    tbell
Date:      2009-07-27 23:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e4ce529b2249

Merge

- src/share/classes/com/sun/mirror/apt/package.html
- src/share/classes/com/sun/mirror/declaration/package.html
- src/share/classes/com/sun/mirror/type/package.html
- src/share/classes/com/sun/mirror/util/package.html

Changeset: 14b1a8ede954
Author:    xdono
Date:      2009-07-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/14b1a8ede954

6862919: Update copyright year
Summary: Update copyright for files that have been modified in 2009, up to 07/09
Reviewed-by: tbell, ohair

! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/legacy.properties
! test/tools/javac/typeAnnotations/failures/OldArray.java

Changeset: 689bec60a482
Author:    xdono
Date:      2009-07-30 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/689bec60a482

Added tag jdk7-b67 for changeset 14b1a8ede954

! .hgtags

Changeset: 95c1212b07e3
Author:    tbell
Date:      2009-07-30 23:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/95c1212b07e3

Merge


Changeset: dbf8a2816201
Author:    tbell
Date:      2009-07-31 17:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dbf8a2816201

Merge




From Ulf.Zibis at gmx.de  Tue Aug  4 09:00:59 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 04 Aug 2009 11:00:59 +0200
Subject: javac CRASH
Message-ID: <4A77F8CB.2070200@gmx.de>

See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
java.lang.NullPointerException from compiler (1.7.0-ea)

-Ulf




From Maurizio.Cimadamore at Sun.COM  Tue Aug  4 09:08:56 2009
From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore)
Date: Tue, 04 Aug 2009 10:08:56 +0100
Subject: javac CRASH
In-Reply-To: <4A77F8CB.2070200@gmx.de>
References: <4A77F8CB.2070200@gmx.de>
Message-ID: <4A77FAA8.5020101@sun.com>

Ulf Zibis wrote:
> See:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
> java.lang.NullPointerException from compiler (1.7.0-ea)
>
> -Ulf
>
>
Hi Ulf,
this is a type annotation (JSR 308) bug that has been recently fixed - 
it is a duplicate of 6861837.

Regards
Maurizio


From Ulf.Zibis at gmx.de  Tue Aug  4 09:16:15 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 04 Aug 2009 11:16:15 +0200
Subject: javac CRASH
In-Reply-To: <4A77FAA8.5020101@sun.com>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
Message-ID: <4A77FC5F.8020407@gmx.de>

Maurizio,

much thanks for the fast info.

Will this fix be included in next build b68 ???
Hopefully !

-Ulf


Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
> Ulf Zibis wrote:
>> See:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>
>> -Ulf
>>
>>
> Hi Ulf,
> this is a type annotation (JSR 308) bug that has been recently fixed - 
> it is a duplicate of 6861837.
>
> Regards
> Maurizio
>
>



From Maurizio.Cimadamore at Sun.COM  Tue Aug  4 10:20:23 2009
From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore)
Date: Tue, 04 Aug 2009 11:20:23 +0100
Subject: javac CRASH
In-Reply-To: <4A77FC5F.8020407@gmx.de>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de>
Message-ID: <4A780B67.3080809@sun.com>

Ulf Zibis wrote:
> Maurizio,
>
> much thanks for the fast info.
>
> Will this fix be included in next build b68 ???
> Hopefully !
Not sure if it will make into b68 - but certainly it will go into b69 
(depends on the integration process). The fix is already available in 
the langtools repository used for development 
(http://hg.openjdk.java.net/jdk7/tl/langtools).

Maurizio
>
> -Ulf
>
>
> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>> Ulf Zibis wrote:
>>> See:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>
>>> -Ulf
>>>
>>>
>> Hi Ulf,
>> this is a type annotation (JSR 308) bug that has been recently fixed 
>> - it is a duplicate of 6861837.
>>
>> Regards
>> Maurizio
>>
>>
>



From Ulf.Zibis at gmx.de  Tue Aug  4 11:07:36 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 04 Aug 2009 13:07:36 +0200
Subject: javac CRASH
In-Reply-To: <4A780B67.3080809@sun.com>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
Message-ID: <4A781678.4050100@gmx.de>

Maurizio,

much thanks for the additional info.

I like to avoid going back to b63.
If the fix will not go into b68, could you please provide a binary patch 
for b67 (or b68) (Windows version)?
I can wait for release of b68, but not for b69, as I'm on vacation until 
Aug. 10.

Thanks in advance,

-Ulf


Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
> Ulf Zibis wrote:
>> Maurizio,
>>
>> much thanks for the fast info.
>>
>> Will this fix be included in next build b68 ???
>> Hopefully !
> Not sure if it will make into b68 - but certainly it will go into b69 
> (depends on the integration process). The fix is already available in 
> the langtools repository used for development 
> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>
> Maurizio
>>
>> -Ulf
>>
>>
>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>> Ulf Zibis wrote:
>>>> See:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>
>>>> -Ulf
>>>>
>>>>
>>> Hi Ulf,
>>> this is a type annotation (JSR 308) bug that has been recently fixed 
>>> - it is a duplicate of 6861837.
>>>
>>> Regards
>>> Maurizio
>>>
>>>
>>
>
>



From forax at univ-mlv.fr  Tue Aug  4 13:17:15 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 04 Aug 2009 15:17:15 +0200
Subject: javac CRASH
In-Reply-To: <4A781678.4050100@gmx.de>
References: <4A77F8CB.2070200@gmx.de>
	<4A77FAA8.5020101@sun.com>	<4A77FC5F.8020407@gmx.de>
	<4A780B67.3080809@sun.com> <4A781678.4050100@gmx.de>
Message-ID: <4A7834DB.7020708@univ-mlv.fr>

Le 04/08/2009 13:07, Ulf Zibis a ?crit :
> Maurizio,
>
> much thanks for the additional info.
>
> I like to avoid going back to b63.
> If the fix will not go into b68, could you please provide a binary 
> patch for b67 (or b68) (Windows version)?
> I can wait for release of b68, but not for b69, as I'm on vacation 
> until Aug. 10.
>
> Thanks in advance,
>
> -Ulf

you can do it by yourself,
clone the langtools repository, it can be built with ant, so just type ant
in the directory "make", it will create a tools.jar.
Now remplace the tools.jar of your binary build by this new one.

cheers,
R?mi

>
>
> Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
>> Ulf Zibis wrote:
>>> Maurizio,
>>>
>>> much thanks for the fast info.
>>>
>>> Will this fix be included in next build b68 ???
>>> Hopefully !
>> Not sure if it will make into b68 - but certainly it will go into b69 
>> (depends on the integration process). The fix is already available in 
>> the langtools repository used for development 
>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>
>> Maurizio
>>>
>>> -Ulf
>>>
>>>
>>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>>> Ulf Zibis wrote:
>>>>> See:
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>>
>>>>> -Ulf
>>>>>
>>>>>
>>>> Hi Ulf,
>>>> this is a type annotation (JSR 308) bug that has been recently 
>>>> fixed - it is a duplicate of 6861837.
>>>>
>>>> Regards
>>>> Maurizio
>>>>
>>>>
>>>
>>
>>
>



From Tim.Bell at Sun.COM  Tue Aug  4 16:05:19 2009
From: Tim.Bell at Sun.COM (Tim Bell)
Date: Tue, 04 Aug 2009 09:05:19 -0700
Subject: javac CRASH
In-Reply-To: <4A780B67.3080809@sun.com>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
Message-ID: <4A785C3F.7040905@sun.com>

Maurizio Cimadamore wrote:

> Not sure if it will make into b68 - but certainly it will go into b69 
> (depends on the integration process). The fix is already available in 
> the langtools repository used for development 
> (http://hg.openjdk.java.net/jdk7/tl/langtools).

The TL forest has already integrated into the master for b68 [1].

The fix for 6861837 will be in b70.

Tim (gatekeeper for TL)
[1] http://openjdk.java.net/projects/jdk7/builds/


From Maurizio.Cimadamore at Sun.COM  Tue Aug  4 16:23:35 2009
From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore)
Date: Tue, 04 Aug 2009 17:23:35 +0100
Subject: javac CRASH
In-Reply-To: <4A785C3F.7040905@sun.com>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A785C3F.7040905@sun.com>
Message-ID: <4A786087.8030800@sun.com>

Tim Bell wrote:
> Maurizio Cimadamore wrote:
>
>   
>> Not sure if it will make into b68 - but certainly it will go into b69 
>> (depends on the integration process). The fix is already available in 
>> the langtools repository used for development 
>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>     
>
> The TL forest has already integrated into the master for b68 [1].
>
> The fix for 6861837 will be in b70.
>   
Thanks for the clarification Tim
I always forget about the even number rule! :-)

Maurizio
> Tim (gatekeeper for TL)
> [1] http://openjdk.java.net/projects/jdk7/builds/
>   



From xueming.shen at sun.com  Tue Aug  4 20:00:13 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Tue, 04 Aug 2009 20:00:13 +0000
Subject: hg: jdk7/tl/jdk: 4116222: Errors in Arabic code-conversion tables,
	part II
Message-ID: <20090804200057.09CF9E0A1@hg.openjdk.java.net>

Changeset: c390fd8fa885
Author:    sherman
Date:      2009-08-04 12:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c390fd8fa885

4116222: Errors in Arabic code-conversion tables, part II
Summary: updated the IBM420 datatable
Reviewed-by: alanb

! make/tools/CharsetMapping/IBM420.c2b
! make/tools/CharsetMapping/IBM420.map
! make/tools/CharsetMapping/IBM420.nr
! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java



From Jonathan.Gibbons at Sun.COM  Wed Aug  5 00:32:13 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Tue, 04 Aug 2009 17:32:13 -0700
Subject: javac CRASH
In-Reply-To: <4A77F8CB.2070200@gmx.de>
References: <4A77F8CB.2070200@gmx.de>
Message-ID: <4A78D30D.1030402@sun.com>

Ulf Zibis wrote:
> See:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
> java.lang.NullPointerException from compiler (1.7.0-ea)
>
> -Ulf
>
>
This is a duplicate of 6861837 which is fixed in b69.

-- Jon


From jonathan.gibbons at sun.com  Wed Aug  5 00:35:01 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 05 Aug 2009 00:35:01 +0000
Subject: hg: jdk7/tl/langtools: 6867671: javap whitespace formatting issues
Message-ID: <20090805003506.7C3A3E110@hg.openjdk.java.net>

Changeset: 743f17b55b44
Author:    jjg
Date:      2009-08-04 17:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/743f17b55b44

6867671: javap whitespace formatting issues
Reviewed-by: mcimadamore

! 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/JavapTask.java
! src/share/classes/com/sun/tools/javap/Options.java



From martinrb at google.com  Wed Aug  5 02:53:23 2009
From: martinrb at google.com (martinrb at google.com)
Date: Wed, 05 Aug 2009 02:53:23 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090805025437.BAF7CE137@hg.openjdk.java.net>

Changeset: 55186701bdbc
Author:    martin
Date:      2009-08-04 19:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/55186701bdbc

6868160: (process) Use vfork, not fork, on Linux to avoid swap exhaustion
Summary: Boldly go where no jdk has dared go before
Reviewed-by: michaelm

! src/solaris/native/java/lang/UNIXProcess_md.c

Changeset: a789c68f1cf3
Author:    martin
Date:      2009-08-04 19:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a789c68f1cf3

6856590: (process) Use RESTARTABLE in UNIXProcess_md.c
Summary: Wrap all system calls with RESTARTABLE
Reviewed-by: michaelm

! src/solaris/native/java/lang/UNIXProcess_md.c



From jonathan.gibbons at sun.com  Wed Aug  5 14:50:35 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 05 Aug 2009 14:50:35 +0000
Subject: hg: jdk7/tl/langtools: 6868553: 6867671 breaks some tests
Message-ID: <20090805145040.19116E1BE@hg.openjdk.java.net>

Changeset: bc0b1f404c40
Author:    jjg
Date:      2009-08-05 07:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bc0b1f404c40

6868553: 6867671 breaks some tests
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/AttributeWriter.java
! test/tools/javac/code/ArrayClone.java
! test/tools/javap/4111861/T4111861.java
! test/tools/javap/T4884240.java
! test/tools/javap/T4975569.java
! test/tools/javap/stackmap/T6271292.sh



From jonathan.gibbons at sun.com  Wed Aug  5 15:45:25 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 05 Aug 2009 15:45:25 +0000
Subject: hg: jdk7/tl/langtools: 6729471: javap should accept class files on
	the command line
Message-ID: <20090805154530.8A712E1C5@hg.openjdk.java.net>

Changeset: 526de25e0b28
Author:    jjg
Date:      2009-08-05 08:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/526de25e0b28

6729471: javap should accept class files on the command line
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/JavapTask.java
+ test/tools/javap/T6729471.java



From daniel.daugherty at sun.com  Wed Aug  5 19:38:39 2009
From: daniel.daugherty at sun.com (daniel.daugherty at sun.com)
Date: Wed, 05 Aug 2009 19:38:39 +0000
Subject: hg: jdk7/tl/jdk: 6868533: 3/4 JDI: remove '-source 1.5' and '-target
	1.5' options from com.sun.jdi tests
Message-ID: <20090805193917.AE760E3A0@hg.openjdk.java.net>

Changeset: 92394e48eed3
Author:    dcubed
Date:      2009-08-05 13:17 -0600
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92394e48eed3

6868533: 3/4 JDI: remove '-source 1.5' and '-target 1.5' options from com.sun.jdi tests
Summary: We are long past needing to make sure these tests can build on Tiger/JDK1.5.0.
Reviewed-by: tbell

! test/com/sun/jdi/EnumTest.java
! test/com/sun/jdi/GenericsTest.java
! test/com/sun/jdi/JdbVarargsTest.sh
! test/com/sun/jdi/StepTest.java
! test/com/sun/jdi/UTF8Test.java
! test/com/sun/jdi/VarargsTest.java



From bradford.wetmore at sun.com  Fri Aug  7 01:08:09 2009
From: bradford.wetmore at sun.com (bradford.wetmore at sun.com)
Date: Fri, 07 Aug 2009 01:08:09 +0000
Subject: hg: jdk7/tl/jdk: 6867657: Many JSN tests do not run under cygwin
Message-ID: <20090807010835.D65F4E590@hg.openjdk.java.net>

Changeset: 2aa570c01c69
Author:    wetmore
Date:      2009-08-06 17:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2aa570c01c69

6867657: Many JSN tests do not run under cygwin
Reviewed-by: ohair

! test/java/net/Authenticator/B4933582.sh
! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh
! test/java/net/Socket/OldSocketImpl.sh
! test/java/net/URL/B5086147.sh
! test/java/net/URL/runconstructor.sh
! test/java/net/URLClassLoader/B5077773.sh
! test/java/net/URLClassLoader/sealing/checksealed.sh
! test/java/net/URLConnection/6212146/test.sh
! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh
! test/java/security/Security/signedfirst/Dyn.sh
! test/java/security/Security/signedfirst/Static.sh
! test/javax/crypto/SecretKeyFactory/FailOverTest.sh
! test/javax/security/auth/Subject/doAs/Test.sh
! test/lib/security/java.policy/Ext_AllPolicy.sh
! test/sun/net/www/MarkResetTest.sh
! test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh
! test/sun/net/www/http/HttpClient/RetryPost.sh
! test/sun/net/www/protocol/jar/B5105410.sh
! test/sun/net/www/protocol/jar/jarbug/run.sh
! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh
! test/sun/security/pkcs11/Provider/Login.sh
! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
! test/sun/security/tools/jarsigner/AlgOptions.sh
! test/sun/security/tools/jarsigner/PercentSign.sh
! test/sun/security/tools/jarsigner/oldsig.sh
! test/sun/security/tools/keytool/AltProviderPath.sh
! test/sun/security/tools/keytool/CloneKeyAskPassword.sh
! test/sun/security/tools/keytool/NoExtNPE.sh
! test/sun/security/tools/keytool/SecretKeyKS.sh
! test/sun/security/tools/keytool/StandardAlgName.sh
! test/sun/security/tools/keytool/i18n.sh
! test/sun/security/tools/keytool/printssl.sh
! test/sun/security/tools/keytool/resource.sh
! test/sun/security/tools/keytool/standard.sh



From john.rose at sun.com  Fri Aug  7 01:38:47 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Fri, 07 Aug 2009 01:38:47 +0000
Subject: hg: jdk7/tl/jdk: 6838598: Legal notice repair:
	jdk/src/share/classes/sun/dyn/FilterGeneric.java
Message-ID: <20090807013917.5C06BE5A4@hg.openjdk.java.net>

Changeset: bc1deb18bfb1
Author:    jrose
Date:      2009-08-06 18:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc1deb18bfb1

6838598: Legal notice repair: jdk/src/share/classes/sun/dyn/FilterGeneric.java
Reviewed-by: xdono

! src/share/classes/sun/dyn/FilterGeneric.java



From tim.bell at sun.com  Fri Aug  7 02:24:34 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 07 Aug 2009 02:24:34 +0000
Subject: hg: jdk7/tl: Added tag jdk7-b68 for changeset e1b972ff53cd
Message-ID: <20090807022434.3E071E5E2@hg.openjdk.java.net>

Changeset: 82e6c820c51a
Author:    xdono
Date:      2009-08-06 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/82e6c820c51a

Added tag jdk7-b68 for changeset e1b972ff53cd

! .hgtags



From tim.bell at sun.com  Fri Aug  7 02:30:06 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 07 Aug 2009 02:30:06 +0000
Subject: hg: jdk7/tl/corba: Added tag jdk7-b68 for changeset 5182bcc9c60c
Message-ID: <20090807023007.DDFB4E5E7@hg.openjdk.java.net>

Changeset: 8120d308ec4e
Author:    xdono
Date:      2009-08-06 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/8120d308ec4e

Added tag jdk7-b68 for changeset 5182bcc9c60c

! .hgtags



From tim.bell at sun.com  Fri Aug  7 02:38:14 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 07 Aug 2009 02:38:14 +0000
Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b68 for changeset d07e68298d4e
Message-ID: <20090807023822.57D77E5F4@hg.openjdk.java.net>

Changeset: 54fd4d923296
Author:    xdono
Date:      2009-08-06 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/54fd4d923296

Added tag jdk7-b68 for changeset d07e68298d4e

! .hgtags



From jonathan.gibbons at sun.com  Fri Aug  7 02:43:11 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 07 Aug 2009 02:43:11 +0000
Subject: hg: jdk7/tl/langtools: 6858429: javap classfile library a minor bug
Message-ID: <20090807024317.14BD0E602@hg.openjdk.java.net>

Changeset: 160d7a994e69
Author:    jjg
Date:      2009-08-06 19:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/160d7a994e69

6858429: javap classfile library a minor bug
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/classfile/ClassWriter.java



From tim.bell at sun.com  Fri Aug  7 02:48:43 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 07 Aug 2009 02:48:43 +0000
Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b68 for changeset 83b2a9331383
Message-ID: <20090807024846.4C123E603@hg.openjdk.java.net>

Changeset: a4ab0d6ded63
Author:    xdono
Date:      2009-08-06 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/a4ab0d6ded63

Added tag jdk7-b68 for changeset 83b2a9331383

! .hgtags



From tim.bell at sun.com  Fri Aug  7 02:56:39 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 07 Aug 2009 02:56:39 +0000
Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b68 for changeset 845fa487f0f7
Message-ID: <20090807025641.E29D3E60B@hg.openjdk.java.net>

Changeset: 3e64fdfb9291
Author:    xdono
Date:      2009-08-06 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/3e64fdfb9291

Added tag jdk7-b68 for changeset 845fa487f0f7

! .hgtags



From tim.bell at sun.com  Fri Aug  7 03:06:11 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 07 Aug 2009 03:06:11 +0000
Subject: hg: jdk7/tl/jdk: 23 new changesets
Message-ID: <20090807031118.D55F0E620@hg.openjdk.java.net>

Changeset: f214db928124
Author:    art
Date:      2009-07-17 15:40 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f214db928124

6844297: java/awt/EventQueue/6638195/bug6638195.java test failed in jdk7 on Windows just on b59,passed on b57
Reviewed-by: bchristi, dcherepanov

! test/java/awt/EventQueue/6638195/bug6638195.java

Changeset: 29a065ef8341
Author:    dcherepanov
Date:      2009-07-22 13:00 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29a065ef8341

6859935: REGRESSION: Settings are missing in JCP/Advanced tab on windows
Reviewed-by: art

! src/windows/classes/sun/awt/windows/WToolkit.java

Changeset: ab4860d7cf28
Author:    anthony
Date:      2009-07-23 13:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ab4860d7cf28

6848424: java/awt/Frame/FrameSize/TestFrameSize.java needs improvement
Summary: The test now thoroughly verifies the pack() method
Reviewed-by: art, dcherepanov

! test/java/awt/Frame/FrameSize/TestFrameSize.java

Changeset: 045c3f367b06
Author:    dcherepanov
Date:      2009-07-27 15:37 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/045c3f367b06

6856929: Frame is not getting resized using Robot in OpenSolaris and Ubuntu
Reviewed-by: art, dav

! src/solaris/classes/sun/awt/X11/XRobotPeer.java
! src/solaris/native/sun/awt/awt_Robot.c

Changeset: 2fb41bc4d896
Author:    yan
Date:      2009-07-27 23:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2fb41bc4d896

Merge


Changeset: dfd0f4b7c7d1
Author:    yan
Date:      2009-07-29 00:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dfd0f4b7c7d1

Merge


Changeset: b624f8613cc6
Author:    gsm
Date:      2009-07-15 19:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b624f8613cc6

6612541: api/javax_swing/text/LabelView/index.html#getXXX[LabelView0004] fails since JDK 7 b20
Reviewed-by: peterz

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

Changeset: f727cac13697
Author:    malenkov
Date:      2009-07-16 20:12 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f727cac13697

6505027: terminateEditOnFocusLost making problems for table in JDesktopPane
Reviewed-by: alexp

! src/share/classes/javax/swing/JInternalFrame.java
+ test/javax/swing/JInternalFrame/Test6505027.java

Changeset: 59249ab7aa16
Author:    peterz
Date:      2009-07-17 15:25 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59249ab7aa16

6387360: Usage of package-private class as a parameter of a method (javax.swing.text.ParagraphView)
Reviewed-by: malenkov

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

Changeset: 4575323d917c
Author:    peterz
Date:      2009-07-20 13:33 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4575323d917c

6857360: NimbusLAF: Menu indicator looks ugly with RTL orientation.
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/nimbus/NimbusIcon.java
! src/share/classes/sun/swing/MenuItemLayoutHelper.java

Changeset: a2114bbf7f3e
Author:    peterz
Date:      2009-07-20 13:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a2114bbf7f3e

6849331: Nimbus L&F: AbstractRegionPainter's paint context is not initialized
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java

Changeset: 125eff6f653f
Author:    malenkov
Date:      2009-07-22 12:21 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/125eff6f653f

6802868: JInternalFrame is not maximized when maximized parent frame.
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
+ test/javax/swing/JInternalFrame/Test6802868.java

Changeset: 9fc588f78952
Author:    rupashka
Date:      2009-07-23 17:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9fc588f78952

6460525: javax/swing/JFileChooser/6396844/TwentyThousandTest.java times out
Reviewed-by: malenkov, peterz

! src/share/classes/javax/swing/JFileChooser.java
! 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/share/classes/sun/swing/FilePane.java
! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java

Changeset: 5054103dc032
Author:    naoto
Date:      2009-06-30 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5054103dc032

6852429: IME should call ImmIsUIMessage() or DefWindowProc() when it receives WM_IME_SETCONTEX
Reviewed-by: peytoia

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

Changeset: 584fe3163de9
Author:    naoto
Date:      2009-07-23 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/584fe3163de9

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- src/share/classes/sun/swing/AccessibleMethod.java
! src/windows/native/sun/windows/awt_Component.cpp
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: 80d076251250
Author:    yan
Date:      2009-07-27 03:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/80d076251250

Merge


Changeset: 0ab4157789d9
Author:    malenkov
Date:      2009-07-28 13:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0ab4157789d9

6864297: Right-to-left oriented JScrollPane is aligned to the wrong direction while resizing the container
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java
+ test/javax/swing/JScrollPane/Test6526631.java
+ test/javax/swing/SwingTest.java

Changeset: 425fcb6d8af4
Author:    yan
Date:      2009-07-29 00:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/425fcb6d8af4

Merge

- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java

Changeset: a48b0984ef2e
Author:    yan
Date:      2009-08-05 00:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a48b0984ef2e

Merge

- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java

Changeset: fe61ef5aada9
Author:    wetmore
Date:      2009-08-03 18:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fe61ef5aada9

6647452: Remove obfuscation, framework and provider self-verification checking
Reviewed-by: valeriep, vinnie

! make/com/sun/crypto/provider/Makefile
! make/javax/crypto/Defs-jce.gmk
! make/javax/crypto/Makefile
! make/sun/security/mscapi/Makefile
! make/sun/security/pkcs11/Makefile
! src/share/classes/com/sun/crypto/provider/AESCipher.java
! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/AESWrapCipher.java
! src/share/classes/com/sun/crypto/provider/ARCFOURCipher.java
! src/share/classes/com/sun/crypto/provider/BlowfishCipher.java
! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/DESCipher.java
! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java
! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/DESedeCipher.java
! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java
! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java
! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java
! src/share/classes/com/sun/crypto/provider/HmacCore.java
! src/share/classes/com/sun/crypto/provider/HmacMD5.java
! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java
! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java
! src/share/classes/com/sun/crypto/provider/HmacSHA1.java
! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java
- src/share/classes/com/sun/crypto/provider/JarVerifier.java
! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java
! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java
! src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java
! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/RC2Cipher.java
! src/share/classes/com/sun/crypto/provider/RSACipher.java
! src/share/classes/com/sun/crypto/provider/SslMacCore.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java
! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java
! src/share/classes/javax/crypto/JarVerifier.java
! src/share/classes/javax/crypto/JceSecurity.java
- src/share/classes/sun/security/pkcs11/JarVerifier.java
! src/share/classes/sun/security/pkcs11/SunPKCS11.java
- src/windows/classes/sun/security/mscapi/JarVerifier.java
! src/windows/classes/sun/security/mscapi/RSACipher.java
! src/windows/classes/sun/security/mscapi/SunMSCAPI.java

Changeset: b23d905cb5d3
Author:    xdono
Date:      2009-08-05 11:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b23d905cb5d3

Merge

- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java

Changeset: 9ae4027c5fe1
Author:    xdono
Date:      2009-08-06 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ae4027c5fe1

Added tag jdk7-b68 for changeset b23d905cb5d3

! .hgtags

Changeset: bf41e885717f
Author:    tbell
Date:      2009-08-06 19:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf41e885717f

Merge

- test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java
- test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java



From tim.bell at sun.com  Fri Aug  7 03:36:31 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 07 Aug 2009 03:36:31 +0000
Subject: hg: jdk7/tl/langtools: 3 new changesets
Message-ID: <20090807033640.A0E56E680@hg.openjdk.java.net>

Changeset: ce9bcdcb7859
Author:    xdono
Date:      2009-08-06 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ce9bcdcb7859

Added tag jdk7-b68 for changeset 95c1212b07e3

! .hgtags

Changeset: b5ab848ba68f
Author:    tbell
Date:      2009-08-06 19:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b5ab848ba68f

Merge


Changeset: 3e38c6da72ec
Author:    tbell
Date:      2009-08-06 20:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3e38c6da72ec

Merge




From christopher.hegarty at sun.com  Fri Aug  7 09:59:50 2009
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Fri, 07 Aug 2009 09:59:50 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090807100119.48D4BE754@hg.openjdk.java.net>

Changeset: 0d99696fec64
Author:    chegar
Date:      2009-08-07 10:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d99696fec64

6826780: URLClassPath should use HashMap<String, XXX> instead of HashMap<URL, XXX>
Summary: Replace URL with a String representation.
Reviewed-by: michaelm, jccollet

! make/sun/net/FILES_java.gmk
! src/share/classes/sun/misc/URLClassPath.java
+ src/share/classes/sun/net/util/URLUtil.java

Changeset: 9424d836691f
Author:    chegar
Date:      2009-08-07 10:51 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9424d836691f

6826801: JarFileFactory should not use HashMap<URL>
Summary: Replace URL with a String representation.
Reviewed-by: michaelm, jccollet

! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java



From gnu_andrew at member.fsf.org  Fri Aug  7 16:00:46 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 7 Aug 2009 17:00:46 +0100
Subject: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from 
	FILES_java.gmk
Message-ID: <17c6771e0908070900m72ba0590h4fb01ae9fa5bb527@mail.gmail.com>

When java.lang.ReflectiveOperationException was added in:

http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e

it wasn't added to make/java/java/FILES_java.gmk.  Although it still
seems to end up in rt.jar when building with IcedTea as the bootstrap
JDK, it fails when using gcj+ecj (which we use in a full bootstrap).

Is there any reason not to explicitly add the file like the others,
rather than relying on the compiler to do so (or not as the case may
be)?

There's a webrev here:
http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Joe.Darcy at Sun.COM  Fri Aug  7 16:13:49 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 07 Aug 2009 09:13:49 -0700
Subject: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from
	FILES_java.gmk
In-Reply-To: <17c6771e0908070900m72ba0590h4fb01ae9fa5bb527@mail.gmail.com>
References: <17c6771e0908070900m72ba0590h4fb01ae9fa5bb527@mail.gmail.com>
Message-ID: <4A7C52BD.4080304@sun.com>

Andrew John Hughes wrote:
> When java.lang.ReflectiveOperationException was added in:
>
> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e
>
> it wasn't added to make/java/java/FILES_java.gmk.  Although it still
> seems to end up in rt.jar when building with IcedTea as the bootstrap
> JDK, it fails when using gcj+ecj (which we use in a full bootstrap).
>
> Is there any reason not to explicitly add the file like the others,
> rather than relying on the compiler to do so (or not as the case may
> be)?
>
> There's a webrev here:
> http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix.
>   

Hmm, curious.  Yes, it does seem the file belongs be on the list in 
FILES_java.gmk; the new class is a superclass of some of the exception 
classes on the list so it gets pulled in, at least by javac.

However, I'm a bit surprised at the use of such a list in the current build.

Kelly, I thought specifying files was generally done at a 
package/directory level now?  What kind of files need to go into 
FILES_java.gmk?

-Joe


From abhijit.saha at sun.com  Fri Aug  7 16:29:35 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Fri, 07 Aug 2009 16:29:35 +0000
Subject: hg: jdk7/tl/jaxp: 7 new changesets
Message-ID: <20090807162946.29627E839@hg.openjdk.java.net>

Changeset: 1687f5192ce7
Author:    asaha
Date:      2009-06-22 13:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/1687f5192ce7

6845701: Xerces2 Java XML library infinite loop with malformed XML input
Reviewed-by: hawtin

! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java

Changeset: 1b3c6eec7d31
Author:    asaha
Date:      2009-06-30 16:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/1b3c6eec7d31

Merge


Changeset: e8d3c15bb7f6
Author:    asaha
Date:      2009-07-06 11:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/e8d3c15bb7f6

Merge


Changeset: 1c82b475604f
Author:    asaha
Date:      2009-07-21 11:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/1c82b475604f

Merge


Changeset: fb3829850f08
Author:    asaha
Date:      2009-07-27 22:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/fb3829850f08

Merge


Changeset: 66f9efcdd76c
Author:    asaha
Date:      2009-08-03 12:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/66f9efcdd76c

Merge


Changeset: 16184436ba33
Author:    asaha
Date:      2009-08-06 22:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/16184436ba33

Merge




From Kelly.Ohair at Sun.COM  Fri Aug  7 16:35:34 2009
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Fri, 07 Aug 2009 09:35:34 -0700
Subject: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from
	FILES_java.gmk
In-Reply-To: <4A7C52BD.4080304@sun.com>
References: <17c6771e0908070900m72ba0590h4fb01ae9fa5bb527@mail.gmail.com>
	<4A7C52BD.4080304@sun.com>
Message-ID: <4A7C57D6.4090205@sun.com>



Joseph D. Darcy wrote:
> Andrew John Hughes wrote:
>> When java.lang.ReflectiveOperationException was added in:
>>
>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e
>>
>> it wasn't added to make/java/java/FILES_java.gmk.  Although it still
>> seems to end up in rt.jar when building with IcedTea as the bootstrap
>> JDK, it fails when using gcj+ecj (which we use in a full bootstrap).
>>
>> Is there any reason not to explicitly add the file like the others,
>> rather than relying on the compiler to do so (or not as the case may
>> be)?
>>
>> There's a webrev here:
>> http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix.
>>   
> 
> Hmm, curious.  Yes, it does seem the file belongs be on the list in 
> FILES_java.gmk; the new class is a superclass of some of the exception 
> classes on the list so it gets pulled in, at least by javac.
> 
> However, I'm a bit surprised at the use of such a list in the current 
> build.
> 
> Kelly, I thought specifying files was generally done at a 
> package/directory level now?  What kind of files need to go into 
> FILES_java.gmk?

I added in an AUTO setting option to the Makefiles where you could just
list packages and the Makefile logic would just get the full list of
files automatically (using find on all the source areas).
But not all the Makefiles were converted to this mechanism.
When I did convert a Makefile, I'd usually delete the retired
FILES_java.gmk file. The make/java/java builds were not so simple.

The one line fix is fine, but I'd prefer to get rid of the explicit
list someday.

-kto

> 
> -Joe


From gnu_andrew at member.fsf.org  Fri Aug  7 16:45:09 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 7 Aug 2009 17:45:09 +0100
Subject: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from 
	FILES_java.gmk
In-Reply-To: <4A7C57D6.4090205@sun.com>
References: <17c6771e0908070900m72ba0590h4fb01ae9fa5bb527@mail.gmail.com>
	<4A7C52BD.4080304@sun.com> <4A7C57D6.4090205@sun.com>
Message-ID: <17c6771e0908070945v17b647a0p44d391eee6612b6@mail.gmail.com>

2009/8/7 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
>
> Joseph D. Darcy wrote:
>>
>> Andrew John Hughes wrote:
>>>
>>> When java.lang.ReflectiveOperationException was added in:
>>>
>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e
>>>
>>> it wasn't added to make/java/java/FILES_java.gmk. ?Although it still
>>> seems to end up in rt.jar when building with IcedTea as the bootstrap
>>> JDK, it fails when using gcj+ecj (which we use in a full bootstrap).
>>>
>>> Is there any reason not to explicitly add the file like the others,
>>> rather than relying on the compiler to do so (or not as the case may
>>> be)?
>>>
>>> There's a webrev here:
>>> http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix.
>>>
>>
>> Hmm, curious. ?Yes, it does seem the file belongs be on the list in
>> FILES_java.gmk; the new class is a superclass of some of the exception
>> classes on the list so it gets pulled in, at least by javac.
>>
>> However, I'm a bit surprised at the use of such a list in the current
>> build.
>>
>> Kelly, I thought specifying files was generally done at a
>> package/directory level now? ?What kind of files need to go into
>> FILES_java.gmk?
>
> I added in an AUTO setting option to the Makefiles where you could just
> list packages and the Makefile logic would just get the full list of
> files automatically (using find on all the source areas).
> But not all the Makefiles were converted to this mechanism.
> When I did convert a Makefile, I'd usually delete the retired
> FILES_java.gmk file. The make/java/java builds were not so simple.
>
> The one line fix is fine, but I'd prefer to get rid of the explicit
> list someday.
>
> -kto
>
>>
>> -Joe
>

Ok, if someone can allocate me a Sun bug ID for it, I'll push the fix :)

I think generally it would be nice to combine some of these javac
calls and that might be the solution for java/java which crosses
multiple packages.  One of the reasons OpenJDK builds take so long
seem to be because it invokes javac a lot, in some cases for only a
couple of files.  Thus, each new invocation is not taking advantage of
any code that was JITed in the last run.  It's also why a native build
of ecj outperforms javac+HotSpot significantly.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From abhijit.saha at sun.com  Fri Aug  7 16:40:39 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Fri, 07 Aug 2009 16:40:39 +0000
Subject: hg: jdk7/tl/jdk: 42 new changesets
Message-ID: <20090807165259.3153AE886@hg.openjdk.java.net>

Changeset: c43105502f46
Author:    malenkov
Date:      2009-04-29 20:03 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c43105502f46

6660539: Introspector shares cache of mutable BeanInfo between AppContexts.
Reviewed-by: peterz

! src/share/classes/java/beans/Introspector.java
+ test/java/beans/Introspector/Test6660539.java

Changeset: 3aeaa5784b3a
Author:    malenkov
Date:      2009-04-29 20:55 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3aeaa5784b3a

6777487: Encoder allows reading private variables with certain names
Reviewed-by: peterz

! src/share/classes/java/beans/MetaData.java
+ test/java/beans/XMLEncoder/6777487/TestBox.java
+ test/java/beans/XMLEncoder/6777487/TestCheckedCollection.java
+ test/java/beans/XMLEncoder/6777487/TestCheckedList.java
+ test/java/beans/XMLEncoder/6777487/TestCheckedMap.java
+ test/java/beans/XMLEncoder/6777487/TestCheckedRandomAccessList.java
+ test/java/beans/XMLEncoder/6777487/TestCheckedSet.java
+ test/java/beans/XMLEncoder/6777487/TestCheckedSortedMap.java
+ test/java/beans/XMLEncoder/6777487/TestCheckedSortedSet.java
+ test/java/beans/XMLEncoder/6777487/TestEncoder.java
+ test/java/beans/XMLEncoder/6777487/TestEnumMap.java
+ test/java/beans/XMLEncoder/6777487/TestEnumSet.java

Changeset: 903ce4bda292
Author:    asaha
Date:      2009-04-29 11:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/903ce4bda292

Merge


Changeset: 5b166df43d63
Author:    peterz
Date:      2009-05-05 12:07 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b166df43d63

6837293: Reapply fix for 6588003 to JDK7
Reviewed-by: alexp

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

Changeset: ead34d1e3c9f
Author:    jccollet
Date:      2009-05-05 11:02 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ead34d1e3c9f

6801497: Proxy is assumed to be immutable but is non-final
Summary: Cloned the proxy instance when necessary
Reviewed-by: chegar

! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/URL.java

Changeset: 38a0e21f345a
Author:    anthony
Date:      2009-05-05 17:47 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38a0e21f345a

6805231: Security Warning Icon is missing in Windows 2000 Prof from Jdk build 6u12
Summary: The icon becomes layered only when the fading-out effect is being performed.
Reviewed-by: art, dcherepanov

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

Changeset: e0636bb69562
Author:    anthony
Date:      2009-05-05 17:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0636bb69562

6818787: It is possible to reposition the security icon too far from the border of the window on X11
Summary: The constraints for the position of the icon are moved to the shared code
Reviewed-by: art, dcherepanov

! src/share/classes/java/awt/Window.java
! src/windows/native/sun/windows/awt_Window.cpp

Changeset: 4b498e41c1c2
Author:    art
Date:      2009-05-06 15:17 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b498e41c1c2

6656586: Cursor.predefined is protected static mutable (findbugs)
Reviewed-by: hawtin, igor

! src/share/classes/java/awt/Cursor.java
+ test/java/awt/Cursor/PredefinedPrivate/PredefinedPrivate.java

Changeset: a53a57a3260c
Author:    emcmanus
Date:      2009-05-07 10:44 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a53a57a3260c

6736293: OpenType checks can be bypassed through finalizer resurrection
Reviewed-by: hawtin

! src/share/classes/java/awt/Window.java
! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenType.java

Changeset: 7b50813648d8
Author:    bae
Date:      2009-05-08 15:38 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b50813648d8

6656625: ImageReaderSpi.STANDARD_INPUT_TYPE/ImageWriterSpi.STANDARD_OUTPUT_TYPE are mutable static (findbugs)
Reviewed-by: prr

! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriterSpi.java
! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java
! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriterSpi.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriterSpi.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriterSpi.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriterSpi.java
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageWriterSpi.java

Changeset: c6ea5b6c3a8d
Author:    bae
Date:      2009-05-08 15:57 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6ea5b6c3a8d

6657133: Mutable statics in imageio plugins (findbugs)
Reviewed-by: prr

! src/share/classes/com/sun/imageio/stream/StreamCloser.java
! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
! src/share/classes/javax/imageio/stream/FileCacheImageInputStream.java
! src/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java
! src/share/lib/security/java.security
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 597377f1ee71
Author:    bae
Date:      2009-05-08 16:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/597377f1ee71

6823373: [ZDI-CAN-460] Java Web Start JPEG header parsing needs more scruity
Reviewed-by: igor

! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c

Changeset: 3de7b0daf355
Author:    chegar
Date:      2009-05-12 16:32 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3de7b0daf355

6801071: Remote sites can compromise user privacy and possibly hijack web sessions
Reviewed-by: jccollet, hawtin

! make/sun/net/FILES_java.gmk
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/URL.java
+ src/share/classes/sun/net/ApplicationProxy.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 05200aff312e
Author:    amenkov
Date:      2009-05-13 13:52 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05200aff312e

6657625: RmfFileReader/StandardMidiFileWriter.types are public mutable statics (findbugs)
Reviewed-by: hawtin

! src/share/classes/com/sun/media/sound/StandardMidiFileWriter.java

Changeset: d09b81d1eb85
Author:    amenkov
Date:      2009-05-13 14:32 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d09b81d1eb85

6738524: JDK13Services allows read access to system properties from untrusted code
Reviewed-by: hawtin

! src/share/classes/com/sun/media/sound/JDK13Services.java

Changeset: 43ed4f9a781a
Author:    amenkov
Date:      2009-05-13 14:32 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/43ed4f9a781a

6777448: JDK13Services.getProviders creates instances with full privileges [hawtin, alexp]
Reviewed-by: hawtin, alexp

! src/share/classes/com/sun/media/sound/JSSecurityManager.java

Changeset: ae62878e6eef
Author:    asaha
Date:      2009-05-07 13:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae62878e6eef

Merge

! src/share/classes/java/awt/Window.java
- src/share/native/sun/java2d/pipe/RenderBuffer.c
! src/windows/native/sun/windows/awt_Window.cpp
! src/windows/native/sun/windows/awt_Window.h
- test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java

Changeset: bf002235470d
Author:    asaha
Date:      2009-06-12 10:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf002235470d

Merge


Changeset: 8156e661d016
Author:    asaha
Date:      2009-06-12 12:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8156e661d016

Merge

! src/share/classes/java/awt/Window.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
! src/windows/native/sun/windows/awt_Window.cpp
! src/windows/native/sun/windows/awt_Window.h

Changeset: f2d65a92ffb2
Author:    malenkov
Date:      2009-06-18 14:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f2d65a92ffb2

6660049: Synth Region.uiToRegionMap/lowerCaseNameMap are mutable statics
Reviewed-by: hawtin

! src/share/classes/javax/swing/plaf/synth/Region.java
+ test/javax/swing/plaf/synth/Test6660049.java

Changeset: a209372d6de8
Author:    asaha
Date:      2009-06-17 13:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a209372d6de8

Merge


Changeset: 2f126d8c369d
Author:    asaha
Date:      2009-06-18 22:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2f126d8c369d

Merge


Changeset: 94bd5497a0d3
Author:    asaha
Date:      2009-06-18 22:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94bd5497a0d3

Merge


Changeset: 75fe05d49f44
Author:    asaha
Date:      2009-06-22 13:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75fe05d49f44

6656610: AccessibleResourceBundle.getContents exposes mutable static (findbugs)
Reviewed-by: hawtin

! src/share/classes/javax/accessibility/AccessibleResourceBundle.java

Changeset: ffb8e36b668c
Author:    mullan
Date:      2009-06-23 13:54 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ffb8e36b668c

6824440: XML Signature HMAC issue
Reviewed-by: asaha

! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java
+ test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java
+ test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1-trunclen-0-attack.xml
+ test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1-trunclen-8-attack.xml
! test/javax/xml/crypto/dsig/GenerationTests.java
! test/javax/xml/crypto/dsig/ValidationTests.java
+ test/javax/xml/crypto/dsig/data/signature-enveloping-hmac-sha1-trunclen-0-attack.xml
+ test/javax/xml/crypto/dsig/data/signature-enveloping-hmac-sha1-trunclen-8-attack.xml

Changeset: 7352778840c7
Author:    ksrini
Date:      2009-06-22 07:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7352778840c7

6830335: Java JAR Pack200 Decompression Integer Overflow Vulnerability
Summary: Fixes a potential vulnerability in the unpack200 logic, by adding extra checks, a back-port.
Reviewed-by: asaha

! src/share/native/com/sun/java/util/jar/pack/unpack.cpp

Changeset: 043280e1fc76
Author:    asaha
Date:      2009-07-01 09:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/043280e1fc76

Merge

! make/sun/net/FILES_java.gmk
! src/share/classes/java/net/SocksSocketImpl.java
- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: 46e4a2e56801
Author:    asaha
Date:      2009-07-06 11:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/46e4a2e56801

Merge

! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: e2726b43d1cc
Author:    mullan
Date:      2009-07-08 16:57 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e2726b43d1cc

6858484: If an invalid HMAC XML Signature is validated, all subsequent valid HMAC signatures are invalid
Reviewed-by: asaha

! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java
+ test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1.xml

Changeset: 78a1ffa5a675
Author:    asaha
Date:      2009-07-08 14:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78a1ffa5a675

Merge


Changeset: 9b15d9813292
Author:    asaha
Date:      2009-07-08 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b15d9813292

Merge


Changeset: 537d8716d8cd
Author:    asaha
Date:      2009-07-13 08:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/537d8716d8cd

Merge


Changeset: 599a7f770842
Author:    asaha
Date:      2009-07-15 10:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/599a7f770842

Merge


Changeset: 97a5d7c6fbfb
Author:    vinnie
Date:      2009-07-17 20:29 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/97a5d7c6fbfb

6657619: DnsContext.debug is public static mutable (findbugs)
Reviewed-by: alanb

! src/share/classes/com/sun/jndi/dns/DnsContext.java
+ test/com/sun/jndi/dns/CheckAccess.java

Changeset: df7d8ae860cf
Author:    vinnie
Date:      2009-07-17 20:43 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df7d8ae860cf

6657695: AbstractSaslImpl.logger is a static mutable (findbugs)
Reviewed-by: alanb

! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
+ test/com/sun/security/sasl/util/CheckAccess.java

Changeset: 83d1885b22d6
Author:    asaha
Date:      2009-07-21 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83d1885b22d6

Merge

! src/share/classes/java/awt/Window.java
! src/share/classes/java/beans/MetaData.java
- src/share/classes/sun/swing/AccessibleMethod.java

Changeset: 14c81c80a7f3
Author:    asaha
Date:      2009-07-21 13:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/14c81c80a7f3

Merge


Changeset: baec332a0ff4
Author:    asaha
Date:      2009-07-27 22:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/baec332a0ff4

Merge


Changeset: ebc7d26588b8
Author:    asaha
Date:      2009-08-04 08:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ebc7d26588b8

Merge

! src/share/classes/java/awt/Window.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/java/beans/MetaData.java
- test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java
- test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java

Changeset: 6fe590dcc49c
Author:    asaha
Date:      2009-08-05 14:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6fe590dcc49c

Merge


Changeset: c223ce2294c1
Author:    asaha
Date:      2009-08-06 22:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c223ce2294c1

Merge

- src/share/classes/com/sun/crypto/provider/JarVerifier.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
- src/share/classes/sun/security/pkcs11/JarVerifier.java
- src/windows/classes/sun/security/mscapi/JarVerifier.java

Changeset: 1774d87963ad
Author:    asaha
Date:      2009-08-07 09:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1774d87963ad

Merge

! make/sun/net/FILES_java.gmk



From Kelly.Ohair at Sun.COM  Fri Aug  7 17:06:04 2009
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Fri, 07 Aug 2009 10:06:04 -0700
Subject: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from
	FILES_java.gmk
In-Reply-To: <17c6771e0908070945v17b647a0p44d391eee6612b6@mail.gmail.com>
References: <17c6771e0908070900m72ba0590h4fb01ae9fa5bb527@mail.gmail.com>
	<4A7C52BD.4080304@sun.com> <4A7C57D6.4090205@sun.com>
	<17c6771e0908070945v17b647a0p44d391eee6612b6@mail.gmail.com>
Message-ID: <4A7C5EFC.80603@sun.com>



Andrew John Hughes wrote:
> 2009/8/7 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>
>> Joseph D. Darcy wrote:
>>> Andrew John Hughes wrote:
>>>> When java.lang.ReflectiveOperationException was added in:
>>>>
>>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e
>>>>
>>>> it wasn't added to make/java/java/FILES_java.gmk.  Although it still
>>>> seems to end up in rt.jar when building with IcedTea as the bootstrap
>>>> JDK, it fails when using gcj+ecj (which we use in a full bootstrap).
>>>>
>>>> Is there any reason not to explicitly add the file like the others,
>>>> rather than relying on the compiler to do so (or not as the case may
>>>> be)?
>>>>
>>>> There's a webrev here:
>>>> http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix.
>>>>
>>> Hmm, curious.  Yes, it does seem the file belongs be on the list in
>>> FILES_java.gmk; the new class is a superclass of some of the exception
>>> classes on the list so it gets pulled in, at least by javac.
>>>
>>> However, I'm a bit surprised at the use of such a list in the current
>>> build.
>>>
>>> Kelly, I thought specifying files was generally done at a
>>> package/directory level now?  What kind of files need to go into
>>> FILES_java.gmk?
>> I added in an AUTO setting option to the Makefiles where you could just
>> list packages and the Makefile logic would just get the full list of
>> files automatically (using find on all the source areas).
>> But not all the Makefiles were converted to this mechanism.
>> When I did convert a Makefile, I'd usually delete the retired
>> FILES_java.gmk file. The make/java/java builds were not so simple.
>>
>> The one line fix is fine, but I'd prefer to get rid of the explicit
>> list someday.
>>
>> -kto
>>
>>> -Joe
> 
> Ok, if someone can allocate me a Sun bug ID for it, I'll push the fix :)
> 
> I think generally it would be nice to combine some of these javac
> calls and that might be the solution for java/java which crosses
> multiple packages.  One of the reasons OpenJDK builds take so long
> seem to be because it invokes javac a lot, in some cases for only a
> couple of files.  Thus, each new invocation is not taking advantage of
> any code that was JITed in the last run.  It's also why a native build
> of ecj outperforms javac+HotSpot significantly.

Yup. I agree.  One of the primary reasons ant build scripts are so much
faster, as long as they avoid fork=true and exec tasks. ;^)

I'll file a bug for you:

   6869697: Missing entry in makefiles for java/lang/ReflectiveOperationException.java

-kto



From ahughes at redhat.com  Fri Aug  7 17:28:31 2009
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Fri, 07 Aug 2009 17:28:31 +0000
Subject: hg: jdk7/tl/jdk: 6869697: Missing entry in makefiles for
	java/lang/ReflectiveOperationException.java
Message-ID: <20090807172906.0F991E8BE@hg.openjdk.java.net>

Changeset: 88229bdd8aae
Author:    andrew
Date:      2009-08-07 18:15 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/88229bdd8aae

6869697: Missing entry in makefiles for java/lang/ReflectiveOperationException.java
Summary: Add new dependency explicitly so all compilers pick it up
Reviewed-by: darcy, ohair

! make/java/java/FILES_java.gmk



From Alan.Bateman at Sun.COM  Fri Aug  7 18:01:03 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 07 Aug 2009 19:01:03 +0100
Subject: Review request for 4516760:  (so) Intermittent SocketException:
	Transport endpoint is not connected (lnx)
Message-ID: <4A7C6BDF.1090308@sun.com>

I need a reviewer for this tiny change. The shutdown(2) call fails with 
ENOTCONN when the socket is not connected. This seems to have different 
interpretations, at least for the case where the connection has been 
reset by the peer.  Solaris and Windows do not return the error for this 
case, Linux does, and this can cause applications using 
SocketChannel.shutdown{Input,Output} (or the adapter equivalents) to 
fail intermittently. Grizzly and others have run into this. We don't see 
this with classic networking because the return value isn't checked. The 
proposed fix is to ignore this specific error, which is harmless because 
the socket channel implementation checks the channel state before 
calling shutdown. The webrev is here:
  http://cr.openjdk.java.net/~alanb/4516760/webrev.00/

Thanks,
Alan.


From gnu_andrew at member.fsf.org  Fri Aug  7 18:04:52 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 7 Aug 2009 19:04:52 +0100
Subject: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from 
	FILES_java.gmk
In-Reply-To: <4A7C5EFC.80603@sun.com>
References: <17c6771e0908070900m72ba0590h4fb01ae9fa5bb527@mail.gmail.com>
	<4A7C52BD.4080304@sun.com> <4A7C57D6.4090205@sun.com>
	<17c6771e0908070945v17b647a0p44d391eee6612b6@mail.gmail.com>
	<4A7C5EFC.80603@sun.com>
Message-ID: <17c6771e0908071104pe6215ecr534dc7ddddb8067a@mail.gmail.com>

2009/8/7 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
>
> Andrew John Hughes wrote:
>>
>> 2009/8/7 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>>
>>> Joseph D. Darcy wrote:
>>>>
>>>> Andrew John Hughes wrote:
>>>>>
>>>>> When java.lang.ReflectiveOperationException was added in:
>>>>>
>>>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e
>>>>>
>>>>> it wasn't added to make/java/java/FILES_java.gmk. ?Although it still
>>>>> seems to end up in rt.jar when building with IcedTea as the bootstrap
>>>>> JDK, it fails when using gcj+ecj (which we use in a full bootstrap).
>>>>>
>>>>> Is there any reason not to explicitly add the file like the others,
>>>>> rather than relying on the compiler to do so (or not as the case may
>>>>> be)?
>>>>>
>>>>> There's a webrev here:
>>>>> http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix.
>>>>>
>>>> Hmm, curious. ?Yes, it does seem the file belongs be on the list in
>>>> FILES_java.gmk; the new class is a superclass of some of the exception
>>>> classes on the list so it gets pulled in, at least by javac.
>>>>
>>>> However, I'm a bit surprised at the use of such a list in the current
>>>> build.
>>>>
>>>> Kelly, I thought specifying files was generally done at a
>>>> package/directory level now? ?What kind of files need to go into
>>>> FILES_java.gmk?
>>>
>>> I added in an AUTO setting option to the Makefiles where you could just
>>> list packages and the Makefile logic would just get the full list of
>>> files automatically (using find on all the source areas).
>>> But not all the Makefiles were converted to this mechanism.
>>> When I did convert a Makefile, I'd usually delete the retired
>>> FILES_java.gmk file. The make/java/java builds were not so simple.
>>>
>>> The one line fix is fine, but I'd prefer to get rid of the explicit
>>> list someday.
>>>
>>> -kto
>>>
>>>> -Joe
>>
>> Ok, if someone can allocate me a Sun bug ID for it, I'll push the fix :)
>>
>> I think generally it would be nice to combine some of these javac
>> calls and that might be the solution for java/java which crosses
>> multiple packages. ?One of the reasons OpenJDK builds take so long
>> seem to be because it invokes javac a lot, in some cases for only a
>> couple of files. ?Thus, each new invocation is not taking advantage of
>> any code that was JITed in the last run. ?It's also why a native build
>> of ecj outperforms javac+HotSpot significantly.
>
> Yup. I agree. ?One of the primary reasons ant build scripts are so much
> faster, as long as they avoid fork=true and exec tasks. ;^)
>
> I'll file a bug for you:
>
> ?6869697: Missing entry in makefiles for
> java/lang/ReflectiveOperationException.java
>

Great, thanks.
Pushed: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/88229bdd8aae

> -kto
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Xueming.Shen at Sun.COM  Sat Aug  8 20:25:10 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Sat, 08 Aug 2009 13:25:10 -0700
Subject: Review request for 4516760:  (so) Intermittent SocketException:
	Transport endpoint is not connected (lnx)
In-Reply-To: <4A7C6BDF.1090308@sun.com>
References: <4A7C6BDF.1090308@sun.com>
Message-ID: <4A7DDF26.5070102@sun.com>

looks fine.

Alan Bateman wrote:
> I need a reviewer for this tiny change. The shutdown(2) call fails 
> with ENOTCONN when the socket is not connected. This seems to have 
> different interpretations, at least for the case where the connection 
> has been reset by the peer.  Solaris and Windows do not return the 
> error for this case, Linux does, and this can cause applications using 
> SocketChannel.shutdown{Input,Output} (or the adapter equivalents) to 
> fail intermittently. Grizzly and others have run into this. We don't 
> see this with classic networking because the return value isn't 
> checked. The proposed fix is to ignore this specific error, which is 
> harmless because the socket channel implementation checks the channel 
> state before calling shutdown. The webrev is here:
>  http://cr.openjdk.java.net/~alanb/4516760/webrev.00/
>
> Thanks,
> Alan.



From jonathan.gibbons at sun.com  Sun Aug  9 01:18:10 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Sun, 09 Aug 2009 01:18:10 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20090809011817.5EAF6E938@hg.openjdk.java.net>

Changeset: cba827f72977
Author:    jjg
Date:      2009-08-08 17:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cba827f72977

6868548: remove spurious ';' from after constant pool entries
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/ConstantWriter.java
! test/tools/javac/code/ArrayClone.java

Changeset: 961dc3acdb06
Author:    jjg
Date:      2009-08-08 17:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/961dc3acdb06

6868539: javap should use current names for constant pool tags
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/ConstantWriter.java
+ test/tools/javap/T6868539.java



From Ulf.Zibis at gmx.de  Mon Aug 10 23:58:02 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Aug 2009 01:58:02 +0200
Subject: javac CRASH
In-Reply-To: <4A7834DB.7020708@univ-mlv.fr>
References: <4A77F8CB.2070200@gmx.de>
	<4A77FAA8.5020101@sun.com>	<4A77FC5F.8020407@gmx.de>
	<4A780B67.3080809@sun.com> <4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr>
Message-ID: <4A80B40A.8090704@gmx.de>

R?mi, thanks.

I just tried it, but got errors:

C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
6.7.1\java2\ant\bin\ant"
Buildfile: build.xml

-def-check:

-check-boot.java.home:

BUILD FAILED
C:\Projects\OpenJDK7\langtools\make\build.xml:370: The following error 
occurred
while executing this line:
C:\Projects\OpenJDK7\langtools\make\build.xml:737: Cannot locate 
bootstrap java:
 please set boot.java.home to its location

Total time: 1 second


-Ulf


Am 04.08.2009 15:17, R?mi Forax schrieb:
> Le 04/08/2009 13:07, Ulf Zibis a ?crit :
>> Maurizio,
>>
>> much thanks for the additional info.
>>
>> I like to avoid going back to b63.
>> If the fix will not go into b68, could you please provide a binary 
>> patch for b67 (or b68) (Windows version)?
>> I can wait for release of b68, but not for b69, as I'm on vacation 
>> until Aug. 10.
>>
>> Thanks in advance,
>>
>> -Ulf
>
> you can do it by yourself,
> clone the langtools repository, it can be built with ant, so just type 
> ant
> in the directory "make", it will create a tools.jar.
> Now remplace the tools.jar of your binary build by this new one.
>
> cheers,
> R?mi
>
>>
>>
>> Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
>>> Ulf Zibis wrote:
>>>> Maurizio,
>>>>
>>>> much thanks for the fast info.
>>>>
>>>> Will this fix be included in next build b68 ???
>>>> Hopefully !
>>> Not sure if it will make into b68 - but certainly it will go into 
>>> b69 (depends on the integration process). The fix is already 
>>> available in the langtools repository used for development 
>>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>>
>>> Maurizio
>>>>
>>>> -Ulf
>>>>
>>>>
>>>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>>>> Ulf Zibis wrote:
>>>>>> See:
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>>>
>>>>>> -Ulf
>>>>>>
>>>>>>
>>>>> Hi Ulf,
>>>>> this is a type annotation (JSR 308) bug that has been recently 
>>>>> fixed - it is a duplicate of 6861837.
>>>>>
>>>>> Regards
>>>>> Maurizio
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From forax at univ-mlv.fr  Tue Aug 11 00:25:07 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 11 Aug 2009 02:25:07 +0200
Subject: javac CRASH
In-Reply-To: <4A80B40A.8090704@gmx.de>
References: <4A77F8CB.2070200@gmx.de>
	<4A77FAA8.5020101@sun.com>	<4A77FC5F.8020407@gmx.de>
	<4A780B67.3080809@sun.com> <4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
Message-ID: <4A80BA63.7010606@univ-mlv.fr>

Le 11/08/2009 01:58, Ulf Zibis a ?crit :
> R?mi, thanks.
>
> I just tried it, but got errors:
>
> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
> 6.7.1\java2\ant\bin\ant"
> Buildfile: build.xml
>
> -def-check:
>
> -check-boot.java.home:
>
> BUILD FAILED
> C:\Projects\OpenJDK7\langtools\make\build.xml:370: The following error 
> occurred
> while executing this line:
> C:\Projects\OpenJDK7\langtools\make\build.xml:737: Cannot locate 
> bootstrap java:
> please set boot.java.home to its location
>
> Total time: 1 second
>
>
> -Ulf

as said, set the bootstrap location,
with bash:
export ALT_BOOTDIR=path_to_a_binary_jdk6or7

R?mi

>
>
> Am 04.08.2009 15:17, R?mi Forax schrieb:
>> Le 04/08/2009 13:07, Ulf Zibis a ?crit :
>>> Maurizio,
>>>
>>> much thanks for the additional info.
>>>
>>> I like to avoid going back to b63.
>>> If the fix will not go into b68, could you please provide a binary 
>>> patch for b67 (or b68) (Windows version)?
>>> I can wait for release of b68, but not for b69, as I'm on vacation 
>>> until Aug. 10.
>>>
>>> Thanks in advance,
>>>
>>> -Ulf
>>
>> you can do it by yourself,
>> clone the langtools repository, it can be built with ant, so just 
>> type ant
>> in the directory "make", it will create a tools.jar.
>> Now remplace the tools.jar of your binary build by this new one.
>>
>> cheers,
>> R?mi
>>
>>>
>>>
>>> Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
>>>> Ulf Zibis wrote:
>>>>> Maurizio,
>>>>>
>>>>> much thanks for the fast info.
>>>>>
>>>>> Will this fix be included in next build b68 ???
>>>>> Hopefully !
>>>> Not sure if it will make into b68 - but certainly it will go into 
>>>> b69 (depends on the integration process). The fix is already 
>>>> available in the langtools repository used for development 
>>>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>>>
>>>> Maurizio
>>>>>
>>>>> -Ulf
>>>>>
>>>>>
>>>>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>>>>> Ulf Zibis wrote:
>>>>>>> See:
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>>>>
>>>>>>> -Ulf
>>>>>>>
>>>>>>>
>>>>>> Hi Ulf,
>>>>>> this is a type annotation (JSR 308) bug that has been recently 
>>>>>> fixed - it is a duplicate of 6861837.
>>>>>>
>>>>>> Regards
>>>>>> Maurizio
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>



From Jonathan.Gibbons at Sun.COM  Tue Aug 11 00:50:17 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Mon, 10 Aug 2009 17:50:17 -0700
Subject: javac CRASH
In-Reply-To: <4A80BA63.7010606@univ-mlv.fr>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr>
Message-ID: <4A80C049.2020202@sun.com>

R?mi , Ulf,

If you're driving Ant directly, you want to set the Ant property 
boot.java.home,
not the Makefile variable ALT_BOOTDIR.
    ant -Dboot.java.home=path-to-jdk6or7 more-args....

The path should be to the root of the installed JDK, not any of its 
subdirectories.
For example, if you've installed JDK 1.7 in C:\opt\jdk\1.7.0 then use
    ant -Dboot.java/home=C:/opt/jdk/1.7.0 more-args...

-- Jon



R?mi Forax wrote:
> Le 11/08/2009 01:58, Ulf Zibis a ?crit :
>> R?mi, thanks.
>>
>> I just tried it, but got errors:
>>
>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
>> 6.7.1\java2\ant\bin\ant"
>> Buildfile: build.xml
>>
>> -def-check:
>>
>> -check-boot.java.home:
>>
>> BUILD FAILED
>> C:\Projects\OpenJDK7\langtools\make\build.xml:370: The following 
>> error occurred
>> while executing this line:
>> C:\Projects\OpenJDK7\langtools\make\build.xml:737: Cannot locate 
>> bootstrap java:
>> please set boot.java.home to its location
>>
>> Total time: 1 second
>>
>>
>> -Ulf
>
> as said, set the bootstrap location,
> with bash:
> export ALT_BOOTDIR=path_to_a_binary_jdk6or7
>
> R?mi
>
>>
>>
>> Am 04.08.2009 15:17, R?mi Forax schrieb:
>>> Le 04/08/2009 13:07, Ulf Zibis a ?crit :
>>>> Maurizio,
>>>>
>>>> much thanks for the additional info.
>>>>
>>>> I like to avoid going back to b63.
>>>> If the fix will not go into b68, could you please provide a binary 
>>>> patch for b67 (or b68) (Windows version)?
>>>> I can wait for release of b68, but not for b69, as I'm on vacation 
>>>> until Aug. 10.
>>>>
>>>> Thanks in advance,
>>>>
>>>> -Ulf
>>>
>>> you can do it by yourself,
>>> clone the langtools repository, it can be built with ant, so just 
>>> type ant
>>> in the directory "make", it will create a tools.jar.
>>> Now remplace the tools.jar of your binary build by this new one.
>>>
>>> cheers,
>>> R?mi
>>>
>>>>
>>>>
>>>> Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
>>>>> Ulf Zibis wrote:
>>>>>> Maurizio,
>>>>>>
>>>>>> much thanks for the fast info.
>>>>>>
>>>>>> Will this fix be included in next build b68 ???
>>>>>> Hopefully !
>>>>> Not sure if it will make into b68 - but certainly it will go into 
>>>>> b69 (depends on the integration process). The fix is already 
>>>>> available in the langtools repository used for development 
>>>>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>>>>
>>>>> Maurizio
>>>>>>
>>>>>> -Ulf
>>>>>>
>>>>>>
>>>>>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>>>>>> Ulf Zibis wrote:
>>>>>>>> See:
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>>>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>>>>>
>>>>>>>> -Ulf
>>>>>>>>
>>>>>>>>
>>>>>>> Hi Ulf,
>>>>>>> this is a type annotation (JSR 308) bug that has been recently 
>>>>>>> fixed - it is a duplicate of 6861837.
>>>>>>>
>>>>>>> Regards
>>>>>>> Maurizio
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>



From maurizio.cimadamore at sun.com  Tue Aug 11 02:23:38 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Tue, 11 Aug 2009 02:23:38 +0000
Subject: hg: jdk7/tl/langtools: 7 new changesets
Message-ID: <20090811022353.A3277E9F3@hg.openjdk.java.net>

Changeset: d5f6c475f475
Author:    mcimadamore
Date:      2009-08-11 01:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d5f6c475f475

6806876: ClassCastException occurs in assignment expressions without any heap pollutions
Summary: intersection types should be considered as non-reifiable by javac
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/varargs/6806876/T6806876.java
+ test/tools/javac/varargs/6806876/T6806876.out

Changeset: abe992640c5a
Author:    mcimadamore
Date:      2009-08-11 01:12 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/abe992640c5a

6390045: Unexpected error "cannot access java.lang.Void" with '-target cldc1.0' with -source >=1.5
Summary: javac needs to synthetize a fake java.lang.Void symbol if one is not given on the classpath
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symtab.java
+ test/tools/javac/6390045/T6390045a.java
+ test/tools/javac/6390045/T6390045b.java

Changeset: 62073a5becc5
Author:    mcimadamore
Date:      2009-08-11 01:12 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/62073a5becc5

6840059: regression: javac silently crashes when resolving erroneous anonymous inner constructor
Summary: resolved an internal crash with constructor resolution
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/6840059/T6840059.java
+ test/tools/javac/6840059/T6840059.out

Changeset: 8227961c64d3
Author:    mcimadamore
Date:      2009-08-11 01:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8227961c64d3

6521805: Regression: JDK5/JDK6 javac allows write access to outer class reference
Summary: javac should warn/complain about identifiers with the same name as synthetic symbol
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/6521805/T6521805a.java
+ test/tools/javac/6521805/T6521805a_1.out
+ test/tools/javac/6521805/T6521805a_2.out
+ test/tools/javac/6521805/T6521805b.java
+ test/tools/javac/6521805/T6521805c.java
+ test/tools/javac/6521805/T6521805d.java
+ test/tools/javac/6521805/T6521805d.out
+ test/tools/javac/6521805/T6521805e.java
+ test/tools/javac/6521805/T6521805e.out
+ test/tools/javac/6521805/p/Outer.java
+ test/tools/javac/6521805/p/Sub.java
! test/tools/javac/6734819/T6734819a.out
! test/tools/javac/6734819/T6734819b.out
! test/tools/javac/policy/test2/byfile.AB.out
! test/tools/javac/policy/test2/bytodo.AB.out

Changeset: 62fb6cafa93b
Author:    mcimadamore
Date:      2009-08-11 01:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/62fb6cafa93b

6869075: regression: javac crashes when compiling compound string assignment with generics
Summary: javac should not add syntehtic cast to the LHS of an assignment expression
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/generics/T6869075.java

Changeset: 13902c0c9b83
Author:    mcimadamore
Date:      2009-08-11 01:14 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/13902c0c9b83

6569404: Cannot instantiate an inner class of a type variable
Summary: javac is too strict in rejecting member selction from a type-var
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/generics/typevars/6569404/T6569404a.java
+ test/tools/javac/generics/typevars/6569404/T6569404b.java
+ test/tools/javac/generics/typevars/6569404/T6569404b.out
+ test/tools/javac/generics/typevars/6569404/T6569404c.java

Changeset: c4c424badb83
Author:    mcimadamore
Date:      2009-08-11 01:14 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c4c424badb83

6199153: Generic throws and overriding
Summary: javac incorrectly rejects an uchecked overriding
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/OverrideChecks/6199153/T6199153.java
+ test/tools/javac/OverrideChecks/6199153/T6199153.out



From weijun.wang at sun.com  Tue Aug 11 04:27:48 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Tue, 11 Aug 2009 04:27:48 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090811042920.49363E9F8@hg.openjdk.java.net>

Changeset: 5439d705c04e
Author:    weijun
Date:      2009-08-11 12:15 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5439d705c04e

6866479: libzip.so caused JVM to crash when running jarsigner
Reviewed-by: mullan

! src/share/classes/sun/security/tools/JarSigner.java
+ test/sun/security/tools/jarsigner/samename.sh

Changeset: c98d2798e16f
Author:    weijun
Date:      2009-08-11 12:17 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c98d2798e16f

6710360: export Kerberos session key to applications
Reviewed-by: valeriep

+ src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java
+ src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java
+ src/share/classes/com/sun/security/jgss/InquireType.java
! src/share/classes/sun/security/jgss/GSSContextImpl.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java
! src/share/classes/sun/security/tools/PolicyTool.java
+ test/com/sun/security/jgss/InquireSecContextPermissionCheck.java
! test/sun/security/krb5/auto/Context.java

Changeset: 6db21e653d99
Author:    weijun
Date:      2009-08-11 12:20 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6db21e653d99

6821190: more InquireType values for ExtendedGSSContext
Reviewed-by: valeriep

+ src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java
! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java
! src/share/classes/com/sun/security/jgss/InquireType.java
! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/krb5/Credentials.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/internal/AuthorizationData.java
! src/share/classes/sun/security/tools/PolicyTool.java
! test/sun/security/krb5/auto/Context.java



From weijun.wang at sun.com  Tue Aug 11 07:43:29 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Tue, 11 Aug 2009 07:43:29 +0000
Subject: hg: jdk7/tl/jdk: 6868867: Test:
	sun/security/tools/keytool/standard.sh fails under windows/cygwin
Message-ID: <20090811074403.F0521E9FD@hg.openjdk.java.net>

Changeset: efe2d2a55b3b
Author:    weijun
Date:      2009-08-11 15:36 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/efe2d2a55b3b

6868867: Test: sun/security/tools/keytool/standard.sh fails under windows/cygwin
Reviewed-by: wetmore

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



From Ulf.Zibis at gmx.de  Tue Aug 11 08:32:07 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Aug 2009 10:32:07 +0200
Subject: javac CRASH
In-Reply-To: <4A80BA63.7010606@univ-mlv.fr>
References: <4A77F8CB.2070200@gmx.de>
	<4A77FAA8.5020101@sun.com>	<4A77FC5F.8020407@gmx.de>
	<4A780B67.3080809@sun.com> <4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr>
Message-ID: <4A812C87.4030001@gmx.de>

R?mi (and all),

(1) My initial question was, if somebody could provide me a patch (here: 
langtools.jar). As it's always difficult. to run the build on Windows, I 
assumed, there is somebody out there who has ready configured his 
system, to run the build for langtools.jar.

(2) Remember, there is no bash on Windows. I don't have any idea, what 
"export" could be translated to, to run it on Windows.

-Ulf


Am 11.08.2009 02:25, R?mi Forax schrieb:
>
> as said, set the bootstrap location,
> with bash:
> export ALT_BOOTDIR=path_to_a_binary_jdk6or7
>
> R?mi
>
>>
>>
>> Am 04.08.2009 15:17, R?mi Forax schrieb:
>>> Le 04/08/2009 13:07, Ulf Zibis a ?crit :
>>>> Maurizio,
>>>>
>>>> much thanks for the additional info.
>>>>
>>>> I like to avoid going back to b63.
>>>> If the fix will not go into b68, could you please provide a binary 
>>>> patch for b67 (or b68) (Windows version)?
>>>> I can wait for release of b68, but not for b69, as I'm on vacation 
>>>> until Aug. 10.
>>>>
>>>> Thanks in advance,
>>>>
>>>> -Ulf
>>>
>>> you can do it by yourself,
>>> clone the langtools repository, it can be built with ant, so just 
>>> type ant
>>> in the directory "make", it will create a tools.jar.
>>> Now remplace the tools.jar of your binary build by this new one.
>>>
>>> cheers,
>>> R?mi
>>>
>>>>
>>>>
>>>> Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
>>>>> Ulf Zibis wrote:
>>>>>> Maurizio,
>>>>>>
>>>>>> much thanks for the fast info.
>>>>>>
>>>>>> Will this fix be included in next build b68 ???
>>>>>> Hopefully !
>>>>> Not sure if it will make into b68 - but certainly it will go into 
>>>>> b69 (depends on the integration process). The fix is already 
>>>>> available in the langtools repository used for development 
>>>>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>>>>
>>>>> Maurizio
>>>>>>
>>>>>> -Ulf
>>>>>>
>>>>>>
>>>>>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>>>>>> Ulf Zibis wrote:
>>>>>>>> See:
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>>>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>>>>>
>>>>>>>> -Ulf
>>>>>>>>
>>>>>>>>
>>>>>>> Hi Ulf,
>>>>>>> this is a type annotation (JSR 308) bug that has been recently 
>>>>>>> fixed - it is a duplicate of 6861837.
>>>>>>>
>>>>>>> Regards
>>>>>>> Maurizio
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From Ulf.Zibis at gmx.de  Tue Aug 11 09:06:32 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Aug 2009 11:06:32 +0200
Subject: javac CRASH
In-Reply-To: <4A80C049.2020202@sun.com>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de> <4A7834DB.7020708@univ-mlv.fr>
	<4A80B40A.8090704@gmx.de> <4A80BA63.7010606@univ-mlv.fr>
	<4A80C049.2020202@sun.com>
Message-ID: <4A813498.3010004@gmx.de>

Jonathan,

thanks for additional help.

Now I tried:
C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
6.7.1\java2\ant\
bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0

... but this didn't make any difference.

I guess, you mean, to set or overwrite the boot.java.home property in 
"build.properties".

So I set in path_to_jdk7_sources\langtools\make\build.properties:
   boot.java.home = C:/Programme/Java/jdk1.6.0_14

I started build from NetBeans 
(path_to_jdk7_sources\langtools\make\netbeans\langtools\build.xml):

clean:
Deleting directory C:\Projects\OpenJDK7\langtools\build
Created dir: C:\Projects\OpenJDK7\langtools\build\toolclasses
Compiling 1 source file to C:\Projects\OpenJDK7\langtools\build\toolclasses
Building all tools
Compiling 2 source files to C:\Projects\OpenJDK7\langtools\build\toolclasses
build-bootstrap-javac:
Created dir: C:\Projects\OpenJDK7\langtools\build\bootstrap\gensrc
Created dir: C:\Projects\OpenJDK7\langtools\build\bootstrap\classes
Generating 7 resource files to 
C:\Projects\OpenJDK7\langtools\build\bootstrap\gensrc
Copying 1 file to C:\Projects\OpenJDK7\langtools\build\bootstrap\gensrc
Generating 1 resource files to 
C:\Projects\OpenJDK7\langtools\build\bootstrap\gensrc
Compiling 8 source files to 
C:\Projects\OpenJDK7\langtools\build\bootstrap\classes
Compiling 271 source files to 
C:\Projects\OpenJDK7\langtools\build\bootstrap\classes
Created dir: C:\Projects\OpenJDK7\langtools\build\bootstrap\lib
Building jar: C:\Projects\OpenJDK7\langtools\build\bootstrap\lib\javac.jar
Created dir: C:\Projects\OpenJDK7\langtools\build\bootstrap\bin
Copying 1 file to C:\Projects\OpenJDK7\langtools\build\bootstrap\bin
build-javac:
Created dir: C:\Projects\OpenJDK7\langtools\build\gensrc
Created dir: C:\Projects\OpenJDK7\langtools\build\classes
Generating 7 resource files to C:\Projects\OpenJDK7\langtools\build\gensrc
Copying 1 file to C:\Projects\OpenJDK7\langtools\build\gensrc
Generating 1 resource files to C:\Projects\OpenJDK7\langtools\build\gensrc
Compiling 8 source files to C:\Projects\OpenJDK7\langtools\build\classes
javac: invalid target release: 7
Usage: javac <options> <source files>
use -help for a list of possible options
C:\Projects\OpenJDK7\langtools\make\netbeans\langtools\build.xml:67: The 
following error occurred while executing this line:
C:\Projects\OpenJDK7\langtools\make\build.xml:192: The following error 
occurred while executing this line:
C:\Projects\OpenJDK7\langtools\make\build.xml:424: The following error 
occurred while executing this line:
C:\Projects\OpenJDK7\langtools\make\build.xml:465: The following error 
occurred while executing this line:
C:\Projects\OpenJDK7\langtools\make\build.xml:518: Compile failed; see 
the compiler error output for details.
BUILD FAILED (total time: 23 seconds)


Then I tried:
    target.java.home = C:/Programme/Java/jdk1.7.0
and later:
   boot.javac.target = 7

... but nothing helped.

-Ulf


Am 11.08.2009 02:50, Jonathan Gibbons schrieb:
> R?mi , Ulf,
>
> If you're driving Ant directly, you want to set the Ant property 
> boot.java.home,
> not the Makefile variable ALT_BOOTDIR.
>    ant -Dboot.java.home=path-to-jdk6or7 more-args....
>
> The path should be to the root of the installed JDK, not any of its 
> subdirectories.
> For example, if you've installed JDK 1.7 in C:\opt\jdk\1.7.0 then use
>    ant -Dboot.java/home=C:/opt/jdk/1.7.0 more-args...
>
> -- Jon
>
>
>
> R?mi Forax wrote:
>> Le 11/08/2009 01:58, Ulf Zibis a ?crit :
>>> R?mi, thanks.
>>>
>>> I just tried it, but got errors:
>>>
>>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
>>> 6.7.1\java2\ant\bin\ant"
>>> Buildfile: build.xml
>>>
>>> -def-check:
>>>
>>> -check-boot.java.home:
>>>
>>> BUILD FAILED
>>> C:\Projects\OpenJDK7\langtools\make\build.xml:370: The following 
>>> error occurred
>>> while executing this line:
>>> C:\Projects\OpenJDK7\langtools\make\build.xml:737: Cannot locate 
>>> bootstrap java:
>>> please set boot.java.home to its location
>>>
>>> Total time: 1 second
>>>
>>>
>>> -Ulf
>>
>> as said, set the bootstrap location,
>> with bash:
>> export ALT_BOOTDIR=path_to_a_binary_jdk6or7
>>
>> R?mi
>>
>>>
>>>
>>> Am 04.08.2009 15:17, R?mi Forax schrieb:
>>>> Le 04/08/2009 13:07, Ulf Zibis a ?crit :
>>>>> Maurizio,
>>>>>
>>>>> much thanks for the additional info.
>>>>>
>>>>> I like to avoid going back to b63.
>>>>> If the fix will not go into b68, could you please provide a binary 
>>>>> patch for b67 (or b68) (Windows version)?
>>>>> I can wait for release of b68, but not for b69, as I'm on vacation 
>>>>> until Aug. 10.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> -Ulf
>>>>
>>>> you can do it by yourself,
>>>> clone the langtools repository, it can be built with ant, so just 
>>>> type ant
>>>> in the directory "make", it will create a tools.jar.
>>>> Now remplace the tools.jar of your binary build by this new one.
>>>>
>>>> cheers,
>>>> R?mi
>>>>
>>>>>
>>>>>
>>>>> Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
>>>>>> Ulf Zibis wrote:
>>>>>>> Maurizio,
>>>>>>>
>>>>>>> much thanks for the fast info.
>>>>>>>
>>>>>>> Will this fix be included in next build b68 ???
>>>>>>> Hopefully !
>>>>>> Not sure if it will make into b68 - but certainly it will go into 
>>>>>> b69 (depends on the integration process). The fix is already 
>>>>>> available in the langtools repository used for development 
>>>>>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>>>>>
>>>>>> Maurizio
>>>>>>>
>>>>>>> -Ulf
>>>>>>>
>>>>>>>
>>>>>>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>>>>>>> Ulf Zibis wrote:
>>>>>>>>> See:
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>>>>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>>>>>>
>>>>>>>>> -Ulf
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hi Ulf,
>>>>>>>> this is a type annotation (JSR 308) bug that has been recently 
>>>>>>>> fixed - it is a duplicate of 6861837.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Maurizio
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>



From forax at univ-mlv.fr  Tue Aug 11 09:23:02 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 11 Aug 2009 11:23:02 +0200
Subject: javac CRASH
In-Reply-To: <4A812C87.4030001@gmx.de>
References: <4A77F8CB.2070200@gmx.de>
	<4A77FAA8.5020101@sun.com>	<4A77FC5F.8020407@gmx.de>
	<4A780B67.3080809@sun.com> <4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr> <4A812C87.4030001@gmx.de>
Message-ID: <4A813876.9040102@univ-mlv.fr>

Le 11/08/2009 10:32, Ulf Zibis a ?crit :
> R?mi (and all),
>
> (1) My initial question was, if somebody could provide me a patch 
> (here: langtools.jar). As it's always difficult. to run the build on 
> Windows, I assumed, there is somebody out there who has ready 
> configured his system, to run the build for langtools.jar.
>
> (2) Remember, there is no bash on Windows. I don't have any idea, what 
> "export" could be translated to, to run it on Windows.
>
> -Ulf

sent using private email.

R?mi

>
>
> Am 11.08.2009 02:25, R?mi Forax schrieb:
>>
>> as said, set the bootstrap location,
>> with bash:
>> export ALT_BOOTDIR=path_to_a_binary_jdk6or7
>>
>> R?mi
>>
>>>
>>>
>>> Am 04.08.2009 15:17, R?mi Forax schrieb:
>>>> Le 04/08/2009 13:07, Ulf Zibis a ?crit :
>>>>> Maurizio,
>>>>>
>>>>> much thanks for the additional info.
>>>>>
>>>>> I like to avoid going back to b63.
>>>>> If the fix will not go into b68, could you please provide a binary 
>>>>> patch for b67 (or b68) (Windows version)?
>>>>> I can wait for release of b68, but not for b69, as I'm on vacation 
>>>>> until Aug. 10.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> -Ulf
>>>>
>>>> you can do it by yourself,
>>>> clone the langtools repository, it can be built with ant, so just 
>>>> type ant
>>>> in the directory "make", it will create a tools.jar.
>>>> Now remplace the tools.jar of your binary build by this new one.
>>>>
>>>> cheers,
>>>> R?mi
>>>>
>>>>>
>>>>>
>>>>> Am 04.08.2009 12:20, Maurizio Cimadamore schrieb:
>>>>>> Ulf Zibis wrote:
>>>>>>> Maurizio,
>>>>>>>
>>>>>>> much thanks for the fast info.
>>>>>>>
>>>>>>> Will this fix be included in next build b68 ???
>>>>>>> Hopefully !
>>>>>> Not sure if it will make into b68 - but certainly it will go into 
>>>>>> b69 (depends on the integration process). The fix is already 
>>>>>> available in the langtools repository used for development 
>>>>>> (http://hg.openjdk.java.net/jdk7/tl/langtools).
>>>>>>
>>>>>> Maurizio
>>>>>>>
>>>>>>> -Ulf
>>>>>>>
>>>>>>>
>>>>>>> Am 04.08.2009 11:08, Maurizio Cimadamore schrieb:
>>>>>>>> Ulf Zibis wrote:
>>>>>>>>> See:
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6868135 --> 
>>>>>>>>> java.lang.NullPointerException from compiler (1.7.0-ea)
>>>>>>>>>
>>>>>>>>> -Ulf
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hi Ulf,
>>>>>>>> this is a type annotation (JSR 308) bug that has been recently 
>>>>>>>> fixed - it is a duplicate of 6861837.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Maurizio
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>



From forax at univ-mlv.fr  Tue Aug 11 09:46:43 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 11 Aug 2009 11:46:43 +0200
Subject: javac CRASH
In-Reply-To: <4A813498.3010004@gmx.de>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de> <4A7834DB.7020708@univ-mlv.fr>
	<4A80B40A.8090704@gmx.de> <4A80BA63.7010606@univ-mlv.fr>
	<4A80C049.2020202@sun.com> <4A813498.3010004@gmx.de>
Message-ID: <4A813E03.4000702@univ-mlv.fr>

Le 11/08/2009 11:06, Ulf Zibis a ?crit :
> Jonathan,
>
> thanks for additional help.
>
> Now I tried:
> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
> 6.7.1\java2\ant\
> bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0

I've noticed that.
You have to run ant with jdk7.

JAVA_HOME=C:/Programme/Java/jdk1.7.0
ant -Dboot.java/home=C:/Programme/Java/jdk1.7.0

Jon, it seems the ant build script need be updated because
we are not able to compile with jdk6 anymore.
The bootstrap javac/javap/etc should be built with -source 1.6 -target 1.6.

R?mi


From xuelei.fan at sun.com  Tue Aug 11 10:35:15 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Tue, 11 Aug 2009 10:35:15 +0000
Subject: hg: jdk7/tl/jdk: 6585239: Regression: 2 DNS tests fail with JDK
	5.0u13 b01 and pass with 5.0u12fcs
Message-ID: <20090811103547.04CE9EA06@hg.openjdk.java.net>

Changeset: aface89bfcf6
Author:    xuelei
Date:      2009-08-11 18:27 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aface89bfcf6

6585239: Regression: 2 DNS tests fail with JDK 5.0u13 b01 and pass with 5.0u12fcs
Reviewed-by: vinnie

! src/share/classes/com/sun/jndi/dns/DnsContext.java



From alan.bateman at sun.com  Tue Aug 11 14:32:19 2009
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Tue, 11 Aug 2009 14:32:19 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090811143326.E031BEA1F@hg.openjdk.java.net>

Changeset: 5b5df0632ecf
Author:    alanb
Date:      2009-08-11 12:37 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b5df0632ecf

4516760: (so) Intermittent SocketException: Transport endpoint is not connected (lnx)
Reviewed-by: sherman

! src/solaris/native/sun/nio/ch/Net.c
! test/java/nio/channels/SocketChannel/Shutdown.java

Changeset: 18554eea6ce6
Author:    alanb
Date:      2009-08-11 12:38 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/18554eea6ce6

6867781: (file) Examples in javadoc use newFileAttributeView instead of getFileAttributeView
Reviewed-by: sherman

! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java

Changeset: a9a5aabecc01
Author:    alanb
Date:      2009-08-11 12:49 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a9a5aabecc01

6865748: (file) SimpleFileVisitor methods ignore null arguments
Reviewed-by: sherman

! src/share/classes/java/nio/file/SimpleFileVisitor.java
! test/java/nio/file/Files/Misc.java



From Jonathan.Gibbons at Sun.COM  Tue Aug 11 14:49:59 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Tue, 11 Aug 2009 07:49:59 -0700
Subject: javac CRASH
In-Reply-To: <4A813E03.4000702@univ-mlv.fr>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr> <4A80C049.2020202@sun.com>
	<4A813498.3010004@gmx.de> <4A813E03.4000702@univ-mlv.fr>
Message-ID: <33338629-C8F0-4649-A3AD-A6BCA88631B7@Sun.COM>

R?mi,

Thanks for the heads up. I'll check this out.  It is still the case  
that you should only need 1.6 to build langtools.

-- Jon



On Aug 11, 2009, at 2:46 AM, R?mi Forax wrote:

> Le 11/08/2009 11:06, Ulf Zibis a ?crit :
>> Jonathan,
>>
>> thanks for additional help.
>>
>> Now I tried:
>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans  
>> 6.7.1\java2\ant\
>> bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>
> I've noticed that.
> You have to run ant with jdk7.
>
> JAVA_HOME=C:/Programme/Java/jdk1.7.0
> ant -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>
> Jon, it seems the ant build script need be updated because
> we are not able to compile with jdk6 anymore.
> The bootstrap javac/javap/etc should be built with -source 1.6 - 
> target 1.6.
>
> R?mi



From abhijit.saha at sun.com  Tue Aug 11 15:29:39 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Tue, 11 Aug 2009 15:29:39 +0000
Subject: hg: jdk7/tl: 2 new changesets
Message-ID: <20090811152940.3B571EA2E@hg.openjdk.java.net>

Changeset: 4cad5a3f5038
Author:    asaha
Date:      2009-08-07 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/4cad5a3f5038

6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14
Reviewed-by: darcy, ramap

! THIRD_PARTY_README

Changeset: fb676d15f20f
Author:    asaha
Date:      2009-08-10 10:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/fb676d15f20f

Merge




From Ulf.Zibis at gmx.de  Tue Aug 11 15:31:52 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Aug 2009 17:31:52 +0200
Subject: javac CRASH
In-Reply-To: <33338629-C8F0-4649-A3AD-A6BCA88631B7@Sun.COM>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de> <4A7834DB.7020708@univ-mlv.fr>
	<4A80B40A.8090704@gmx.de> <4A80BA63.7010606@univ-mlv.fr>
	<4A80C049.2020202@sun.com> <4A813498.3010004@gmx.de>
	<4A813E03.4000702@univ-mlv.fr>
	<33338629-C8F0-4649-A3AD-A6BCA88631B7@Sun.COM>
Message-ID: <4A818EE8.6030307@gmx.de>

Jon,

that would be great.

I've found out a solution, but I'm not sure, if this is as designed. In 
path_to_jdk7_sources\langtools\make\build.properties I set:
boot.java.home = C:/Programme/Java/jdk1.6.0_14
target.java.home = C:/Programme/Java/jdk1.7.0
javac.source = 6
javac.target = 6

I'm wondering, that there is no ...\make\build.properties file in tl/jdk 
tree.

Maybe you like to have a look on ...\make\netbeans\charset\* in my patch 
for https://bugs.openjdk.java.net/show_bug.cgi?id=100098 ?

-Ulf



Am 11.08.2009 16:49, Jonathan Gibbons schrieb:
> R?mi,
>
> Thanks for the heads up. I'll check this out.  It is still the case 
> that you should only need 1.6 to build langtools.
>
> -- Jon
>
>
>
> On Aug 11, 2009, at 2:46 AM, R?mi Forax wrote:
>
>> Le 11/08/2009 11:06, Ulf Zibis a ?crit :
>>> Jonathan,
>>>
>>> thanks for additional help.
>>>
>>> Now I tried:
>>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
>>> 6.7.1\java2\ant\
>>> bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>
>> I've noticed that.
>> You have to run ant with jdk7.
>>
>> JAVA_HOME=C:/Programme/Java/jdk1.7.0
>> ant -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>
>> Jon, it seems the ant build script need be updated because
>> we are not able to compile with jdk6 anymore.
>> The bootstrap javac/javap/etc should be built with -source 1.6 
>> -target 1.6.
>>
>> R?mi
>
>



From abhijit.saha at sun.com  Tue Aug 11 15:35:19 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Tue, 11 Aug 2009 15:35:19 +0000
Subject: hg: jdk7/tl/corba: 2 new changesets
Message-ID: <20090811153522.2EEDFEA33@hg.openjdk.java.net>

Changeset: f3f572ea0cf2
Author:    asaha
Date:      2009-08-07 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/f3f572ea0cf2

6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14
Reviewed-by: darcy, ramap

! THIRD_PARTY_README

Changeset: 691649734a70
Author:    asaha
Date:      2009-08-10 10:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/691649734a70

Merge




From abhijit.saha at sun.com  Tue Aug 11 15:41:44 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Tue, 11 Aug 2009 15:41:44 +0000
Subject: hg: jdk7/tl/hotspot: 2 new changesets
Message-ID: <20090811154152.6F90AEA38@hg.openjdk.java.net>

Changeset: 185d256992c3
Author:    asaha
Date:      2009-08-07 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/185d256992c3

6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14
Reviewed-by: darcy, ramap

! THIRD_PARTY_README

Changeset: adba5b333f26
Author:    asaha
Date:      2009-08-10 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/adba5b333f26

Merge




From abhijit.saha at sun.com  Tue Aug 11 15:48:22 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Tue, 11 Aug 2009 15:48:22 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20090811154825.ED5C2EA3D@hg.openjdk.java.net>

Changeset: c7914d53581c
Author:    asaha
Date:      2009-08-07 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c7914d53581c

6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14
Reviewed-by: darcy, ramap

! THIRD_PARTY_README

Changeset: deec13478962
Author:    asaha
Date:      2009-08-10 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/deec13478962

Merge




From abhijit.saha at sun.com  Tue Aug 11 15:55:14 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Tue, 11 Aug 2009 15:55:14 +0000
Subject: hg: jdk7/tl/jaxws: 2 new changesets
Message-ID: <20090811155518.6FC97EA44@hg.openjdk.java.net>

Changeset: 860b95cc8d1d
Author:    asaha
Date:      2009-08-07 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/860b95cc8d1d

6813167: 6u14 JAX-WS audit mutable static bugs
6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14
Reviewed-by: darcy, ramap

! THIRD_PARTY_README
+ jaxws.patch
+ patch.out
! src/share/classes/com/sun/codemodel/internal/JAnnotatable.java
! src/share/classes/com/sun/codemodel/internal/JAnnotationUse.java
! src/share/classes/com/sun/codemodel/internal/JAnnotationWriter.java
! src/share/classes/com/sun/codemodel/internal/JBlock.java
! src/share/classes/com/sun/codemodel/internal/JCommentPart.java
! src/share/classes/com/sun/codemodel/internal/JDirectClass.java
! src/share/classes/com/sun/codemodel/internal/JExpr.java
! src/share/classes/com/sun/codemodel/internal/JJavaName.java
! src/share/classes/com/sun/codemodel/internal/JMethod.java
! src/share/classes/com/sun/codemodel/internal/JPackage.java
! src/share/classes/com/sun/codemodel/internal/JTypeWildcard.java
! src/share/classes/com/sun/codemodel/internal/TypedAnnotationWriter.java
- src/share/classes/com/sun/codemodel/internal/fmt/package.html
! src/share/classes/com/sun/codemodel/internal/package-info.java
! src/share/classes/com/sun/codemodel/internal/util/EncoderFactory.java
! src/share/classes/com/sun/codemodel/internal/util/MS1252Encoder.java
! src/share/classes/com/sun/codemodel/internal/writer/FilterCodeWriter.java
+ src/share/classes/com/sun/istack/internal/Builder.java
! src/share/classes/com/sun/istack/internal/Pool.java
! src/share/classes/com/sun/istack/internal/XMLStreamReaderToContentHandler.java
+ src/share/classes/com/sun/istack/internal/localization/Localizable.java
+ src/share/classes/com/sun/istack/internal/localization/LocalizableMessage.java
+ src/share/classes/com/sun/istack/internal/localization/LocalizableMessageFactory.java
+ src/share/classes/com/sun/istack/internal/localization/Localizer.java
! src/share/classes/com/sun/istack/internal/ws/AnnotationProcessorFactoryImpl.java
! src/share/classes/com/sun/tools/internal/jxc/ConfigReader.java
! src/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/jxc/Messages.java
! src/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java
+ src/share/classes/com/sun/tools/internal/jxc/SchemaGeneratorFacade.java
! src/share/classes/com/sun/tools/internal/jxc/apt/AnnotationParser.java
! src/share/classes/com/sun/tools/internal/jxc/apt/AnnotationProcessorFactoryImpl.java
! src/share/classes/com/sun/tools/internal/jxc/apt/Const.java
! src/share/classes/com/sun/tools/internal/jxc/apt/ErrorReceiverImpl.java
! src/share/classes/com/sun/tools/internal/jxc/apt/InlineAnnotationReaderImpl.java
! src/share/classes/com/sun/tools/internal/jxc/apt/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/jxc/apt/Messages.java
! src/share/classes/com/sun/tools/internal/jxc/apt/Options.java
! src/share/classes/com/sun/tools/internal/jxc/apt/SchemaGenerator.java
! src/share/classes/com/sun/tools/internal/jxc/gen/config/Classes.java
! src/share/classes/com/sun/tools/internal/jxc/gen/config/Config.java
! src/share/classes/com/sun/tools/internal/jxc/gen/config/Schema.java
! src/share/classes/com/sun/tools/internal/jxc/gen/config/config.xsd
! src/share/classes/com/sun/tools/internal/jxc/model/nav/APTNavigator.java
! src/share/classes/com/sun/tools/internal/ws/Invoker.java
! src/share/classes/com/sun/tools/internal/ws/api/TJavaGeneratorExtension.java
+ src/share/classes/com/sun/tools/internal/ws/api/WsgenExtension.java
+ src/share/classes/com/sun/tools/internal/ws/api/WsgenProtocol.java
! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensible.java
! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtension.java
! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensionHandler.java
! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLOperation.java
! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLParserContext.java
! src/share/classes/com/sun/tools/internal/ws/package-info.java
! src/share/classes/com/sun/tools/internal/ws/processor/generator/GeneratorBase.java
! src/share/classes/com/sun/tools/internal/ws/processor/generator/SeiGenerator.java
! src/share/classes/com/sun/tools/internal/ws/processor/generator/ServiceGenerator.java
! src/share/classes/com/sun/tools/internal/ws/processor/generator/W3CAddressingJavaGeneratorExtension.java
! src/share/classes/com/sun/tools/internal/ws/processor/model/Port.java
! src/share/classes/com/sun/tools/internal/ws/processor/model/java/JavaMethod.java
! src/share/classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBType.java
! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceAP.java
! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceVisitor.java
! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceWrapperGenerator.java
! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ConsoleErrorReporter.java
! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/PseudoSchemaBuilder.java
! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModeler.java
! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModelerBase.java
! src/share/classes/com/sun/tools/internal/ws/processor/util/ClassNameCollector.java
! src/share/classes/com/sun/tools/internal/ws/resources/GeneratorMessages.java
! src/share/classes/com/sun/tools/internal/ws/resources/ModelMessages.java
! src/share/classes/com/sun/tools/internal/ws/resources/ModelerMessages.java
! src/share/classes/com/sun/tools/internal/ws/resources/WebserviceapMessages.java
! src/share/classes/com/sun/tools/internal/ws/resources/WscompileMessages.java
! src/share/classes/com/sun/tools/internal/ws/resources/WsdlMessages.java
! src/share/classes/com/sun/tools/internal/ws/resources/configuration.properties
! src/share/classes/com/sun/tools/internal/ws/resources/generator.properties
! src/share/classes/com/sun/tools/internal/ws/resources/javacompiler.properties
! src/share/classes/com/sun/tools/internal/ws/resources/model.properties
! src/share/classes/com/sun/tools/internal/ws/resources/modeler.properties
! src/share/classes/com/sun/tools/internal/ws/resources/processor.properties
! src/share/classes/com/sun/tools/internal/ws/resources/util.properties
! src/share/classes/com/sun/tools/internal/ws/resources/webserviceap.properties
! src/share/classes/com/sun/tools/internal/ws/resources/wscompile.properties
! src/share/classes/com/sun/tools/internal/ws/resources/wsdl.properties
! src/share/classes/com/sun/tools/internal/ws/version.properties
! src/share/classes/com/sun/tools/internal/ws/wscompile/AbortException.java
+ src/share/classes/com/sun/tools/internal/ws/wscompile/AuthInfo.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/BadCommandLineException.java
+ src/share/classes/com/sun/tools/internal/ws/wscompile/DefaultAuthTester.java
+ src/share/classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/ErrorReceiver.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/ErrorReceiverFilter.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/JavaCompilerHelper.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/Options.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/WsgenOptions.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportListener.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java
! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/document/Message.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/document/jaxws/JAXWSBinding.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/framework/AbstractDocument.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/AbstractReferenceFinderImpl.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMBuilder.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java
+ src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestParser.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestScanner.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/InternalizationLogic.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/Internalizer.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/MemberSubmissionAddressingExtensionHandler.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/MetadataFinder.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/NamespaceContextImpl.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/VersionChecker.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/W3CAddressingExtensionHandler.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLInternalizationLogic.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLParser.java
! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WhitespaceStripper.java
+ src/share/classes/com/sun/tools/internal/xjc/ClassLoaderBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/Driver.java
! src/share/classes/com/sun/tools/internal/xjc/Language.java
! src/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/ModelLoader.java
! src/share/classes/com/sun/tools/internal/xjc/Options.java
! src/share/classes/com/sun/tools/internal/xjc/ProgressCodeWriter.java
! src/share/classes/com/sun/tools/internal/xjc/SchemaCache.java
+ src/share/classes/com/sun/tools/internal/xjc/XJCFacade.java
! src/share/classes/com/sun/tools/internal/xjc/XJCListener.java
! src/share/classes/com/sun/tools/internal/xjc/addon/at_generated/PluginImpl.java
! src/share/classes/com/sun/tools/internal/xjc/addon/code_injector/Const.java
! src/share/classes/com/sun/tools/internal/xjc/addon/code_injector/PluginImpl.java
! src/share/classes/com/sun/tools/internal/xjc/addon/episode/PluginImpl.java
! src/share/classes/com/sun/tools/internal/xjc/addon/episode/package-info.java
! src/share/classes/com/sun/tools/internal/xjc/api/ClassNameAllocator.java
! src/share/classes/com/sun/tools/internal/xjc/api/J2SJAXBModel.java
! src/share/classes/com/sun/tools/internal/xjc/api/Reference.java
! src/share/classes/com/sun/tools/internal/xjc/api/S2JJAXBModel.java
! src/share/classes/com/sun/tools/internal/xjc/api/SchemaCompiler.java
! src/share/classes/com/sun/tools/internal/xjc/api/SpecVersion.java
! src/share/classes/com/sun/tools/internal/xjc/api/TypeAndAnnotation.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java
- src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/Messages.java
- src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/Messages.properties
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/AbstractMappingImpl.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/BeanMappingImpl.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/DowngradingErrorHandler.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementCollectionAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementMappingImpl.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementSingleAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/PropertyImpl.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/SchemaCompilerImpl.java
! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/TypeAndAnnotationImpl.java
! src/share/classes/com/sun/tools/internal/xjc/api/package.html
! src/share/classes/com/sun/tools/internal/xjc/api/util/APTClassLoader.java
! src/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java
! src/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties
! src/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java
+ src/share/classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java
! src/share/classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/DualObjectFactoryGenerator.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ElementOutlineImpl.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ImplStructureStrategy.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/MethodWriter.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ObjectFactoryGeneratorImpl.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PrivateObjectFactoryGenerator.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PublicObjectFactoryGenerator.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractFieldWithVar.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractListField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ArrayField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ConstFieldRenderer.java
+ src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ContentListField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/DefaultFieldRenderer.java
+ src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/DummyListField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/FieldRenderer.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/FieldRendererFactory.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/IsSetFieldRenderer.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/Messages.java
+ src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/NoExtendedContentField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/SingleField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/SinglePrimitiveAccessField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/UnboxedField.java
! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/UntypedListFieldRenderer.java
! src/share/classes/com/sun/tools/internal/xjc/generator/package-info.java
! src/share/classes/com/sun/tools/internal/xjc/model/AbstractCElement.java
! src/share/classes/com/sun/tools/internal/xjc/model/AbstractCTypeInfoImpl.java
! src/share/classes/com/sun/tools/internal/xjc/model/AutoClassNameAllocator.java
! src/share/classes/com/sun/tools/internal/xjc/model/CAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/model/CArrayInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CAttributePropertyInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CBuiltinLeafInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CClass.java
! src/share/classes/com/sun/tools/internal/xjc/model/CClassInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CClassInfoParent.java
! src/share/classes/com/sun/tools/internal/xjc/model/CClassRef.java
! src/share/classes/com/sun/tools/internal/xjc/model/CCustomizable.java
! src/share/classes/com/sun/tools/internal/xjc/model/CCustomizations.java
! src/share/classes/com/sun/tools/internal/xjc/model/CDefaultValue.java
! src/share/classes/com/sun/tools/internal/xjc/model/CElement.java
! src/share/classes/com/sun/tools/internal/xjc/model/CElementInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CElementPropertyInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CEnumConstant.java
! src/share/classes/com/sun/tools/internal/xjc/model/CNonElement.java
! src/share/classes/com/sun/tools/internal/xjc/model/CPluginCustomization.java
! src/share/classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CPropertyVisitor.java
! src/share/classes/com/sun/tools/internal/xjc/model/CReferencePropertyInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CSingleTypePropertyInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CTypeInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CTypeRef.java
! src/share/classes/com/sun/tools/internal/xjc/model/CValuePropertyInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/CWildcardTypeInfo.java
! src/share/classes/com/sun/tools/internal/xjc/model/ClassNameAllocatorWrapper.java
! src/share/classes/com/sun/tools/internal/xjc/model/Model.java
! src/share/classes/com/sun/tools/internal/xjc/model/Populatable.java
! src/share/classes/com/sun/tools/internal/xjc/model/TypeUse.java
! src/share/classes/com/sun/tools/internal/xjc/model/TypeUseFactory.java
! src/share/classes/com/sun/tools/internal/xjc/model/TypeUseImpl.java
! src/share/classes/com/sun/tools/internal/xjc/model/nav/EagerNClass.java
! src/share/classes/com/sun/tools/internal/xjc/model/nav/EagerNType.java
! src/share/classes/com/sun/tools/internal/xjc/model/nav/NClass.java
! src/share/classes/com/sun/tools/internal/xjc/model/nav/NClassByJClass.java
! src/share/classes/com/sun/tools/internal/xjc/model/nav/NParameterizedType.java
! src/share/classes/com/sun/tools/internal/xjc/model/nav/NType.java
! src/share/classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java
! src/share/classes/com/sun/tools/internal/xjc/model/package-info.java
! src/share/classes/com/sun/tools/internal/xjc/outline/Aspect.java
! src/share/classes/com/sun/tools/internal/xjc/outline/ClassOutline.java
! src/share/classes/com/sun/tools/internal/xjc/outline/ElementOutline.java
! src/share/classes/com/sun/tools/internal/xjc/outline/EnumConstantOutline.java
! src/share/classes/com/sun/tools/internal/xjc/outline/EnumOutline.java
! src/share/classes/com/sun/tools/internal/xjc/package-info.java
! src/share/classes/com/sun/tools/internal/xjc/reader/AbstractExtensionBindingChecker.java
! src/share/classes/com/sun/tools/internal/xjc/reader/Const.java
! src/share/classes/com/sun/tools/internal/xjc/reader/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/reader/ModelChecker.java
! src/share/classes/com/sun/tools/internal/xjc/reader/RawTypeSet.java
! src/share/classes/com/sun/tools/internal/xjc/reader/Ring.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Block.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Element.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/ModelGroup.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Occurence.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Term.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMUtil.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DTDExtensionBindingChecker.java
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/bindingfile.rng
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/bindingfile.xsd
! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/xjc.xsd
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Choice.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ConnectedComponent.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Element.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ElementSet.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ElementSets.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Expression.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Graph.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/OneOrMore.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Sequence.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/SinkNode.java
! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/SourceNode.java
! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/ContentHandlerNamespacePrefixAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/NamespaceContextImpl.java
! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/SCDBasedBindingSet.java
! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/WhitespaceStripper.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/BindStyle.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/ContentModelBinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DatatypeLib.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DefineFinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/NameCalculator.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGCompiler.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RawTypeSetBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/TypePatternBinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/TypeUseBinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/Abstractifier.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindBlue.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindGreen.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindPurple.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindRed.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindYellow.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindingComponent.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ClassBinderFilter.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/CollisionInfo.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ColorBinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/DefaultParticleBinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ExpressionBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ExpressionParticleBinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GElement.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GElementImpl.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GWildcardElement.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/Messages.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/MultiplicityCounter.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/RawTypeSetBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/RefererFinder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/UnusedCustomizationChecker.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/AnnotationParserFactoryImpl.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIConversion.java
+ src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIFactoryMethod.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIGlobalBinding.java
+ src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIInlineBinaryData.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIProperty.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXDom.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXPluginCustomization.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXSubstitutable.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/CollectionTypeAttribute.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/DomHandlerEx.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/EnumMemberMode.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/ForkingFilter.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/LocalScoping.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/OptionalPropertyMode.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/binding.rng
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/binding.xsd
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package-info.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package.html
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/xjc.xsd
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/xs.xsd
+ src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ChoiceContentComplexTypeBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ComplexTypeBindingMode.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ComplexTypeFieldBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ExtendedComplexTypeBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/Messages.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MixedComplexTypeBuilder.java
+ src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MixedExtendedComplexTypeBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/RestrictedComplexTypeBuilder.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/LSInputSAXWrapper.java
! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/runtime/JAXBContextFactory.java
! src/share/classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/util/ForkContentHandler.java
! src/share/classes/com/sun/tools/internal/xjc/util/ForkEntityResolver.java
! src/share/classes/com/sun/tools/internal/xjc/util/MessageBundle.properties
! src/share/classes/com/sun/tools/internal/xjc/util/MimeTypeRange.java
! src/share/classes/com/sun/tools/internal/xjc/util/NamespaceContextAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/util/ReadOnlyAdapter.java
! src/share/classes/com/sun/tools/internal/xjc/util/StringCutter.java
! src/share/classes/com/sun/tools/internal/xjc/util/SubtreeCutter.java
! src/share/classes/com/sun/xml/internal/bind/AccessorFactoryImpl.java
! src/share/classes/com/sun/xml/internal/bind/AnyTypeAdapter.java
! src/share/classes/com/sun/xml/internal/bind/CycleRecoverable.java
! src/share/classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java
! src/share/classes/com/sun/xml/internal/bind/IDResolver.java
! src/share/classes/com/sun/xml/internal/bind/Locatable.java
! src/share/classes/com/sun/xml/internal/bind/Util.java
! src/share/classes/com/sun/xml/internal/bind/ValidationEventLocatorEx.java
! src/share/classes/com/sun/xml/internal/bind/XmlAccessorFactory.java
+ src/share/classes/com/sun/xml/internal/bind/annotation/OverrideAnnotationOf.java
! src/share/classes/com/sun/xml/internal/bind/annotation/XmlIsSet.java
! src/share/classes/com/sun/xml/internal/bind/annotation/XmlLocation.java
! src/share/classes/com/sun/xml/internal/bind/api/AccessorException.java
! src/share/classes/com/sun/xml/internal/bind/api/Bridge.java
! src/share/classes/com/sun/xml/internal/bind/api/BridgeContext.java
! src/share/classes/com/sun/xml/internal/bind/api/ClassResolver.java
! src/share/classes/com/sun/xml/internal/bind/api/CompositeStructure.java
! src/share/classes/com/sun/xml/internal/bind/api/ErrorListener.java
! src/share/classes/com/sun/xml/internal/bind/api/JAXBRIContext.java
+ src/share/classes/com/sun/xml/internal/bind/api/Messages.java
+ src/share/classes/com/sun/xml/internal/bind/api/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/api/RawAccessor.java
! src/share/classes/com/sun/xml/internal/bind/api/TypeReference.java
! src/share/classes/com/sun/xml/internal/bind/api/impl/NameConverter.java
! src/share/classes/com/sun/xml/internal/bind/api/impl/NameUtil.java
! src/share/classes/com/sun/xml/internal/bind/api/package-info.java
! src/share/classes/com/sun/xml/internal/bind/marshaller/DataWriter.java
! src/share/classes/com/sun/xml/internal/bind/marshaller/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/marshaller/MinimumEscapeHandler.java
! src/share/classes/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java
! src/share/classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java
! src/share/classes/com/sun/xml/internal/bind/unmarshaller/DOMScanner.java
! src/share/classes/com/sun/xml/internal/bind/unmarshaller/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/unmarshaller/Patcher.java
! src/share/classes/com/sun/xml/internal/bind/util/AttributesImpl.java
! src/share/classes/com/sun/xml/internal/bind/util/ValidationEventLocatorExImpl.java
! src/share/classes/com/sun/xml/internal/bind/util/Which.java
! src/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java
! src/share/classes/com/sun/xml/internal/bind/v2/ContextFactory.java
! src/share/classes/com/sun/xml/internal/bind/v2/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/TODO.java
! src/share/classes/com/sun/xml/internal/bind/v2/bytecode/ClassTailor.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AbstractInlineAnnotationReaderImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AnnotationReader.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AnnotationSource.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/ClassLocatable.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/FieldLocatable.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Locatable.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/LocatableAnnotation.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Messages.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/MethodLocatable.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Quick.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/RuntimeAnnotationReader.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/RuntimeInlineAnnotationReader.java
+ src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Adapter.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ArrayInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/AttributePropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/BuiltinLeafInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ClassInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Element.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementPropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/EnumConstant.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/EnumLeafInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ErrorHandler.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ID.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/LeafInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/MapPropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/MaybeElement.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/NonElement.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/NonElementRef.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/PropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/PropertyKind.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Ref.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ReferencePropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeInfoSet.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeRef.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ValuePropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/WildcardMode.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/WildcardTypeInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/core/package-info.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/AnyTypeImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ArrayInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/AttributePropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/BuiltinLeafInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java
+ src/share/classes/com/sun/xml/internal/bind/v2/model/impl/DummyPropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ERPropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/EnumConstantImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/EnumLeafInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/FieldPropertySeed.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/GetterSetterPropertySeed.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/LeafInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/MapPropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Messages.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/PropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/PropertySeed.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ReferencePropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RegistryInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAnyTypeImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeArrayInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAttributePropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeClassInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementPropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeEnumConstantImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeEnumLeafInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeMapPropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeModelBuilder.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeReferencePropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeRefImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeValuePropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/SingleTypePropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeInfoSetImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeRefImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Util.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ValuePropertyInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/GenericArrayTypeImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/Navigator.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/ParameterizedTypeImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/TypeVisitor.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/WildcardTypeImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeArrayInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeAttributePropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeBuiltinLeafInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeClassInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElement.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeEnumLeafInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeLeafInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeMapPropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElement.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElementRef.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimePropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeReferencePropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeRef.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeValuePropertyInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/package-info.java
! src/share/classes/com/sun/xml/internal/bind/v2/package-info.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/AnyTypeBeanInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ArrayBeanInfoImpl.java
+ src/share/classes/com/sun/xml/internal/bind/v2/runtime/AttributeAccessor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BinderImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeContextImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ClassBeanInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/CompositeStructureBeanInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/DomPostInitAction.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/FilterTransducer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/IllegalAnnotationException.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/IllegalAnnotationsException.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/InlineBinaryTransducer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/InternalBridge.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/JaxBeanInfo.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/LeafBeanInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/LifecycleMethods.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Location.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Messages.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/MimeTypedTransducer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Name.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/NameBuilder.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/NameList.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/SchemaTypeTransducer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/StAXPostInitAction.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/SwaRefAdapter.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Transducer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ValueListBeanInfoImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/C14nXmlOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/DOMOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/Encoded.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/NamespaceContextImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/Pcdata.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.java
+ src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutputAbstractImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/package-info.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayERProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementLeafProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementNodeProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayReferenceNodeProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/AttributeProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ListElementProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Messages.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Property.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/PropertyFactory.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/PropertyImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementLeafProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementNodeProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleReferenceNodeProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/StructureLoaderBuilder.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/TagAndType.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/UnmarshallerChain.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ValueProperty.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/AdaptedAccessor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/AdaptedLister.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/DefaultTransducedAccessor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/ListIterator.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/ListTransducedAccessorImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/NullSafeAccessor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerByte.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/TransducedAccessor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Bean.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Const.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Byte.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Ref.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Byte.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Ref.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedTransducedAccessorFactory.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Ref.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Boolean.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Byte.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Integer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Byte.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Integer.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/AttributesEx.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/AttributesExImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Base64Data.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ChildLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DefaultIDResolver.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DefaultValueLoaderDecorator.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Discarder.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DomLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/FastInfosetConnector.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/IntArrayData.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/IntData.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Intercepter.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/InterningXmlVisitor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LeafPropertyLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorEx.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorExWrapper.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/MTOMDecorator.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Patcher.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ProxyLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Receiver.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Scope.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXConnector.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXEventConnector.java
+ src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXExConnector.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXStreamConnector.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StructureLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/TagName.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/TextLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallerImpl.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ValuePropertyLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/WildcardLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XmlVisitor.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiNilLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/FoolProofResolver.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Form.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/GroupKind.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Messages.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Messages.properties
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/MultiMap.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Tree.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/Bindings.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/Klass.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/SchemaBindings.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/package-info.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/package-info.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ContentModelContainer.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Particle.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java
! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/ByteArrayOutputStreamEx.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/CollisionCheckStack.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/DataSourceSource.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/EditDistance.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/FatalAdapter.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/FlattenIterator.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/QNameMap.java
+ src/share/classes/com/sun/xml/internal/bind/v2/util/StackRecorder.java
! src/share/classes/com/sun/xml/internal/bind/v2/util/TypeCast.java
! src/share/classes/com/sun/xml/internal/dtdparser/DTDParser.java
! src/share/classes/com/sun/xml/internal/dtdparser/resources/Messages.properties
! src/share/classes/com/sun/xml/internal/fastinfoset/AbstractResourceBundle.java
! src/share/classes/com/sun/xml/internal/fastinfoset/Decoder.java
! src/share/classes/com/sun/xml/internal/fastinfoset/DecoderStateTables.java
! src/share/classes/com/sun/xml/internal/fastinfoset/Encoder.java
! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/BuiltInEncodingAlgorithmFactory.java
! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/HexadecimalEncodingAlgorithm.java
! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/LongEncodingAlgorithm.java
! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/UUIDEncodingAlgorithm.java
! src/share/classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentParser.java
! src/share/classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentSerializer.java
! src/share/classes/com/sun/xml/internal/fastinfoset/org/apache/xerces/util/XMLChar.java
! src/share/classes/com/sun/xml/internal/fastinfoset/resources/ResourceBundle.properties
! src/share/classes/com/sun/xml/internal/fastinfoset/sax/AttributesHolder.java
! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentParser.java
! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentSerializer.java
! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentSerializerWithPrefixMapping.java
! src/share/classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentParser.java
! src/share/classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentSerializer.java
- src/share/classes/com/sun/xml/internal/fastinfoset/stax/events/StAXEventAllocator.java
! src/share/classes/com/sun/xml/internal/fastinfoset/tools/VocabularyGenerator.java
! src/share/classes/com/sun/xml/internal/fastinfoset/util/CharArrayIntMap.java
! src/share/classes/com/sun/xml/internal/fastinfoset/util/DuplicateAttributeVerifier.java
! src/share/classes/com/sun/xml/internal/fastinfoset/util/NamespaceContextImplementation.java
! src/share/classes/com/sun/xml/internal/fastinfoset/util/StringIntMap.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/SOAPExceptionImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnectionFactory.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings.properties
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/Envelope.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/GifDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/JpegDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings.properties
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MultipartDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocument.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPIOException.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPVersionMismatchException.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPFactoryDynamicImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailEntryImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementFactory.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultElementImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderElementImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings.properties
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TreeException.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings.properties
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Body1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/BodyElement1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Detail1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/DetailEntry1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Envelope1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/FaultElement1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings.properties
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPFactory1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPMessageFactory1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/BodyElement1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/DetailEntry1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/FaultElement1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings.properties
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Message1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPFactory1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPMessageFactory1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/Base64.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteInputStream.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteOutputStream.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings.properties
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/LogDomainConstants.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/MimeHeadersUtil.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/NamespaceContextIterator.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ParserPool.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/TeeInputStream.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/XMLDeclarationParser.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java
! src/share/classes/com/sun/xml/internal/org/jvnet/fastinfoset/FastInfosetSerializer.java
! src/share/classes/com/sun/xml/internal/org/jvnet/fastinfoset/sax/helpers/EncodingAlgorithmAttributesImpl.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/Chunk.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/ChunkInputStream.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/Data.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/DataFile.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/DataHead.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FileData.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FinalArrayList.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/Header.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/InternetHeaders.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEConfig.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEEvent.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEMessage.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParser.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParsingException.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEPart.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MemoryData.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/WeakDataFile.java
! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java
! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/Base64Encoder.java
! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/ByteArrayOutputStreamEx.java
! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/NamespaceContextEx.java
+ src/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java
! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamReaderEx.java
! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamWriterEx.java
! src/share/classes/com/sun/xml/internal/rngom/binary/Messages.properties
! src/share/classes/com/sun/xml/internal/rngom/dt/builtin/Messages.properties
! src/share/classes/com/sun/xml/internal/rngom/parse/Messages.properties
! src/share/classes/com/sun/xml/internal/rngom/parse/compact/Messages.properties
! src/share/classes/com/sun/xml/internal/rngom/parse/xml/Messages.properties
! src/share/classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java
! src/share/classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java
! src/share/classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java
! src/share/classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferProcessor.java
! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java
! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java
! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java
! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java
! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferProcessor.java
! src/share/classes/com/sun/xml/internal/txw2/NamespaceSupport.java
! src/share/classes/com/sun/xml/internal/txw2/TXW.java
! src/share/classes/com/sun/xml/internal/txw2/annotation/XmlValue.java
! src/share/classes/com/sun/xml/internal/txw2/output/ResultFactory.java
+ src/share/classes/com/sun/xml/internal/txw2/output/TXWResult.java
+ src/share/classes/com/sun/xml/internal/txw2/output/TXWSerializer.java
! src/share/classes/com/sun/xml/internal/ws/addressing/EndpointReferenceUtil.java
+ src/share/classes/com/sun/xml/internal/ws/addressing/W3CWsaClientTube.java
+ src/share/classes/com/sun/xml/internal/ws/addressing/W3CWsaServerTube.java
! src/share/classes/com/sun/xml/internal/ws/addressing/WsaClientTube.java
+ src/share/classes/com/sun/xml/internal/ws/addressing/WsaPropertyBag.java
! src/share/classes/com/sun/xml/internal/ws/addressing/WsaServerTube.java
! src/share/classes/com/sun/xml/internal/ws/addressing/WsaTube.java
! src/share/classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java
! src/share/classes/com/sun/xml/internal/ws/addressing/WsaTubeHelperImpl.java
! src/share/classes/com/sun/xml/internal/ws/addressing/model/ActionNotSupportedException.java
+ src/share/classes/com/sun/xml/internal/ws/addressing/model/InvalidAddressingHeaderException.java
- src/share/classes/com/sun/xml/internal/ws/addressing/model/InvalidMapException.java
- src/share/classes/com/sun/xml/internal/ws/addressing/model/MapRequiredException.java
+ src/share/classes/com/sun/xml/internal/ws/addressing/model/MissingAddressingHeaderException.java
+ src/share/classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaClientTube.java
+ src/share/classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaServerTube.java
! src/share/classes/com/sun/xml/internal/ws/addressing/v200408/WsaTubeHelperImpl.java
! src/share/classes/com/sun/xml/internal/ws/api/BindingID.java
! src/share/classes/com/sun/xml/internal/ws/api/EndpointAddress.java
+ src/share/classes/com/sun/xml/internal/ws/api/ResourceLoader.java
! src/share/classes/com/sun/xml/internal/ws/api/SOAPVersion.java
! src/share/classes/com/sun/xml/internal/ws/api/WSService.java
! src/share/classes/com/sun/xml/internal/ws/api/addressing/AddressingVersion.java
! src/share/classes/com/sun/xml/internal/ws/api/addressing/OutboundReferenceParameterHeader.java
! src/share/classes/com/sun/xml/internal/ws/api/addressing/WSEndpointReference.java
+ src/share/classes/com/sun/xml/internal/ws/api/handler/MessageHandler.java
+ src/share/classes/com/sun/xml/internal/ws/api/handler/MessageHandlerContext.java
+ src/share/classes/com/sun/xml/internal/ws/api/message/FilterMessageImpl.java
! src/share/classes/com/sun/xml/internal/ws/api/message/Message.java
! src/share/classes/com/sun/xml/internal/ws/api/message/Messages.java
! src/share/classes/com/sun/xml/internal/ws/api/message/Packet.java
! src/share/classes/com/sun/xml/internal/ws/api/model/JavaMethod.java
+ src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundFault.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLInput.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLMessage.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java
! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/ClientPipeAssemblerContext.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/ClientTubeAssemblerContext.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/Fiber.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/NextAction.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/ServerPipeAssemblerContext.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/ServerTubeAssemblerContext.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/StreamSOAPCodec.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/TransportTubeFactory.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractFilterTubeImpl.java
! src/share/classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractTubeImpl.java
! src/share/classes/com/sun/xml/internal/ws/api/server/BoundEndpoint.java
+ src/share/classes/com/sun/xml/internal/ws/api/server/EndpointComponent.java
+ src/share/classes/com/sun/xml/internal/ws/api/server/HttpEndpoint.java
! src/share/classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java
! src/share/classes/com/sun/xml/internal/ws/api/server/PortAddressResolver.java
! src/share/classes/com/sun/xml/internal/ws/api/server/SDDocument.java
! src/share/classes/com/sun/xml/internal/ws/api/server/WSEndpoint.java
! src/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
! src/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java
! src/share/classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java
! src/share/classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java
! src/share/classes/com/sun/xml/internal/ws/binding/BindingImpl.java
! src/share/classes/com/sun/xml/internal/ws/binding/HTTPBindingImpl.java
! src/share/classes/com/sun/xml/internal/ws/binding/SOAPBindingImpl.java
! src/share/classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java
! src/share/classes/com/sun/xml/internal/ws/client/AsyncInvoker.java
! src/share/classes/com/sun/xml/internal/ws/client/AsyncResponseImpl.java
! src/share/classes/com/sun/xml/internal/ws/client/BindingProviderProperties.java
+ src/share/classes/com/sun/xml/internal/ws/client/ClientContainer.java
+ src/share/classes/com/sun/xml/internal/ws/client/ClientSchemaValidationTube.java
! src/share/classes/com/sun/xml/internal/ws/client/HandlerConfiguration.java
- src/share/classes/com/sun/xml/internal/ws/client/ResponseImpl.java
! src/share/classes/com/sun/xml/internal/ws/client/Stub.java
! src/share/classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java
! src/share/classes/com/sun/xml/internal/ws/client/dispatch/DataSourceDispatch.java
! src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchImpl.java
! src/share/classes/com/sun/xml/internal/ws/client/dispatch/RESTSourceDispatch.java
! src/share/classes/com/sun/xml/internal/ws/client/dispatch/SOAPMessageDispatch.java
- src/share/classes/com/sun/xml/internal/ws/client/sei/AsyncBuilder.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/AsyncMethodHandler.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/BodyBuilder.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/CallbackMethodHandler.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/MessageFiller.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/MethodHandler.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/PollingMethodHandler.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/ResponseBuilder.java
+ src/share/classes/com/sun/xml/internal/ws/client/sei/SEIMethodHandler.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/SEIStub.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/SyncMethodHandler.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/ValueGetter.java
+ src/share/classes/com/sun/xml/internal/ws/client/sei/ValueGetterFactory.java
! src/share/classes/com/sun/xml/internal/ws/client/sei/ValueSetter.java
+ src/share/classes/com/sun/xml/internal/ws/client/sei/ValueSetterFactory.java
+ src/share/classes/com/sun/xml/internal/ws/client/sei/pacakge-info.java
- src/share/classes/com/sun/xml/internal/ws/client/sei/package-info.java
+ src/share/classes/com/sun/xml/internal/ws/developer/BindingTypeFeature.java
+ src/share/classes/com/sun/xml/internal/ws/developer/JAXBContextFactory.java
! src/share/classes/com/sun/xml/internal/ws/developer/JAXWSProperties.java
! src/share/classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressing.java
! src/share/classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressingFeature.java
! src/share/classes/com/sun/xml/internal/ws/developer/MemberSubmissionEndpointReference.java
+ src/share/classes/com/sun/xml/internal/ws/developer/SchemaValidation.java
+ src/share/classes/com/sun/xml/internal/ws/developer/SchemaValidationFeature.java
! src/share/classes/com/sun/xml/internal/ws/developer/StatefulFeature.java
+ src/share/classes/com/sun/xml/internal/ws/developer/StreamingAttachment.java
+ src/share/classes/com/sun/xml/internal/ws/developer/StreamingAttachmentFeature.java
+ src/share/classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java
+ src/share/classes/com/sun/xml/internal/ws/developer/UsesJAXBContext.java
+ src/share/classes/com/sun/xml/internal/ws/developer/UsesJAXBContextFeature.java
+ src/share/classes/com/sun/xml/internal/ws/developer/ValidationErrorHandler.java
! src/share/classes/com/sun/xml/internal/ws/developer/WSBindingProvider.java
- src/share/classes/com/sun/xml/internal/ws/encoding/AbstractXMLStreamWriterExImpl.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/ContentType.java
! src/share/classes/com/sun/xml/internal/ws/encoding/ContentTypeImpl.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/DataSourceStreamingDataHandler.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/HeaderTokenizer.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/ImageDataContentHandler.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/MIMEPartStreamingDataHandler.java
! src/share/classes/com/sun/xml/internal/ws/encoding/MimeCodec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/MimeMultipartParser.java
! src/share/classes/com/sun/xml/internal/ws/encoding/MtomCodec.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/ParameterList.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/RootOnlyCodec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/SOAPBindingCodec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/StringDataContentHandler.java
! src/share/classes/com/sun/xml/internal/ws/encoding/SwACodec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/TagInfoset.java
! src/share/classes/com/sun/xml/internal/ws/encoding/XMLHTTPBindingCodec.java
+ src/share/classes/com/sun/xml/internal/ws/encoding/XmlDataContentHandler.java
! src/share/classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetCodec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLCodec.java
! src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLMessage.java
! src/share/classes/com/sun/xml/internal/ws/fault/SOAP11Fault.java
! src/share/classes/com/sun/xml/internal/ws/fault/SOAP12Fault.java
! src/share/classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java
! src/share/classes/com/sun/xml/internal/ws/handler/ClientLogicalHandlerTube.java
+ src/share/classes/com/sun/xml/internal/ws/handler/ClientMessageHandlerTube.java
! src/share/classes/com/sun/xml/internal/ws/handler/ClientSOAPHandlerTube.java
! src/share/classes/com/sun/xml/internal/ws/handler/HandlerTube.java
+ src/share/classes/com/sun/xml/internal/ws/handler/MessageHandlerContextImpl.java
! src/share/classes/com/sun/xml/internal/ws/handler/SOAPMessageContextImpl.java
! src/share/classes/com/sun/xml/internal/ws/handler/ServerLogicalHandlerTube.java
+ src/share/classes/com/sun/xml/internal/ws/handler/ServerMessageHandlerTube.java
! src/share/classes/com/sun/xml/internal/ws/handler/ServerSOAPHandlerTube.java
! src/share/classes/com/sun/xml/internal/ws/message/AttachmentUnmarshallerImpl.java
! src/share/classes/com/sun/xml/internal/ws/message/ByteArrayAttachment.java
! src/share/classes/com/sun/xml/internal/ws/message/DOMHeader.java
! src/share/classes/com/sun/xml/internal/ws/message/DataHandlerAttachment.java
+ src/share/classes/com/sun/xml/internal/ws/message/FaultMessage.java
! src/share/classes/com/sun/xml/internal/ws/message/JAXBAttachment.java
! src/share/classes/com/sun/xml/internal/ws/message/MimeAttachmentSet.java
! src/share/classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java
! src/share/classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java
! src/share/classes/com/sun/xml/internal/ws/message/jaxb/MarshallerBridge.java
! src/share/classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java
! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamAttachment.java
! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamHeader.java
! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamHeader11.java
! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamHeader12.java
! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java
! src/share/classes/com/sun/xml/internal/ws/model/AbstractSEIModelImpl.java
+ src/share/classes/com/sun/xml/internal/ws/model/FieldSignature.java
+ src/share/classes/com/sun/xml/internal/ws/model/Injector.java
! src/share/classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java
! src/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java
! src/share/classes/com/sun/xml/internal/ws/model/SOAPSEIModel.java
+ src/share/classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java
+ src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java
! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java
! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java
! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java
! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java
! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java
! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/AnnotationVisitor.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/AnnotationWriter.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Attribute.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ByteVector.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassReader.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassVisitor.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassWriter.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Edge.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/FieldVisitor.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/FieldWriter.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Frame.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Handler.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Item.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Label.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/MethodVisitor.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/MethodWriter.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Opcodes.java
+ src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Type.java
! src/share/classes/com/sun/xml/internal/ws/protocol/soap/MUTube.java
+ src/share/classes/com/sun/xml/internal/ws/protocol/soap/MessageCreationException.java
! src/share/classes/com/sun/xml/internal/ws/resources/AddressingMessages.java
! src/share/classes/com/sun/xml/internal/ws/resources/ClientMessages.java
! src/share/classes/com/sun/xml/internal/ws/resources/ModelerMessages.java
! src/share/classes/com/sun/xml/internal/ws/resources/ProviderApiMessages.java
! src/share/classes/com/sun/xml/internal/ws/resources/ServerMessages.java
! src/share/classes/com/sun/xml/internal/ws/resources/WsservletMessages.java
! src/share/classes/com/sun/xml/internal/ws/resources/addressing.properties
! src/share/classes/com/sun/xml/internal/ws/resources/client.properties
! src/share/classes/com/sun/xml/internal/ws/resources/dispatch.properties
! src/share/classes/com/sun/xml/internal/ws/resources/encoding.properties
! src/share/classes/com/sun/xml/internal/ws/resources/handler.properties
! src/share/classes/com/sun/xml/internal/ws/resources/httpserver.properties
! src/share/classes/com/sun/xml/internal/ws/resources/modeler.properties
! src/share/classes/com/sun/xml/internal/ws/resources/providerApi.properties
! src/share/classes/com/sun/xml/internal/ws/resources/sender.properties
! src/share/classes/com/sun/xml/internal/ws/resources/server.properties
! src/share/classes/com/sun/xml/internal/ws/resources/soap.properties
! src/share/classes/com/sun/xml/internal/ws/resources/streaming.properties
! src/share/classes/com/sun/xml/internal/ws/resources/util.properties
! src/share/classes/com/sun/xml/internal/ws/resources/wsdlmodel.properties
! src/share/classes/com/sun/xml/internal/ws/resources/wsservlet.properties
! src/share/classes/com/sun/xml/internal/ws/resources/xmlmessage.properties
! src/share/classes/com/sun/xml/internal/ws/server/AbstractInstanceResolver.java
+ src/share/classes/com/sun/xml/internal/ws/server/DraconianValidationErrorHandler.java
! src/share/classes/com/sun/xml/internal/ws/server/EndpointFactory.java
+ src/share/classes/com/sun/xml/internal/ws/server/JMXAgent.java
! src/share/classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java
+ src/share/classes/com/sun/xml/internal/ws/server/ServerSchemaValidationTube.java
! src/share/classes/com/sun/xml/internal/ws/server/StatefulInstanceResolver.java
! src/share/classes/com/sun/xml/internal/ws/server/UnsupportedMediaException.java
! src/share/classes/com/sun/xml/internal/ws/server/WSDLPatcher.java
! src/share/classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java
! src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderArgumentsBuilder.java
! src/share/classes/com/sun/xml/internal/ws/server/provider/XMLProviderArgumentBuilder.java
! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointArgumentsBuilder.java
! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointMethodDispatcher.java
! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointMethodDispatcherGetter.java
! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointMethodHandler.java
! src/share/classes/com/sun/xml/internal/ws/server/sei/PayloadQNameBasedDispatcher.java
! src/share/classes/com/sun/xml/internal/ws/server/sei/SEIInvokerTube.java
+ src/share/classes/com/sun/xml/internal/ws/server/sei/SOAPActionBasedDispatcher.java
! src/share/classes/com/sun/xml/internal/ws/spi/ProviderImpl.java
! src/share/classes/com/sun/xml/internal/ws/streaming/DOMStreamReader.java
+ src/share/classes/com/sun/xml/internal/ws/streaming/MtomStreamWriter.java
- src/share/classes/com/sun/xml/internal/ws/streaming/XMLReader.java
! src/share/classes/com/sun/xml/internal/ws/streaming/XMLReaderException.java
! src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderUtil.java
! src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterUtil.java
! src/share/classes/com/sun/xml/internal/ws/transport/Headers.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/DeploymentDescriptorParser.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java
+ src/share/classes/com/sun/xml/internal/ws/transport/http/HttpDump.java
+ src/share/classes/com/sun/xml/internal/ws/transport/http/HttpDumpMBean.java
+ src/share/classes/com/sun/xml/internal/ws/transport/http/HttpMetadataPublisher.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/WSHTTPConnection.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransport.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointImpl.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/server/HttpEndpoint.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerConnectionImpl.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
! src/share/classes/com/sun/xml/internal/ws/transport/http/server/WSHttpHandler.java
! src/share/classes/com/sun/xml/internal/ws/util/ByteArrayBuffer.java
! src/share/classes/com/sun/xml/internal/ws/util/DOMUtil.java
! src/share/classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java
+ src/share/classes/com/sun/xml/internal/ws/util/MetadataUtil.java
! src/share/classes/com/sun/xml/internal/ws/util/Pool.java
! src/share/classes/com/sun/xml/internal/ws/util/QNameMap.java
! src/share/classes/com/sun/xml/internal/ws/util/RuntimeVersion.java
+ src/share/classes/com/sun/xml/internal/ws/util/RuntimeVersionMBean.java
+ src/share/classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/share/classes/com/sun/xml/internal/ws/util/pipe/DumpTube.java
! src/share/classes/com/sun/xml/internal/ws/util/pipe/StandaloneTubeAssembler.java
! src/share/classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties
! src/share/classes/com/sun/xml/internal/ws/util/version.properties
! src/share/classes/com/sun/xml/internal/ws/util/xml/ContentHandlerToXMLStreamWriter.java
+ src/share/classes/com/sun/xml/internal/ws/util/xml/MetadataDocument.java
! src/share/classes/com/sun/xml/internal/ws/util/xml/StAXSource.java
! src/share/classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToXMLStreamWriter.java
! src/share/classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/ParserUtil.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java
+ src/share/classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/writer/UsingAddressing.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/writer/W3CAddressingWSDLGeneratorExtension.java
! src/share/classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java
! src/share/classes/com/sun/xml/internal/xsom/ForeignAttributes.java
! src/share/classes/com/sun/xml/internal/xsom/SCD.java
! src/share/classes/com/sun/xml/internal/xsom/XSAnnotation.java
! src/share/classes/com/sun/xml/internal/xsom/XSAttContainer.java
! src/share/classes/com/sun/xml/internal/xsom/XSAttGroupDecl.java
! src/share/classes/com/sun/xml/internal/xsom/XSAttributeDecl.java
! src/share/classes/com/sun/xml/internal/xsom/XSAttributeUse.java
! src/share/classes/com/sun/xml/internal/xsom/XSComplexType.java
! src/share/classes/com/sun/xml/internal/xsom/XSComponent.java
! src/share/classes/com/sun/xml/internal/xsom/XSContentType.java
! src/share/classes/com/sun/xml/internal/xsom/XSDeclaration.java
! src/share/classes/com/sun/xml/internal/xsom/XSElementDecl.java
! src/share/classes/com/sun/xml/internal/xsom/XSFacet.java
! src/share/classes/com/sun/xml/internal/xsom/XSIdentityConstraint.java
! src/share/classes/com/sun/xml/internal/xsom/XSListSimpleType.java
! src/share/classes/com/sun/xml/internal/xsom/XSModelGroup.java
! src/share/classes/com/sun/xml/internal/xsom/XSModelGroupDecl.java
! src/share/classes/com/sun/xml/internal/xsom/XSNotation.java
! src/share/classes/com/sun/xml/internal/xsom/XSParticle.java
! src/share/classes/com/sun/xml/internal/xsom/XSRestrictionSimpleType.java
! src/share/classes/com/sun/xml/internal/xsom/XSSchema.java
! src/share/classes/com/sun/xml/internal/xsom/XSSchemaSet.java
! src/share/classes/com/sun/xml/internal/xsom/XSSimpleType.java
! src/share/classes/com/sun/xml/internal/xsom/XSTerm.java
! src/share/classes/com/sun/xml/internal/xsom/XSType.java
! src/share/classes/com/sun/xml/internal/xsom/XSUnionSimpleType.java
! src/share/classes/com/sun/xml/internal/xsom/XSVariety.java
! src/share/classes/com/sun/xml/internal/xsom/XSWildcard.java
! src/share/classes/com/sun/xml/internal/xsom/XSXPath.java
! src/share/classes/com/sun/xml/internal/xsom/XmlString.java
! src/share/classes/com/sun/xml/internal/xsom/impl/AnnotationImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/AttGroupDeclImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/AttributeDeclImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/AttributeUseImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/AttributesHolder.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ComplexTypeImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ComponentImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/Const.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ContentTypeImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/DeclarationImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ElementDecl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/EmptyImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/FacetImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ForeignAttributesImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/IdentityConstraintImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ListSimpleTypeImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ModelGroupDeclImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ModelGroupImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/NotationImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/ParticleImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/Ref.java
! src/share/classes/com/sun/xml/internal/xsom/impl/RestrictionSimpleTypeImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/SchemaImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/SchemaSetImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/SimpleTypeImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/UName.java
! src/share/classes/com/sun/xml/internal/xsom/impl/UnionSimpleTypeImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/Util.java
! src/share/classes/com/sun/xml/internal/xsom/impl/WildcardImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/XPathImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/package.html
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/BaseContentRef.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/DefaultAnnotationParser.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/DelayedRef.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Messages.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Messages_ja.properties
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/NGCCRuntimeEx.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/ParserContext.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Patch.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/PatcherManager.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/SchemaDocumentImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/SubstGroupBaseTypeRef.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/group.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java
! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java
! src/share/classes/com/sun/xml/internal/xsom/impl/scd/AbstractAxisImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/scd/Axis.java
! src/share/classes/com/sun/xml/internal/xsom/impl/scd/Iterators.java
! src/share/classes/com/sun/xml/internal/xsom/impl/scd/ParseException.java
! src/share/classes/com/sun/xml/internal/xsom/impl/scd/SCDImpl.java
! src/share/classes/com/sun/xml/internal/xsom/impl/scd/SCDParserConstants.java
! src/share/classes/com/sun/xml/internal/xsom/impl/scd/Step.java
! src/share/classes/com/sun/xml/internal/xsom/impl/util/DraconianErrorHandler.java
! src/share/classes/com/sun/xml/internal/xsom/impl/util/ResourceEntityResolver.java
! src/share/classes/com/sun/xml/internal/xsom/impl/util/SchemaTreeTraverser.java
! src/share/classes/com/sun/xml/internal/xsom/impl/util/SchemaWriter.java
! src/share/classes/com/sun/xml/internal/xsom/impl/util/Uri.java
! src/share/classes/com/sun/xml/internal/xsom/parser/AnnotationContext.java
! src/share/classes/com/sun/xml/internal/xsom/parser/AnnotationParser.java
! src/share/classes/com/sun/xml/internal/xsom/parser/AnnotationParserFactory.java
! src/share/classes/com/sun/xml/internal/xsom/parser/JAXPParser.java
! src/share/classes/com/sun/xml/internal/xsom/parser/SchemaDocument.java
! src/share/classes/com/sun/xml/internal/xsom/parser/XMLParser.java
! src/share/classes/com/sun/xml/internal/xsom/parser/XSOMParser.java
! src/share/classes/com/sun/xml/internal/xsom/parser/package.html
! src/share/classes/com/sun/xml/internal/xsom/util/ComponentNameFunction.java
! src/share/classes/com/sun/xml/internal/xsom/util/DeferedCollection.java
! src/share/classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java
! src/share/classes/com/sun/xml/internal/xsom/util/NameGetter.java
! src/share/classes/com/sun/xml/internal/xsom/util/NameGetter.properties
! src/share/classes/com/sun/xml/internal/xsom/util/SimpleTypeSet.java
! src/share/classes/com/sun/xml/internal/xsom/util/TypeClosure.java
! src/share/classes/com/sun/xml/internal/xsom/util/TypeSet.java
! src/share/classes/com/sun/xml/internal/xsom/util/XSFinder.java
! src/share/classes/com/sun/xml/internal/xsom/util/XSFunctionFilter.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSContentTypeFunction.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSContentTypeVisitor.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSFunction.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSSimpleTypeFunction.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSSimpleTypeVisitor.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSTermFunction.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSTermFunctionWithParam.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSTermVisitor.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSVisitor.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSWildcardFunction.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/XSWildcardVisitor.java
! src/share/classes/com/sun/xml/internal/xsom/visitor/package.html
! src/share/classes/javax/xml/bind/ContextFinder.java
! src/share/classes/javax/xml/bind/DatatypeConverter.java
! src/share/classes/javax/xml/bind/DatatypeConverterImpl.java
! src/share/classes/javax/xml/bind/DatatypeConverterInterface.java
! src/share/classes/javax/xml/bind/Element.java
! src/share/classes/javax/xml/bind/JAXBContext.java
! src/share/classes/javax/xml/bind/JAXBException.java
! src/share/classes/javax/xml/bind/MarshalException.java
! src/share/classes/javax/xml/bind/Marshaller.java
! src/share/classes/javax/xml/bind/Messages.properties
! src/share/classes/javax/xml/bind/NotIdentifiableEvent.java
! src/share/classes/javax/xml/bind/ParseConversionEvent.java
! src/share/classes/javax/xml/bind/PrintConversionEvent.java
! src/share/classes/javax/xml/bind/PropertyException.java
! src/share/classes/javax/xml/bind/TypeConstraintException.java
! src/share/classes/javax/xml/bind/UnmarshalException.java
! src/share/classes/javax/xml/bind/Unmarshaller.java
! src/share/classes/javax/xml/bind/UnmarshallerHandler.java
! src/share/classes/javax/xml/bind/ValidationEvent.java
! src/share/classes/javax/xml/bind/ValidationEventHandler.java
! src/share/classes/javax/xml/bind/ValidationEventLocator.java
! src/share/classes/javax/xml/bind/ValidationException.java
! src/share/classes/javax/xml/bind/Validator.java
! src/share/classes/javax/xml/bind/annotation/XmlAccessOrder.java
! src/share/classes/javax/xml/bind/annotation/XmlAccessType.java
! src/share/classes/javax/xml/bind/annotation/XmlAccessorOrder.java
! src/share/classes/javax/xml/bind/annotation/XmlAccessorType.java
! src/share/classes/javax/xml/bind/annotation/XmlAttribute.java
! src/share/classes/javax/xml/bind/annotation/XmlElement.java
! src/share/classes/javax/xml/bind/annotation/XmlID.java
! src/share/classes/javax/xml/bind/annotation/XmlIDREF.java
! src/share/classes/javax/xml/bind/annotation/XmlNs.java
! src/share/classes/javax/xml/bind/annotation/XmlNsForm.java
! src/share/classes/javax/xml/bind/annotation/XmlSchema.java
! src/share/classes/javax/xml/bind/annotation/XmlSeeAlso.java
! src/share/classes/javax/xml/bind/annotation/XmlTransient.java
! src/share/classes/javax/xml/bind/annotation/XmlType.java
! src/share/classes/javax/xml/bind/annotation/XmlValue.java
! src/share/classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java
! src/share/classes/javax/xml/bind/annotation/adapters/package.html
! src/share/classes/javax/xml/bind/annotation/package.html
! src/share/classes/javax/xml/bind/attachment/package.html
! src/share/classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java
! src/share/classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java
! src/share/classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java
! src/share/classes/javax/xml/bind/helpers/Messages.properties
! src/share/classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java
! src/share/classes/javax/xml/bind/helpers/ParseConversionEventImpl.java
! src/share/classes/javax/xml/bind/helpers/PrintConversionEventImpl.java
! src/share/classes/javax/xml/bind/helpers/ValidationEventImpl.java
! src/share/classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java
! src/share/classes/javax/xml/bind/helpers/package.html
! src/share/classes/javax/xml/bind/package.html
! src/share/classes/javax/xml/bind/util/Messages.properties
! src/share/classes/javax/xml/bind/util/ValidationEventCollector.java
! src/share/classes/javax/xml/bind/util/package.html
! src/share/classes/javax/xml/soap/AttachmentPart.java
! src/share/classes/javax/xml/soap/Detail.java
! src/share/classes/javax/xml/soap/DetailEntry.java
! src/share/classes/javax/xml/soap/FactoryFinder.java
! src/share/classes/javax/xml/soap/MessageFactory.java
! src/share/classes/javax/xml/soap/MimeHeader.java
! src/share/classes/javax/xml/soap/MimeHeaders.java
! src/share/classes/javax/xml/soap/Name.java
! src/share/classes/javax/xml/soap/Node.java
! src/share/classes/javax/xml/soap/SAAJMetaFactory.java
! src/share/classes/javax/xml/soap/SAAJResult.java
! src/share/classes/javax/xml/soap/SOAPBody.java
! src/share/classes/javax/xml/soap/SOAPBodyElement.java
! src/share/classes/javax/xml/soap/SOAPConnection.java
! src/share/classes/javax/xml/soap/SOAPConnectionFactory.java
! src/share/classes/javax/xml/soap/SOAPConstants.java
! src/share/classes/javax/xml/soap/SOAPElement.java
! src/share/classes/javax/xml/soap/SOAPElementFactory.java
! src/share/classes/javax/xml/soap/SOAPEnvelope.java
! src/share/classes/javax/xml/soap/SOAPException.java
! src/share/classes/javax/xml/soap/SOAPFactory.java
! src/share/classes/javax/xml/soap/SOAPFault.java
! src/share/classes/javax/xml/soap/SOAPFaultElement.java
! src/share/classes/javax/xml/soap/SOAPHeader.java
! src/share/classes/javax/xml/soap/SOAPHeaderElement.java
! src/share/classes/javax/xml/soap/SOAPMessage.java
! src/share/classes/javax/xml/soap/SOAPPart.java
! src/share/classes/javax/xml/soap/Text.java
! src/share/classes/javax/xml/soap/package.html
! src/share/classes/javax/xml/ws/spi/FactoryFinder.java
! src/share/classes/javax/xml/ws/wsaddressing/W3CEndpointReference.java
! src/share/classes/org/relaxng/datatype/Datatype.java
! src/share/classes/org/relaxng/datatype/DatatypeBuilder.java
! src/share/classes/org/relaxng/datatype/DatatypeException.java
! src/share/classes/org/relaxng/datatype/DatatypeLibrary.java
! src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java
! src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java
! src/share/classes/org/relaxng/datatype/ValidationContext.java
! src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java
! src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java
! src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.java

Changeset: 3d1c5fd9c01d
Author:    asaha
Date:      2009-08-10 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/3d1c5fd9c01d

Merge




From Jonathan.Gibbons at Sun.COM  Tue Aug 11 15:59:52 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Tue, 11 Aug 2009 08:59:52 -0700
Subject: javac CRASH
In-Reply-To: <4A818EE8.6030307@gmx.de>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr> <4A80C049.2020202@sun.com>
	<4A813498.3010004@gmx.de> <4A813E03.4000702@univ-mlv.fr>
	<33338629-C8F0-4649-A3AD-A6BCA88631B7@Sun.COM>
	<4A818EE8.6030307@gmx.de>
Message-ID: <CF5F34C7-8A2E-4693-8C13-A8C46720B2F7@Sun.COM>

Ulf,

Your settings for boot.java.home and target.java.home look OK.

The intent of the build is that while building the bootstrap compiler,  
the settings for boot.javac.source and boot.javac.target should be  
active and these are correctly set to 6 in langtools/make/ 
build.properties.  I will investigate why these might not be in use  
later today, when I have easy access to a Windows machine.

Separately, I also note that the intent is that you should not *need*  
to edit langtools/make/build.properties, although it is not incorrect  
to do so. But, it can lead to accidents if you might be committing and  
pushing changes.   To minimize that risk, you can provide/override  
values in a number of ways:
-- on the Ant command line (if you invoke Ant directly)
-- in NetBeans, in the Properties box under Tools> Options>  
Miscellaneous> Ant
-- in a new unmanaged file langtools/build.properties (note no make/  
component)
-- in ${user.home}/.openjdk/langtools-build.properties
-- in ${user.home}/.openjdk/build.properties
The last two choices allow you to set values to be shared by multiple  
repositories.

There is no make/build.properties in the jdk/ repository because that  
repository uses "make" instead of "ant" for building.   To build the  
jdk repository, you will need either MKS or Cygwin installed on your  
system. For more info, see the notes on the OpenJDK web pages. There  
are NetBeans projects for selected parts of the jdk/ to make it easy  
to work on small subsystems. However, I don't believe those (NetBeans)  
projects are being actively maintained at this point. [This does not  
apply to the langtools/ files. ]

-- Jon





On Aug 11, 2009, at 8:31 AM, Ulf Zibis wrote:

> Jon,
>
> that would be great.
>
> I've found out a solution, but I'm not sure, if this is as designed.  
> In path_to_jdk7_sources\langtools\make\build.properties I set:
> boot.java.home = C:/Programme/Java/jdk1.6.0_14
> target.java.home = C:/Programme/Java/jdk1.7.0
> javac.source = 6
> javac.target = 6
>
> I'm wondering, that there is no ...\make\build.properties file in tl/ 
> jdk tree.
>
> Maybe you like to have a look on ...\make\netbeans\charset\* in my  
> patch for https://bugs.openjdk.java.net/show_bug.cgi?id=100098 ?
>
> -Ulf
>
>
>
> Am 11.08.2009 16:49, Jonathan Gibbons schrieb:
>> R?mi,
>>
>> Thanks for the heads up. I'll check this out.  It is still the case  
>> that you should only need 1.6 to build langtools.
>>
>> -- Jon
>>
>>
>>
>> On Aug 11, 2009, at 2:46 AM, R?mi Forax wrote:
>>
>>> Le 11/08/2009 11:06, Ulf Zibis a ?crit :
>>>> Jonathan,
>>>>
>>>> thanks for additional help.
>>>>
>>>> Now I tried:
>>>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans  
>>>> 6.7.1\java2\ant\
>>>> bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>>
>>> I've noticed that.
>>> You have to run ant with jdk7.
>>>
>>> JAVA_HOME=C:/Programme/Java/jdk1.7.0
>>> ant -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>>
>>> Jon, it seems the ant build script need be updated because
>>> we are not able to compile with jdk6 anymore.
>>> The bootstrap javac/javap/etc should be built with -source 1.6 - 
>>> target 1.6.
>>>
>>> R?mi
>>
>>
>



From abhijit.saha at sun.com  Tue Aug 11 16:02:27 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Tue, 11 Aug 2009 16:02:27 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090811160334.D6FFFEA5B@hg.openjdk.java.net>

Changeset: 8b97f8827d08
Author:    asaha
Date:      2009-08-07 11:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b97f8827d08

6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14
Reviewed-by: darcy, ramap

! THIRD_PARTY_README

Changeset: 1ec22dda0652
Author:    asaha
Date:      2009-08-10 09:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ec22dda0652

Merge

- src/share/classes/com/sun/crypto/provider/JarVerifier.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
- src/share/classes/sun/security/pkcs11/JarVerifier.java
- src/windows/classes/sun/security/mscapi/JarVerifier.java

Changeset: 7681fa43d310
Author:    asaha
Date:      2009-08-11 08:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7681fa43d310

Merge




From abhijit.saha at sun.com  Tue Aug 11 16:09:59 2009
From: abhijit.saha at sun.com (abhijit.saha at sun.com)
Date: Tue, 11 Aug 2009 16:09:59 +0000
Subject: hg: jdk7/tl/langtools: 3 new changesets
Message-ID: <20090811161008.E5EDEEA60@hg.openjdk.java.net>

Changeset: 21f1d2462c7c
Author:    asaha
Date:      2009-08-07 11:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/21f1d2462c7c

6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14
Reviewed-by: darcy, ramap

! THIRD_PARTY_README

Changeset: 91852fb12e2e
Author:    asaha
Date:      2009-08-10 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/91852fb12e2e

Merge


Changeset: 38f54dbd2e5b
Author:    asaha
Date:      2009-08-11 08:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/38f54dbd2e5b

Merge




From vincent.ryan at sun.com  Tue Aug 11 16:10:00 2009
From: vincent.ryan at sun.com (vincent.ryan at sun.com)
Date: Tue, 11 Aug 2009 16:10:00 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090811161052.326C9EA61@hg.openjdk.java.net>

Changeset: 1ff7163fc5f7
Author:    vinnie
Date:      2009-08-11 16:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ff7163fc5f7

6840752: Provide out-of-the-box support for ECC algorithms
Reviewed-by: alanb, mullan, wetmore

! make/sun/security/Makefile
+ make/sun/security/ec/FILES_c.gmk
+ make/sun/security/ec/Makefile
+ make/sun/security/ec/mapfile-vers
! make/sun/security/other/Makefile
+ src/share/classes/sun/security/ec/ECDHKeyAgreement.java
+ src/share/classes/sun/security/ec/ECDSASignature.java
+ src/share/classes/sun/security/ec/ECKeyPairGenerator.java
+ src/share/classes/sun/security/ec/SunEC.java
+ src/share/classes/sun/security/ec/SunECEntries.java
! src/share/lib/security/java.security
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
+ src/share/native/sun/security/ec/ECC_JNI.cpp
+ src/share/native/sun/security/ec/ec.c
+ src/share/native/sun/security/ec/ec.h
+ src/share/native/sun/security/ec/ec2.h
+ src/share/native/sun/security/ec/ec2_163.c
+ src/share/native/sun/security/ec/ec2_193.c
+ src/share/native/sun/security/ec/ec2_233.c
+ src/share/native/sun/security/ec/ec2_aff.c
+ src/share/native/sun/security/ec/ec2_mont.c
+ src/share/native/sun/security/ec/ec_naf.c
+ src/share/native/sun/security/ec/ecc_impl.h
+ src/share/native/sun/security/ec/ecdecode.c
+ src/share/native/sun/security/ec/ecl-curve.h
+ src/share/native/sun/security/ec/ecl-exp.h
+ src/share/native/sun/security/ec/ecl-priv.h
+ src/share/native/sun/security/ec/ecl.c
+ src/share/native/sun/security/ec/ecl.h
+ src/share/native/sun/security/ec/ecl_curve.c
+ src/share/native/sun/security/ec/ecl_gf.c
+ src/share/native/sun/security/ec/ecl_mult.c
+ src/share/native/sun/security/ec/ecp.h
+ src/share/native/sun/security/ec/ecp_192.c
+ src/share/native/sun/security/ec/ecp_224.c
+ src/share/native/sun/security/ec/ecp_256.c
+ src/share/native/sun/security/ec/ecp_384.c
+ src/share/native/sun/security/ec/ecp_521.c
+ src/share/native/sun/security/ec/ecp_aff.c
+ src/share/native/sun/security/ec/ecp_jac.c
+ src/share/native/sun/security/ec/ecp_jm.c
+ src/share/native/sun/security/ec/ecp_mont.c
+ src/share/native/sun/security/ec/logtab.h
+ src/share/native/sun/security/ec/mp_gf2m-priv.h
+ src/share/native/sun/security/ec/mp_gf2m.c
+ src/share/native/sun/security/ec/mp_gf2m.h
+ src/share/native/sun/security/ec/mpi-config.h
+ src/share/native/sun/security/ec/mpi-priv.h
+ src/share/native/sun/security/ec/mpi.c
+ src/share/native/sun/security/ec/mpi.h
+ src/share/native/sun/security/ec/mplogic.c
+ src/share/native/sun/security/ec/mplogic.h
+ src/share/native/sun/security/ec/mpmontg.c
+ src/share/native/sun/security/ec/mpprime.h
+ src/share/native/sun/security/ec/oid.c
+ src/share/native/sun/security/ec/secitem.c
+ src/share/native/sun/security/ec/secoidt.h
+ test/sun/security/ec/TestEC.java
+ test/sun/security/ec/p12passwords.txt
+ test/sun/security/ec/pkcs12/secp256r1server-secp384r1ca.p12
+ test/sun/security/ec/pkcs12/sect193r1server-rsa1024ca.p12

Changeset: 485d3eb9b50b
Author:    vinnie
Date:      2009-08-11 16:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/485d3eb9b50b

Merge


Changeset: 95ae810b66fb
Author:    vinnie
Date:      2009-08-11 17:01 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/95ae810b66fb

Merge




From Jonathan.Gibbons at Sun.COM  Tue Aug 11 18:28:38 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Tue, 11 Aug 2009 11:28:38 -0700
Subject: javac CRASH
In-Reply-To: <4A818EE8.6030307@gmx.de>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr> <4A80C049.2020202@sun.com>
	<4A813498.3010004@gmx.de> <4A813E03.4000702@univ-mlv.fr>
	<33338629-C8F0-4649-A3AD-A6BCA88631B7@Sun.COM>
	<4A818EE8.6030307@gmx.de>
Message-ID: <4A81B856.7000702@sun.com>

Ulf, R?mi,

I have found an issue in the langtools/make/build.xml file that is 
likely the cause of the problems you are having.
There are references to @{javac.java.home}/bin/javac which look suspect. 
I suspect they should be javac.exe
on Windows.

I will post a fix once I have one and have verified it for plain 
invocation from the Windows command shell and
from Cygwin.

-- Jon


Ulf Zibis wrote:
> Jon,
>
> that would be great.
>
> I've found out a solution, but I'm not sure, if this is as designed. 
> In path_to_jdk7_sources\langtools\make\build.properties I set:
> boot.java.home = C:/Programme/Java/jdk1.6.0_14
> target.java.home = C:/Programme/Java/jdk1.7.0
> javac.source = 6
> javac.target = 6
>
> I'm wondering, that there is no ...\make\build.properties file in 
> tl/jdk tree.
>
> Maybe you like to have a look on ...\make\netbeans\charset\* in my 
> patch for https://bugs.openjdk.java.net/show_bug.cgi?id=100098 ?
>
> -Ulf
>
>
>
> Am 11.08.2009 16:49, Jonathan Gibbons schrieb:
>> R?mi,
>>
>> Thanks for the heads up. I'll check this out.  It is still the case 
>> that you should only need 1.6 to build langtools.
>>
>> -- Jon
>>
>>
>>
>> On Aug 11, 2009, at 2:46 AM, R?mi Forax wrote:
>>
>>> Le 11/08/2009 11:06, Ulf Zibis a ?crit :
>>>> Jonathan,
>>>>
>>>> thanks for additional help.
>>>>
>>>> Now I tried:
>>>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
>>>> 6.7.1\java2\ant\
>>>> bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>>
>>> I've noticed that.
>>> You have to run ant with jdk7.
>>>
>>> JAVA_HOME=C:/Programme/Java/jdk1.7.0
>>> ant -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>>
>>> Jon, it seems the ant build script need be updated because
>>> we are not able to compile with jdk6 anymore.
>>> The bootstrap javac/javap/etc should be built with -source 1.6 
>>> -target 1.6.
>>>
>>> R?mi
>>
>>
>



From jonathan.gibbons at sun.com  Tue Aug 11 21:15:09 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 11 Aug 2009 21:15:09 +0000
Subject: hg: jdk7/tl/langtools: 6870591: langtools build sets
	javac.bootclasspath incorrectly
Message-ID: <20090811211519.4860DEA9B@hg.openjdk.java.net>

Changeset: beefdeb352e6
Author:    jjg
Date:      2009-08-11 14:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/beefdeb352e6

6870591: langtools build sets javac.bootclasspath incorrectly
Reviewed-by: ohair

! make/build.xml



From Ulf.Zibis at gmx.de  Tue Aug 11 21:58:05 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 11 Aug 2009 23:58:05 +0200
Subject: javac CRASH
In-Reply-To: <CF5F34C7-8A2E-4693-8C13-A8C46720B2F7@Sun.COM>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de> <4A7834DB.7020708@univ-mlv.fr>
	<4A80B40A.8090704@gmx.de> <4A80BA63.7010606@univ-mlv.fr>
	<4A80C049.2020202@sun.com> <4A813498.3010004@gmx.de>
	<4A813E03.4000702@univ-mlv.fr>
	<33338629-C8F0-4649-A3AD-A6BCA88631B7@Sun.COM>
	<4A818EE8.6030307@gmx.de>
	<CF5F34C7-8A2E-4693-8C13-A8C46720B2F7@Sun.COM>
Message-ID: <4A81E96D.5050609@gmx.de>

Jon,

thanks for 1st clarification.

I have
    bootstrap.jdk=C:/Programme/Java/jdk1.7.0
in ${user.home}/.openjdk/build.properties instead of boot.javac.target. 
Why 2 different names for the same thing?
So I guess, settings for boot.javac.source and boot.javac.target should 
be better located in ${user.home}/.openjdk/langtools-build.properties, 
than in
${user.home}/.openjdk/build.properties ?

For NetBeans "Clean and Build" settings for boot.javac.source and 
boot.javac.target in ${user.home}/.openjdk/*build.properties don't seem 
to be necessary, and regrettably settings for:
    javac.source = 6
    javac.target = 6
don't work, either in 
make/netbeans/langtools/nbproject/private/langtools.properties. I had to 
set them in build.properties.


I'm not happy to use NetBeans Properties box under Tools> Options> 
Miscellaneous> Ant, because those settings are for ALL NetBeans projects.
IMO best location would be: 
make/netbeans/langtools/nbproject/private/langtools.properties. In 
make/netbeans/langtools/build.xml they should be loaded before:
    <import file="../../build.xml"/>
Please add NetBeans project specific hints in make/build.properties.
...

Am 11.08.2009 17:59, Jonathan Gibbons schrieb:
> Ulf,
>
> Your settings for boot.java.home and target.java.home look OK.
>
> The intent of the build is that while building the bootstrap compiler, 
> the settings for boot.javac.source and boot.javac.target should be 
> active and these are correctly set to 6 in 
> langtools/make/build.properties.  I will investigate why these might 
> not be in use later today, when I have easy access to a Windows machine.
>
> Separately, I also note that the intent is that you should not *need* 
> to edit langtools/make/build.properties, although it is not incorrect 
> to do so. But, it can lead to accidents if you might be committing and 
> pushing changes.   To minimize that risk, you can provide/override 
> values in a number of ways:
> -- on the Ant command line (if you invoke Ant directly)
> -- in NetBeans, in the Properties box under Tools> Options> 
> Miscellaneous> Ant
> -- in a new unmanaged file langtools/build.properties (note no make/ 
> component)
> -- in ${user.home}/.openjdk/langtools-build.properties
> -- in ${user.home}/.openjdk/build.properties
> The last two choices allow you to set values to be shared by multiple 
> repositories.

Thanks for those valuable hints.
I would like to see those explicitly in make/build.properties.


-Ulf
 

>
> There is no make/build.properties in the jdk/ repository because that 
> repository uses "make" instead of "ant" for building.   To build the 
> jdk repository, you will need either MKS or Cygwin installed on your 
> system. For more info, see the notes on the OpenJDK web pages. There 
> are NetBeans projects for selected parts of the jdk/ to make it easy 
> to work on small subsystems. However, I don't believe those (NetBeans) 
> projects are being actively maintained at this point. [This does not 
> apply to the langtools/ files. ]
>
> -- Jon
>
>
>
>
>
> On Aug 11, 2009, at 8:31 AM, Ulf Zibis wrote:
>
>> Jon,
>>
>> that would be great.
>>
>> I've found out a solution, but I'm not sure, if this is as designed. 
>> In path_to_jdk7_sources\langtools\make\build.properties I set:
>> boot.java.home = C:/Programme/Java/jdk1.6.0_14
>> target.java.home = C:/Programme/Java/jdk1.7.0
>> javac.source = 6
>> javac.target = 6
>>
>> I'm wondering, that there is no ...\make\build.properties file in 
>> tl/jdk tree.
>>
>> Maybe you like to have a look on ...\make\netbeans\charset\* in my 
>> patch for https://bugs.openjdk.java.net/show_bug.cgi?id=100098 ?
>>
>> -Ulf
>>
>>
>>
>> Am 11.08.2009 16:49, Jonathan Gibbons schrieb:
>>> R?mi,
>>>
>>> Thanks for the heads up. I'll check this out.  It is still the case 
>>> that you should only need 1.6 to build langtools.
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On Aug 11, 2009, at 2:46 AM, R?mi Forax wrote:
>>>
>>>> Le 11/08/2009 11:06, Ulf Zibis a ?crit :
>>>>> Jonathan,
>>>>>
>>>>> thanks for additional help.
>>>>>
>>>>> Now I tried:
>>>>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans 
>>>>> 6.7.1\java2\ant\
>>>>> bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>>>
>>>> I've noticed that.
>>>> You have to run ant with jdk7.
>>>>
>>>> JAVA_HOME=C:/Programme/Java/jdk1.7.0
>>>> ant -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>>>>
>>>> Jon, it seems the ant build script need be updated because
>>>> we are not able to compile with jdk6 anymore.
>>>> The bootstrap javac/javap/etc should be built with -source 1.6 
>>>> -target 1.6.
>>>>
>>>> R?mi
>>>
>>>
>>
>
>



From Jonathan.Gibbons at Sun.COM  Tue Aug 11 22:23:45 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Tue, 11 Aug 2009 15:23:45 -0700
Subject: javac CRASH
In-Reply-To: <4A81E96D.5050609@gmx.de>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr> <4A80C049.2020202@sun.com>
	<4A813498.3010004@gmx.de> <4A813E03.4000702@univ-mlv.fr>
	<33338629-C8F0-4649-A3AD-A6BCA88631B7@Sun.COM>
	<4A818EE8.6030307@gmx.de>
	<CF5F34C7-8A2E-4693-8C13-A8C46720B2F7@Sun.COM>
	<4A81E96D.5050609@gmx.de>
Message-ID: <4A81EF71.2030806@sun.com>

Ulf Zibis wrote:
> Jon,
>
> thanks for 1st clarification.
>
> I have
>    bootstrap.jdk=C:/Programme/Java/jdk1.7.0
> in ${user.home}/.openjdk/build.properties instead of 
> boot.javac.target. Why 2 different names for the same thing?

The NetBeans projects in the jdk/ repository were written by a different 
person who has since left Sun.  As far as I know, no-one is looking 
after those projects at this point.  I cannot speak to their contents.


> So I guess, settings for boot.javac.source and boot.javac.target 
> should be better located in 
> ${user.home}/.openjdk/langtools-build.properties, than in
> ${user.home}/.openjdk/build.properties ?
Yes, that would seem best.

>
> For NetBeans "Clean and Build" settings for boot.javac.source and 
> boot.javac.target in ${user.home}/.openjdk/*build.properties don't 
> seem to be necessary, and regrettably settings for:
>    javac.source = 6
>    javac.target = 6
> don't work, either in 
> make/netbeans/langtools/nbproject/private/langtools.properties. I had 
> to set them in build.properties.

This morning, we identified and fixed an issue with the setting of 
javac.bootclasspath in the langtools/make/build.xml file.   A fix has 
been pushed to the TL/ family of repositories. This should fix being 
able to build langtools with JDK 6, so no additional changes to 
javac.source and javac.target should be necessary.

>
>
> I'm not happy to use NetBeans Properties box under Tools> Options> 
> Miscellaneous> Ant, because those settings are for ALL NetBeans projects.
Noted.  I mostly work on copies of the langtools repository so setting 
values there works OK for me.  I accept this may not work for everyone.

> IMO best location would be: 
> make/netbeans/langtools/nbproject/private/langtools.properties. In 
> make/netbeans/langtools/build.xml they should be loaded before:
>    <import file="../../build.xml"/>

This would only work if you are using NetBeans all the time.

> Please add NetBeans project specific hints in make/build.properties.
> ...
There should not need to be any NetBeans project specific hints, because 
you can configure and use make/build.xml and make/build.properties with 
Ant directly, without using NetBeans.

Please bear in mind that some of this issues you have been fighting have 
been caused by a mistake in make/build.xml, for which I apologise.   For 
the most part, you should just have to set boot.java.home to build 
langtools, and target.java.home and jtreg.home if you want to run the tests.

-- Jon



From jonathan.gibbons at sun.com  Wed Aug 12 01:42:33 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 12 Aug 2009 01:42:33 +0000
Subject: hg: jdk7/tl/langtools: 6870743: update comments in
	langtools/make/build.properties
Message-ID: <20090812014235.5593BEABB@hg.openjdk.java.net>

Changeset: 5a26c8fd0830
Author:    jjg
Date:      2009-08-11 18:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5a26c8fd0830

6870743: update comments in langtools/make/build.properties
Reviewed-by: darcy

! make/build.properties



From daniel.daugherty at sun.com  Wed Aug 12 02:16:42 2009
From: daniel.daugherty at sun.com (daniel.daugherty at sun.com)
Date: Wed, 12 Aug 2009 02:16:42 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090812021728.DDFC1EAC6@hg.openjdk.java.net>

Changeset: 36e0f4e00f20
Author:    dcubed
Date:      2009-08-11 20:02 -0600
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/36e0f4e00f20

6870298: 4/4 fix minor typos in java/lang/instrument/Instrumentation.java
Summary: Fix typos in the JavaDoc.
Reviewed-by: tbell

! src/share/classes/java/lang/instrument/Instrumentation.java

Changeset: 82b66d0368ff
Author:    dcubed
Date:      2009-08-11 20:06 -0600
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/82b66d0368ff

Merge

- src/share/classes/com/sun/crypto/provider/JarVerifier.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
- src/share/classes/sun/security/pkcs11/JarVerifier.java
- src/windows/classes/sun/security/mscapi/JarVerifier.java



From jonathan.gibbons at sun.com  Wed Aug 12 14:21:40 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 12 Aug 2009 14:21:40 +0000
Subject: hg: jdk7/tl/langtools: 6870706: langtools launcher issues
Message-ID: <20090812142148.961ADEB21@hg.openjdk.java.net>

Changeset: 8a03f3c7d160
Author:    jjg
Date:      2009-08-12 07:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8a03f3c7d160

6870706: langtools launcher issues
Reviewed-by: mcimadamore

! make/build.xml
! src/share/bin/launcher.sh-template



From jonathan.gibbons at sun.com  Wed Aug 12 15:03:11 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 12 Aug 2009 15:03:11 +0000
Subject: hg: jdk7/tl/langtools: 6758471: should be able to set jtreg options
	in langtools build
Message-ID: <20090812150316.0C8ADEB31@hg.openjdk.java.net>

Changeset: 71680973d8ec
Author:    jjg
Date:      2009-08-12 07:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/71680973d8ec

6758471: should be able to set jtreg options in langtools build
Reviewed-by: mcimadamore

! make/build.properties
! make/build.xml



From jonathan.gibbons at sun.com  Wed Aug 12 17:41:36 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 12 Aug 2009 17:41:36 +0000
Subject: hg: jdk7/tl/langtools: 6558476: com/sun/tools/javac/Main.compile
	don't release file handles on return
Message-ID: <20090812174142.92323EB8F@hg.openjdk.java.net>

Changeset: 7dbb79875a63
Author:    jjg
Date:      2009-08-12 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7dbb79875a63

6558476: com/sun/tools/javac/Main.compile don't release file handles on return
Reviewed-by: darcy

+ src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/T6558476.java



From jeremymanson at google.com  Thu Aug 13 01:11:07 2009
From: jeremymanson at google.com (Jeremy Manson)
Date: Wed, 12 Aug 2009 18:11:07 -0700
Subject: Adding a link() Method to Method
Message-ID: <bf03e3fa0908121811p2d11b3cjfdf790c86d076906@mail.gmail.com>

Hi folks,

I found myself in need of a method that determines whether a given
native method is linked, and links it if it is present.  My use case
prevents me from calling the method directly and catching an
UnsatisfiedLinkError, because the method has side effects.

This is not the first time I've needed such a method, so I implemented
it and dropped it into java.lang.reflect.Method. I thought I would ask
if it was something that should be added to the platform.  The
prototype looks like this:

   /**
    * Attempts to link this method, per Section 5.6 of the Java
    * Virtual Machine Specification.  Returns {@code true} if this is
    * a Java method, or if it is a native method and the Java Virtual
    * Machine succeeds in loading an appropriate native-language
    * definition of it; returns {@code false} otherwise.
    *
    * @return {@code true} if this is a Java method, or if it is a
    * native method and the Java Virtual Machine succeeds in
    * loading an appropriate native-language definition of it; returns
    * {@code false} otherwise.
    *
    * @since 1.7
    */
   public boolean tryLink();

This is basically useful in any case where you would otherwise catch
UnsatisfiedLinkError, but can't invoke the method.  For example, if
you have a binary that lives on the system, but you aren't sure
whether that shared library provides the implementation you want.

(Another point in the design space would be to have it called link(),
return void, and throw an UnsatisfiedLinkError if it fails.  It is
also worth pointing out that the JVMS calls it "binding", not
"linking", so there is that possibility as well.)

What do you all think?  It seems equally as useful as the ability to
catch UnsatisfiedLinkError from native method invocation.

Jeremy


From Jonathan.Gibbons at Sun.COM  Thu Aug 13 01:23:56 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Wed, 12 Aug 2009 18:23:56 -0700
Subject: javac CRASH
In-Reply-To: <4A813E03.4000702@univ-mlv.fr>
References: <4A77F8CB.2070200@gmx.de> <4A77FAA8.5020101@sun.com>
	<4A77FC5F.8020407@gmx.de> <4A780B67.3080809@sun.com>
	<4A781678.4050100@gmx.de>
	<4A7834DB.7020708@univ-mlv.fr> <4A80B40A.8090704@gmx.de>
	<4A80BA63.7010606@univ-mlv.fr> <4A80C049.2020202@sun.com>
	<4A813498.3010004@gmx.de> <4A813E03.4000702@univ-mlv.fr>
Message-ID: <70CEC2FE-54C3-4DF6-B288-1A577EAFAFA5@Sun.COM>

This thread continued on a subset of the to: list, but to summarize  
the net result here,
we identified and fixed a problem with the langtools make/build.xml  
file that was causing
bootclasspath problems on WIndows.  This problem has been fixed, and  
changesets
have been pushed to jdk6/jdk6 and jdk7/tl.

Thanks , R?mi and Ulf, for helping to point out the problem.

-- Jon


On Aug 11, 2009, at 2:46 AM, R?mi Forax wrote:

> Le 11/08/2009 11:06, Ulf Zibis a ?crit :
>> Jonathan,
>>
>> thanks for additional help.
>>
>> Now I tried:
>> C:\Projects\OpenJDK7\langtools\make>"C:\Programme\Java\NetBeans  
>> 6.7.1\java2\ant\
>> bin\ant" -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>
> I've noticed that.
> You have to run ant with jdk7.
>
> JAVA_HOME=C:/Programme/Java/jdk1.7.0
> ant -Dboot.java/home=C:/Programme/Java/jdk1.7.0
>
> Jon, it seems the ant build script need be updated because
> we are not able to compile with jdk6 anymore.
> The bootstrap javac/javap/etc should be built with -source 1.6 - 
> target 1.6.
>
> R?mi



From martinrb at google.com  Thu Aug 13 01:30:28 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Aug 2009 18:30:28 -0700
Subject: Matcher performance improvements
Message-ID: <1ccfd1c10908121830v3ac4278esd3406e81f796151c@mail.gmail.com>

Hi regex/String team,

We would like to contribute a performance improvement for Matcher.

Please file a bug.

category: java_util_regex
Synopsis: Faster Matcher by replacing StringBuffer with StringBuilder

Description:
The old Matcher API and implementation depend on the old StringBuffer class.
The use of StringBuilder gives measurable performance improvement in
real world applications.
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Matcher-perf/
Written by Jeremy Manson.

Here's a microbenchmark, where it gives 25% win:

public class StringReplace {
  static String jabber = "Twas brillig, and the slithy toves " +
      "Did gyre and gimble in the wabe; " +
      "All mimsy were the borogoves, " +
      "And the mome raths outgrabe. " +
      " " +
      "Beware the Jabberwock, my son! " +
      "The jaws that bite, the claws that catch! " +
      "Beware the Jubjub bird, and shun " +
      "The frumious Bandersnatch!" +
      " " +
      "He took his vorpal sword in hand: " +
      "Long time the manxome foe he sought??? " +
      "So rested he by the Tumtum tree, " +
      "And stood awhile in thought. " +
      " " +
      "And as in uffish thought he stood, " +
      "The Jabberwock, with eyes of flame, " +
      "Came whiffling through the tulgey wood, " +
      "And burbled as it came! " +
      " " +
      "One, two! One, two! and through and through " +
      "The vorpal blade went snicker-snack! " +
      "He left it dead, and with its head " +
      "He went galumphing back. " +
      " " +
      "And hast thou slain the Jabberwock? " +
      "Come to my arms, my beamish boy! " +
      "O frabjous day! Callooh! Callay!" +" " +
      "He chortled in his joy. " +
      " " +
      "'Twas brillig, and the slithy toves " +
      "Did gyre and gimble in the wabe; " +
      "All mimsy were the borogoves, " +
      "And the mome raths outgrabe?";

  public static void replace() {
    long start = System.currentTimeMillis();
    for (int i = 0; i < 100000; i++) {
      jabber.replaceAll("the", "ze");
    }
    long stop = System.currentTimeMillis();
    System.out.println(stop);
    System.out.println(start);

    System.out.println(stop - start);
  }

  public static void main(String[] args) {
    for (int i = 0; i < 5; i++) {
      replace();
    }
  }
}


From Xueming.Shen at Sun.COM  Thu Aug 13 01:56:58 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Wed, 12 Aug 2009 18:56:58 -0700
Subject: Matcher performance improvements
In-Reply-To: <1ccfd1c10908121830v3ac4278esd3406e81f796151c@mail.gmail.com>
References: <1ccfd1c10908121830v3ac4278esd3406e81f796151c@mail.gmail.com>
Message-ID: <4A8372EA.3020207@sun.com>


The RFE#5066679 has been on my "next week's todo list" for a while:-) it 
looks like
the Appendable might be a better choice here? I guess we should gain the 
same performance
when you pass in a StringBuilder. Opinion?

Sherman

Martin Buchholz wrote:
> Hi regex/String team,
>
> We would like to contribute a performance improvement for Matcher.
>
> Please file a bug.
>
> category: java_util_regex
> Synopsis: Faster Matcher by replacing StringBuffer with StringBuilder
>
> Description:
> The old Matcher API and implementation depend on the old StringBuffer class.
> The use of StringBuilder gives measurable performance improvement in
> real world applications.
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Matcher-perf/
> Written by Jeremy Manson.
>
> Here's a microbenchmark, where it gives 25% win:
>
> public class StringReplace {
>   static String jabber = "Twas brillig, and the slithy toves " +
>       "Did gyre and gimble in the wabe; " +
>       "All mimsy were the borogoves, " +
>       "And the mome raths outgrabe. " +
>       " " +
>       "Beware the Jabberwock, my son! " +
>       "The jaws that bite, the claws that catch! " +
>       "Beware the Jubjub bird, and shun " +
>       "The frumious Bandersnatch!" +
>       " " +
>       "He took his vorpal sword in hand: " +
>       "Long time the manxome foe he sought??? " +
>       "So rested he by the Tumtum tree, " +
>       "And stood awhile in thought. " +
>       " " +
>       "And as in uffish thought he stood, " +
>       "The Jabberwock, with eyes of flame, " +
>       "Came whiffling through the tulgey wood, " +
>       "And burbled as it came! " +
>       " " +
>       "One, two! One, two! and through and through " +
>       "The vorpal blade went snicker-snack! " +
>       "He left it dead, and with its head " +
>       "He went galumphing back. " +
>       " " +
>       "And hast thou slain the Jabberwock? " +
>       "Come to my arms, my beamish boy! " +
>       "O frabjous day! Callooh! Callay!" +" " +
>       "He chortled in his joy. " +
>       " " +
>       "'Twas brillig, and the slithy toves " +
>       "Did gyre and gimble in the wabe; " +
>       "All mimsy were the borogoves, " +
>       "And the mome raths outgrabe?";
>
>   public static void replace() {
>     long start = System.currentTimeMillis();
>     for (int i = 0; i < 100000; i++) {
>       jabber.replaceAll("the", "ze");
>     }
>     long stop = System.currentTimeMillis();
>     System.out.println(stop);
>     System.out.println(start);
>
>     System.out.println(stop - start);
>   }
>
>   public static void main(String[] args) {
>     for (int i = 0; i < 5; i++) {
>       replace();
>     }
>   }
> }
>   



From forax at univ-mlv.fr  Thu Aug 13 08:03:33 2009
From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=)
Date: Thu, 13 Aug 2009 10:03:33 +0200
Subject: Matcher performance improvements
In-Reply-To: <1ccfd1c10908121830v3ac4278esd3406e81f796151c@mail.gmail.com>
References: <1ccfd1c10908121830v3ac4278esd3406e81f796151c@mail.gmail.com>
Message-ID: <4A83C8D5.6080804@univ-mlv.fr>

Le 13/08/2009 03:30, Martin Buchholz a ?crit :
> Hi regex/String team,
>
> We would like to contribute a performance improvement for Matcher.
>    

Just a minor comment, there is not @since 1.7

R?mi

> Please file a bug.
>
> category: java_util_regex
> Synopsis: Faster Matcher by replacing StringBuffer with StringBuilder
>
> Description:
> The old Matcher API and implementation depend on the old StringBuffer class.
> The use of StringBuilder gives measurable performance improvement in
> real world applications.
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Matcher-perf/
> Written by Jeremy Manson.
>
> Here's a microbenchmark, where it gives 25% win:
>
> public class StringReplace {
>    static String jabber = "Twas brillig, and the slithy toves " +
>        "Did gyre and gimble in the wabe; " +
>        "All mimsy were the borogoves, " +
>        "And the mome raths outgrabe. " +
>        " " +
>        "Beware the Jabberwock, my son! " +
>        "The jaws that bite, the claws that catch! " +
>        "Beware the Jubjub bird, and shun " +
>        "The frumious Bandersnatch!" +
>        " " +
>        "He took his vorpal sword in hand: " +
>        "Long time the manxome foe he sought??? " +
>        "So rested he by the Tumtum tree, " +
>        "And stood awhile in thought. " +
>        " " +
>        "And as in uffish thought he stood, " +
>        "The Jabberwock, with eyes of flame, " +
>        "Came whiffling through the tulgey wood, " +
>        "And burbled as it came! " +
>        " " +
>        "One, two! One, two! and through and through " +
>        "The vorpal blade went snicker-snack! " +
>        "He left it dead, and with its head " +
>        "He went galumphing back. " +
>        " " +
>        "And hast thou slain the Jabberwock? " +
>        "Come to my arms, my beamish boy! " +
>        "O frabjous day! Callooh! Callay!" +" " +
>        "He chortled in his joy. " +
>        " " +
>        "'Twas brillig, and the slithy toves " +
>        "Did gyre and gimble in the wabe; " +
>        "All mimsy were the borogoves, " +
>        "And the mome raths outgrabe?";
>
>    public static void replace() {
>      long start = System.currentTimeMillis();
>      for (int i = 0; i<  100000; i++) {
>        jabber.replaceAll("the", "ze");
>      }
>      long stop = System.currentTimeMillis();
>      System.out.println(stop);
>      System.out.println(start);
>
>      System.out.println(stop - start);
>    }
>
>    public static void main(String[] args) {
>      for (int i = 0; i<  5; i++) {
>        replace();
>      }
>    }
> }
>    



From Alan.Bateman at Sun.COM  Thu Aug 13 08:49:42 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 13 Aug 2009 09:49:42 +0100
Subject: Adding a link() Method to Method
In-Reply-To: <bf03e3fa0908121811p2d11b3cjfdf790c86d076906@mail.gmail.com>
References: <bf03e3fa0908121811p2d11b3cjfdf790c86d076906@mail.gmail.com>
Message-ID: <4A83D3A6.1020700@sun.com>

Jeremy Manson wrote:
> Hi folks,
>
> I found myself in need of a method that determines whether a given
> native method is linked, and links it if it is present.  My use case
> prevents me from calling the method directly and catching an
> UnsatisfiedLinkError, because the method has side effects.
>
> This is not the first time I've needed such a method, so I implemented
> it and dropped it into java.lang.reflect.Method. I thought I would ask
> if it was something that should be added to the platform.  The
> prototype looks like this:
>
>    /**
>     * Attempts to link this method, per Section 5.6 of the Java
>     * Virtual Machine Specification.  Returns {@code true} if this is
>     * a Java method, or if it is a native method and the Java Virtual
>     * Machine succeeds in loading an appropriate native-language
>     * definition of it; returns {@code false} otherwise.
>     *
>     * @return {@code true} if this is a Java method, or if it is a
>     * native method and the Java Virtual Machine succeeds in
>     * loading an appropriate native-language definition of it; returns
>     * {@code false} otherwise.
>     *
>     * @since 1.7
>     */
>    public boolean tryLink();
>
> This is basically useful in any case where you would otherwise catch
> UnsatisfiedLinkError, but can't invoke the method.  For example, if
> you have a binary that lives on the system, but you aren't sure
> whether that shared library provides the implementation you want.
>
> (Another point in the design space would be to have it called link(),
> return void, and throw an UnsatisfiedLinkError if it fails.  It is
> also worth pointing out that the JVMS calls it "binding", not
> "linking", so there is that possibility as well.)
>
> What do you all think?  It seems equally as useful as the ability to
> catch UnsatisfiedLinkError from native method invocation.
>
> Jeremy
>   
In your example, is this a versioning issue with the native library? 
Just wondering if it would make more sense to write a native method that 
returns a version number of some such? One thing to mention is that you 
could encounter libraries that do their own linking with RegisterNatives.

-Alan.






From martinrb at google.com  Thu Aug 13 14:46:01 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 13 Aug 2009 07:46:01 -0700
Subject: Matcher performance improvements
In-Reply-To: <4A83C8D5.6080804@univ-mlv.fr>
References: <1ccfd1c10908121830v3ac4278esd3406e81f796151c@mail.gmail.com>
	<4A83C8D5.6080804@univ-mlv.fr>
Message-ID: <1ccfd1c10908130746k37dfeeacjaa4994ab54352b96@mail.gmail.com>

On Thu, Aug 13, 2009 at 01:03, R?mi Forax<forax at univ-mlv.fr> wrote:
> Le 13/08/2009 03:30, Martin Buchholz a ?crit :
>>
>> Hi regex/String team,
>>
>> We would like to contribute a performance improvement for Matcher.
>>
>
> Just a minor comment, there is not @since 1.7

Fixed.

Easy to forget, especially since we know
the computer is better at finding the missing ones
than us puny humans.

Martin


From xueming.shen at sun.com  Thu Aug 13 17:58:19 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Thu, 13 Aug 2009 17:58:19 +0000
Subject: hg: jdk7/tl/jdk: 6840246: Lightweight implementation of String.split
	for simple use case
Message-ID: <20090813175850.8295CEC79@hg.openjdk.java.net>

Changeset: 1ff977b938e5
Author:    sherman
Date:      2009-08-13 10:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ff977b938e5

6840246: Lightweight implementation of String.split for simple use case
Summary: Added a fastpath for simple use case
Reviewed-by: alanb, martin

! src/share/classes/java/lang/String.java
! test/java/lang/String/Split.java



From bradford.wetmore at sun.com  Thu Aug 13 20:00:07 2009
From: bradford.wetmore at sun.com (bradford.wetmore at sun.com)
Date: Thu, 13 Aug 2009 20:00:07 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090813200057.4642CEC8A@hg.openjdk.java.net>

Changeset: 8c0c96a3f9f6
Author:    wetmore
Date:      2009-08-13 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8c0c96a3f9f6

6870335: Provider numbers need to be bumped to 1.7
Reviewed-by: mullan

! src/share/classes/com/sun/security/sasl/Provider.java
! src/share/classes/sun/security/jgss/SunProvider.java
! src/share/classes/sun/security/provider/Sun.java
! src/share/classes/sun/security/smartcardio/SunPCSC.java
! src/share/classes/sun/security/ssl/SunJSSE.java

Changeset: 6797a2407a50
Author:    wetmore
Date:      2009-08-13 12:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6797a2407a50

Merge




From xueming.shen at sun.com  Thu Aug 13 22:20:10 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Thu, 13 Aug 2009 22:20:10 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090813222035.EF1F4ECE6@hg.openjdk.java.net>

Changeset: 35f32639ee20
Author:    sherman
Date:      2009-08-13 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/35f32639ee20

6676423: (prefs) Opensource unit/regression tests for java.util.prefs
Summary: Moved the existing test cases for prefs to open area
Reviewed-by: martin, alanb

+ test/java/util/prefs/CommentsInXml.java
+ test/java/util/prefs/ConflictInFlush.java
+ test/java/util/prefs/ExportNode.java
+ test/java/util/prefs/ExportSubtree.java
+ test/java/util/prefs/PrefsSpi.java
+ test/java/util/prefs/PrefsSpi.sh
+ test/java/util/prefs/RemoveReadOnlyNode.java
+ test/java/util/prefs/RemoveUnregedListener.java
+ test/java/util/prefs/SerializeExceptions.java

Changeset: f094eb92a6e0
Author:    sherman
Date:      2009-08-13 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f094eb92a6e0

Merge




From martinrb at google.com  Fri Aug 14 00:14:12 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 13 Aug 2009 17:14:12 -0700
Subject: Matcher performance improvements
In-Reply-To: <4A8372EA.3020207@sun.com>
References: <1ccfd1c10908121830v3ac4278esd3406e81f796151c@mail.gmail.com>
	<4A8372EA.3020207@sun.com>
Message-ID: <1ccfd1c10908131714y5bd40010y8e21fb0dd6fa8ea1@mail.gmail.com>

Jeremy is out for a few days - let's pick this up next week.

In the meantime, we probably don't want
public Appendable appendTail(Appendable a) {

but instead

public <T extends Appendable> T appendTail(T a) {

It would be nice to be able to simply change the signature of the
existing method
that takes a StringBuffer, but there's no doubt some obscure
reason why that would not be 100% compatible.

Martin


> I suggested yesterday that you might consider to add the pair for the "Appendable" for more general use scenario,
> instead of the StringBuilder. I just tried your test case with this approach

> http://cr.openjdk.java.net/~sherman/regex_replace/webrev/src/share/classes/java/util/regex/Matcher.java.sdiff.html

> I still see 20%+ gain.

> The only trick is we will have to deal with the "IOException" from the Appendable append methods...


On Wed, Aug 12, 2009 at 18:56, Xueming Shen<Xueming.Shen at sun.com> wrote:
>
> The RFE#5066679 has been on my "next week's todo list" for a while:-) it
> looks like
> the Appendable might be a better choice here? I guess we should gain the
> same performance
> when you pass in a StringBuilder. Opinion?
>
> Sherman
>
> Martin Buchholz wrote:
>>
>> Hi regex/String team,
>>
>> We would like to contribute a performance improvement for Matcher.
>>
>> Please file a bug.
>>
>> category: java_util_regex
>> Synopsis: Faster Matcher by replacing StringBuffer with StringBuilder
>>
>> Description:
>> The old Matcher API and implementation depend on the old StringBuffer
>> class.
>> The use of StringBuilder gives measurable performance improvement in
>> real world applications.
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Matcher-perf/
>> Written by Jeremy Manson.
>>
>> Here's a microbenchmark, where it gives 25% win:
>>
>> public class StringReplace {
>> ?static String jabber = "Twas brillig, and the slithy toves " +
>> ? ? ?"Did gyre and gimble in the wabe; " +
>> ? ? ?"All mimsy were the borogoves, " +
>> ? ? ?"And the mome raths outgrabe. " +
>> ? ? ?" " +
>> ? ? ?"Beware the Jabberwock, my son! " +
>> ? ? ?"The jaws that bite, the claws that catch! " +
>> ? ? ?"Beware the Jubjub bird, and shun " +
>> ? ? ?"The frumious Bandersnatch!" +
>> ? ? ?" " +
>> ? ? ?"He took his vorpal sword in hand: " +
>> ? ? ?"Long time the manxome foe he sought??? " +
>> ? ? ?"So rested he by the Tumtum tree, " +
>> ? ? ?"And stood awhile in thought. " +
>> ? ? ?" " +
>> ? ? ?"And as in uffish thought he stood, " +
>> ? ? ?"The Jabberwock, with eyes of flame, " +
>> ? ? ?"Came whiffling through the tulgey wood, " +
>> ? ? ?"And burbled as it came! " +
>> ? ? ?" " +
>> ? ? ?"One, two! One, two! and through and through " +
>> ? ? ?"The vorpal blade went snicker-snack! " +
>> ? ? ?"He left it dead, and with its head " +
>> ? ? ?"He went galumphing back. " +
>> ? ? ?" " +
>> ? ? ?"And hast thou slain the Jabberwock? " +
>> ? ? ?"Come to my arms, my beamish boy! " +
>> ? ? ?"O frabjous day! Callooh! Callay!" +" " +
>> ? ? ?"He chortled in his joy. " +
>> ? ? ?" " +
>> ? ? ?"'Twas brillig, and the slithy toves " +
>> ? ? ?"Did gyre and gimble in the wabe; " +
>> ? ? ?"All mimsy were the borogoves, " +
>> ? ? ?"And the mome raths outgrabe?";
>>
>> ?public static void replace() {
>> ? ?long start = System.currentTimeMillis();
>> ? ?for (int i = 0; i < 100000; i++) {
>> ? ? ?jabber.replaceAll("the", "ze");
>> ? ?}
>> ? ?long stop = System.currentTimeMillis();
>> ? ?System.out.println(stop);
>> ? ?System.out.println(start);
>>
>> ? ?System.out.println(stop - start);
>> ?}
>>
>> ?public static void main(String[] args) {
>> ? ?for (int i = 0; i < 5; i++) {
>> ? ? ?replace();
>> ? ?}
>> ?}
>> }
>>
>
>


From xueming.shen at sun.com  Fri Aug 14 18:51:27 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 14 Aug 2009 18:51:27 +0000
Subject: hg: jdk7/tl/jdk: 6866397: (file) PathMatcher with regex syntax
	doesn't match as expected (win)
Message-ID: <20090814185206.1ACC9EE12@hg.openjdk.java.net>

Changeset: 7fcdefc99dc4
Author:    sherman
Date:      2009-08-14 11:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fcdefc99dc4

6866397: (file) PathMatcher with regex syntax doesn't match as expected (win)
Summary: Use unicode_case_insensitive for windows path matcher for now.
Reviewed-by: alanb

! src/windows/classes/sun/nio/fs/WindowsFileSystem.java
! test/java/nio/file/PathMatcher/Basic.java



From xueming.shen at sun.com  Fri Aug 14 21:39:48 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 14 Aug 2009 21:39:48 +0000
Subject: hg: jdk7/tl/jdk: 6730652: CharsetEncoder.canEncode(char) returns
	incorrect values for some charsets
Message-ID: <20090814214100.02FDFEE5D@hg.openjdk.java.net>

Changeset: 77a1c2056565
Author:    sherman
Date:      2009-08-14 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/77a1c2056565

6730652: CharsetEncoder.canEncode(char) returns incorrect values for some charsets
Summary: override the canEncode() in ISO2022_CN_CNS
Reviewed-by: martin

! src/share/classes/sun/nio/cs/ext/ISO2022.java
! src/share/classes/sun/nio/cs/ext/ISO2022_CN_CNS.java
! test/sun/nio/cs/FindCanEncodeBugs.java



From bradford.wetmore at sun.com  Sat Aug 15 00:37:06 2009
From: bradford.wetmore at sun.com (bradford.wetmore at sun.com)
Date: Sat, 15 Aug 2009 00:37:06 +0000
Subject: hg: jdk7/tl: 6872177: JCE framework and provider builds broken
	following -target 7 changes
Message-ID: <20090815003706.92671EE99@hg.openjdk.java.net>

Changeset: d8b49b53d8cf
Author:    wetmore
Date:      2009-08-14 17:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/d8b49b53d8cf

6872177: JCE framework and provider builds broken following -target 7 changes
Reviewed-by: ohair

! make/Defs-internal.gmk



From Ulf.Zibis at gmx.de  Sat Aug 15 15:41:37 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 15 Aug 2009 17:41:37 +0200
Subject: hg: jdk7/tl/jdk: 6730652: CharsetEncoder.canEncode(char) returns
	incorrect values for some charsets
In-Reply-To: <20090814214100.02FDFEE5D@hg.openjdk.java.net>
References: <20090814214100.02FDFEE5D@hg.openjdk.java.net>
Message-ID: <4A86D731.3080107@gmx.de>

My tiny comment:

It would suffice, to make the constants package private, instead of public.

-Ulf


Am 14.08.2009 23:39, xueming.shen at sun.com schrieb:
> Changeset: 77a1c2056565
> Author:    sherman
> Date:      2009-08-14 14:29 -0700
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/77a1c2056565
>
> 6730652: CharsetEncoder.canEncode(char) returns incorrect values for some charsets
> Summary: override the canEncode() in ISO2022_CN_CNS
> Reviewed-by: martin
>
> ! src/share/classes/sun/nio/cs/ext/ISO2022.java
> ! src/share/classes/sun/nio/cs/ext/ISO2022_CN_CNS.java
> ! test/sun/nio/cs/FindCanEncodeBugs.java
>
>
>   



From Ulf.Zibis at gmx.de  Sat Aug 15 15:51:55 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 15 Aug 2009 17:51:55 +0200
Subject: hg: jdk7/tl/jdk: 4116222: Errors in Arabic code-conversion tables,
	part II
In-Reply-To: <20090804200057.09CF9E0A1@hg.openjdk.java.net>
References: <20090804200057.09CF9E0A1@hg.openjdk.java.net>
Message-ID: <4A86D99A.6090402@gmx.de>

Hi Sherman,

I've seen, that you have again changed GenerateSBCS.java

I like to remember to review my changes on:
https://bugs.openjdk.java.net/attachment.cgi?id=130&action=diff#a/make/tools/src/build/tools/charsetmapping/GenerateSBCS.java_sec1

IMHO my code is much smarter, and faster too (saves JDK build time), + 
you can simply copy the principle to all other GenerateX.java.
(It's fast, because of direct formatting to file, instead of first 
replacing long String's range-wise.)

Additionally I've fixed a small bug regarding c2bLength calculation:
  If there is:
  xxx.map:
  0x01 0x0101
  0x02 0x0202
  0x03 0x0303

  xxx.nr:
  0x03 0x0303

  ... c2bLength was calculated to 0x300, but should be 0x200.


-Ulf



Am 04.08.2009 22:00, xueming.shen at sun.com schrieb:
> Changeset: c390fd8fa885
> Author:    sherman
> Date:      2009-08-04 12:44 -0700
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c390fd8fa885
>
> 4116222: Errors in Arabic code-conversion tables, part II
> Summary: updated the IBM420 datatable
> Reviewed-by: alanb
>
> ! make/tools/CharsetMapping/IBM420.c2b
> ! make/tools/CharsetMapping/IBM420.map
> ! make/tools/CharsetMapping/IBM420.nr
> ! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java
>
>
>   



From jeremymanson at google.com  Mon Aug 17 21:18:47 2009
From: jeremymanson at google.com (Jeremy Manson)
Date: Mon, 17 Aug 2009 14:18:47 -0700
Subject: Adding a link() Method to Method
In-Reply-To: <4A83D3A6.1020700@sun.com>
References: <bf03e3fa0908121811p2d11b3cjfdf790c86d076906@mail.gmail.com>
	<4A83D3A6.1020700@sun.com>
Message-ID: <bf03e3fa0908171418r765ff126q4cce1a5bdcffb222@mail.gmail.com>

Hi Alan,

(Sorry about the delay - I was out of town)

In my cases, there may be a versioning issue AND the library might not
be there at all.  I could certainly use a versioning scheme to do this
and catch the ULE if the versioning method isn't present.  However,
the code gets pretty dirty.  I have to increment the version number
every time I add a native method and keep track of it from both native
code and Java.  Also, I have to watch carefully to make sure that I am
adding functionality in a monotonically increasing way.

That's a lot of logistical overhead from something that is a pretty
trivial platform addition.

Of course, the method could be made more complicated.  For example,
you could try to link from a specific native library.

I guess that the method's behavior in the presence of RegisterNatives
should be the same as its behavior with any native method that is
already linked - i.e., return true (presumably).


  /**
   * Attempts to link this method, per Section 5.6 of the Java
   * Virtual Machine Specification.  Returns {@code true} if this is
   * a Java method, if it is already linked, or if it is a native method
   * and the Java Virtual Machine succeeds in loading an
   * appropriate native-language definition of it; returns
   * {@code false} otherwise.
   *
   * @return {@code true} if this is a Java method, if it is already
   * linked, or if it is a native method and the Java Virtual
   * Machine succeeds in loading an appropriate native-language
   * definition of it; returns {@code false} otherwise.
   *
   * @since 1.7
   */
  public boolean tryLink();

Jeremy


On Thu, Aug 13, 2009 at 1:49 AM, Alan Bateman<Alan.Bateman at sun.com> wrote:
> Jeremy Manson wrote:
>>
>> Hi folks,
>>
>> I found myself in need of a method that determines whether a given
>> native method is linked, and links it if it is present. ?My use case
>> prevents me from calling the method directly and catching an
>> UnsatisfiedLinkError, because the method has side effects.
>>
>> This is not the first time I've needed such a method, so I implemented
>> it and dropped it into java.lang.reflect.Method. I thought I would ask
>> if it was something that should be added to the platform. ?The
>> prototype looks like this:
>>
>> ? /**
>> ? ?* Attempts to link this method, per Section 5.6 of the Java
>> ? ?* Virtual Machine Specification. ?Returns {@code true} if this is
>> ? ?* a Java method, or if it is a native method and the Java Virtual
>> ? ?* Machine succeeds in loading an appropriate native-language
>> ? ?* definition of it; returns {@code false} otherwise.
>> ? ?*
>> ? ?* @return {@code true} if this is a Java method, or if it is a
>> ? ?* native method and the Java Virtual Machine succeeds in
>> ? ?* loading an appropriate native-language definition of it; returns
>> ? ?* {@code false} otherwise.
>> ? ?*
>> ? ?* @since 1.7
>> ? ?*/
>> ? public boolean tryLink();
>>
>> This is basically useful in any case where you would otherwise catch
>> UnsatisfiedLinkError, but can't invoke the method. ?For example, if
>> you have a binary that lives on the system, but you aren't sure
>> whether that shared library provides the implementation you want.
>>
>> (Another point in the design space would be to have it called link(),
>> return void, and throw an UnsatisfiedLinkError if it fails. ?It is
>> also worth pointing out that the JVMS calls it "binding", not
>> "linking", so there is that possibility as well.)
>>
>> What do you all think? ?It seems equally as useful as the ability to
>> catch UnsatisfiedLinkError from native method invocation.
>>
>> Jeremy
>>
>
> In your example, is this a versioning issue with the native library? Just
> wondering if it would make more sense to write a native method that returns
> a version number of some such? One thing to mention is that you could
> encounter libraries that do their own linking with RegisterNatives.
>
> -Alan.
>
>
>
>
>


From weijun.wang at sun.com  Tue Aug 18 02:46:32 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Tue, 18 Aug 2009 02:46:32 +0000
Subject: hg: jdk7/tl/jdk: 6829785: TextCallbackHandler does not honor
	PasswordCallback.isEchoOn()
Message-ID: <20090818024730.37D12EFD7@hg.openjdk.java.net>

Changeset: 8414927b41d8
Author:    weijun
Date:      2009-08-18 10:20 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8414927b41d8

6829785: TextCallbackHandler does not honor PasswordCallback.isEchoOn()
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java
! src/share/classes/sun/security/util/Password.java
+ test/com/sun/security/auth/callback/TextCallbackHandler/Password.java



From tim.bell at sun.com  Wed Aug 19 04:34:54 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Wed, 19 Aug 2009 04:34:54 +0000
Subject: hg: jdk7/tl/corba: 2 new changesets
Message-ID: <20090819043457.094BC1205F@hg.openjdk.java.net>

Changeset: 07b3e9ba5085
Author:    xdono
Date:      2009-08-13 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/07b3e9ba5085

Added tag jdk7-b69 for changeset 8120d308ec4e

! .hgtags

Changeset: 175bd6877954
Author:    tbell
Date:      2009-08-14 08:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/175bd6877954

Merge




From tim.bell at sun.com  Wed Aug 19 04:41:11 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Wed, 19 Aug 2009 04:41:11 +0000
Subject: hg: jdk7/tl/hotspot: 2 new changesets
Message-ID: <20090819044124.7520312064@hg.openjdk.java.net>

Changeset: 5021b9893d0a
Author:    xdono
Date:      2009-08-13 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5021b9893d0a

Added tag jdk7-b69 for changeset 54fd4d923296

! .hgtags

Changeset: 0632c3e615a3
Author:    tbell
Date:      2009-08-14 08:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0632c3e615a3

Merge




From tim.bell at sun.com  Wed Aug 19 04:49:01 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Wed, 19 Aug 2009 04:49:01 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20090819044905.261B212069@hg.openjdk.java.net>

Changeset: 8287833daabc
Author:    xdono
Date:      2009-08-13 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/8287833daabc

Added tag jdk7-b69 for changeset a4ab0d6ded63

! .hgtags

Changeset: c83f0106b78a
Author:    tbell
Date:      2009-08-14 08:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c83f0106b78a

Merge




From tim.bell at sun.com  Wed Aug 19 04:54:49 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Wed, 19 Aug 2009 04:54:49 +0000
Subject: hg: jdk7/tl/jaxws: 3 new changesets
Message-ID: <20090819045455.5C9BB1206E@hg.openjdk.java.net>

Changeset: 1041c9cce799
Author:    xdono
Date:      2009-08-13 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/1041c9cce799

Added tag jdk7-b69 for changeset 3e64fdfb9291

! .hgtags

Changeset: 6608dd3dae86
Author:    tbell
Date:      2009-08-14 08:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/6608dd3dae86

Merge


Changeset: dd3c5f3ec28d
Author:    tbell
Date:      2009-08-18 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/dd3c5f3ec28d

6873200: patch.out and jaxws.patch do not belong in jaxws repository
Reviewed-by: xdono, ohair

- jaxws.patch
- patch.out



From tim.bell at sun.com  Wed Aug 19 05:01:38 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Wed, 19 Aug 2009 05:01:38 +0000
Subject: hg: jdk7/tl/jdk: 6 new changesets
Message-ID: <20090819050326.9EEDA12073@hg.openjdk.java.net>

Changeset: 7e491e39ea0f
Author:    tbell
Date:      2009-08-06 17:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e491e39ea0f

6865853: Additional code changes needed to build deploy using WXP SP2 and Visual Studio 2008
Reviewed-by: ohair

! src/windows/native/sun/jkernel/kernel.cpp

Changeset: 08baaf8638c9
Author:    tbell
Date:      2009-08-06 17:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/08baaf8638c9

Merge

- src/share/classes/com/sun/crypto/provider/JarVerifier.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
- src/share/classes/sun/security/pkcs11/JarVerifier.java
- src/windows/classes/sun/security/mscapi/JarVerifier.java

Changeset: 226b20019b1f
Author:    xdono
Date:      2009-08-12 10:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/226b20019b1f

Merge


Changeset: 36c8ddbe9bc5
Author:    xdono
Date:      2009-08-13 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/36c8ddbe9bc5

Added tag jdk7-b69 for changeset 226b20019b1f

! .hgtags

Changeset: abac33c4bd67
Author:    tbell
Date:      2009-08-14 08:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abac33c4bd67

Merge


Changeset: 74029d1cf4e4
Author:    tbell
Date:      2009-08-18 17:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74029d1cf4e4

Merge




From tim.bell at sun.com  Wed Aug 19 05:13:26 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Wed, 19 Aug 2009 05:13:26 +0000
Subject: hg: jdk7/tl/langtools: 3 new changesets
Message-ID: <20090819051348.5E6FD12078@hg.openjdk.java.net>

Changeset: 4ac89259512f
Author:    xdono
Date:      2009-08-13 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4ac89259512f

Added tag jdk7-b69 for changeset ce9bcdcb7859

! .hgtags

Changeset: 97d06f3e8787
Author:    tbell
Date:      2009-08-14 08:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/97d06f3e8787

Merge


Changeset: b055a5ea0dad
Author:    tbell
Date:      2009-08-18 17:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b055a5ea0dad

Merge




From ahughes at redhat.com  Wed Aug 19 20:20:25 2009
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Wed, 19 Aug 2009 20:20:25 +0000
Subject: hg: jdk7/tl/langtools: 6873059: Explicitly use -source 6 -target 6
	when compiling with the boot jdk
Message-ID: <20090819202030.8CD46120CB@hg.openjdk.java.net>

Changeset: 2aa3a1cdb094
Author:    andrew
Date:      2009-08-19 20:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2aa3a1cdb094

6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk
Summary: Set source and target explicitly in pcompile task
Reviewed-by: jjg

! make/build.xml



From joe.darcy at sun.com  Thu Aug 20 00:20:14 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 20 Aug 2009 00:20:14 +0000
Subject: hg: jdk7/tl/langtools: 6871291: Please clarify
	javax.tools.JavaCompiler.getTask() "classes" parameter
Message-ID: <20090820002018.CA6071210E@hg.openjdk.java.net>

Changeset: 2ce3597237f0
Author:    darcy
Date:      2009-08-19 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2ce3597237f0

6871291: Please clarify javax.tools.JavaCompiler.getTask() "classes" parameter
Reviewed-by: jjg

! src/share/classes/javax/tools/JavaCompiler.java



From weijun.wang at sun.com  Thu Aug 20 03:37:03 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Thu, 20 Aug 2009 03:37:03 +0000
Subject: hg: jdk7/tl/jdk: 6867665: Problem with keytabs with multiple kvno's
	(key versions)
Message-ID: <20090820033736.9EFE512137@hg.openjdk.java.net>

Changeset: 5e8986cabdd8
Author:    weijun
Date:      2009-08-20 11:24 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e8986cabdd8

6867665: Problem with keytabs with multiple kvno's (key versions)
Reviewed-by: valeriep, ohair

! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
+ test/sun/security/krb5/ktab/HighestKvno.java



From alan.bateman at sun.com  Thu Aug 20 12:55:54 2009
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Thu, 20 Aug 2009 12:55:54 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090820125714.716FA12162@hg.openjdk.java.net>

Changeset: dfece53c600f
Author:    alanb
Date:      2009-08-20 08:39 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dfece53c600f

6595866: File does work with symbolic links (win,vista)
Reviewed-by: sherman

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

Changeset: 70c03e494a68
Author:    alanb
Date:      2009-08-20 08:42 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/70c03e494a68

6870926: (file) Path.toRealPath performance can be improved (win)
Reviewed-by: sherman

! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java
! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c

Changeset: 5cd12b68d09b
Author:    alanb
Date:      2009-08-20 08:48 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5cd12b68d09b

6866804: (file) Path calls checkPermission insteadof checkXXX (sol)
Reviewed-by: sherman

! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java
+ test/java/nio/file/Path/CheckPermissions.java
! test/java/nio/file/Path/Misc.java



From Ulf.Zibis at gmx.de  Thu Aug 20 14:30:35 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 20 Aug 2009 16:30:35 +0200
Subject: EUC-TW Decoder up to 100% faster, especially on ASCII on JDK-7 -server
Message-ID: <4A8D5E0B.9080309@gmx.de>

Hi Sherman, Martin and all,

I have found a way, how to speed-up charset decoders in a general way. 
In case of EUC-TW it does speed-up to 100 % (on ASCII on JDK-7 -server)

Here the output of my benchmark:
(see code: 
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/test/sun/nio/cs/ext/EUC_TWBenchmark.java)

java.version : 1.7.0-ea
java.vm.version : 16.0-b07
time to instantiate EUC_TW_xueming: 8716 ?s
time to instantiate EUC_TW_int: 4802 ?s
time to instantiate EUC_TW: 2819 ?s
time to instantiate EUC_TW_ASCII_inl: 4806 ?s
time to init decoder EUC_TW_xueming: 5873 ?s
time to init encoder EUC_TW_xueming: 33726 ?s
time to init decoder EUC_TW_int: 6618 ?s
time to init encoder EUC_TW_int: 25075 ?s
time to init decoder EUC_TW: 5404 ?s
time to init encoder EUC_TW: 21776 ?s
time to init decoder EUC_TW_ASCII_inl: 7827 ?s
time to init encoder EUC_TW_ASCII_inl: 24514 ?s
time to instantiate TestEUC_TW: 3075 ?s
time for warm up 1: 608 ms
time for warm up 2: 470 ms
time for warm up 3: 496 ms
time for warm up 4: 487 ms
time for       EUC_TW_xueming ASCII decode: 505 ms
time for           EUC_TW_int ASCII decode: 282 ms
time for               EUC_TW ASCII decode: 255 ms
time for     EUC_TW_ASCII_inl ASCII decode: 303 ms
time for       EUC_TW_xueming Plane0 decode: 687 ms
time for           EUC_TW_int Plane0 decode: 623 ms
time for               EUC_TW Plane0 decode: 632 ms
time for     EUC_TW_ASCII_inl Plane0 decode: 621 ms
last warm up ./. test loops: 1.2456994

-Ulf




From otto at informatik.rwth-aachen.de  Thu Aug 20 15:26:32 2009
From: otto at informatik.rwth-aachen.de (Carsten Otto)
Date: Thu, 20 Aug 2009 17:26:32 +0200
Subject: Which classes need to be supplied by any JVM?
Message-ID: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>

Hello,

I am working on automated termination analysis of Java Bytecode and I am
missing an important bit of information in the Java Virtual Machine
Specification (JVMS). I'd be happy to get some help from you!

Every JVM needs to provide certain classes including code for their native
methods, e.g. java.lang.Object (obvious) and java.io.Serializable (because
every array implements it). The list of such classes can easily be
extended, but I have huge problems finding a lower bound to keep this list
as small[1] as allowed according to the JVMS.

Is there some part of the specification that states which classes need to
be provided? I can only see references to the API (e.g. "reflective APIs"),
but no clear definition of the classes that need to exist. In the current
draft for JVMS 3rd edition, the necessity to include java.io.Serializable
is not even part of the JVMS, this is only visible by looking at the
definition of arrays in the Java Language Specification (JLS).

Some hints in this direction are also appreciated. So far I can only guess,
that sun.awt.* is not part of the language defined in the JVMS - but who
knows?

[1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar does not
work.

Thanks a lot,
-- 
Carsten Otto           otto at informatik.rwth-aachen.de
LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
RWTH Aachen            phone: +49 241 80-21211
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090820/b57b6438/signature.asc>

From Ulf.Zibis at gmx.de  Thu Aug 20 15:44:16 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 20 Aug 2009 17:44:16 +0200
Subject: EUC-TW Decoder up to 100% faster, especially on ASCII on JDK-7
	-server
In-Reply-To: <4A8D69EB.1030807@sun.com>
References: <4A8D5E0B.9080309@gmx.de> <4A8D69EB.1030807@sun.com>
Message-ID: <4A8D6F50.8020706@gmx.de>

Oops, the link is:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/all-in-charsets/test/sun/nio/cs/ext/EUC_TWBenchmark.java

The "way" you can see here (the trick is in the CoderResult escape methods):
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/all-in-charsets/src/sun/nio/cs/FastCharset.java?rev=&view=markup

There is no price of "double-byte" coding for "ascii" performance. :-)

Now I'm working on: 
http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6873330

-Ulf

Am 20.08.2009 17:21, Xueming Shen schrieb:
> Ulf,
>
> My apology that I have not looked into your recent proposals (I did 
> quickly scan the change) as I
> should have to, mostly because I shifted myself out of charsets for 
> some other stuff the last couple
> weeks/month...I will  get back to it to finish some my leftover and 
> pick up your stuff after I finish the
> zlib123 upgrade, hopefully soon.
>
> The link below does not seem work...and can you detail th "way" you 
> found (from the name the
> link is the benchmark). Does the "ascii benefit" come with the cost  
> of "non-ascii" decoding? I'm
> asking because in case of double-byte charset, you don't want to pay a 
> price of "double-byte"
> coding for "ascii" performance, but other way around.  the performance 
> of "double-byte" is
> more important.
>
> sherman
>
> Ulf Zibis wrote:
>> Hi Sherman, Martin and all,
>>
>> I have found a way, how to speed-up charset decoders in a general 
>> way. In case of EUC-TW it does speed-up to 100 % (on ASCII on JDK-7 
>> -server)
>>
>> Here the output of my benchmark:
>> (see code: 
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/test/sun/nio/cs/ext/EUC_TWBenchmark.java) 
>>
>>
>> java.version : 1.7.0-ea
>> java.vm.version : 16.0-b07
>> time to instantiate EUC_TW_xueming: 8716 ?s
>> time to instantiate EUC_TW_int: 4802 ?s
>> time to instantiate EUC_TW: 2819 ?s
>> time to instantiate EUC_TW_ASCII_inl: 4806 ?s
>> time to init decoder EUC_TW_xueming: 5873 ?s
>> time to init encoder EUC_TW_xueming: 33726 ?s
>> time to init decoder EUC_TW_int: 6618 ?s
>> time to init encoder EUC_TW_int: 25075 ?s
>> time to init decoder EUC_TW: 5404 ?s
>> time to init encoder EUC_TW: 21776 ?s
>> time to init decoder EUC_TW_ASCII_inl: 7827 ?s
>> time to init encoder EUC_TW_ASCII_inl: 24514 ?s
>> time to instantiate TestEUC_TW: 3075 ?s
>> time for warm up 1: 608 ms
>> time for warm up 2: 470 ms
>> time for warm up 3: 496 ms
>> time for warm up 4: 487 ms
>> time for       EUC_TW_xueming ASCII decode: 505 ms
>> time for           EUC_TW_int ASCII decode: 282 ms
>> time for               EUC_TW ASCII decode: 255 ms
>> time for     EUC_TW_ASCII_inl ASCII decode: 303 ms
>> time for       EUC_TW_xueming Plane0 decode: 687 ms
>> time for           EUC_TW_int Plane0 decode: 623 ms
>> time for               EUC_TW Plane0 decode: 632 ms
>> time for     EUC_TW_ASCII_inl Plane0 decode: 621 ms
>> last warm up ./. test loops: 1.2456994
>>
>> -Ulf
>>
>>
>
>



From martinrb at google.com  Thu Aug 20 17:32:44 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 20 Aug 2009 10:32:44 -0700
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
Message-ID: <1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>

The set of all public APIs that must be part of the java se platform
are tested by the platform tck, in particular by the "signature test",
and you can get the sources for that test (for research only)
and from that it should be possible (with work) to get a list of
all required classes.  But that's a very large list, so is probably not
what you want.  In practice, the subset of rt.jar of public classes
matching java.* or javax.* is a pretty good approximation.

Martin

On Thu, Aug 20, 2009 at 08:26, Carsten Otto
<otto at informatik.rwth-aachen.de>wrote:

> Hello,
>
> I am working on automated termination analysis of Java Bytecode and I am
> missing an important bit of information in the Java Virtual Machine
> Specification (JVMS). I'd be happy to get some help from you!
>
> Every JVM needs to provide certain classes including code for their native
> methods, e.g. java.lang.Object (obvious) and java.io.Serializable (because
> every array implements it). The list of such classes can easily be
> extended, but I have huge problems finding a lower bound to keep this list
> as small[1] as allowed according to the JVMS.
>
> Is there some part of the specification that states which classes need to
> be provided? I can only see references to the API (e.g. "reflective APIs"),
> but no clear definition of the classes that need to exist. In the current
> draft for JVMS 3rd edition, the necessity to include java.io.Serializable
> is not even part of the JVMS, this is only visible by looking at the
> definition of arrays in the Java Language Specification (JLS).
>
> Some hints in this direction are also appreciated. So far I can only guess,
> that sun.awt.* is not part of the language defined in the JVMS - but who
> knows?
>
> [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar does not
> work.
>
> Thanks a lot,
> --
> Carsten Otto           otto at informatik.rwth-aachen.de
> LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
> RWTH Aachen            phone: +49 241 80-21211
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
> 4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
> =Brg8
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090820/d1b2e04c/attachment.html>

From lance.andersen at sun.com  Thu Aug 20 21:29:26 2009
From: lance.andersen at sun.com (lance.andersen at sun.com)
Date: Thu, 20 Aug 2009 21:29:26 +0000
Subject: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate
	COMMIT_ON_ACCEPT_CHANGES,
	make constants final that needed to be. (also reviewed by ksaks,
	ryano)
Message-ID: <20090820213035.8C70D121A1@hg.openjdk.java.net>

Changeset: 4ec7d1890538
Author:    lancea
Date:      2009-08-20 19:21 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4ec7d1890538

6843995: Added RowsetFactory and Deprecate COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be. (also reviewed by ksaks, ryano)
Reviewed-by: valeriep

+ src/share/classes/com/sun/rowset/RowSetFactoryImpl.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
+ src/share/classes/javax/sql/rowset/RowSetFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java



From Ulf.Zibis at gmx.de  Thu Aug 20 21:31:25 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 20 Aug 2009 23:31:25 +0200
Subject: EUC-TW Decoder up to 100% faster, especially on ASCII on JDK-7
	-server
In-Reply-To: <4A8D69EB.1030807@sun.com>
References: <4A8D5E0B.9080309@gmx.de> <4A8D69EB.1030807@sun.com>
Message-ID: <4A8DC0AD.30001@gmx.de>

Now also faster for double/quad bytes:

java.version : 1.7.0-ea
java.vm.version : 16.0-b07
time to instantiate EUC_TW_xueming: 7571 ?s
time to instantiate EUC_TW_int: 3758 ?s
time to instantiate EUC_TW: 3294 ?s
time to instantiate EUC_TW_ASCII_inl: 3823 ?s
time to init decoder EUC_TW_xueming: 7117 ?s
time to init encoder EUC_TW_xueming: 31024 ?s
time to init decoder EUC_TW_int: 7030 ?s
time to init encoder EUC_TW_int: 21805 ?s
time to init decoder EUC_TW: 7727 ?s
time to init encoder EUC_TW: 27897 ?s
time to init decoder EUC_TW_ASCII_inl: 7464 ?s
time to init encoder EUC_TW_ASCII_inl: 22535 ?s
time to instantiate TestEUC_TW: 1481 ?s
time for warm up 1: 1116 ms
time for warm up 2: 941 ms
time for warm up 3: 939 ms
time for warm up 4: 962 ms
time for       EUC_TW_xueming ASCII decode: 489 ms
time for           EUC_TW_int ASCII decode: 286 ms
time for               EUC_TW ASCII decode: 256 ms
time for     EUC_TW_ASCII_inl ASCII decode: 260 ms
time for       EUC_TW_xueming Plane0 decode: 699 ms
time for           EUC_TW_int Plane0 decode: 617 ms
time for               EUC_TW Plane0 decode: 594 ms
time for     EUC_TW_ASCII_inl Plane0 decode: 642 ms
time for       EUC_TW_xueming Plane2 decode: 378 ms
time for           EUC_TW_int Plane2 decode: 358 ms
time for               EUC_TW Plane2 decode: 355 ms
time for     EUC_TW_ASCII_inl Plane2 decode: 367 ms
time for       EUC_TW_xueming Plane15 decode: 519 ms
time for           EUC_TW_int Plane15 decode: 816 ms
time for               EUC_TW Plane15 decode: 476 ms
time for     EUC_TW_ASCII_inl Plane15 decode: 761 ms
last warm up ./. test loops: 1.2208825


-Ulf




From mr at sun.com  Thu Aug 20 22:40:00 2009
From: mr at sun.com (Mark Reinhold)
Date: Thu, 20 Aug 2009 15:40:00 -0700
Subject: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate
	COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.
In-Reply-To: lance.andersen@sun.com; Thu, 20 Aug 2009 21:29:26 -0000;
	<20090820213035.8C70D121A1@hg.openjdk.java.net> 
Message-ID: <20090820224000.6B168E12@eggemoggin.niobe.net>

This change was integrated prematurely.  I've rolled it back in the
jdk7/tl/jdk repository.

If you've already pulled it into a local repository then you can remove
it using the hg strip command, which is part of the mq extension.

Your tip changeset should be:

  changeset:   1563:5cd12b68d09b
  user:        alanb
  date:        Thu Aug 20 08:48:29 2009 +0100
  summary:     6866804: (file) Path calls checkPermission insteadof checkXXX (sol)

- Mark


From David.Holmes at Sun.COM  Thu Aug 20 23:32:52 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 21 Aug 2009 09:32:52 +1000
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
Message-ID: <4A8DDD24.4090400@sun.com>

As Martin stated what you are looking for is not part of the JVMS nor 
the JLS, but the platform specification, which is essentially the entire 
set of Java API's as found for example here:

http://java.sun.com/javase/6/docs/index.html

But the implementation of those classes will then have dependencies on 
other implementation specific classes, so I'm not sure that you will be 
able to establish a transitive closure of required classes that is 
independent of the JVM in question.

If you were thinking about this from a basic language perspective - eg 
we must have Object, and we must have Class, and array implies 
Serializable etc, then there is a core set of classes that form the 
transitive closure of the JVM bootstrap process. If you are interested 
in that then -XX:+TraceClassLoading (might need a debug VM) will give 
you the set used by a particular VM. But again this list is dependent on 
how those classes are implemented themselves, so the list is JVM dependent.

HTH

David Holmes

Martin Buchholz said the following on 08/21/09 03:32:
> The set of all public APIs that must be part of the java se platform
> are tested by the platform tck, in particular by the "signature test",
> and you can get the sources for that test (for research only)
> and from that it should be possible (with work) to get a list of
> all required classes.  But that's a very large list, so is probably not
> what you want.  In practice, the subset of rt.jar of public classes
> matching java.* or javax.* is a pretty good approximation.
> 
> Martin
> 
> On Thu, Aug 20, 2009 at 08:26, Carsten Otto 
> <otto at informatik.rwth-aachen.de <mailto:otto at informatik.rwth-aachen.de>> 
> wrote:
> 
>     Hello,
> 
>     I am working on automated termination analysis of Java Bytecode and I am
>     missing an important bit of information in the Java Virtual Machine
>     Specification (JVMS). I'd be happy to get some help from you!
> 
>     Every JVM needs to provide certain classes including code for their
>     native
>     methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>     (because
>     every array implements it). The list of such classes can easily be
>     extended, but I have huge problems finding a lower bound to keep
>     this list
>     as small[1] as allowed according to the JVMS.
> 
>     Is there some part of the specification that states which classes
>     need to
>     be provided? I can only see references to the API (e.g. "reflective
>     APIs"),
>     but no clear definition of the classes that need to exist. In the
>     current
>     draft for JVMS 3rd edition, the necessity to include
>     java.io.Serializable
>     is not even part of the JVMS, this is only visible by looking at the
>     definition of arrays in the Java Language Specification (JLS).
> 
>     Some hints in this direction are also appreciated. So far I can only
>     guess,
>     that sun.awt.* is not part of the language defined in the JVMS - but who
>     knows?
> 
>     [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>     does not
>     work.
> 
>     Thanks a lot,
>     --
>     Carsten Otto           otto at informatik.rwth-aachen.de
>     <mailto:otto at informatik.rwth-aachen.de>
>     LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
>     RWTH Aachen            phone: +49 241 80-21211
> 
>     -----BEGIN PGP SIGNATURE-----
>     Version: GnuPG v1.4.9 (GNU/Linux)
> 
>     iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>     4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>     =Brg8
>     -----END PGP SIGNATURE-----
> 
> 


From Xueming.Shen at Sun.COM  Fri Aug 21 02:49:44 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 20 Aug 2009 19:49:44 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
Message-ID: <4A8E0B48.3030703@sun.com>

Here is the latest webrev for updating the zlib from the aged 1.1.3 to 
the latest version 1.2.3

http://cr.openjdk.java.net/~sherman/zlib123/webrev

Alan, Kumar Martin, thanks for the comments, while I'm continuing 
running more tests:-) here are the
reply to your comments/questions.

(1) The ZLIB_VERSION has been moved into common/Defs.gmk.
(2) The copyright you quoted in the original copyright of zlib1.1.3 (it 
was there is jdk6 and earlier before we opensourced the jdk7).
(3) Yes, I have run the regression tests in tools/pack200 and those in 
launcher, as well as other jar, zip related.
(4) I just jprt-ed a full forest/control build including everything, it 
finished without any problem
(5) So far the "large zip support" still holds on all platforms I tested 
on (Solaris sparc 32-bit/x86 32-bit, Linux x64 and Windows32-bit.
(6)I would still prefer to get the source code from zlib.org. I took a 
quick scan at the ubuntu diff, don't see the value of replacing the one
    we have.
(7) The java port change log has been moved to
 http://cr.openjdk.java.net/~sherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html

Sherman








From mark at klomp.org  Fri Aug 21 07:37:00 2009
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 21 Aug 2009 09:37:00 +0200
Subject: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate
	COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.
In-Reply-To: <20090820224000.6B168E12@eggemoggin.niobe.net>
References: <20090820224000.6B168E12@eggemoggin.niobe.net>
Message-ID: <1250840220.3908.9.camel@springer.wildebeest.org>

Hi Mark,

On Thu, 2009-08-20 at 15:40 -0700, Mark Reinhold wrote:
> This change was integrated prematurely.  I've rolled it back in the
> jdk7/tl/jdk repository.

If at all possible, please don't do this. It plays havoc with already
checked out repos and/or automatic clones/backups. You force people to
recreate their local repos if you purge a commit that was already public
like this. Could you use a normal hg backout instead in the future? That
will make sure the integrity of the repo isn't compromised.

Thanks,

Mark



From martinrb at google.com  Fri Aug 21 08:03:48 2009
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 21 Aug 2009 01:03:48 -0700
Subject: zlib1.2.3
In-Reply-To: <4A8E0B48.3030703@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
Message-ID: <1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>

I like very much that you are saving local changes in the form of patches
(I've been advocating this style of modification of upstream sources
for a while now), but...
- please generate your patches in "unidiff" form (diff -u)
- the extension ".patch" is, I think, preferable to ".diff"
  (or put them into a "patches" directory, as debian does)

I don't think we need minigzip.c - it's a kind of "demo" program.

Do we really need to rename files?  That's quite confusing.

The pervasive change of
uLong => unsigned long
seems unnecessary - just get the typedef of uLong correct.

Martin

On Thu, Aug 20, 2009 at 19:49, Xueming Shen <Xueming.Shen at sun.com> wrote:

> Here is the latest webrev for updating the zlib from the aged 1.1.3 to the
> latest version 1.2.3
>
> http://cr.openjdk.java.net/~sherman/zlib123/webrev<http://cr.openjdk.java.net/%7Esherman/zlib123/webrev>
>
> Alan, Kumar Martin, thanks for the comments, while I'm continuing running
> more tests:-) here are the
> reply to your comments/questions.
>
> (1) The ZLIB_VERSION has been moved into common/Defs.gmk.
> (2) The copyright you quoted in the original copyright of zlib1.1.3 (it was
> there is jdk6 and earlier before we opensourced the jdk7).
> (3) Yes, I have run the regression tests in tools/pack200 and those in
> launcher, as well as other jar, zip related.
> (4) I just jprt-ed a full forest/control build including everything, it
> finished without any problem
> (5) So far the "large zip support" still holds on all platforms I tested on
> (Solaris sparc 32-bit/x86 32-bit, Linux x64 and Windows32-bit.
> (6)I would still prefer to get the source code from zlib.org. I took a
> quick scan at the ubuntu diff, don't see the value of replacing the one
>   we have.
> (7) The java port change log has been moved to
>
> http://cr.openjdk.java.net/~sherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html<http://cr.openjdk.java.net/%7Esherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html>
>
> Sherman
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090821/6531fa58/attachment.html>

From fweimer at bfk.de  Fri Aug 21 08:14:52 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 21 Aug 2009 08:14:52 +0000
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <4A8DDD24.4090400@sun.com> (David Holmes's message of "Fri\,
	21 Aug 2009 09\:32\:52 +1000")
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
	<4A8DDD24.4090400@sun.com>
Message-ID: <82my5t1t37.fsf@mid.bfk.de>

* David Holmes:

> If you were thinking about this from a basic language perspective - eg
> we must have Object, and we must have Class, and array implies
> Serializable etc, then there is a core set of classes that form the
> transitive closure of the JVM bootstrap process. If you are interested
> in that then -XX:+TraceClassLoading (might need a debug VM)

Plain old "-verbose" works in production builds, by the way.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From scolebourne at joda.org  Fri Aug 21 08:14:59 2009
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 21 Aug 2009 09:14:59 +0100
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <4A8DDD24.4090400@sun.com>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
	<4A8DDD24.4090400@sun.com>
Message-ID: <4A8E5783.5000606@joda.org>

I was actually interested in the thrust of the original question, let me 
rephrase it.

If you wanted to code from scratch a JVM, but not include the rest of 
the Java SE platform (such as the .class files), what would you need to 
include? Is Object.class mandatory for a pure JVM? Anything else?

The answers given imply that the JVM is not an isolated well defined 
component. Yet that argues against being able to write a new programming 
language for the JVM that has no integration whatsoever with the Java 
language and just emits 'pure bytecode' for a 'pure JVM'.

I, like Carsten, find it odd if this isn't well-defined.

Stephen

David Holmes - Sun Microsystems wrote:
> As Martin stated what you are looking for is not part of the JVMS nor 
> the JLS, but the platform specification, which is essentially the entire 
> set of Java API's as found for example here:
> 
> http://java.sun.com/javase/6/docs/index.html
> 
> But the implementation of those classes will then have dependencies on 
> other implementation specific classes, so I'm not sure that you will be 
> able to establish a transitive closure of required classes that is 
> independent of the JVM in question.
> 
> If you were thinking about this from a basic language perspective - eg 
> we must have Object, and we must have Class, and array implies 
> Serializable etc, then there is a core set of classes that form the 
> transitive closure of the JVM bootstrap process. If you are interested 
> in that then -XX:+TraceClassLoading (might need a debug VM) will give 
> you the set used by a particular VM. But again this list is dependent on 
> how those classes are implemented themselves, so the list is JVM dependent.
> 
> HTH
> 
> David Holmes
> 
> Martin Buchholz said the following on 08/21/09 03:32:
>> The set of all public APIs that must be part of the java se platform
>> are tested by the platform tck, in particular by the "signature test",
>> and you can get the sources for that test (for research only)
>> and from that it should be possible (with work) to get a list of
>> all required classes.  But that's a very large list, so is probably not
>> what you want.  In practice, the subset of rt.jar of public classes
>> matching java.* or javax.* is a pretty good approximation.
>>
>> Martin
>>
>> On Thu, Aug 20, 2009 at 08:26, Carsten Otto 
>> <otto at informatik.rwth-aachen.de 
>> <mailto:otto at informatik.rwth-aachen.de>> wrote:
>>
>>     Hello,
>>
>>     I am working on automated termination analysis of Java Bytecode 
>> and I am
>>     missing an important bit of information in the Java Virtual Machine
>>     Specification (JVMS). I'd be happy to get some help from you!
>>
>>     Every JVM needs to provide certain classes including code for their
>>     native
>>     methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>>     (because
>>     every array implements it). The list of such classes can easily be
>>     extended, but I have huge problems finding a lower bound to keep
>>     this list
>>     as small[1] as allowed according to the JVMS.
>>
>>     Is there some part of the specification that states which classes
>>     need to
>>     be provided? I can only see references to the API (e.g. "reflective
>>     APIs"),
>>     but no clear definition of the classes that need to exist. In the
>>     current
>>     draft for JVMS 3rd edition, the necessity to include
>>     java.io.Serializable
>>     is not even part of the JVMS, this is only visible by looking at the
>>     definition of arrays in the Java Language Specification (JLS).
>>
>>     Some hints in this direction are also appreciated. So far I can only
>>     guess,
>>     that sun.awt.* is not part of the language defined in the JVMS - 
>> but who
>>     knows?
>>
>>     [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>>     does not
>>     work.
>>
>>     Thanks a lot,
>>     --
>>     Carsten Otto           otto at informatik.rwth-aachen.de
>>     <mailto:otto at informatik.rwth-aachen.de>
>>     LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
>>     RWTH Aachen            phone: +49 241 80-21211
>>
>>     -----BEGIN PGP SIGNATURE-----
>>     Version: GnuPG v1.4.9 (GNU/Linux)
>>
>>     iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>>     4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>>     =Brg8
>>     -----END PGP SIGNATURE-----
>>
>>
> 


From David.Holmes at Sun.COM  Fri Aug 21 08:24:58 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 21 Aug 2009 18:24:58 +1000
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <4A8E5783.5000606@joda.org>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
	<4A8DDD24.4090400@sun.com> <4A8E5783.5000606@joda.org>
Message-ID: <4A8E59DA.2000205@sun.com>

Stephen,

Stephen Colebourne said the following on 08/21/09 18:14:
> If you wanted to code from scratch a JVM, but not include the rest of 
> the Java SE platform (such as the .class files), what would you need to 
> include? Is Object.class mandatory for a pure JVM? Anything else?
> 
> The answers given imply that the JVM is not an isolated well defined 
> component. Yet that argues against being able to write a new programming 
> language for the JVM that has no integration whatsoever with the Java 
> language and just emits 'pure bytecode' for a 'pure JVM'.

I think you would need to separate the bytecode-engine part of the JVM 
from the "Java runtime platform" part. The bytecode engine has few 
dependencies on classes, perhaps not even Object, while the runtime 
environment has many dependencies.

David Holmes

> I, like Carsten, find it odd if this isn't well-defined.
> 
> Stephen
> 
> David Holmes - Sun Microsystems wrote:
>> As Martin stated what you are looking for is not part of the JVMS nor 
>> the JLS, but the platform specification, which is essentially the 
>> entire set of Java API's as found for example here:
>>
>> http://java.sun.com/javase/6/docs/index.html
>>
>> But the implementation of those classes will then have dependencies on 
>> other implementation specific classes, so I'm not sure that you will 
>> be able to establish a transitive closure of required classes that is 
>> independent of the JVM in question.
>>
>> If you were thinking about this from a basic language perspective - eg 
>> we must have Object, and we must have Class, and array implies 
>> Serializable etc, then there is a core set of classes that form the 
>> transitive closure of the JVM bootstrap process. If you are interested 
>> in that then -XX:+TraceClassLoading (might need a debug VM) will give 
>> you the set used by a particular VM. But again this list is dependent 
>> on how those classes are implemented themselves, so the list is JVM 
>> dependent.
>>
>> HTH
>>
>> David Holmes
>>
>> Martin Buchholz said the following on 08/21/09 03:32:
>>> The set of all public APIs that must be part of the java se platform
>>> are tested by the platform tck, in particular by the "signature test",
>>> and you can get the sources for that test (for research only)
>>> and from that it should be possible (with work) to get a list of
>>> all required classes.  But that's a very large list, so is probably not
>>> what you want.  In practice, the subset of rt.jar of public classes
>>> matching java.* or javax.* is a pretty good approximation.
>>>
>>> Martin
>>>
>>> On Thu, Aug 20, 2009 at 08:26, Carsten Otto 
>>> <otto at informatik.rwth-aachen.de 
>>> <mailto:otto at informatik.rwth-aachen.de>> wrote:
>>>
>>>     Hello,
>>>
>>>     I am working on automated termination analysis of Java Bytecode 
>>> and I am
>>>     missing an important bit of information in the Java Virtual Machine
>>>     Specification (JVMS). I'd be happy to get some help from you!
>>>
>>>     Every JVM needs to provide certain classes including code for their
>>>     native
>>>     methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>>>     (because
>>>     every array implements it). The list of such classes can easily be
>>>     extended, but I have huge problems finding a lower bound to keep
>>>     this list
>>>     as small[1] as allowed according to the JVMS.
>>>
>>>     Is there some part of the specification that states which classes
>>>     need to
>>>     be provided? I can only see references to the API (e.g. "reflective
>>>     APIs"),
>>>     but no clear definition of the classes that need to exist. In the
>>>     current
>>>     draft for JVMS 3rd edition, the necessity to include
>>>     java.io.Serializable
>>>     is not even part of the JVMS, this is only visible by looking at the
>>>     definition of arrays in the Java Language Specification (JLS).
>>>
>>>     Some hints in this direction are also appreciated. So far I can only
>>>     guess,
>>>     that sun.awt.* is not part of the language defined in the JVMS - 
>>> but who
>>>     knows?
>>>
>>>     [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>>>     does not
>>>     work.
>>>
>>>     Thanks a lot,
>>>     --
>>>     Carsten Otto           otto at informatik.rwth-aachen.de
>>>     <mailto:otto at informatik.rwth-aachen.de>
>>>     LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
>>>     RWTH Aachen            phone: +49 241 80-21211
>>>
>>>     -----BEGIN PGP SIGNATURE-----
>>>     Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>>     iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>>>     4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>>>     =Brg8
>>>     -----END PGP SIGNATURE-----
>>>
>>>
>>


From Ulf.Zibis at gmx.de  Fri Aug 21 09:34:25 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 21 Aug 2009 11:34:25 +0200
Subject: codereview request: 6639443/
In-Reply-To: <4A5CE18F.7030906@sun.com>
References: <4A57CB2C.50707@sun.com>	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
	<4A5CE18F.7030906@sun.com>
Message-ID: <4A8E6A21.4040106@gmx.de>

Sherman, Martin,

Why you don't commit this change to the repository ?

Especially please add Character.isSurrogate(char ch) soon.
I like to get rid of using the sun.nio.cs.Surrogate class in my changes.

IMO, there only should remain Surrogate.Parser and Surrogate.Generator, 
if someone likes to use it.

-Ulf



Am 14.07.2009 21:50, Xueming Shen schrieb:
> I included the core-libs-dev as you suggested.
>
>
>
> (1)The toCodePoint change looks good.
>
> (2)
>
> a)    return (int)(char) uc ==uc;
>
>    is nice:-) but I would go with the "more easy to read"
>
>    return uc < Surrogate.UCS4_MIN;
>
>    if it were my code. Is there a big performance gain by doing that?
>
> b) The "buffer" version and the "array" version of generate() are not 
> synced.
>
>
> (3)6860431: Character.isSurrogate(char ch)
>
> has been filed on your behalf, as well as the CCC 
> http://ccc.sfbay.sun.com/6860431.
> Masayoshi, would you please review the spec and add yourself as the 
> reviewer? I
> need the reviewer to fast-track it.
>
> Sherman
>
> Martin Buchholz wrote:
>> Hey Character team,
>>
>> (should we add more people to this conversation?)
>>
>> One of the reasons I don't finish projects is
>> that I never think the code is good enough.
>> In that spirit, here are 3 reviews for you:
>>
>> ----
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/toCodePoint/ 
>> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/toCodePoint/>
>>
>> Since the unoptimized code is easier to understand,
>> I re-added it, in a comment.
>>
>> ----
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Surrogate/ 
>> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/Surrogate/>
>>
>> I removed more (but certainly not all) uses of Surrogate
>> stuff that was duplicated from Character.
>>
>> I added a TODO to remove more such code duplication.
>>
>> In generate(), there is now a genuine difference in behavior.
>> I believe the intent of the original code was to handle
>> negative codepoint values, but never quite got that right.
>> My fix removed dead code, but was incorrect in that
>> I should have preserved the intent, not just behavior.
>>
>> I optimized for the common case of BMP chars,
>> and introduced isBMP.
>>
>> ----
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isSurrogate/ 
>> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/isSurrogate/>
>>
>> This is a spec change.  Please file bug and CCC on my behalf.
>> Synopsis: Character.isSurrogate(char ch)
>> Description:
>> Character.isSurrogate(char ch)
>> is *the* missing method
>> that we all use from Surrogate.java.
>>
>> Let's put it into Character.
>>
>> When approved, we can make sure it's tested by
>> replacing calls to Surrogate.is(int) with calls to
>> Character.isSurrogate(char) (but they're not exactly the same
>> because the domain of the function is different.
>>
>> ----
>>
>> Thanks,
>>
>> Martin
>>
>> On Fri, Jul 10, 2009 at 17:39, Martin Buchholz <martinrb at google.com 
>> <mailto:martinrb at google.com>> wrote:
>>
>>     Thanks for kicking me!
>>
>>     I have a bad habit of starting projects and not finishing them.
>>     If it's OK with you, I will commit this change (and perhaps others
>>     like it).  Let's call it guilt-driven software development.
>>
>>     Martin
>>
>>
>>     On Fri, Jul 10, 2009 at 16:13, Xueming Shen <Xueming.Shen at sun.com
>>     <mailto:Xueming.Shen at sun.com>> wrote:
>>
>>         I'm cleaning up the 7 bug list, this one is the one you did
>>         not finish/putback before left.
>>
>>         http://cr.openjdk.java.net/~sherman/6639443/webrev
>>         <http://cr.openjdk.java.net/%7Esherman/6639443/webrev>
>>
>>         The fix looks fine. Can you "review" it as well?
>>
>>         Masayoshi, please take a look as well.
>>
>>         Btw, where is the regression tests for supplementary
>>         characters? I can't find it under test/java/lang...
>>
>>         Thanks!
>>         Sherman
>>
>>
>>
>
>



From Xueming.Shen at Sun.COM  Fri Aug 21 15:46:53 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Fri, 21 Aug 2009 08:46:53 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
Message-ID: <4A8EC16D.80505@sun.com>

Martin Buchholz wrote:
> I like very much that you are saving local changes in the form of patches
> (I've been advocating this style of modification of upstream sources
> for a while now), but...
> - please generate your patches in "unidiff" form (diff -u)
> - the extension ".patch" is, I think, preferable to ".diff"
>   (or put them into a "patches" directory, as debian does)
>
> I don't think we need minigzip.c - it's a kind of "demo" program.
>
> Do we really need to rename files?  That's quite confusing.

The names conflict with our CRC32.c and Adler.c on Windows platform.

>
> The pervasive change of
> uLong => unsigned long
> seems unnecessary - just get the typedef of uLong correct.
You meant the "unsigned long -> uLong" in crc.c?

sherman

>
> Martin
>
> On Thu, Aug 20, 2009 at 19:49, Xueming Shen <Xueming.Shen at sun.com 
> <mailto:Xueming.Shen at sun.com>> wrote:
>
>     Here is the latest webrev for updating the zlib from the aged
>     1.1.3 to the latest version 1.2.3
>
>
>     http://cr.openjdk.java.net/~sherman/zlib123/webrev
>     <http://cr.openjdk.java.net/%7Esherman/zlib123/webrev>
>
>     Alan, Kumar Martin, thanks for the comments, while I'm continuing
>     running more tests:-) here are the
>     reply to your comments/questions.
>
>     (1) The ZLIB_VERSION has been moved into common/Defs.gmk.
>     (2) The copyright you quoted in the original copyright of
>     zlib1.1.3 (it was there is jdk6 and earlier before we opensourced
>     the jdk7).
>     (3) Yes, I have run the regression tests in tools/pack200 and
>     those in launcher, as well as other jar, zip related.
>     (4) I just jprt-ed a full forest/control build including
>     everything, it finished without any problem
>     (5) So far the "large zip support" still holds on all platforms I
>     tested on (Solaris sparc 32-bit/x86 32-bit, Linux x64 and
>     Windows32-bit.
>     (6)I would still prefer to get the source code from zlib.org
>     <http://zlib.org>. I took a quick scan at the ubuntu diff, don't
>     see the value of replacing the one
>       we have.
>     (7) The java port change log has been moved to
>     http://cr.openjdk.java.net/~sherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html
>     <http://cr.openjdk.java.net/%7Esherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html>
>
>     Sherman
>
>
>
>
>
>
>



From Joe.Darcy at Sun.COM  Fri Aug 21 16:29:56 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 21 Aug 2009 09:29:56 -0700
Subject: Core review request for 6378701
	"(enum) Unclear purpose of EnumConstantNotPresentException "
Message-ID: <4A8ECB84.4010105@sun.com>

Hello.

Please review the patch below is clarify the use of certain exception 
types to address bug 6378701 "(enum) Unclear purpose of 
EnumConstantNotPresentException."  Five exceptions/errors can be thrown 
by the methods of the AnnotatedElement interface; those methods are used 
to retrieve annotations reflectively.  I've added cross references 
between the AnnotatedElement intefaces and the throwables it may throw.

-Joe

--- 
old/src/share/classes/java/lang/EnumConstantNotPresentException.java    
2009-08-21 00:43:31.000000000 -0700
+++ 
new/src/share/classes/java/lang/EnumConstantNotPresentException.java    
2009-08-21 00:43:30.000000000 -0700
@@ -28,8 +28,12 @@
 /**
  * Thrown when an application tries to access an enum constant by name
  * and the enum type contains no constant with the specified name.
+ * This exception can be thrown by the {@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
  *
  * @author  Josh Bloch
+ * @see     java.lang.reflect.AnnotatedElement
  * @since   1.5
  */
 public class EnumConstantNotPresentException extends RuntimeException {
--- old/src/share/classes/java/lang/TypeNotPresentException.java    
2009-08-21 00:43:32.000000000 -0700
+++ new/src/share/classes/java/lang/TypeNotPresentException.java    
2009-08-21 00:43:31.000000000 -0700
@@ -35,8 +35,12 @@
  * <p>Note that this exception may be used when undefined type variables
  * are accessed as well as when types (e.g., classes, interfaces or
  * annotation types) are loaded.
+ * In particular, this exception can be thrown by the {@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
  *
  * @author  Josh Bloch
+ * @see     java.lang.reflect.AnnotatedElement
  * @since 1.5
  */
 public class TypeNotPresentException extends RuntimeException {
--- 
old/src/share/classes/java/lang/annotation/AnnotationFormatError.java    
2009-08-21 00:43:32.000000000 -0700
+++ 
new/src/share/classes/java/lang/annotation/AnnotationFormatError.java    
2009-08-21 00:43:32.000000000 -0700
@@ -28,8 +28,12 @@
 /**
  * Thrown when the annotation parser attempts to read an annotation
  * from a class file and determines that the annotation is malformed.
+ * This error can be thrown by the {@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
  *
  * @author  Josh Bloch
+ * @see     java.lang.reflect.AnnotatedElement
  * @since   1.5
  */
 public class AnnotationFormatError extends Error {
--- 
old/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java    
2009-08-21 00:43:33.000000000 -0700
+++ 
new/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java    
2009-08-21 00:43:33.000000000 -0700
@@ -30,8 +30,12 @@
  * Thrown to indicate that a program has attempted to access an element of
  * an annotation whose type has changed after the annotation was compiled
  * (or serialized).
+ * This exception can be thrown by the {@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
  *
  * @author  Josh Bloch
+ * @see     java.lang.reflect.AnnotatedElement
  * @since 1.5
  */
 public class AnnotationTypeMismatchException extends RuntimeException {
--- 
old/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java    
2009-08-21 00:43:34.000000000 -0700
+++ 
new/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java    
2009-08-21 00:43:33.000000000 -0700
@@ -30,8 +30,12 @@
  * an annotation type that was added to the annotation type definition 
after
  * the annotation was compiled (or serialized).  This exception will not be
  * thrown if the new element has a default value.
+ * This exception can be thrown by the {@linkplain
+ * java.lang.reflect.AnnotatedElement API used to read annotations
+ * reflectively}.
  *
  * @author  Josh Bloch
+ * @see     java.lang.reflect.AnnotatedElement
  * @since 1.5
  */
 public class IncompleteAnnotationException extends RuntimeException {
--- old/src/share/classes/java/lang/reflect/AnnotatedElement.java    
2009-08-21 00:43:34.000000000 -0700
+++ new/src/share/classes/java/lang/reflect/AnnotatedElement.java    
2009-08-21 00:43:34.000000000 -0700
@@ -50,6 +50,11 @@
  * java.lang.annotation.AnnotationTypeMismatchException} or an
  * {@link java.lang.annotation.IncompleteAnnotationException}.
  *
+ * @see java.lang.EnumConstantNotPresentException
+ * @see java.lang.TypeNotPresentException
+ * @see java.lang.annotation.AnnotationFormatError
+ * @see java.lang.annotation.AnnotationTypeMismatchException
+ * @see java.lang.annotation.IncompleteAnnotationException
  * @since 1.5
  * @author Josh Bloch
  */


From Lance.Andersen at Sun.COM  Fri Aug 21 16:35:42 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Fri, 21 Aug 2009 12:35:42 -0400
Subject: Core review request for 6378701
	"(enum) Unclear purpose of EnumConstantNotPresentException "
In-Reply-To: <4A8ECB84.4010105@sun.com>
References: <4A8ECB84.4010105@sun.com>
Message-ID: <4A8ECCDE.9030007@sun.com>

Hi Joe,

The changes are fine and make things clearer.

Regards
Lance

Joseph D. Darcy wrote:
> Hello.
>
> Please review the patch below is clarify the use of certain exception 
> types to address bug 6378701 "(enum) Unclear purpose of 
> EnumConstantNotPresentException."  Five exceptions/errors can be 
> thrown by the methods of the AnnotatedElement interface; those methods 
> are used to retrieve annotations reflectively.  I've added cross 
> references between the AnnotatedElement intefaces and the throwables 
> it may throw.
>
> -Joe
>
> --- 
> old/src/share/classes/java/lang/EnumConstantNotPresentException.java    
> 2009-08-21 00:43:31.000000000 -0700
> +++ 
> new/src/share/classes/java/lang/EnumConstantNotPresentException.java    
> 2009-08-21 00:43:30.000000000 -0700
> @@ -28,8 +28,12 @@
> /**
>  * Thrown when an application tries to access an enum constant by name
>  * and the enum type contains no constant with the specified name.
> + * This exception can be thrown by the {@linkplain
> + * java.lang.reflect.AnnotatedElement API used to read annotations
> + * reflectively}.
>  *
>  * @author  Josh Bloch
> + * @see     java.lang.reflect.AnnotatedElement
>  * @since   1.5
>  */
> public class EnumConstantNotPresentException extends RuntimeException {
> --- old/src/share/classes/java/lang/TypeNotPresentException.java    
> 2009-08-21 00:43:32.000000000 -0700
> +++ new/src/share/classes/java/lang/TypeNotPresentException.java    
> 2009-08-21 00:43:31.000000000 -0700
> @@ -35,8 +35,12 @@
>  * <p>Note that this exception may be used when undefined type variables
>  * are accessed as well as when types (e.g., classes, interfaces or
>  * annotation types) are loaded.
> + * In particular, this exception can be thrown by the {@linkplain
> + * java.lang.reflect.AnnotatedElement API used to read annotations
> + * reflectively}.
>  *
>  * @author  Josh Bloch
> + * @see     java.lang.reflect.AnnotatedElement
>  * @since 1.5
>  */
> public class TypeNotPresentException extends RuntimeException {
> --- 
> old/src/share/classes/java/lang/annotation/AnnotationFormatError.java    
> 2009-08-21 00:43:32.000000000 -0700
> +++ 
> new/src/share/classes/java/lang/annotation/AnnotationFormatError.java    
> 2009-08-21 00:43:32.000000000 -0700
> @@ -28,8 +28,12 @@
> /**
>  * Thrown when the annotation parser attempts to read an annotation
>  * from a class file and determines that the annotation is malformed.
> + * This error can be thrown by the {@linkplain
> + * java.lang.reflect.AnnotatedElement API used to read annotations
> + * reflectively}.
>  *
>  * @author  Josh Bloch
> + * @see     java.lang.reflect.AnnotatedElement
>  * @since   1.5
>  */
> public class AnnotationFormatError extends Error {
> --- 
> old/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java    
> 2009-08-21 00:43:33.000000000 -0700
> +++ 
> new/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java    
> 2009-08-21 00:43:33.000000000 -0700
> @@ -30,8 +30,12 @@
>  * Thrown to indicate that a program has attempted to access an 
> element of
>  * an annotation whose type has changed after the annotation was compiled
>  * (or serialized).
> + * This exception can be thrown by the {@linkplain
> + * java.lang.reflect.AnnotatedElement API used to read annotations
> + * reflectively}.
>  *
>  * @author  Josh Bloch
> + * @see     java.lang.reflect.AnnotatedElement
>  * @since 1.5
>  */
> public class AnnotationTypeMismatchException extends RuntimeException {
> --- 
> old/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java    
> 2009-08-21 00:43:34.000000000 -0700
> +++ 
> new/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java    
> 2009-08-21 00:43:33.000000000 -0700
> @@ -30,8 +30,12 @@
>  * an annotation type that was added to the annotation type definition 
> after
>  * the annotation was compiled (or serialized).  This exception will 
> not be
>  * thrown if the new element has a default value.
> + * This exception can be thrown by the {@linkplain
> + * java.lang.reflect.AnnotatedElement API used to read annotations
> + * reflectively}.
>  *
>  * @author  Josh Bloch
> + * @see     java.lang.reflect.AnnotatedElement
>  * @since 1.5
>  */
> public class IncompleteAnnotationException extends RuntimeException {
> --- old/src/share/classes/java/lang/reflect/AnnotatedElement.java    
> 2009-08-21 00:43:34.000000000 -0700
> +++ new/src/share/classes/java/lang/reflect/AnnotatedElement.java    
> 2009-08-21 00:43:34.000000000 -0700
> @@ -50,6 +50,11 @@
>  * java.lang.annotation.AnnotationTypeMismatchException} or an
>  * {@link java.lang.annotation.IncompleteAnnotationException}.
>  *
> + * @see java.lang.EnumConstantNotPresentException
> + * @see java.lang.TypeNotPresentException
> + * @see java.lang.annotation.AnnotationFormatError
> + * @see java.lang.annotation.AnnotationTypeMismatchException
> + * @see java.lang.annotation.IncompleteAnnotationException
>  * @since 1.5
>  * @author Josh Bloch
>  */


From gnu_andrew at member.fsf.org  Fri Aug 21 16:36:41 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 21 Aug 2009 17:36:41 +0100
Subject: Core review request for 6378701 "(enum) Unclear purpose of 
	EnumConstantNotPresentException "
In-Reply-To: <4A8ECCDE.9030007@sun.com>
References: <4A8ECB84.4010105@sun.com> <4A8ECCDE.9030007@sun.com>
Message-ID: <17c6771e0908210936u6da0fa26x85f31ccbd5fe176a@mail.gmail.com>

2009/8/21 Lance J. Andersen <Lance.Andersen at sun.com>:
> Hi Joe,
>
> The changes are fine and make things clearer.
>
> Regards
> Lance
>
> Joseph D. Darcy wrote:
>>
>> Hello.
>>
>> Please review the patch below is clarify the use of certain exception
>> types to address bug 6378701 "(enum) Unclear purpose of
>> EnumConstantNotPresentException." ?Five exceptions/errors can be thrown by
>> the methods of the AnnotatedElement interface; those methods are used to
>> retrieve annotations reflectively. ?I've added cross references between the
>> AnnotatedElement intefaces and the throwables it may throw.
>>
>> -Joe
>>
>> --- old/src/share/classes/java/lang/EnumConstantNotPresentException.java
>> ?2009-08-21 00:43:31.000000000 -0700
>> +++ new/src/share/classes/java/lang/EnumConstantNotPresentException.java
>> ?2009-08-21 00:43:30.000000000 -0700
>> @@ -28,8 +28,12 @@
>> /**
>> ?* Thrown when an application tries to access an enum constant by name
>> ?* and the enum type contains no constant with the specified name.
>> + * This exception can be thrown by the {@linkplain
>> + * java.lang.reflect.AnnotatedElement API used to read annotations
>> + * reflectively}.
>> ?*
>> ?* @author ?Josh Bloch
>> + * @see ? ? java.lang.reflect.AnnotatedElement
>> ?* @since ? 1.5
>> ?*/
>> public class EnumConstantNotPresentException extends RuntimeException {
>> --- old/src/share/classes/java/lang/TypeNotPresentException.java
>> ?2009-08-21 00:43:32.000000000 -0700
>> +++ new/src/share/classes/java/lang/TypeNotPresentException.java
>> ?2009-08-21 00:43:31.000000000 -0700
>> @@ -35,8 +35,12 @@
>> ?* <p>Note that this exception may be used when undefined type variables
>> ?* are accessed as well as when types (e.g., classes, interfaces or
>> ?* annotation types) are loaded.
>> + * In particular, this exception can be thrown by the {@linkplain
>> + * java.lang.reflect.AnnotatedElement API used to read annotations
>> + * reflectively}.
>> ?*
>> ?* @author ?Josh Bloch
>> + * @see ? ? java.lang.reflect.AnnotatedElement
>> ?* @since 1.5
>> ?*/
>> public class TypeNotPresentException extends RuntimeException {
>> --- old/src/share/classes/java/lang/annotation/AnnotationFormatError.java
>> ? ?2009-08-21 00:43:32.000000000 -0700
>> +++ new/src/share/classes/java/lang/annotation/AnnotationFormatError.java
>> ? ?2009-08-21 00:43:32.000000000 -0700
>> @@ -28,8 +28,12 @@
>> /**
>> ?* Thrown when the annotation parser attempts to read an annotation
>> ?* from a class file and determines that the annotation is malformed.
>> + * This error can be thrown by the {@linkplain
>> + * java.lang.reflect.AnnotatedElement API used to read annotations
>> + * reflectively}.
>> ?*
>> ?* @author ?Josh Bloch
>> + * @see ? ? java.lang.reflect.AnnotatedElement
>> ?* @since ? 1.5
>> ?*/
>> public class AnnotationFormatError extends Error {
>> ---
>> old/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
>> ? ?2009-08-21 00:43:33.000000000 -0700
>> +++
>> new/src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
>> ? ?2009-08-21 00:43:33.000000000 -0700
>> @@ -30,8 +30,12 @@
>> ?* Thrown to indicate that a program has attempted to access an element of
>> ?* an annotation whose type has changed after the annotation was compiled
>> ?* (or serialized).
>> + * This exception can be thrown by the {@linkplain
>> + * java.lang.reflect.AnnotatedElement API used to read annotations
>> + * reflectively}.
>> ?*
>> ?* @author ?Josh Bloch
>> + * @see ? ? java.lang.reflect.AnnotatedElement
>> ?* @since 1.5
>> ?*/
>> public class AnnotationTypeMismatchException extends RuntimeException {
>> ---
>> old/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
>> ? ?2009-08-21 00:43:34.000000000 -0700
>> +++
>> new/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
>> ? ?2009-08-21 00:43:33.000000000 -0700
>> @@ -30,8 +30,12 @@
>> ?* an annotation type that was added to the annotation type definition
>> after
>> ?* the annotation was compiled (or serialized). ?This exception will not
>> be
>> ?* thrown if the new element has a default value.
>> + * This exception can be thrown by the {@linkplain
>> + * java.lang.reflect.AnnotatedElement API used to read annotations
>> + * reflectively}.
>> ?*
>> ?* @author ?Josh Bloch
>> + * @see ? ? java.lang.reflect.AnnotatedElement
>> ?* @since 1.5
>> ?*/
>> public class IncompleteAnnotationException extends RuntimeException {
>> --- old/src/share/classes/java/lang/reflect/AnnotatedElement.java
>> ?2009-08-21 00:43:34.000000000 -0700
>> +++ new/src/share/classes/java/lang/reflect/AnnotatedElement.java
>> ?2009-08-21 00:43:34.000000000 -0700
>> @@ -50,6 +50,11 @@
>> ?* java.lang.annotation.AnnotationTypeMismatchException} or an
>> ?* {@link java.lang.annotation.IncompleteAnnotationException}.
>> ?*
>> + * @see java.lang.EnumConstantNotPresentException
>> + * @see java.lang.TypeNotPresentException
>> + * @see java.lang.annotation.AnnotationFormatError
>> + * @see java.lang.annotation.AnnotationTypeMismatchException
>> + * @see java.lang.annotation.IncompleteAnnotationException
>> ?* @since 1.5
>> ?* @author Josh Bloch
>> ?*/
>


Likewise; makes things clearer for me.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Alan.Bateman at Sun.COM  Fri Aug 21 16:49:33 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 21 Aug 2009 17:49:33 +0100
Subject: Core review request for 6378701
	"(enum) Unclear purpose of EnumConstantNotPresentException "
In-Reply-To: <4A8ECB84.4010105@sun.com>
References: <4A8ECB84.4010105@sun.com>
Message-ID: <4A8ED01D.4080905@sun.com>

Joseph D. Darcy wrote:
> Hello.
>
> Please review the patch below is clarify the use of certain exception 
> types to address bug 6378701 "(enum) Unclear purpose of 
> EnumConstantNotPresentException."  Five exceptions/errors can be 
> thrown by the methods of the AnnotatedElement interface; those methods 
> are used to retrieve annotations reflectively.  I've added cross 
> references between the AnnotatedElement intefaces and the throwables 
> it may throw.
>
> -Joe
Looks okay to me (although maybe you don't need two links to 
j.l.reflect.AnnotatedElement from each of the exceptions?).

-Alan.



From Xueming.Shen at Sun.COM  Fri Aug 21 18:09:21 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Fri, 21 Aug 2009 11:09:21 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
Message-ID: <4A8EE2D1.2080006@sun.com>

Martin, webrev has been updated to

(1)use unidiff (and the correct order of src and target)
(2)put those diffs into a patches dir
(3)remove the minigzip.c from the ws (this one is not included in the 
file_c list...)

http://cr.openjdk.java.net/~sherman/zlib123/webrev

Thanks
Sherman

Martin Buchholz wrote:
> I like very much that you are saving local changes in the form of patches
> (I've been advocating this style of modification of upstream sources
> for a while now), but...
> - please generate your patches in "unidiff" form (diff -u)
> - the extension ".patch" is, I think, preferable to ".diff"
>   (or put them into a "patches" directory, as debian does)
>
> I don't think we need minigzip.c - it's a kind of "demo" program.
>
> Do we really need to rename files?  That's quite confusing.
>
> The pervasive change of
> uLong => unsigned long
> seems unnecessary - just get the typedef of uLong correct.
>
> Martin
>
> On Thu, Aug 20, 2009 at 19:49, Xueming Shen <Xueming.Shen at sun.com 
> <mailto:Xueming.Shen at sun.com>> wrote:
>
>     Here is the latest webrev for updating the zlib from the aged
>     1.1.3 to the latest version 1.2.3
>
>
>     http://cr.openjdk.java.net/~sherman/zlib123/webrev
>     <http://cr.openjdk.java.net/%7Esherman/zlib123/webrev>
>
>     Alan, Kumar Martin, thanks for the comments, while I'm continuing
>     running more tests:-) here are the
>     reply to your comments/questions.
>
>     (1) The ZLIB_VERSION has been moved into common/Defs.gmk.
>     (2) The copyright you quoted in the original copyright of
>     zlib1.1.3 (it was there is jdk6 and earlier before we opensourced
>     the jdk7).
>     (3) Yes, I have run the regression tests in tools/pack200 and
>     those in launcher, as well as other jar, zip related.
>     (4) I just jprt-ed a full forest/control build including
>     everything, it finished without any problem
>     (5) So far the "large zip support" still holds on all platforms I
>     tested on (Solaris sparc 32-bit/x86 32-bit, Linux x64 and
>     Windows32-bit.
>     (6)I would still prefer to get the source code from zlib.org
>     <http://zlib.org>. I took a quick scan at the ubuntu diff, don't
>     see the value of replacing the one
>       we have.
>     (7) The java port change log has been moved to
>     http://cr.openjdk.java.net/~sherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html
>     <http://cr.openjdk.java.net/%7Esherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html>
>
>     Sherman
>
>
>
>
>
>
>



From jonathan.gibbons at sun.com  Fri Aug 21 18:35:50 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 21 Aug 2009 18:35:50 +0000
Subject: hg: jdk7/tl/langtools: 6873849: suppress notes generated by javac
Message-ID: <20090821183556.49CD41230E@hg.openjdk.java.net>

Changeset: 61c1f735df67
Author:    jjg
Date:      2009-08-21 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/61c1f735df67

6873849: suppress notes generated by javac
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/T6873849.java



From gnu_andrew at member.fsf.org  Fri Aug 21 19:35:24 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 21 Aug 2009 20:35:24 +0100
Subject: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate 
	COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.
In-Reply-To: <1250840220.3908.9.camel@springer.wildebeest.org>
References: <20090820224000.6B168E12@eggemoggin.niobe.net>
	<1250840220.3908.9.camel@springer.wildebeest.org>
Message-ID: <17c6771e0908211235p5b275de1hb2a7c882a24a839f@mail.gmail.com>

2009/8/21 Mark Wielaard <mark at klomp.org>:
> Hi Mark,
>
> On Thu, 2009-08-20 at 15:40 -0700, Mark Reinhold wrote:
>> This change was integrated prematurely. ?I've rolled it back in the
>> jdk7/tl/jdk repository.
>
> If at all possible, please don't do this. It plays havoc with already
> checked out repos and/or automatic clones/backups. You force people to
> recreate their local repos if you purge a commit that was already public
> like this. Could you use a normal hg backout instead in the future? That
> will make sure the integrity of the repo isn't compromised.
>

It would be much cleaner to just do a commit reversing the patch (mjw,
is that what you mean by a backout or something else?)

I really don't like the idea of sanitising the repos to remove all
mistakes and there's also no guarantee everyone will do this and push
it in every forest.

> Thanks,
>
> Mark
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Joe.Darcy at Sun.COM  Fri Aug 21 20:52:15 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 21 Aug 2009 13:52:15 -0700
Subject: Core review request for 6378701
	"(enum) Unclear purpose of EnumConstantNotPresentException "
In-Reply-To: <4A8ED01D.4080905@sun.com>
References: <4A8ECB84.4010105@sun.com> <4A8ED01D.4080905@sun.com>
Message-ID: <4A8F08FF.9090501@sun.com>

Alan Bateman wrote:
> Joseph D. Darcy wrote:
>> Hello.
>>
>> Please review the patch below is clarify the use of certain exception 
>> types to address bug 6378701 "(enum) Unclear purpose of 
>> EnumConstantNotPresentException."  Five exceptions/errors can be 
>> thrown by the methods of the AnnotatedElement interface; those 
>> methods are used to retrieve annotations reflectively.  I've added 
>> cross references between the AnnotatedElement intefaces and the 
>> throwables it may throw.
>>
>> -Joe
> Looks okay to me (although maybe you don't need two links to 
> j.l.reflect.AnnotatedElement from each of the exceptions?).
>

I think calling out the connection in the "See also" area makes things 
clearer since the "See also" section stands apart from the text.

Thanks,

-Joe


From jonathan.gibbons at sun.com  Fri Aug 21 22:07:47 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 21 Aug 2009 22:07:47 +0000
Subject: hg: jdk7/tl/langtools: 6873845: refine access to symbol file
Message-ID: <20090821220753.BB65E12353@hg.openjdk.java.net>

Changeset: d9febdd5ae21
Author:    jjg
Date:      2009-08-21 14:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d9febdd5ae21

6873845: refine access to symbol file
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/main/JavacOption.java
! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/T6873845.java



From jeremymanson at google.com  Sat Aug 22 01:12:09 2009
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 21 Aug 2009 18:12:09 -0700
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <4A8E59DA.2000205@sun.com>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
	<4A8DDD24.4090400@sun.com> <4A8E5783.5000606@joda.org>
	<4A8E59DA.2000205@sun.com>
Message-ID: <bf03e3fa0908211812p5255d7b9m4786b75e629ecf5c@mail.gmail.com>

Even with just a bytecode execution engine, you would need pretty much
all of the Throwables in java.lang - NullPointerException,
OutOfMemoryError, ArithmeticException, VerifyError, ClassFormatError,
IndexOutOfBoundsException and the like.

The flip side of "what classes does the VM need" is "what VM support
do the classes need".  You can't actually implement a compliant
version of Java without special VM support for a bunch of the classes.
 You would have to know what all of those requirements were, too.

Jeremy

On Fri, Aug 21, 2009 at 1:24 AM, David Holmes - Sun
Microsystems<David.Holmes at sun.com> wrote:
> Stephen,
>
> Stephen Colebourne said the following on 08/21/09 18:14:
>>
>> If you wanted to code from scratch a JVM, but not include the rest of the
>> Java SE platform (such as the .class files), what would you need to include?
>> Is Object.class mandatory for a pure JVM? Anything else?
>>
>> The answers given imply that the JVM is not an isolated well defined
>> component. Yet that argues against being able to write a new programming
>> language for the JVM that has no integration whatsoever with the Java
>> language and just emits 'pure bytecode' for a 'pure JVM'.
>
> I think you would need to separate the bytecode-engine part of the JVM from
> the "Java runtime platform" part. The bytecode engine has few dependencies
> on classes, perhaps not even Object, while the runtime environment has many
> dependencies.
>
> David Holmes
>
>> I, like Carsten, find it odd if this isn't well-defined.
>>
>> Stephen
>>
>> David Holmes - Sun Microsystems wrote:
>>>
>>> As Martin stated what you are looking for is not part of the JVMS nor the
>>> JLS, but the platform specification, which is essentially the entire set of
>>> Java API's as found for example here:
>>>
>>> http://java.sun.com/javase/6/docs/index.html
>>>
>>> But the implementation of those classes will then have dependencies on
>>> other implementation specific classes, so I'm not sure that you will be able
>>> to establish a transitive closure of required classes that is independent of
>>> the JVM in question.
>>>
>>> If you were thinking about this from a basic language perspective - eg we
>>> must have Object, and we must have Class, and array implies Serializable
>>> etc, then there is a core set of classes that form the transitive closure of
>>> the JVM bootstrap process. If you are interested in that then
>>> -XX:+TraceClassLoading (might need a debug VM) will give you the set used by
>>> a particular VM. But again this list is dependent on how those classes are
>>> implemented themselves, so the list is JVM dependent.
>>>
>>> HTH
>>>
>>> David Holmes
>>>
>>> Martin Buchholz said the following on 08/21/09 03:32:
>>>>
>>>> The set of all public APIs that must be part of the java se platform
>>>> are tested by the platform tck, in particular by the "signature test",
>>>> and you can get the sources for that test (for research only)
>>>> and from that it should be possible (with work) to get a list of
>>>> all required classes. ?But that's a very large list, so is probably not
>>>> what you want. ?In practice, the subset of rt.jar of public classes
>>>> matching java.* or javax.* is a pretty good approximation.
>>>>
>>>> Martin
>>>>
>>>> On Thu, Aug 20, 2009 at 08:26, Carsten Otto
>>>> <otto at informatik.rwth-aachen.de <mailto:otto at informatik.rwth-aachen.de>>
>>>> wrote:
>>>>
>>>> ? ?Hello,
>>>>
>>>> ? ?I am working on automated termination analysis of Java Bytecode and I
>>>> am
>>>> ? ?missing an important bit of information in the Java Virtual Machine
>>>> ? ?Specification (JVMS). I'd be happy to get some help from you!
>>>>
>>>> ? ?Every JVM needs to provide certain classes including code for their
>>>> ? ?native
>>>> ? ?methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>>>> ? ?(because
>>>> ? ?every array implements it). The list of such classes can easily be
>>>> ? ?extended, but I have huge problems finding a lower bound to keep
>>>> ? ?this list
>>>> ? ?as small[1] as allowed according to the JVMS.
>>>>
>>>> ? ?Is there some part of the specification that states which classes
>>>> ? ?need to
>>>> ? ?be provided? I can only see references to the API (e.g. "reflective
>>>> ? ?APIs"),
>>>> ? ?but no clear definition of the classes that need to exist. In the
>>>> ? ?current
>>>> ? ?draft for JVMS 3rd edition, the necessity to include
>>>> ? ?java.io.Serializable
>>>> ? ?is not even part of the JVMS, this is only visible by looking at the
>>>> ? ?definition of arrays in the Java Language Specification (JLS).
>>>>
>>>> ? ?Some hints in this direction are also appreciated. So far I can only
>>>> ? ?guess,
>>>> ? ?that sun.awt.* is not part of the language defined in the JVMS - but
>>>> who
>>>> ? ?knows?
>>>>
>>>> ? ?[1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>>>> ? ?does not
>>>> ? ?work.
>>>>
>>>> ? ?Thanks a lot,
>>>> ? ?--
>>>> ? ?Carsten Otto ? ? ? ? ? otto at informatik.rwth-aachen.de
>>>> ? ?<mailto:otto at informatik.rwth-aachen.de>
>>>> ? ?LuFG Informatik 2 ? ? ?http://verify.rwth-aachen.de/otto/
>>>> ? ?RWTH Aachen ? ? ? ? ? ?phone: +49 241 80-21211
>>>>
>>>> ? ?-----BEGIN PGP SIGNATURE-----
>>>> ? ?Version: GnuPG v1.4.9 (GNU/Linux)
>>>>
>>>> ? ?iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>>>> ? ?4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>>>> ? ?=Brg8
>>>> ? ?-----END PGP SIGNATURE-----
>>>>
>>>>
>>>
>


From scolebourne at joda.org  Sat Aug 22 09:43:12 2009
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 22 Aug 2009 10:43:12 +0100
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <bf03e3fa0908211812p5255d7b9m4786b75e629ecf5c@mail.gmail.com>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>	
	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>	
	<4A8DDD24.4090400@sun.com> <4A8E5783.5000606@joda.org>	
	<4A8E59DA.2000205@sun.com>
	<bf03e3fa0908211812p5255d7b9m4786b75e629ecf5c@mail.gmail.com>
Message-ID: <4A8FBDB0.50003@joda.org>

Interesting. I guess I'd naively assumed that the 'bytecode engine' 
would have some mechansim of "registering" certain classes to act as the 
key classes it requires. (My hypothetical setup here is the tuned 
hotspot engine but no java.* class files whatsoever)

What we've learnt however is that its going to be very hard to create a 
lightweight platform built on the hotspot JVM. Anyone trying to do this 
is going to need to ship a fair chunk of the Java SE class libraries.

Splitting the Java SE platform like that would also break the 
JCP/platform rules, again making it less likely. Thus, it seems we will 
always be shipping the entire Java SE platform even for a new language 
that essentially wants to use none of it.

I guess that modular Java helps a little bit here in minimising the 
required class file list?

Stephen


Jeremy Manson wrote:
> Even with just a bytecode execution engine, you would need pretty much
> all of the Throwables in java.lang - NullPointerException,
> OutOfMemoryError, ArithmeticException, VerifyError, ClassFormatError,
> IndexOutOfBoundsException and the like.
> 
> The flip side of "what classes does the VM need" is "what VM support
> do the classes need".  You can't actually implement a compliant
> version of Java without special VM support for a bunch of the classes.
>  You would have to know what all of those requirements were, too.
> 
> Jeremy
> 
> On Fri, Aug 21, 2009 at 1:24 AM, David Holmes - Sun
> Microsystems<David.Holmes at sun.com> wrote:
>> Stephen,
>>
>> Stephen Colebourne said the following on 08/21/09 18:14:
>>> If you wanted to code from scratch a JVM, but not include the rest of the
>>> Java SE platform (such as the .class files), what would you need to include?
>>> Is Object.class mandatory for a pure JVM? Anything else?
>>>
>>> The answers given imply that the JVM is not an isolated well defined
>>> component. Yet that argues against being able to write a new programming
>>> language for the JVM that has no integration whatsoever with the Java
>>> language and just emits 'pure bytecode' for a 'pure JVM'.
>> I think you would need to separate the bytecode-engine part of the JVM from
>> the "Java runtime platform" part. The bytecode engine has few dependencies
>> on classes, perhaps not even Object, while the runtime environment has many
>> dependencies.
>>
>> David Holmes
>>
>>> I, like Carsten, find it odd if this isn't well-defined.
>>>
>>> Stephen
>>>
>>> David Holmes - Sun Microsystems wrote:
>>>> As Martin stated what you are looking for is not part of the JVMS nor the
>>>> JLS, but the platform specification, which is essentially the entire set of
>>>> Java API's as found for example here:
>>>>
>>>> http://java.sun.com/javase/6/docs/index.html
>>>>
>>>> But the implementation of those classes will then have dependencies on
>>>> other implementation specific classes, so I'm not sure that you will be able
>>>> to establish a transitive closure of required classes that is independent of
>>>> the JVM in question.
>>>>
>>>> If you were thinking about this from a basic language perspective - eg we
>>>> must have Object, and we must have Class, and array implies Serializable
>>>> etc, then there is a core set of classes that form the transitive closure of
>>>> the JVM bootstrap process. If you are interested in that then
>>>> -XX:+TraceClassLoading (might need a debug VM) will give you the set used by
>>>> a particular VM. But again this list is dependent on how those classes are
>>>> implemented themselves, so the list is JVM dependent.
>>>>
>>>> HTH
>>>>
>>>> David Holmes
>>>>
>>>> Martin Buchholz said the following on 08/21/09 03:32:
>>>>> The set of all public APIs that must be part of the java se platform
>>>>> are tested by the platform tck, in particular by the "signature test",
>>>>> and you can get the sources for that test (for research only)
>>>>> and from that it should be possible (with work) to get a list of
>>>>> all required classes.  But that's a very large list, so is probably not
>>>>> what you want.  In practice, the subset of rt.jar of public classes
>>>>> matching java.* or javax.* is a pretty good approximation.
>>>>>
>>>>> Martin
>>>>>
>>>>> On Thu, Aug 20, 2009 at 08:26, Carsten Otto
>>>>> <otto at informatik.rwth-aachen.de <mailto:otto at informatik.rwth-aachen.de>>
>>>>> wrote:
>>>>>
>>>>>    Hello,
>>>>>
>>>>>    I am working on automated termination analysis of Java Bytecode and I
>>>>> am
>>>>>    missing an important bit of information in the Java Virtual Machine
>>>>>    Specification (JVMS). I'd be happy to get some help from you!
>>>>>
>>>>>    Every JVM needs to provide certain classes including code for their
>>>>>    native
>>>>>    methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>>>>>    (because
>>>>>    every array implements it). The list of such classes can easily be
>>>>>    extended, but I have huge problems finding a lower bound to keep
>>>>>    this list
>>>>>    as small[1] as allowed according to the JVMS.
>>>>>
>>>>>    Is there some part of the specification that states which classes
>>>>>    need to
>>>>>    be provided? I can only see references to the API (e.g. "reflective
>>>>>    APIs"),
>>>>>    but no clear definition of the classes that need to exist. In the
>>>>>    current
>>>>>    draft for JVMS 3rd edition, the necessity to include
>>>>>    java.io.Serializable
>>>>>    is not even part of the JVMS, this is only visible by looking at the
>>>>>    definition of arrays in the Java Language Specification (JLS).
>>>>>
>>>>>    Some hints in this direction are also appreciated. So far I can only
>>>>>    guess,
>>>>>    that sun.awt.* is not part of the language defined in the JVMS - but
>>>>> who
>>>>>    knows?
>>>>>
>>>>>    [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>>>>>    does not
>>>>>    work.
>>>>>
>>>>>    Thanks a lot,
>>>>>    --
>>>>>    Carsten Otto           otto at informatik.rwth-aachen.de
>>>>>    <mailto:otto at informatik.rwth-aachen.de>
>>>>>    LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
>>>>>    RWTH Aachen            phone: +49 241 80-21211
>>>>>
>>>>>    -----BEGIN PGP SIGNATURE-----
>>>>>    Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>
>>>>>    iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>>>>>    4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>>>>>    =Brg8
>>>>>    -----END PGP SIGNATURE-----
>>>>>
>>>>>
> 


From jeremymanson at google.com  Sat Aug 22 16:54:03 2009
From: jeremymanson at google.com (Jeremy Manson)
Date: Sat, 22 Aug 2009 09:54:03 -0700
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <4A8FBDB0.50003@joda.org>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
	<4A8DDD24.4090400@sun.com> <4A8E5783.5000606@joda.org>
	<4A8E59DA.2000205@sun.com>
	<bf03e3fa0908211812p5255d7b9m4786b75e629ecf5c@mail.gmail.com>
	<4A8FBDB0.50003@joda.org>
Message-ID: <bf03e3fa0908220954n78141f76sfde15b5d01108ca4@mail.gmail.com>

To be fair, it isn't really all that much compared to the size of the
platform.  You can grep through the sources to find out - it is mostly
just the stuff in java.lang.* and java.lang.*.*, with some additional
bits and bobs.

I suspect you can actually do this, too - isn't it fine as long as you
don't call it Java?

Jeremy

On Sat, Aug 22, 2009 at 2:43 AM, Stephen Colebourne<scolebourne at joda.org> wrote:
> Interesting. I guess I'd naively assumed that the 'bytecode engine' would
> have some mechansim of "registering" certain classes to act as the key
> classes it requires. (My hypothetical setup here is the tuned hotspot engine
> but no java.* class files whatsoever)
>
> What we've learnt however is that its going to be very hard to create a
> lightweight platform built on the hotspot JVM. Anyone trying to do this is
> going to need to ship a fair chunk of the Java SE class libraries.
>
> Splitting the Java SE platform like that would also break the JCP/platform
> rules, again making it less likely. Thus, it seems we will always be
> shipping the entire Java SE platform even for a new language that
> essentially wants to use none of it.
>
> I guess that modular Java helps a little bit here in minimising the required
> class file list?
>
> Stephen
>
>
> Jeremy Manson wrote:
>>
>> Even with just a bytecode execution engine, you would need pretty much
>> all of the Throwables in java.lang - NullPointerException,
>> OutOfMemoryError, ArithmeticException, VerifyError, ClassFormatError,
>> IndexOutOfBoundsException and the like.
>>
>> The flip side of "what classes does the VM need" is "what VM support
>> do the classes need". ?You can't actually implement a compliant
>> version of Java without special VM support for a bunch of the classes.
>> ?You would have to know what all of those requirements were, too.
>>
>> Jeremy
>>
>> On Fri, Aug 21, 2009 at 1:24 AM, David Holmes - Sun
>> Microsystems<David.Holmes at sun.com> wrote:
>>>
>>> Stephen,
>>>
>>> Stephen Colebourne said the following on 08/21/09 18:14:
>>>>
>>>> If you wanted to code from scratch a JVM, but not include the rest of
>>>> the
>>>> Java SE platform (such as the .class files), what would you need to
>>>> include?
>>>> Is Object.class mandatory for a pure JVM? Anything else?
>>>>
>>>> The answers given imply that the JVM is not an isolated well defined
>>>> component. Yet that argues against being able to write a new programming
>>>> language for the JVM that has no integration whatsoever with the Java
>>>> language and just emits 'pure bytecode' for a 'pure JVM'.
>>>
>>> I think you would need to separate the bytecode-engine part of the JVM
>>> from
>>> the "Java runtime platform" part. The bytecode engine has few
>>> dependencies
>>> on classes, perhaps not even Object, while the runtime environment has
>>> many
>>> dependencies.
>>>
>>> David Holmes
>>>
>>>> I, like Carsten, find it odd if this isn't well-defined.
>>>>
>>>> Stephen
>>>>
>>>> David Holmes - Sun Microsystems wrote:
>>>>>
>>>>> As Martin stated what you are looking for is not part of the JVMS nor
>>>>> the
>>>>> JLS, but the platform specification, which is essentially the entire
>>>>> set of
>>>>> Java API's as found for example here:
>>>>>
>>>>> http://java.sun.com/javase/6/docs/index.html
>>>>>
>>>>> But the implementation of those classes will then have dependencies on
>>>>> other implementation specific classes, so I'm not sure that you will be
>>>>> able
>>>>> to establish a transitive closure of required classes that is
>>>>> independent of
>>>>> the JVM in question.
>>>>>
>>>>> If you were thinking about this from a basic language perspective - eg
>>>>> we
>>>>> must have Object, and we must have Class, and array implies
>>>>> Serializable
>>>>> etc, then there is a core set of classes that form the transitive
>>>>> closure of
>>>>> the JVM bootstrap process. If you are interested in that then
>>>>> -XX:+TraceClassLoading (might need a debug VM) will give you the set
>>>>> used by
>>>>> a particular VM. But again this list is dependent on how those classes
>>>>> are
>>>>> implemented themselves, so the list is JVM dependent.
>>>>>
>>>>> HTH
>>>>>
>>>>> David Holmes
>>>>>
>>>>> Martin Buchholz said the following on 08/21/09 03:32:
>>>>>>
>>>>>> The set of all public APIs that must be part of the java se platform
>>>>>> are tested by the platform tck, in particular by the "signature test",
>>>>>> and you can get the sources for that test (for research only)
>>>>>> and from that it should be possible (with work) to get a list of
>>>>>> all required classes. ?But that's a very large list, so is probably
>>>>>> not
>>>>>> what you want. ?In practice, the subset of rt.jar of public classes
>>>>>> matching java.* or javax.* is a pretty good approximation.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> On Thu, Aug 20, 2009 at 08:26, Carsten Otto
>>>>>> <otto at informatik.rwth-aachen.de
>>>>>> <mailto:otto at informatik.rwth-aachen.de>>
>>>>>> wrote:
>>>>>>
>>>>>> ? Hello,
>>>>>>
>>>>>> ? I am working on automated termination analysis of Java Bytecode and
>>>>>> I
>>>>>> am
>>>>>> ? missing an important bit of information in the Java Virtual Machine
>>>>>> ? Specification (JVMS). I'd be happy to get some help from you!
>>>>>>
>>>>>> ? Every JVM needs to provide certain classes including code for their
>>>>>> ? native
>>>>>> ? methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>>>>>> ? (because
>>>>>> ? every array implements it). The list of such classes can easily be
>>>>>> ? extended, but I have huge problems finding a lower bound to keep
>>>>>> ? this list
>>>>>> ? as small[1] as allowed according to the JVMS.
>>>>>>
>>>>>> ? Is there some part of the specification that states which classes
>>>>>> ? need to
>>>>>> ? be provided? I can only see references to the API (e.g. "reflective
>>>>>> ? APIs"),
>>>>>> ? but no clear definition of the classes that need to exist. In the
>>>>>> ? current
>>>>>> ? draft for JVMS 3rd edition, the necessity to include
>>>>>> ? java.io.Serializable
>>>>>> ? is not even part of the JVMS, this is only visible by looking at the
>>>>>> ? definition of arrays in the Java Language Specification (JLS).
>>>>>>
>>>>>> ? Some hints in this direction are also appreciated. So far I can only
>>>>>> ? guess,
>>>>>> ? that sun.awt.* is not part of the language defined in the JVMS - but
>>>>>> who
>>>>>> ? knows?
>>>>>>
>>>>>> ? [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>>>>>> ? does not
>>>>>> ? work.
>>>>>>
>>>>>> ? Thanks a lot,
>>>>>> ? --
>>>>>> ? Carsten Otto ? ? ? ? ? otto at informatik.rwth-aachen.de
>>>>>> ? <mailto:otto at informatik.rwth-aachen.de>
>>>>>> ? LuFG Informatik 2 ? ? ?http://verify.rwth-aachen.de/otto/
>>>>>> ? RWTH Aachen ? ? ? ? ? ?phone: +49 241 80-21211
>>>>>>
>>>>>> ? -----BEGIN PGP SIGNATURE-----
>>>>>> ? Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>
>>>>>> ? iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>>>>>> ? 4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>>>>>> ? =Brg8
>>>>>> ? -----END PGP SIGNATURE-----
>>>>>>
>>>>>>
>>
>


From joe.darcy at sun.com  Sat Aug 22 17:58:18 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Sat, 22 Aug 2009 17:58:18 +0000
Subject: hg: jdk7/tl/jdk: 6378701: (enum) Unclear purpose of
	EnumConstantNotPresentException
Message-ID: <20090822175901.9518A123A7@hg.openjdk.java.net>

Changeset: 3992a43bb0a5
Author:    darcy
Date:      2009-08-21 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3992a43bb0a5

6378701: (enum) Unclear purpose of EnumConstantNotPresentException
Reviewed-by: lancea, andrew, alanb

! src/share/classes/java/lang/EnumConstantNotPresentException.java
! src/share/classes/java/lang/TypeNotPresentException.java
! src/share/classes/java/lang/annotation/AnnotationFormatError.java
! src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java



From mark at klomp.org  Sat Aug 22 20:02:18 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 22 Aug 2009 22:02:18 +0200
Subject: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate 
	COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.
In-Reply-To: <17c6771e0908211235p5b275de1hb2a7c882a24a839f@mail.gmail.com>
References: <20090820224000.6B168E12@eggemoggin.niobe.net>
	<1250840220.3908.9.camel@springer.wildebeest.org>
	<17c6771e0908211235p5b275de1hb2a7c882a24a839f@mail.gmail.com>
Message-ID: <1250971338.2627.6.camel@hermans.wildebeest.org>

Hi Andrew,

On Fri, 2009-08-21 at 20:35 +0100, Andrew John Hughes wrote:
> 2009/8/21 Mark Wielaard <mark at klomp.org>:
> > On Thu, 2009-08-20 at 15:40 -0700, Mark Reinhold wrote:
> >> This change was integrated prematurely.  I've rolled it back in the
> >> jdk7/tl/jdk repository.
> >
> > If at all possible, please don't do this. It plays havoc with already
> > checked out repos and/or automatic clones/backups. You force people to
> > recreate their local repos if you purge a commit that was already public
> > like this. Could you use a normal hg backout instead in the future? That
> > will make sure the integrity of the repo isn't compromised.
> >
> It would be much cleaner to just do a commit reversing the patch (mjw,
> is that what you mean by a backout or something else?)

Yes. "hg backout" creates a reverse changeset that "cancels out" an
earlier commit (but does so in a way that keeps the integrity of
repository, plus the whole history). See also: hg backout --help

> I really don't like the idea of sanitising the repos to remove all
> mistakes and there's also no guarantee everyone will do this and push
> it in every forest.
> 
> > Thanks,
> >
> > Mark



From scolebourne at joda.org  Sat Aug 22 22:09:39 2009
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 22 Aug 2009 23:09:39 +0100
Subject: Currency updates in JDK 7
Message-ID: <4A906CA3.2050307@joda.org>

I've been reviewing the Javadoc for the JDK 7 Currency class changes.
http://download.java.net/jdk7/docs/api/java/util/Currency.html

The updates appear to allow users the ability to override the built in 
currency data, as indicated in the class javadoc:

"Users can supersede the Java runtime currency data by creating a 
properties file named <JAVA_HOME>/lib/currency.properties. The contents 
of the properties file are key/value pairs of the ISO 3166 country codes 
and the ISO 4217 currency data respectively. The value part consists of 
three ISO 4217 values of a currency, i.e., an alphabetic code, a numeric 
code, and a minor unit. Those three ISO 4217 values are separated by 
commas. The lines which start with '#'s are considered comment lines. 
For example,

#Sample currency properties
JP=JPZ,999,0

will supersede the currency data for Japan. "

Unfortunately, not all currencies are associated with countries. Some, 
like XAG for 'silver', XDR for 'IMF drawing rights' or XXX for 'no 
currency' have no matching country. Thus, this file format is unable to 
represent user overrides to those countries.

Further, the Javadoc is unclear as to whether users can _add_ new 
currencies. An example would be if a country split, like Czech/Slovak, 
and created two currencies. Does the new format add a currency to the 
built in list if it isn't recognised?

I believe that we should also consider if Currency should implement 
Comparable, sorting alphabetically on the currency code. While there are 
many possible sort orders, having this as the default one makes a lot of 
sense.

Finally, I'd like to see a method isPsuedoCurrency() added. This would 
return a boolean indicating if the currency is 'real' or not.

Otherwise the changes pretty much complete the use cases for the class.

Stephen



From jeremymanson at google.com  Sat Aug 22 23:20:12 2009
From: jeremymanson at google.com (Jeremy Manson)
Date: Sat, 22 Aug 2009 16:20:12 -0700
Subject: Which classes need to be supplied by any JVM?
In-Reply-To: <bf03e3fa0908220954n78141f76sfde15b5d01108ca4@mail.gmail.com>
References: <20090820152632.GD8636@daedalus.informatik.rwth-aachen.de>
	<1ccfd1c10908201032r715845c6i810bc4425b57761b@mail.gmail.com>
	<4A8DDD24.4090400@sun.com> <4A8E5783.5000606@joda.org>
	<4A8E59DA.2000205@sun.com>
	<bf03e3fa0908211812p5255d7b9m4786b75e629ecf5c@mail.gmail.com>
	<4A8FBDB0.50003@joda.org>
	<bf03e3fa0908220954n78141f76sfde15b5d01108ca4@mail.gmail.com>
Message-ID: <bf03e3fa0908221620r6ddf78aalb3c663ca1b6e8979@mail.gmail.com>

That was probably a stunningly unclear reply.  Let me be a little clearer:

The list of classes you actually need is not very long.  You can grep
through the Hotspot code to figure it out.  Mostly, it consists of
things in java.lang.* and java.lang.*.*.

I'm not a lawyer, but it is my understanding that you can ship
whatever you want, as long as you abide by the GPL and don't claim
that what you are shipping is "Java".

Jeremy

On Sat, Aug 22, 2009 at 9:54 AM, Jeremy Manson<jeremymanson at google.com> wrote:
> To be fair, it isn't really all that much compared to the size of the
> platform. ?You can grep through the sources to find out - it is mostly
> just the stuff in java.lang.* and java.lang.*.*, with some additional
> bits and bobs.
>
> I suspect you can actually do this, too - isn't it fine as long as you
> don't call it Java?
>
> Jeremy
>
> On Sat, Aug 22, 2009 at 2:43 AM, Stephen Colebourne<scolebourne at joda.org> wrote:
>> Interesting. I guess I'd naively assumed that the 'bytecode engine' would
>> have some mechansim of "registering" certain classes to act as the key
>> classes it requires. (My hypothetical setup here is the tuned hotspot engine
>> but no java.* class files whatsoever)
>>
>> What we've learnt however is that its going to be very hard to create a
>> lightweight platform built on the hotspot JVM. Anyone trying to do this is
>> going to need to ship a fair chunk of the Java SE class libraries.
>>
>> Splitting the Java SE platform like that would also break the JCP/platform
>> rules, again making it less likely. Thus, it seems we will always be
>> shipping the entire Java SE platform even for a new language that
>> essentially wants to use none of it.
>>
>> I guess that modular Java helps a little bit here in minimising the required
>> class file list?
>>
>> Stephen
>>
>>
>> Jeremy Manson wrote:
>>>
>>> Even with just a bytecode execution engine, you would need pretty much
>>> all of the Throwables in java.lang - NullPointerException,
>>> OutOfMemoryError, ArithmeticException, VerifyError, ClassFormatError,
>>> IndexOutOfBoundsException and the like.
>>>
>>> The flip side of "what classes does the VM need" is "what VM support
>>> do the classes need". ?You can't actually implement a compliant
>>> version of Java without special VM support for a bunch of the classes.
>>> ?You would have to know what all of those requirements were, too.
>>>
>>> Jeremy
>>>
>>> On Fri, Aug 21, 2009 at 1:24 AM, David Holmes - Sun
>>> Microsystems<David.Holmes at sun.com> wrote:
>>>>
>>>> Stephen,
>>>>
>>>> Stephen Colebourne said the following on 08/21/09 18:14:
>>>>>
>>>>> If you wanted to code from scratch a JVM, but not include the rest of
>>>>> the
>>>>> Java SE platform (such as the .class files), what would you need to
>>>>> include?
>>>>> Is Object.class mandatory for a pure JVM? Anything else?
>>>>>
>>>>> The answers given imply that the JVM is not an isolated well defined
>>>>> component. Yet that argues against being able to write a new programming
>>>>> language for the JVM that has no integration whatsoever with the Java
>>>>> language and just emits 'pure bytecode' for a 'pure JVM'.
>>>>
>>>> I think you would need to separate the bytecode-engine part of the JVM
>>>> from
>>>> the "Java runtime platform" part. The bytecode engine has few
>>>> dependencies
>>>> on classes, perhaps not even Object, while the runtime environment has
>>>> many
>>>> dependencies.
>>>>
>>>> David Holmes
>>>>
>>>>> I, like Carsten, find it odd if this isn't well-defined.
>>>>>
>>>>> Stephen
>>>>>
>>>>> David Holmes - Sun Microsystems wrote:
>>>>>>
>>>>>> As Martin stated what you are looking for is not part of the JVMS nor
>>>>>> the
>>>>>> JLS, but the platform specification, which is essentially the entire
>>>>>> set of
>>>>>> Java API's as found for example here:
>>>>>>
>>>>>> http://java.sun.com/javase/6/docs/index.html
>>>>>>
>>>>>> But the implementation of those classes will then have dependencies on
>>>>>> other implementation specific classes, so I'm not sure that you will be
>>>>>> able
>>>>>> to establish a transitive closure of required classes that is
>>>>>> independent of
>>>>>> the JVM in question.
>>>>>>
>>>>>> If you were thinking about this from a basic language perspective - eg
>>>>>> we
>>>>>> must have Object, and we must have Class, and array implies
>>>>>> Serializable
>>>>>> etc, then there is a core set of classes that form the transitive
>>>>>> closure of
>>>>>> the JVM bootstrap process. If you are interested in that then
>>>>>> -XX:+TraceClassLoading (might need a debug VM) will give you the set
>>>>>> used by
>>>>>> a particular VM. But again this list is dependent on how those classes
>>>>>> are
>>>>>> implemented themselves, so the list is JVM dependent.
>>>>>>
>>>>>> HTH
>>>>>>
>>>>>> David Holmes
>>>>>>
>>>>>> Martin Buchholz said the following on 08/21/09 03:32:
>>>>>>>
>>>>>>> The set of all public APIs that must be part of the java se platform
>>>>>>> are tested by the platform tck, in particular by the "signature test",
>>>>>>> and you can get the sources for that test (for research only)
>>>>>>> and from that it should be possible (with work) to get a list of
>>>>>>> all required classes. ?But that's a very large list, so is probably
>>>>>>> not
>>>>>>> what you want. ?In practice, the subset of rt.jar of public classes
>>>>>>> matching java.* or javax.* is a pretty good approximation.
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On Thu, Aug 20, 2009 at 08:26, Carsten Otto
>>>>>>> <otto at informatik.rwth-aachen.de
>>>>>>> <mailto:otto at informatik.rwth-aachen.de>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> ? Hello,
>>>>>>>
>>>>>>> ? I am working on automated termination analysis of Java Bytecode and
>>>>>>> I
>>>>>>> am
>>>>>>> ? missing an important bit of information in the Java Virtual Machine
>>>>>>> ? Specification (JVMS). I'd be happy to get some help from you!
>>>>>>>
>>>>>>> ? Every JVM needs to provide certain classes including code for their
>>>>>>> ? native
>>>>>>> ? methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>>>>>>> ? (because
>>>>>>> ? every array implements it). The list of such classes can easily be
>>>>>>> ? extended, but I have huge problems finding a lower bound to keep
>>>>>>> ? this list
>>>>>>> ? as small[1] as allowed according to the JVMS.
>>>>>>>
>>>>>>> ? Is there some part of the specification that states which classes
>>>>>>> ? need to
>>>>>>> ? be provided? I can only see references to the API (e.g. "reflective
>>>>>>> ? APIs"),
>>>>>>> ? but no clear definition of the classes that need to exist. In the
>>>>>>> ? current
>>>>>>> ? draft for JVMS 3rd edition, the necessity to include
>>>>>>> ? java.io.Serializable
>>>>>>> ? is not even part of the JVMS, this is only visible by looking at the
>>>>>>> ? definition of arrays in the Java Language Specification (JLS).
>>>>>>>
>>>>>>> ? Some hints in this direction are also appreciated. So far I can only
>>>>>>> ? guess,
>>>>>>> ? that sun.awt.* is not part of the language defined in the JVMS - but
>>>>>>> who
>>>>>>> ? knows?
>>>>>>>
>>>>>>> ? [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>>>>>>> ? does not
>>>>>>> ? work.
>>>>>>>
>>>>>>> ? Thanks a lot,
>>>>>>> ? --
>>>>>>> ? Carsten Otto ? ? ? ? ? otto at informatik.rwth-aachen.de
>>>>>>> ? <mailto:otto at informatik.rwth-aachen.de>
>>>>>>> ? LuFG Informatik 2 ? ? ?http://verify.rwth-aachen.de/otto/
>>>>>>> ? RWTH Aachen ? ? ? ? ? ?phone: +49 241 80-21211
>>>>>>>
>>>>>>> ? -----BEGIN PGP SIGNATURE-----
>>>>>>> ? Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>>
>>>>>>> ? iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>>>>>>> ? 4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>>>>>>> ? =Brg8
>>>>>>> ? -----END PGP SIGNATURE-----
>>>>>>>
>>>>>>>
>>>
>>
>


From martinrb at google.com  Sun Aug 23 02:07:33 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 22 Aug 2009 19:07:33 -0700
Subject: zlib1.2.3
In-Reply-To: <4A8EE2D1.2080006@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
Message-ID: <1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>

On Fri, Aug 21, 2009 at 11:09, Xueming Shen <Xueming.Shen at sun.com> wrote:
>
> Martin, webrev has been updated to
>
> (1)use unidiff (and the correct order of src and target)
> (2)put those diffs into a patches dir
> (3)remove the minigzip.c from the ws (this one is not included in the file_c list...)

Thanks.

-------------

  35 +/* for _LP64 */
  36 +#include <sys/types.h>
  37 +
  38  /*
  39   * If you *really* need a unique prefix for all types and
library functions,
  40   * compile with -DZ_PREFIX. The "standard" zlib should be
compiled without it.
  41 @@ -261,7 +288,11 @@
  42  typedef unsigned char  Byte;  /* 8 bits */
  43  #endif
  44  typedef unsigned int   uInt;  /* 16 bits or more */
  45 +#ifdef _LP64
  46 +typedef unsigned int  uLong;  /* 32 bits or more */
  47 +#else
  48  typedef unsigned long  uLong; /* 32 bits or more */
  49 +#endif

zlib (intentionally) doesn't have much of a configure layer,
so we take our best shots at portability.
I think the above probably works fine, but I would do the very simple

typedef unsigned int uLong;

since unsigned int is likely to be 32 bits on any platform the JDK
is ever likely to run on.  Only early Dec Alpha systems made the mistake
of having a 64-bit int.

The 32-bit vs. 64-bit types are a mess.  I notice that crc32 tries to define
its own "u4" portability type

-------------
  31 @@ -39,7 +63,7 @@
  32         typedef unsigned int u4;
  33  #    else
  34  #      if (ULONG_MAX == 0xffffffffUL)
  35 -         typedef unsigned long u4;
  36 +         typedef uLong u4;
  37  #      else
  38  #        if (USHRT_MAX == 0xffffffffUL)
  39             typedef unsigned short u4;

Using uLong in the above is probably not right,
since comparison against ULONG_MAX means
the corresponding type is unsigned long
(not that it matters)

I'm suspicious that the changes in crc32.c might not be needed,
because nobody else is having to make these changes.
Perhaps use of "unsigned long" in crc32.c is correct because
in these cases either a 32-bit or 64-bit type will do?

Did you actually encounter functional problems with the original code?

-------------

Meta-comment: It would be nice if Sun engineers were able to keep
changes explicitly compatible with the zlib license (i.e. no GPL),
so that they were upstreamable to the zlib team.

-------------

Martin

>
>
> http://cr.openjdk.java.net/~sherman/zlib123/webrev
>
> Thanks
> Sherman
>
> Martin Buchholz wrote:
>>
>> I like very much that you are saving local changes in the form of patches
>> (I've been advocating this style of modification of upstream sources
>> for a while now), but...
>> - please generate your patches in "unidiff" form (diff -u)
>> - the extension ".patch" is, I think, preferable to ".diff"
>> ?(or put them into a "patches" directory, as debian does)
>>
>> I don't think we need minigzip.c - it's a kind of "demo" program.
>>
>> Do we really need to rename files? ?That's quite confusing.
>>
>> The pervasive change of
>> uLong => unsigned long
>> seems unnecessary - just get the typedef of uLong correct.
>>
>> Martin
>>
>> On Thu, Aug 20, 2009 at 19:49, Xueming Shen <Xueming.Shen at sun.com <mailto:Xueming.Shen at sun.com>> wrote:
>>
>> ? ?Here is the latest webrev for updating the zlib from the aged
>> ? ?1.1.3 to the latest version 1.2.3
>>
>>
>> ? ?http://cr.openjdk.java.net/~sherman/zlib123/webrev
>> ? ?<http://cr.openjdk.java.net/%7Esherman/zlib123/webrev>
>>
>> ? ?Alan, Kumar Martin, thanks for the comments, while I'm continuing
>> ? ?running more tests:-) here are the
>> ? ?reply to your comments/questions.
>>
>> ? ?(1) The ZLIB_VERSION has been moved into common/Defs.gmk.
>> ? ?(2) The copyright you quoted in the original copyright of
>> ? ?zlib1.1.3 (it was there is jdk6 and earlier before we opensourced
>> ? ?the jdk7).
>> ? ?(3) Yes, I have run the regression tests in tools/pack200 and
>> ? ?those in launcher, as well as other jar, zip related.
>> ? ?(4) I just jprt-ed a full forest/control build including
>> ? ?everything, it finished without any problem
>> ? ?(5) So far the "large zip support" still holds on all platforms I
>> ? ?tested on (Solaris sparc 32-bit/x86 32-bit, Linux x64 and
>> ? ?Windows32-bit.
>> ? ?(6)I would still prefer to get the source code from zlib.org
>> ? ?<http://zlib.org>. I took a quick scan at the ubuntu diff, don't
>> ? ?see the value of replacing the one
>> ? ? ?we have.
>> ? ?(7) The java port change log has been moved to
>> ? ?http://cr.openjdk.java.net/~sherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html
>> ? ?<http://cr.openjdk.java.net/%7Esherman/zlib123/webrev/src/share/native/java/util/zip/zlib-1.2.3/ChangeLog_java.html>
>>
>> ? ?Sherman
>>
>>
>>
>>
>>
>>
>>
>


From Xueming.Shen at Sun.COM  Sun Aug 23 03:37:18 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Sat, 22 Aug 2009 20:37:18 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
Message-ID: <4A90B96E.6000103@sun.com>

Martin Buchholz wrote:
> On Fri, Aug 21, 2009 at 11:09, Xueming Shen <Xueming.Shen at sun.com> wrote:
>   
>> Martin, webrev has been updated to
>>
>> (1)use unidiff (and the correct order of src and target)
>> (2)put those diffs into a patches dir
>> (3)remove the minigzip.c from the ws (this one is not included in the file_c list...)
>>     
>
> Thanks.
>
> -------------
>
>   35 +/* for _LP64 */
>   36 +#include <sys/types.h>
>   37 +
>   38  /*
>   39   * If you *really* need a unique prefix for all types and
> library functions,
>   40   * compile with -DZ_PREFIX. The "standard" zlib should be
> compiled without it.
>   41 @@ -261,7 +288,11 @@
>   42  typedef unsigned char  Byte;  /* 8 bits */
>   43  #endif
>   44  typedef unsigned int   uInt;  /* 16 bits or more */
>   45 +#ifdef _LP64
>   46 +typedef unsigned int  uLong;  /* 32 bits or more */
>   47 +#else
>   48  typedef unsigned long  uLong; /* 32 bits or more */
>   49 +#endif
>
> zlib (intentionally) doesn't have much of a configure layer,
> so we take our best shots at portability.
> I think the above probably works fine, but I would do the very simple
>
> typedef unsigned int uLong;
>   
sure. if this is important for you, I can make the change as you 
suggested. I have just finished
all the testing on the platforms I can get here (solaris sparc 32-bit,  
solaris x86 32-bit, linux 64-bit,
windows xp 32bit, vista 32-bit and windows 2003 64-bit). The 
regression/unit tests have been
on all platforms via jprt. So I will have to go through the build/test 
circle again if I'm going to
make this change:-) provided you are convinced that keep the crc32 asis...

> since unsigned int is likely to be 32 bits on any platform the JDK
> is ever likely to run on.  Only early Dec Alpha systems made the mistake
> of having a 64-bit int.
>
> The 32-bit vs. 64-bit types are a mess.  I notice that crc32 tries to define
> its own "u4" portability type
>
> -------------
>   31 @@ -39,7 +63,7 @@
>   32         typedef unsigned int u4;
>   33  #    else
>   34  #      if (ULONG_MAX == 0xffffffffUL)
>   35 -         typedef unsigned long u4;
>   36 +         typedef uLong u4;
>   37  #      else
>   38  #        if (USHRT_MAX == 0xffffffffUL)
>   39             typedef unsigned short u4;
>
> Using uLong in the above is probably not right,
> since comparison against ULONG_MAX means
> the corresponding type is unsigned long
> (not that it matters)
>   
uLong is unsigned long on the 32-bit platform and on a 64-bit platform the
ULONG_MAX should not be 0xffffffffUL. My understanding is that as
long as the u4 is a "unsigned 4-byte" type, we are OK. The crc32 value
is a unsigned 32-bit integer. The zlib1.1.3 does use the uLong, which is
consistent with the rest of the code base, it's kind of strange that the 
crc32
of the 1.2.3 starts to use its own style of "unsigned long".

> I'm suspicious that the changes in crc32.c might not be needed,
> because nobody else is having to make these changes.
> Perhaps use of "unsigned long" in crc32.c is correct because
> in these cases either a 32-bit or 64-bit type will do?
>
> Did you actually encounter functional problems with the original code?
>
>   
pack code at src/share/native/com/sun/java/util/jar/pack/zip.cpp expects 
the crc32() returns
a "uint", it actually matches the uLong. So there is a compiling err on 
64-bit platform if we keep
crc32 un-touched. Sure, its possible to solve this problem by changing 
the pack code...first I
would like to avid to touch pack code if possible, second asI said 
above, crc32 is a unsigned
32-bit,  it seems right to simply use the unsigned 32-bit.

sherman



From Alan.Bateman at Sun.COM  Sun Aug 23 07:43:21 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 23 Aug 2009 08:43:21 +0100
Subject: Currency updates in JDK 7
In-Reply-To: <4A906CA3.2050307@joda.org>
References: <4A906CA3.2050307@joda.org>
Message-ID: <4A90F319.6080607@sun.com>

Stephen Colebourne wrote:
> I've been reviewing the Javadoc for the JDK 7 Currency class changes.
> http://download.java.net/jdk7/docs/api/java/util/Currency.html
>
> The updates appear to allow users the ability to override the built in 
> currency data, as indicated in the class javadoc:
>
> "Users can supersede the Java runtime currency data by creating a 
> properties file named <JAVA_HOME>/lib/currency.properties. The 
> contents of the properties file are key/value pairs of the ISO 3166 
> country codes and the ISO 4217 currency data respectively. The value 
> part consists of three ISO 4217 values of a currency, i.e., an 
> alphabetic code, a numeric code, and a minor unit. Those three ISO 
> 4217 values are separated by commas. The lines which start with '#'s 
> are considered comment lines. For example,
>
> #Sample currency properties
> JP=JPZ,999,0
>
> will supersede the currency data for Japan. "
>
> Unfortunately, not all currencies are associated with countries. Some, 
> like XAG for 'silver', XDR for 'IMF drawing rights' or XXX for 'no 
> currency' have no matching country. Thus, this file format is unable 
> to represent user overrides to those countries.
>
> Further, the Javadoc is unclear as to whether users can _add_ new 
> currencies. An example would be if a country split, like Czech/Slovak, 
> and created two currencies. Does the new format add a currency to the 
> built in list if it isn't recognised?
>
> I believe that we should also consider if Currency should implement 
> Comparable, sorting alphabetically on the currency code. While there 
> are many possible sort orders, having this as the default one makes a 
> lot of sense.
>
> Finally, I'd like to see a method isPsuedoCurrency() added. This would 
> return a boolean indicating if the currency is 'real' or not.
>
> Otherwise the changes pretty much complete the use cases for the class.
>
> Stephen
>
Stephen - the Currency class (and a few others in java.util, such as 
Locale, Calendar, ...) are maintained by the i18n group. I don't know if 
the folks in that group are on this mailing list so you might be better 
re-sending to i18n-dev. If it helps, the bugID used to separate the 
currency data from rt.jar, and allow it be superseded , was 6332666.

-Alan.



From gnu_andrew at member.fsf.org  Sun Aug 23 15:22:16 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 23 Aug 2009 16:22:16 +0100
Subject: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate 
	COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.
In-Reply-To: <1250971338.2627.6.camel@hermans.wildebeest.org>
References: <20090820224000.6B168E12@eggemoggin.niobe.net>
	<1250840220.3908.9.camel@springer.wildebeest.org>
	<17c6771e0908211235p5b275de1hb2a7c882a24a839f@mail.gmail.com>
	<1250971338.2627.6.camel@hermans.wildebeest.org>
Message-ID: <17c6771e0908230822j152d0249xe21075ac77453cc0@mail.gmail.com>

2009/8/22 Mark Wielaard <mark at klomp.org>:
> Hi Andrew,
>
> On Fri, 2009-08-21 at 20:35 +0100, Andrew John Hughes wrote:
>> 2009/8/21 Mark Wielaard <mark at klomp.org>:
>> > On Thu, 2009-08-20 at 15:40 -0700, Mark Reinhold wrote:
>> >> This change was integrated prematurely. ?I've rolled it back in the
>> >> jdk7/tl/jdk repository.
>> >
>> > If at all possible, please don't do this. It plays havoc with already
>> > checked out repos and/or automatic clones/backups. You force people to
>> > recreate their local repos if you purge a commit that was already public
>> > like this. Could you use a normal hg backout instead in the future? That
>> > will make sure the integrity of the repo isn't compromised.
>> >
>> It would be much cleaner to just do a commit reversing the patch (mjw,
>> is that what you mean by a backout or something else?)
>
> Yes. "hg backout" creates a reverse changeset that "cancels out" an
> earlier commit (but does so in a way that keeps the integrity of
> repository, plus the whole history). See also: hg backout --help
>
>> I really don't like the idea of sanitising the repos to remove all
>> mistakes and there's also no guarantee everyone will do this and push
>> it in every forest.
>>
>> > Thanks,
>> >
>> > Mark
>
>

Ah, so it autocreates what I was talking about.

Cheers,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From alan.bateman at sun.com  Sun Aug 23 16:27:58 2009
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Sun, 23 Aug 2009 16:27:58 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090823162902.4328D123BE@hg.openjdk.java.net>

Changeset: 99a55f6f1cef
Author:    alanb
Date:      2009-08-22 17:40 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99a55f6f1cef

6874521: Remove @note tags
Reviewed-by: andrew, darcy

! src/share/classes/java/nio/channels/Channels.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/channels/FileLock.java
! src/share/classes/java/nio/channels/package-info.java
! src/share/classes/java/nio/file/FileRef.java
! src/share/classes/java/util/Scanner.java

Changeset: cef30252932a
Author:    alanb
Date:      2009-08-23 12:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cef30252932a

6842687: New I/O: Update Asynchronous I/O API to jsr203/nio2-b101
Reviewed-by: sherman

! make/java/nio/FILES_java.gmk
! src/share/classes/java/nio/channels/AsynchronousByteChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannel.java
! src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/CompletionHandler.java
! src/share/classes/java/nio/channels/exceptions
- src/share/classes/sun/nio/ch/AbstractFuture.java
! src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java
! src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/CompletedFuture.java
! src/share/classes/sun/nio/ch/Invoker.java
! src/share/classes/sun/nio/ch/PendingFuture.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/solaris/classes/sun/nio/ch/EPollPort.java
! src/solaris/classes/sun/nio/ch/Port.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/Iocp.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/native/sun/nio/ch/Iocp.c
! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
! test/java/nio/channels/AsynchronousChannelGroup/Identity.java
! test/java/nio/channels/AsynchronousChannelGroup/Restart.java
! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java
! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java
! test/java/nio/channels/AsynchronousFileChannel/Basic.java
! test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java
! test/java/nio/channels/AsynchronousFileChannel/Lock.java
! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java
! test/java/nio/channels/AsynchronousSocketChannel/Basic.java
+ test/java/nio/channels/AsynchronousSocketChannel/DieBeforeComplete.java
! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java

Changeset: fca3e1a178fd
Author:    alanb
Date:      2009-08-23 17:20 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fca3e1a178fd

Merge




From Xueming.Shen at Sun.COM  Sun Aug 23 18:04:14 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Sun, 23 Aug 2009 11:04:14 -0700
Subject: zlib1.2.3
In-Reply-To: <4A90B96E.6000103@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
Message-ID: <4A91849E.1010204@sun.com>

Martin,

Forgot to mentioned in last email, the original zlib.h actually has 
crc32 declared using uLong, so
we have a compiling error on 64-bit after we define the uLong to 32-bit 
unsigned, since the unsigned
long is 64-bit in crc32.c.

sherman

Xueming Shen wrote:
>
>> I'm suspicious that the changes in crc32.c might not be needed,
>> because nobody else is having to make these changes.
>> Perhaps use of "unsigned long" in crc32.c is correct because
>> in these cases either a 32-bit or 64-bit type will do?
>>
>> Did you actually encounter functional problems with the original code?
>>
>>   
> pack code at src/share/native/com/sun/java/util/jar/pack/zip.cpp 
> expects the crc32() returns
> a "uint", it actually matches the uLong. So there is a compiling err 
> on 64-bit platform if we keep
> crc32 un-touched. Sure, its possible to solve this problem by changing 
> the pack code...first I
> would like to avid to touch pack code if possible, second asI said 
> above, crc32 is a unsigned
> 32-bit,  it seems right to simply use the unsigned 32-bit.
>
> sherman
>



From martinrb at google.com  Mon Aug 24 02:40:43 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 23 Aug 2009 19:40:43 -0700
Subject: zlib1.2.3
In-Reply-To: <4A91849E.1010204@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com> <4A91849E.1010204@sun.com>
Message-ID: <1ccfd1c10908231940g6c24548fq738c67d83f06ace1@mail.gmail.com>

On Sun, Aug 23, 2009 at 11:04, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Martin,
>
> Forgot to mentioned in last email, the original zlib.h actually has crc32
> declared using uLong, so
> we have a compiling error on 64-bit after we define the uLong to 32-bit
> unsigned, since the unsigned
> long is 64-bit in crc32.c.

You're right that it's just an obvious bug in zlib 1.2.3
that the declaration and definition of crc32 don't match.
Not confidence-inspiring.

Martin

> sherman
>
> Xueming Shen wrote:
>>
>>> I'm suspicious that the changes in crc32.c might not be needed,
>>> because nobody else is having to make these changes.
>>> Perhaps use of "unsigned long" in crc32.c is correct because
>>> in these cases either a 32-bit or 64-bit type will do?
>>>
>>> Did you actually encounter functional problems with the original code?
>>>
>>>
>>
>> pack code at src/share/native/com/sun/java/util/jar/pack/zip.cpp expects
>> the crc32() returns
>> a "uint", it actually matches the uLong. So there is a compiling err on
>> 64-bit platform if we keep
>> crc32 un-touched. Sure, its possible to solve this problem by changing the
>> pack code...first I
>> would like to avid to touch pack code if possible, second asI said above,
>> crc32 is a unsigned
>> 32-bit, ?it seems right to simply use the unsigned 32-bit.
>>
>> sherman
>>
>
>


From martinrb at google.com  Mon Aug 24 02:45:25 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 23 Aug 2009 19:45:25 -0700
Subject: zlib1.2.3
In-Reply-To: <4A90B96E.6000103@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
Message-ID: <1ccfd1c10908231945x62af8349x305319e2ca18f87d@mail.gmail.com>

On Sat, Aug 22, 2009 at 20:37, Xueming Shen<Xueming.Shen at sun.com> wrote:
>> -------------
>>
>> ?35 +/* for _LP64 */
>> ?36 +#include <sys/types.h>
>> ?37 +
>> ?38 ?/*
>> ?39 ? * If you *really* need a unique prefix for all types and
>> library functions,
>> ?40 ? * compile with -DZ_PREFIX. The "standard" zlib should be
>> compiled without it.
>> ?41 @@ -261,7 +288,11 @@
>> ?42 ?typedef unsigned char ?Byte; ?/* 8 bits */
>> ?43 ?#endif
>> ?44 ?typedef unsigned int ? uInt; ?/* 16 bits or more */
>> ?45 +#ifdef _LP64
>> ?46 +typedef unsigned int ?uLong; ?/* 32 bits or more */
>> ?47 +#else
>> ?48 ?typedef unsigned long ?uLong; /* 32 bits or more */
>> ?49 +#endif
>>
>> zlib (intentionally) doesn't have much of a configure layer,
>> so we take our best shots at portability.
>> I think the above probably works fine, but I would do the very simple
>>
>> typedef unsigned int uLong;
>>
>
> sure. if this is important for you, I can make the change as you suggested.
> I have just finished
> all the testing on the platforms I can get here (solaris sparc 32-bit,
> ?solaris x86 32-bit, linux 64-bit,
> windows xp 32bit, vista 32-bit and windows 2003 64-bit). The regression/unit
> tests have been
> on all platforms via jprt. So I will have to go through the build/test
> circle again if I'm going to
> make this change:-) provided you are convinced that keep the crc32 asis...

As you know, I am an incurable nitpicker.  I haven't found any bug in
your code, so feel free to commit.  Especially since this is a pre-existing
Sun modification.
But I'll keep sending you comments anyways.


From martinrb at google.com  Mon Aug 24 02:51:44 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 23 Aug 2009 19:51:44 -0700
Subject: zlib1.2.3
In-Reply-To: <4A90B96E.6000103@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
Message-ID: <1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>

On Sat, Aug 22, 2009 at 20:37, Xueming Shen<Xueming.Shen at sun.com> wrote:
>> -------------
>> ?31 @@ -39,7 +63,7 @@
>> ?32 ? ? ? ? typedef unsigned int u4;
>> ?33 ?# ? ?else
>> ?34 ?# ? ? ?if (ULONG_MAX == 0xffffffffUL)
>> ?35 - ? ? ? ? typedef unsigned long u4;
>> ?36 + ? ? ? ? typedef uLong u4;
>> ?37 ?# ? ? ?else
>> ?38 ?# ? ? ? ?if (USHRT_MAX == 0xffffffffUL)
>> ?39 ? ? ? ? ? ? typedef unsigned short u4;
>>
>> Using uLong in the above is probably not right,
>> since comparison against ULONG_MAX means
>> the corresponding type is unsigned long
>> (not that it matters)
>>

#    if (UINT_MAX == 0xffffffffUL)
       typedef unsigned int u4;
#    else
#      if (ULONG_MAX == 0xffffffffUL)
         typedef unsigned long u4;
#      else
#        if (USHRT_MAX == 0xffffffffUL)
           typedef unsigned short u4;

I believe that on all platforms where the JDK will be built,
the first test UINT_MAX == 0xffffffffUL will be true,
so the suggested change will never pass the preprocessor.
I believe it to both be wrong and to have no effect, and increase the
size of local changes - but still OK to commit if you insist!

Martin


From martinrb at google.com  Mon Aug 24 02:58:28 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 23 Aug 2009 19:58:28 -0700
Subject: zlib1.2.3
In-Reply-To: <4A8EC16D.80505@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EC16D.80505@sun.com>
Message-ID: <1ccfd1c10908231958k23767121q5c1d6ee79b0851c2@mail.gmail.com>

On Fri, Aug 21, 2009 at 08:46, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> Do we really need to rename files? ?That's quite confusing.
>
> The names conflict with our CRC32.c and Adler.c on Windows platform.

YUK!  I finally understand this problem.

Good makefile hygiene would be to build zlib separately into its own library,
and have the jdk zip code link against that, instead of having the two
sets of c files be compiled together.  But that's beyond the scope of
this change.

Martin


From Xueming.Shen at Sun.COM  Mon Aug 24 04:56:26 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Sun, 23 Aug 2009 21:56:26 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
Message-ID: <4A921D7A.1080806@sun.com>

Martin Buchholz wrote:
> On Sat, Aug 22, 2009 at 20:37, Xueming Shen<Xueming.Shen at sun.com> wrote:
>   
>>> -------------
>>>  31 @@ -39,7 +63,7 @@
>>>  32         typedef unsigned int u4;
>>>  33  #    else
>>>  34  #      if (ULONG_MAX == 0xffffffffUL)
>>>  35 -         typedef unsigned long u4;
>>>  36 +         typedef uLong u4;
>>>  37  #      else
>>>  38  #        if (USHRT_MAX == 0xffffffffUL)
>>>  39             typedef unsigned short u4;
>>>
>>> Using uLong in the above is probably not right,
>>> since comparison against ULONG_MAX means
>>> the corresponding type is unsigned long
>>> (not that it matters)
>>>
>>>       
>
> #    if (UINT_MAX == 0xffffffffUL)
>        typedef unsigned int u4;
> #    else
> #      if (ULONG_MAX == 0xffffffffUL)
>          typedef unsigned long u4;
> #      else
> #        if (USHRT_MAX == 0xffffffffUL)
>            typedef unsigned short u4;
>
> I believe that on all platforms where the JDK will be built,
> the first test UINT_MAX == 0xffffffffUL will be true,
> so the suggested change will never pass the preprocessor.
> I believe it to both be wrong and to have no effect, and increase the
> size of local changes - but still OK to commit if you insist!
>   
Oh, I see your point. Are you saying this "local change" is not 
necessary since it never gets
preprocessed? OK, I admit I did the replace all in emacs:-) Maybe I 
should have touched
those that affected. But given the nature of crc32, I'm pretty sure a 
32-bit unsigned integer
is what it should be (and is intended,) as the code purposely defines 
the "u4".

An alternative is to keep the crc32.c/h untouched, change the crc32() 
declare in zlib.h to
unsigned long and then change the rest of jdk (our CRC.c and the pack 
code to prepare
a 64-bit unsigned long on 64-bits), is this the direction you would 
prefer to?

Sherman


From martinrb at google.com  Mon Aug 24 07:02:12 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2009 00:02:12 -0700
Subject: zlib1.2.3
In-Reply-To: <4A921D7A.1080806@sun.com>
References: <4A8C7D62.6070405@sun.com> <4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
Message-ID: <1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>

On Sun, Aug 23, 2009 at 21:56, Xueming Shen <Xueming.Shen at sun.com> wrote:

> Martin Buchholz wrote:
>
>> On Sat, Aug 22, 2009 at 20:37, Xueming Shen<Xueming.Shen at sun.com> wrote:
>>
>>
>>> -------------
>>>>  31 @@ -39,7 +63,7 @@
>>>>  32         typedef unsigned int u4;
>>>>  33  #    else
>>>>  34  #      if (ULONG_MAX == 0xffffffffUL)
>>>>  35 -         typedef unsigned long u4;
>>>>  36 +         typedef uLong u4;
>>>>  37  #      else
>>>>  38  #        if (USHRT_MAX == 0xffffffffUL)
>>>>  39             typedef unsigned short u4;
>>>>
>>>> Using uLong in the above is probably not right,
>>>> since comparison against ULONG_MAX means
>>>> the corresponding type is unsigned long
>>>> (not that it matters)
>>>>
>>>>
>>>>
>>>
>> #    if (UINT_MAX == 0xffffffffUL)
>>       typedef unsigned int u4;
>> #    else
>> #      if (ULONG_MAX == 0xffffffffUL)
>>         typedef unsigned long u4;
>> #      else
>> #        if (USHRT_MAX == 0xffffffffUL)
>>           typedef unsigned short u4;
>>
>> I believe that on all platforms where the JDK will be built,
>> the first test UINT_MAX == 0xffffffffUL will be true,
>> so the suggested change will never pass the preprocessor.
>> I believe it to both be wrong and to have no effect, and increase the
>> size of local changes - but still OK to commit if you insist!
>>
>>
> Oh, I see your point. Are you saying this "local change" is not necessary
> since it never gets
> preprocessed?


No, more than that - the code is defining a derived type u4 from
primitive types - it should not be using other derived types.
BTW, u4 is of size *exactly* 4 bytes, while uLong I think is of size
*at least* 4 bytes, so these are slightly semantically different.

Looking again at zlib's types, I see that
uLong is unconditionally typedef'ed to "unsigned long"
so in an unmodified distribution they can be used interchangeably
(although a little unclean - why have a typedef in the first place?)
zlib definitely claims to support 64-bit platforms - see FAQ.
It should Just Work to let uLong be always unsigned long,
even though that might be "too large"
for the data being provided on LP64 systems.

----

You should probably update zconf.h to include unistd.h
as if you had run configure, at least on Unix.

 318 #if 0           /* HAVE_UNISTD_H -- this line is updated by ./configure */
 319 #  include <sys/types.h> /* for off_t */
 320 #  include <unistd.h>    /* for SEEK_* and off_t */

It looks like you won't get large file support on 32-bit systems
without struggling with configury stuff.  Or maybe we never use
zlib in the JDK to directly access files via seek and off_t?


OK, I admit I did the replace all in emacs:-) Maybe I should have touched
> those that affected. But given the nature of crc32, I'm pretty sure a
> 32-bit unsigned integer
> is what it should be (and is intended,) as the code purposely defines the
> "u4".
>
> An alternative is to keep the crc32.c/h untouched, change the crc32()
> declare in zlib.h to
> unsigned long and then change the rest of jdk (our CRC.c and the pack code
> to prepare
> a 64-bit unsigned long on 64-bits), is this the direction you would prefer
> to?
>

I don't see why the rest of the jdk has to be changed,
or why a completely unmodified zlib cannot be used
(although some modifications, like for total_in are well motivated)

If we are ever to support using alternative zlibs like the system zlib,
as icedtea has done, then we cannot depend on enhancements like
a 64-bit total_in.  Perhaps even that change should not be made.

Martin


>
> Sherman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090824/8a6536d4/attachment.html>

From fweimer at bfk.de  Mon Aug 24 07:20:26 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Mon, 24 Aug 2009 07:20:26 +0000
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	(Martin Buchholz's message of "Sat\,
	22 Aug 2009 19\:07\:33 -0700")
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
Message-ID: <82my5poeyt.fsf@mid.bfk.de>

* Martin Buchholz:

>   45 +#ifdef _LP64
>   46 +typedef unsigned int  uLong;  /* 32 bits or more */
>   47 +#else
>   48  typedef unsigned long  uLong; /* 32 bits or more */
>   49 +#endif

This is guaranteed to break interoperability with the system zlib.  If
you want to make such adjustments, you really have to rename all
functions to avoid name clashes.  Such clashes materialize if you load
a DSO which contains code linked to the system zlib (usually via JNI).

Technically, this is not a regression because OpenJDK's existing zlib
1.1 code is incompatible with 1.2 zlibs used on most systems, so the
same problem happens.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From martinrb at google.com  Mon Aug 24 07:43:01 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2009 00:43:01 -0700
Subject: zlib1.2.3
In-Reply-To: <82my5poeyt.fsf@mid.bfk.de>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<82my5poeyt.fsf@mid.bfk.de>
Message-ID: <1ccfd1c10908240043h7c5424f4p814ca0f4a57bbcfa@mail.gmail.com>

It is reasonable for jni code to be built against the system zlib.
Such jni code should not accidentally invoke the jdk bundled zlib.
zlib includes support for symbol renaming (Z_PREFIX),
but better is to build the jdk so that jni does not have direct access
to the zlib functions under any name (but that might be a lot of work).

Martin

On Mon, Aug 24, 2009 at 00:20, Florian Weimer <fweimer at bfk.de> wrote:

> * Martin Buchholz:
>
> >   45 +#ifdef _LP64
> >   46 +typedef unsigned int  uLong;  /* 32 bits or more */
> >   47 +#else
> >   48  typedef unsigned long  uLong; /* 32 bits or more */
> >   49 +#endif
>
> This is guaranteed to break interoperability with the system zlib.  If
> you want to make such adjustments, you really have to rename all
> functions to avoid name clashes.  Such clashes materialize if you load
> a DSO which contains code linked to the system zlib (usually via JNI).
>
> Technically, this is not a regression because OpenJDK's existing zlib
> 1.1 code is incompatible with 1.2 zlibs used on most systems, so the
> same problem happens.
>
> --
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra?e 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090824/1fd66434/attachment.html>

From weijun.wang at sun.com  Mon Aug 24 10:44:55 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Mon, 24 Aug 2009 10:44:55 +0000
Subject: hg: jdk7/tl/jdk: 6875033: regression: test of 6867665 fail
Message-ID: <20090824104526.CAC36123DA@hg.openjdk.java.net>

Changeset: dbcc1f13e4fd
Author:    weijun
Date:      2009-08-24 18:37 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbcc1f13e4fd

6875033: regression: test of 6867665 fail
Reviewed-by: xuelei

! test/sun/security/krb5/ktab/HighestKvno.java



From kelly.ohair at sun.com  Mon Aug 24 17:06:11 2009
From: kelly.ohair at sun.com (kelly.ohair at sun.com)
Date: Mon, 24 Aug 2009 17:06:11 +0000
Subject: hg: jdk7/tl/jdk: 6853636: Fix warnings in jdwpgen,
	add jdwpgen NetBeans project
Message-ID: <20090824170721.BF88712404@hg.openjdk.java.net>

Changeset: d954cd279188
Author:    ohair
Date:      2009-08-24 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d954cd279188

6853636: Fix warnings in jdwpgen, add jdwpgen NetBeans project
Reviewed-by: andrew, alanb, tbell, swamyv

! .hgignore
+ make/netbeans/jdwpgen/build.xml
+ make/netbeans/jdwpgen/nbproject/build-impl.xml
+ make/netbeans/jdwpgen/nbproject/findbugs.settings
+ make/netbeans/jdwpgen/nbproject/genfiles.properties
+ make/netbeans/jdwpgen/nbproject/project.properties
+ make/netbeans/jdwpgen/nbproject/project.xml
+ make/netbeans/jdwpgen/nbproject/sqe.properties
! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
! make/tools/src/build/tools/jdwpgen/AltNode.java
! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
! make/tools/src/build/tools/jdwpgen/Main.java
! make/tools/src/build/tools/jdwpgen/Node.java
! make/tools/src/build/tools/jdwpgen/Parse.java
! make/tools/src/build/tools/jdwpgen/RepeatNode.java
! make/tools/src/build/tools/jdwpgen/SelectNode.java



From Xueming.Shen at Sun.COM  Mon Aug 24 17:17:53 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 24 Aug 2009 10:17:53 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908240043h7c5424f4p814ca0f4a57bbcfa@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<82my5poeyt.fsf@mid.bfk.de>
	<1ccfd1c10908240043h7c5424f4p814ca0f4a57bbcfa@mail.gmail.com>
Message-ID: <4A92CB41.7060100@sun.com>

This is a different issue. I would prefer to separate the "to upgrade to 
zlib 1.2.3" and
"to use host platform zlib on linux, if preferable" into two different 
tasks. We tend to
try to put too many "similar" things into one project and end up missing 
the primary
goal:-) Given the zlib is so "important", I would like to safe-land the 
zlib1.2.3 first,
without touching too many other stuff.

Personally I agree, there is good reason to use the zlib from native 
platform/resource,
"depending on your perspective", as Joe said. However there is also good 
reason to
stick with the approach of "using our own zlib, even there is a native 
zlib". The linux is
an open platform and zlib itself is NOT a real "standard" library like 
libc, there is no
guarantee that the zlib loaded on the platform is the one you want to 
use. Sure you
can do your best try to "detect"...the reason I don't want to bundle 
this issue into the
upgrade work.

Sherman

Martin Buchholz wrote:
> It is reasonable for jni code to be built against the system zlib.
> Such jni code should not accidentally invoke the jdk bundled zlib.
> zlib includes support for symbol renaming (Z_PREFIX),
> but better is to build the jdk so that jni does not have direct access
> to the zlib functions under any name (but that might be a lot of work).
>
> Martin
>
> On Mon, Aug 24, 2009 at 00:20, Florian Weimer <fweimer at bfk.de 
> <mailto:fweimer at bfk.de>> wrote:
>
>     * Martin Buchholz:
>
>     >   45 +#ifdef _LP64
>     >   46 +typedef unsigned int  uLong;  /* 32 bits or more */
>     >   47 +#else
>     >   48  typedef unsigned long  uLong; /* 32 bits or more */
>     >   49 +#endif
>
>     This is guaranteed to break interoperability with the system zlib.  If
>     you want to make such adjustments, you really have to rename all
>     functions to avoid name clashes.  Such clashes materialize if you load
>     a DSO which contains code linked to the system zlib (usually via JNI).
>
>     Technically, this is not a regression because OpenJDK's existing zlib
>     1.1 code is incompatible with 1.2 zlibs used on most systems, so the
>     same problem happens.
>
>     --
>     Florian Weimer                <fweimer at bfk.de <mailto:fweimer at bfk.de>>
>     BFK edv-consulting GmbH       http://www.bfk.de/
>     Kriegsstra?e 100              tel: +49-721-96201-1
>     D-76133 Karlsruhe             fax: +49-721-96201-99
>
>



From Xueming.Shen at Sun.COM  Mon Aug 24 18:06:02 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 24 Aug 2009 11:06:02 -0700
Subject: zlib1.2.3
In-Reply-To: <82my5poeyt.fsf@mid.bfk.de>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<82my5poeyt.fsf@mid.bfk.de>
Message-ID: <4A92D68A.6000208@sun.com>

Florian Weimer wrote:
> * Martin Buchholz:
>
>   
>>   45 +#ifdef _LP64
>>   46 +typedef unsigned int  uLong;  /* 32 bits or more */
>>   47 +#else
>>   48  typedef unsigned long  uLong; /* 32 bits or more */
>>   49 +#endif
>>     
>
> This is guaranteed to break interoperability with the system zlib.  If
> you want to make such adjustments, you really have to rename all
> functions to avoid name clashes.  Such clashes materialize if you load
> a DSO which contains code linked to the system zlib (usually via JNI).
>
> Technically, this is not a regression because OpenJDK's existing zlib
> 1.1 code is incompatible with 1.2 zlibs used on most systems, so the
> same problem happens.
>
>   

None of the zlib functions/methods is exported from libzip.o as "glocal" 
symbol, we are using
make/java/zip/mapfile_vers to make them "local". Those zlib methods are 
supposed to be
only accessed by our "own" jar/zip jnis. So what is exactly the 
"interoperability with the system
zlib" concern here?

Sherman





From Xueming.Shen at Sun.COM  Mon Aug 24 18:16:48 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 24 Aug 2009 11:16:48 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com> <4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
Message-ID: <4A92D910.2060904@sun.com>

Martin Buchholz wrote:
>
>         mit if you insist!
>          
>
>     Oh, I see your point. Are you saying this "local change" is not
>     necessary since it never gets
>     preprocessed? 
>
>
> No, more than that - the code is defining a derived type u4 from
> primitive types - it should not be using other derived types.
> BTW, u4 is of size *exactly* 4 bytes, while uLong I think is of size
> *at least* 4 bytes, so these are slightly semantically different.

If you consider we have "already" made the change to make sure uLong is 
32-bit, then
this should no longer be a problem, yes, semantically we should simply 
use "unsigned long"
here, but it does not make any difference. I made this change with the 
assumption of that LP64
change.

>  
> Looking again at zlib's types, I see that
> uLong is unconditionally typedef'ed to "unsigned long"
> so in an unmodified distribution they can be used interchangeably
> (although a little unclean - why have a typedef in the first place?)
> zlib definitely claims to support 64-bit platforms - see FAQ. 
> It should Just Work to let uLong be always unsigned long,
> even though that might be "too large"
> for the data being provided on LP64 systems.

The SCCS history shows there were some "check in, check out then check 
in again" history regarding
this "32-bit or 64-bit" modification, due to some hotspot failure bug. 
This is the most reasons I decided
to go with the "working version".

Seems like I'm not going to catch tonight's deadline:-), maybe we can 
try some experiments.

>
> ----
>
> You should probably update zconf.h to include unistd.h
> as if you had run configure, at least on Unix.
>  318 #if 0           /* HAVE_UNISTD_H -- this line is updated by ./configure */
>
>  319 #  include <sys/types.h> /* for off_t */
>  320 #  include <unistd.h>    /* for SEEK_* and off_t */
>   
> It looks like you won't get large file support on 32-bit systems
> without struggling with configury stuff.  Or maybe we never use
> zlib in the JDK to directly access files via seek and off_t?
>
No, the zlib in our code never accesses the file directly. File access 
is done in our own zipfile code..


From martinrb at google.com  Mon Aug 24 18:35:22 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2009 11:35:22 -0700
Subject: zlib1.2.3
In-Reply-To: <4A92CB41.7060100@sun.com>
References: <4A8C7D62.6070405@sun.com> <4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<82my5poeyt.fsf@mid.bfk.de>
	<1ccfd1c10908240043h7c5424f4p814ca0f4a57bbcfa@mail.gmail.com>
	<4A92CB41.7060100@sun.com>
Message-ID: <1ccfd1c10908241135n1fda9240neda450c76ee5c4b3@mail.gmail.com>

On Mon, Aug 24, 2009 at 10:17, Xueming Shen<Xueming.Shen at sun.com> wrote:
> This is a different issue. I would prefer to separate the "to upgrade to
> zlib 1.2.3" and
> "to use host platform zlib on linux, if preferable" into two different
> tasks. We tend to
> try to put too many "similar" things into one project and end up missing the
> primary
> goal:-) Given the zlib is so "important", I would like to safe-land the
> zlib1.2.3 first,
> without touching too many other stuff.

Agreed.

> Personally I agree, there is good reason to use the zlib from native
> platform/resource,
> "depending on your perspective", as Joe said. However there is also good
> reason to
> stick with the approach of "using our own zlib, even there is a native
> zlib". The linux is
> an open platform and zlib itself is NOT a real "standard" library like libc,
> there is no
> guarantee that the zlib loaded on the platform is the one you want to use.
> Sure you
> can do your best try to "detect"...the reason I don't want to bundle this
> issue into the
> upgrade work.

Agreed.  Using the system zlib entails binary compatibility
risks of which I was not previously aware.

Martin

> Sherman
>
> Martin Buchholz wrote:
>>
>> It is reasonable for jni code to be built against the system zlib.
>> Such jni code should not accidentally invoke the jdk bundled zlib.
>> zlib includes support for symbol renaming (Z_PREFIX),
>> but better is to build the jdk so that jni does not have direct access
>> to the zlib functions under any name (but that might be a lot of work).
>>
>> Martin
>>
>> On Mon, Aug 24, 2009 at 00:20, Florian Weimer <fweimer at bfk.de
>> <mailto:fweimer at bfk.de>> wrote:
>>
>> ? ?* Martin Buchholz:
>>
>> ? ?> ? 45 +#ifdef _LP64
>> ? ?> ? 46 +typedef unsigned int ?uLong; ?/* 32 bits or more */
>> ? ?> ? 47 +#else
>> ? ?> ? 48 ?typedef unsigned long ?uLong; /* 32 bits or more */
>> ? ?> ? 49 +#endif
>>
>> ? ?This is guaranteed to break interoperability with the system zlib. ?If
>> ? ?you want to make such adjustments, you really have to rename all
>> ? ?functions to avoid name clashes. ?Such clashes materialize if you load
>> ? ?a DSO which contains code linked to the system zlib (usually via JNI).
>>
>> ? ?Technically, this is not a regression because OpenJDK's existing zlib
>> ? ?1.1 code is incompatible with 1.2 zlibs used on most systems, so the
>> ? ?same problem happens.
>>
>> ? ?--
>> ? ?Florian Weimer ? ? ? ? ? ? ? ?<fweimer at bfk.de <mailto:fweimer at bfk.de>>
>> ? ?BFK edv-consulting GmbH ? ? ? http://www.bfk.de/
>> ? ?Kriegsstra?e 100 ? ? ? ? ? ? ?tel: +49-721-96201-1
>> ? ?D-76133 Karlsruhe ? ? ? ? ? ? fax: +49-721-96201-99
>>
>>
>
>


From martinrb at google.com  Mon Aug 24 18:46:16 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2009 11:46:16 -0700
Subject: zlib1.2.3
In-Reply-To: <4A92D68A.6000208@sun.com>
References: <4A8C7D62.6070405@sun.com>
	<1ccfd1c10908201134n4881ac8la0ffc5ea01deb4b6@mail.gmail.com>
	<4A8D9C57.9090404@sun.com>
	<1ccfd1c10908201626u348adab2i736dc1c07b20f9da@mail.gmail.com>
	<4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<82my5poeyt.fsf@mid.bfk.de> <4A92D68A.6000208@sun.com>
Message-ID: <1ccfd1c10908241146x273a53a9vaf68ee34dd32126d@mail.gmail.com>

On Mon, Aug 24, 2009 at 11:06, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Florian Weimer wrote:
>>
>> * Martin Buchholz:
>>
>>
>>>
>>> ?45 +#ifdef _LP64
>>> ?46 +typedef unsigned int ?uLong; ?/* 32 bits or more */
>>> ?47 +#else
>>> ?48 ?typedef unsigned long ?uLong; /* 32 bits or more */
>>> ?49 +#endif
>>>
>>
>> This is guaranteed to break interoperability with the system zlib. ?If
>> you want to make such adjustments, you really have to rename all
>> functions to avoid name clashes. ?Such clashes materialize if you load
>> a DSO which contains code linked to the system zlib (usually via JNI).
>>
>> Technically, this is not a regression because OpenJDK's existing zlib
>> 1.1 code is incompatible with 1.2 zlibs used on most systems, so the
>> same problem happens.
>>
>>
>
> None of the zlib functions/methods is exported from libzip.o as "glocal"
> symbol, we are using
> make/java/zip/mapfile_vers to make them "local". Those zlib methods are
> supposed to be
> only accessed by our "own" jar/zip jnis. So what is exactly the
> "interoperability with the system
> zlib" concern here?
>

Sherman: Running "nm" on jdk7 binaries suggests that you are right.

Florian: Do you have a test case demonstrating zlib failure due to
namespace contamination?

Martin


From martinrb at google.com  Mon Aug 24 18:52:45 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2009 11:52:45 -0700
Subject: zlib1.2.3
In-Reply-To: <4A92D910.2060904@sun.com>
References: <4A8C7D62.6070405@sun.com> <4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
	<4A92D910.2060904@sun.com>
Message-ID: <1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>

On Mon, Aug 24, 2009 at 11:16, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> ? ? ? ?mit if you insist!
>>
>> ? ?Oh, I see your point. Are you saying this "local change" is not
>> ? ?necessary since it never gets
>> ? ?preprocessed?
>>
>> No, more than that - the code is defining a derived type u4 from
>> primitive types - it should not be using other derived types.
>> BTW, u4 is of size *exactly* 4 bytes, while uLong I think is of size
>> *at least* 4 bytes, so these are slightly semantically different.
>
> If you consider we have "already" made the change to make sure uLong is
> 32-bit, then
> this should no longer be a problem, yes, semantically we should simply use
> "unsigned long"
> here, but it does not make any difference. I made this change with the
> assumption of that LP64
> change.
>
>> ?Looking again at zlib's types, I see that
>> uLong is unconditionally typedef'ed to "unsigned long"
>> so in an unmodified distribution they can be used interchangeably
>> (although a little unclean - why have a typedef in the first place?)
>> zlib definitely claims to support 64-bit platforms - see FAQ. It should
>> Just Work to let uLong be always unsigned long,
>> even though that might be "too large"
>> for the data being provided on LP64 systems.
>
> The SCCS history shows there were some "check in, check out then check in
> again" history regarding
> this "32-bit or 64-bit" modification, due to some hotspot failure bug. This
> is the most reasons I decided
> to go with the "working version".

Working is always better than Not Working.

You have my blessing to commit your current changes.
But if I was RE, I would probably do more work on this in the
directions I outlined
- reduce JDK-specific diffs - try to use unmodified zlib
- #include <unistd.h> in zconf.h
- resolve lingering doubts about 64-bit file offset support on 32-bit
Unix systems.

Martin

> Seems like I'm not going to catch tonight's deadline:-), maybe we can try
> some experiments.
>
>>
>> ----
>>
>> You should probably update zconf.h to include unistd.h
>> as if you had run configure, at least on Unix.
>> ?318 #if 0 ? ? ? ? ? /* HAVE_UNISTD_H -- this line is updated by
>> ./configure */
>>
>> ?319 # ?include <sys/types.h> /* for off_t */
>> ?320 # ?include <unistd.h> ? ?/* for SEEK_* and off_t */
>> ?It looks like you won't get large file support on 32-bit systems
>> without struggling with configury stuff. ?Or maybe we never use
>> zlib in the JDK to directly access files via seek and off_t?
>>
> No, the zlib in our code never accesses the file directly. File access is
> done in our own zipfile code..
>


From vincent.ryan at sun.com  Mon Aug 24 17:45:55 2009
From: vincent.ryan at sun.com (vincent.ryan at sun.com)
Date: Mon, 24 Aug 2009 17:45:55 +0000
Subject: hg: jdk7/tl/jdk: 6872048: bad private keys are generated for 2
	specific ECC curves
Message-ID: <20090824174654.AA6E412415@hg.openjdk.java.net>

Changeset: dd997cc0c823
Author:    vinnie
Date:      2009-08-24 18:37 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd997cc0c823

6872048: bad private keys are generated for 2 specific ECC curves
Reviewed-by: wetmore

! src/share/native/sun/security/ec/ec.c
! test/sun/security/ec/TestEC.java



From Xueming.Shen at Sun.COM  Mon Aug 24 21:21:25 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 24 Aug 2009 14:21:25 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com> <4A8E0B48.3030703@sun.com>
	<1ccfd1c10908210103p7c6fdc5fmdde2ad5f69fef9b8@mail.gmail.com>
	<4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
	<4A92D910.2060904@sun.com>
	<1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>
Message-ID: <4A930455.2070508@sun.com>

Martin Buchholz wrote:
> On Mon, Aug 24, 2009 at 11:16, Xueming Shen<Xueming.Shen at sun.com> wrote:
>   
>> Martin Buchholz wrote:
>>     
>>>        mit if you insist!
>>>
>>>    Oh, I see your point. Are you saying this "local change" is not
>>>    necessary since it never gets
>>>    preprocessed?
>>>
>>> No, more than that - the code is defining a derived type u4 from
>>> primitive types - it should not be using other derived types.
>>> BTW, u4 is of size *exactly* 4 bytes, while uLong I think is of size
>>> *at least* 4 bytes, so these are slightly semantically different.
>>>       
>> If you consider we have "already" made the change to make sure uLong is
>> 32-bit, then
>> this should no longer be a problem, yes, semantically we should simply use
>> "unsigned long"
>> here, but it does not make any difference. I made this change with the
>> assumption of that LP64
>> change.
>>
>>     
>>>  Looking again at zlib's types, I see that
>>> uLong is unconditionally typedef'ed to "unsigned long"
>>> so in an unmodified distribution they can be used interchangeably
>>> (although a little unclean - why have a typedef in the first place?)
>>> zlib definitely claims to support 64-bit platforms - see FAQ. It should
>>> Just Work to let uLong be always unsigned long,
>>> even though that might be "too large"
>>> for the data being provided on LP64 systems.
>>>       
>> The SCCS history shows there were some "check in, check out then check in
>> again" history regarding
>> this "32-bit or 64-bit" modification, due to some hotspot failure bug. This
>> is the most reasons I decided
>> to go with the "working version".
>>     
>
> Working is always better than Not Working.
>
> You have my blessing to commit your current changes.
> But if I was RE, I would probably do more work on this in the
> directions I outlined
> - reduce JDK-specific diffs - try to use unmodified zlib
> - #include <unistd.h> in zconf.h
> - resolve lingering doubts about 64-bit file offset support on 32-bit
> Unix systems.
>
>   
I believe 64-bit file offset support has been done in zip_util.c/h 
already in 7 and the latest 6 (don't be
surprised if there is yet another corner case, but I'm pretty much sure 
we are safe on this one).
The current implementation interfaces with the zlib via in/out byte 
buffer. I don't there is anything 64-bit file
offset issue to "resolve" inside zlib1.2.3.

I was reminded that the b72 (tonight deadline) is the last build of m5,  
so to play safe I will hold the change
for m6's first build. Will look into your "reduce JDK-specific diffs", 
please commit yourself for the review:-)

Re:
"I don't see why the rest of the jdk has to be changed,
or why a completely unmodified zlib cannot be used"

Current CRC32 and pack/zip.c expect a 32bit unsigned uint from zlib 
crc32(). If we keep the new crc32 as
"unsigned long", which is 64-bit on 64-bit platform, we have to do 
something such as cast and testing.


Sherman





From martinrb at google.com  Mon Aug 24 21:34:09 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2009 14:34:09 -0700
Subject: zlib1.2.3
In-Reply-To: <4A930455.2070508@sun.com>
References: <4A8C7D62.6070405@sun.com> <4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
	<4A92D910.2060904@sun.com>
	<1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>
	<4A930455.2070508@sun.com>
Message-ID: <1ccfd1c10908241434r10bdaa18s1b4077839236915b@mail.gmail.com>

On Mon, Aug 24, 2009 at 14:21, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Martin Buchholz wrote:

> Re:
> "I don't see why the rest of the jdk has to be changed,
> or why a completely unmodified zlib cannot be used"
>
> Current CRC32 and pack/zip.c expect a 32bit unsigned uint from zlib crc32().
> If we keep the new crc32 as
> "unsigned long", which is 64-bit on 64-bit platform, we have to do something
> such as cast and testing.

I imagine that the only issue with having unsigned long be 64-bit is that
crc32.c will compute a 32-bit integer, it will get widened to 64-bit,
and then narrowed back to 32-bit, which is allowed in C and harmless
(although there might be a warning),
but not in Java, where you have to explicitly cast to throw away the
top 32 bits.

Martin


From jonathan.gibbons at sun.com  Mon Aug 24 21:49:49 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 24 Aug 2009 21:49:49 +0000
Subject: hg: jdk7/tl/langtools: 6869216: testgetallmembers should consistently
	use correct filemanager
Message-ID: <20090824214955.1077912436@hg.openjdk.java.net>

Changeset: c863e90091ee
Author:    jjg
Date:      2009-08-24 14:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c863e90091ee

6869216: testgetallmembers should consistently use correct filemanager
Reviewed-by: darcy

! test/tools/javac/processing/model/testgetallmembers/Main.java



From Xueming.Shen at Sun.COM  Mon Aug 24 22:24:14 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 24 Aug 2009 15:24:14 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908241434r10bdaa18s1b4077839236915b@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com> <4A8EE2D1.2080006@sun.com>
	<1ccfd1c10908221907o3b6d109v7f54bd3272d6dd6f@mail.gmail.com>
	<4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
	<4A92D910.2060904@sun.com>
	<1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>
	<4A930455.2070508@sun.com>
	<1ccfd1c10908241434r10bdaa18s1b4077839236915b@mail.gmail.com>
Message-ID: <4A93130E.3070209@sun.com>

Martin Buchholz wrote:
>
> I imagine that the only issue with having unsigned long be 64-bit is that
> crc32.c will compute a 32-bit integer, it will get widened to 64-bit,
> and then narrowed back to 32-bit, which is allowed in C and harmless
> (although there might be a warning),
> but not in Java, where you have to explicitly cast to throw away the
> top 32 bits.
>
> Martin
>   
Given "uLong" is used widely in zlib.h,  I would like to keep it asis 
(to be 32-bit as we have been doing
for years). So the question is can you live with the following simle 
"local change" in crc32.c. crc32.h therefor
will remained untouched, the same as the original zip (which means the 
crc32 is calculated on 64-bit
actually, I'm not sure the impact of "register u4 c" will have, but 
believe it will use up a full 64-bit register
anyway).

--- /home/sherman/TL/zlib-1.2.3_ORG/crc32.c	Sun Jun 12 16:56:07 2005
+++ ../../../src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c	Mon Aug 24 15:10:22 2009
@@ -216,8 +216,8 @@
 #define DO8 DO1; DO1; DO1; DO1; DO1; DO1; DO1; DO1
 
 /* ========================================================================= */
-unsigned long ZEXPORT crc32(crc, buf, len)
-    unsigned long crc;
+uLong ZEXPORT crc32(crc, buf, len)
+    uLong crc;
     const unsigned char FAR *buf;
     unsigned len;
 {
@@ -234,9 +234,9 @@
 
         endian = 1;
         if (*((unsigned char *)(&endian)))
-            return crc32_little(crc, buf, len);
+            return (uLong)crc32_little(crc, buf, len);
         else
-            return crc32_big(crc, buf, len);
+            return (uLong)crc32_big(crc, buf, len);
     }
 #endif /* BYFOUR */

     crc = crc ^ 0xffffffffUL;


It should be a safe change, and "much less" than the original one:-) If 
you're OK with this, I can go kick start
the build and test.

btw, I really don't like the big/littleendian detecting code...but 
should not be a big deal if mostly we do bulk
calculation.

sherman


From martinrb at google.com  Tue Aug 25 00:16:44 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2009 17:16:44 -0700
Subject: zlib1.2.3
In-Reply-To: <4A93130E.3070209@sun.com>
References: <4A8C7D62.6070405@sun.com> <4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
	<4A92D910.2060904@sun.com>
	<1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>
	<4A930455.2070508@sun.com>
	<1ccfd1c10908241434r10bdaa18s1b4077839236915b@mail.gmail.com>
	<4A93130E.3070209@sun.com>
Message-ID: <1ccfd1c10908241716u68e5a3ben6c9fd08ae0e012ca@mail.gmail.com>

On Mon, Aug 24, 2009 at 15:24, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> I imagine that the only issue with having unsigned long be 64-bit is that
>> crc32.c will compute a 32-bit integer, it will get widened to 64-bit,
>> and then narrowed back to 32-bit, which is allowed in C and harmless
>> (although there might be a warning),
>> but not in Java, where you have to explicitly cast to throw away the
>> top 32 bits.
>>
>> Martin
>>
>
> Given "uLong" is used widely in zlib.h, ?I would like to keep it asis (to be
> 32-bit as we have been doing
> for years). So the question is can you live with the following simle "local
> change" in crc32.c. crc32.h therefor
> will remained untouched, the same as the original zip (which means the crc32
> is calculated on 64-bit
> actually, I'm not sure the impact of "register u4 c" will have, but believe
> it will use up a full 64-bit register
> anyway).
>
> --- /home/sherman/TL/zlib-1.2.3_ORG/crc32.c ? ? Sun Jun 12 16:56:07 2005
> +++ ../../../src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c Mon Aug 24
> 15:10:22 2009
> @@ -216,8 +216,8 @@
> #define DO8 DO1; DO1; DO1; DO1; DO1; DO1; DO1; DO1
>
> /* =========================================================================
> */
> -unsigned long ZEXPORT crc32(crc, buf, len)
> - ? ?unsigned long crc;
> +uLong ZEXPORT crc32(crc, buf, len)
> + ? ?uLong crc;
> ? ?const unsigned char FAR *buf;
> ? ?unsigned len;
> {
> @@ -234,9 +234,9 @@
>
> ? ? ? ?endian = 1;
> ? ? ? ?if (*((unsigned char *)(&endian)))
> - ? ? ? ? ? ?return crc32_little(crc, buf, len);
> + ? ? ? ? ? ?return (uLong)crc32_little(crc, buf, len);
> ? ? ? ?else
> - ? ? ? ? ? ?return crc32_big(crc, buf, len);
> + ? ? ? ? ? ?return (uLong)crc32_big(crc, buf, len);
> ? ?}
> #endif /* BYFOUR */
>
> ? ?crc = crc ^ 0xffffffffUL;

I approve of this compromise, and also
approve of making the corresponding change to
crc32_little and crc32_big, if you wish to do that.

> It should be a safe change, and "much less" than the original one:-) If
> you're OK with this, I can go kick start
> the build and test.
>
> btw, I really don't like the big/littleendian detecting code...but should
> not be a big deal if mostly we do bulk
> calculation.

endian-detection should happen at configure-time, not run time.
But zlib does not have a history of an extensive "configure layer".
And I don't think it is possible to determine endian-ness using
only the C preprocessor.  Hence the current situation.

Martin


From Xueming.Shen at Sun.COM  Tue Aug 25 19:10:50 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Tue, 25 Aug 2009 12:10:50 -0700
Subject: zlib1.2.3
In-Reply-To: <1ccfd1c10908241716u68e5a3ben6c9fd08ae0e012ca@mail.gmail.com>
References: <4A8C7D62.6070405@sun.com> <4A90B96E.6000103@sun.com>
	<1ccfd1c10908231951l5e3b8227g93a836780a4748d6@mail.gmail.com>
	<4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
	<4A92D910.2060904@sun.com>
	<1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>
	<4A930455.2070508@sun.com>
	<1ccfd1c10908241434r10bdaa18s1b4077839236915b@mail.gmail.com>
	<4A93130E.3070209@sun.com>
	<1ccfd1c10908241716u68e5a3ben6c9fd08ae0e012ca@mail.gmail.com>
Message-ID: <4A94373A.4090903@sun.com>

Thanks Martin1

We are very close:-)

Here is the latest webrev, compared to the last one, the only changes are

(1)zcrc.c, the "compromised" change you approved.
(2)undo any change in crc.h
(3)a final tweak in zlib.h, this one is used by nobody and never 
exported. Just to make compile happy

  21 -ZEXTERN const unsigned long FAR * ZEXPORT get_crc_table    OF((void));
  22 +ZEXTERN const uLongf * ZEXPORT get_crc_table    OF((void));

http://cr.openjdk.java.net/~sherman/zlib123/webrev

Tests (all related jar/zip/pack/unpack tests, LargZip, jar c/x/t of 
large(>6g) zip, pack200/unpack200 of rt.jar,
ZlibTest on all standard jdk jar lirbraries) have been done on Solaris 
sparc/i586 32-bit &64-bit, Linux 64-bit,
Windows XpVista 32-bit and 2003 Server 64-bit. One last test is still 
running on a sparc 32-bit (jar up single > 6G file).

Let me know if you guys are OK with  the latest one.

Sherman


Martin Buchholz wrote:
> On Mon, Aug 24, 2009 at 15:24, Xueming Shen<Xueming.Shen at sun.com> wrote:
>   
>> Martin Buchholz wrote:
>>     
>>> I imagine that the only issue with having unsigned long be 64-bit is that
>>> crc32.c will compute a 32-bit integer, it will get widened to 64-bit,
>>> and then narrowed back to 32-bit, which is allowed in C and harmless
>>> (although there might be a warning),
>>> but not in Java, where you have to explicitly cast to throw away the
>>> top 32 bits.
>>>
>>> Martin
>>>
>>>       
>> Given "uLong" is used widely in zlib.h,  I would like to keep it asis (to be
>> 32-bit as we have been doing
>> for years). So the question is can you live with the following simle "local
>> change" in crc32.c. crc32.h therefor
>> will remained untouched, the same as the original zip (which means the crc32
>> is calculated on 64-bit
>> actually, I'm not sure the impact of "register u4 c" will have, but believe
>> it will use up a full 64-bit register
>> anyway).
>>
>> --- /home/sherman/TL/zlib-1.2.3_ORG/crc32.c     Sun Jun 12 16:56:07 2005
>> +++ ../../../src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c Mon Aug 24
>> 15:10:22 2009
>> @@ -216,8 +216,8 @@
>> #define DO8 DO1; DO1; DO1; DO1; DO1; DO1; DO1; DO1
>>
>> /* =========================================================================
>> */
>> -unsigned long ZEXPORT crc32(crc, buf, len)
>> -    unsigned long crc;
>> +uLong ZEXPORT crc32(crc, buf, len)
>> +    uLong crc;
>>    const unsigned char FAR *buf;
>>    unsigned len;
>> {
>> @@ -234,9 +234,9 @@
>>
>>        endian = 1;
>>        if (*((unsigned char *)(&endian)))
>> -            return crc32_little(crc, buf, len);
>> +            return (uLong)crc32_little(crc, buf, len);
>>        else
>> -            return crc32_big(crc, buf, len);
>> +            return (uLong)crc32_big(crc, buf, len);
>>    }
>> #endif /* BYFOUR */
>>
>>    crc = crc ^ 0xffffffffUL;
>>     
>
> I approve of this compromise, and also
> approve of making the corresponding change to
> crc32_little and crc32_big, if you wish to do that.
>
>   
>> It should be a safe change, and "much less" than the original one:-) If
>> you're OK with this, I can go kick start
>> the build and test.
>>
>> btw, I really don't like the big/littleendian detecting code...but should
>> not be a big deal if mostly we do bulk
>> calculation.
>>     
>
> endian-detection should happen at configure-time, not run time.
> But zlib does not have a history of an extensive "configure layer".
> And I don't think it is possible to determine endian-ness using
> only the C preprocessor.  Hence the current situation.
>
> Martin
>   



From martinrb at google.com  Tue Aug 25 20:40:22 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 25 Aug 2009 13:40:22 -0700
Subject: zlib1.2.3
In-Reply-To: <4A94373A.4090903@sun.com>
References: <4A8C7D62.6070405@sun.com> <4A921D7A.1080806@sun.com>
	<1ccfd1c10908240002u1b0ae0bai4a15e75a5cf42ede@mail.gmail.com>
	<4A92D910.2060904@sun.com>
	<1ccfd1c10908241152g6109c800u5a0ef7cf7ea8d146@mail.gmail.com>
	<4A930455.2070508@sun.com>
	<1ccfd1c10908241434r10bdaa18s1b4077839236915b@mail.gmail.com>
	<4A93130E.3070209@sun.com>
	<1ccfd1c10908241716u68e5a3ben6c9fd08ae0e012ca@mail.gmail.com>
	<4A94373A.4090903@sun.com>
Message-ID: <1ccfd1c10908251340q5afd1b7dlc1d1f6a86a5a21db@mail.gmail.com>

On Tue, Aug 25, 2009 at 12:10, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Thanks Martin1
>
> We are very close:-)
>
> Here is the latest webrev, compared to the last one, the only changes are
>
> (1)zcrc.c, the "compromised" change you approved.
> (2)undo any change in crc.h
> (3)a final tweak in zlib.h, this one is used by nobody and never exported.
> Just to make compile happy
>
> ?21 -ZEXTERN const unsigned long FAR * ZEXPORT get_crc_table ? ?OF((void));
> ?22 +ZEXTERN const uLongf * ZEXPORT get_crc_table ? ?OF((void));
>
> http://cr.openjdk.java.net/~sherman/zlib123/webrev
>
> Tests (all related jar/zip/pack/unpack tests, LargZip, jar c/x/t of
> large(>6g) zip, pack200/unpack200 of rt.jar,
> ZlibTest on all standard jdk jar lirbraries) have been done on Solaris
> sparc/i586 32-bit &64-bit, Linux 64-bit,
> Windows XpVista 32-bit and 2003 Server 64-bit. One last test is still
> running on a sparc 32-bit (jar up single > 6G file).
>
> Let me know if you guys are OK with ?the latest one.

Yes, except one detail - the diffs are reversed.

Fix that and feel free to commit.

Regarding the timing - changes to jar/zip are always high risk,
so it is quite reasonable for this change to go in at the beginning of
a milestone cycle.

Martin


From xueming.shen at sun.com  Tue Aug 25 22:25:56 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Tue, 25 Aug 2009 22:25:56 +0000
Subject: hg: jdk7/tl/jdk: 4963968: zlib should be upgraded to current version
	of zlib
Message-ID: <20090825222640.9F5411256B@hg.openjdk.java.net>

Changeset: b115cf946852
Author:    sherman
Date:      2009-08-25 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b115cf946852

4963968: zlib should be upgraded to current version of zlib
Summary: upgrade zlib to the latest ver 1.2.3
Reviewed-by: martin, alanb, ksrini

! make/com/sun/java/pack/Makefile
! make/common/Defs.gmk
! make/java/jli/Makefile
! make/java/zip/FILES_c.gmk
! make/java/zip/Makefile
! make/java/zip/reorder-i586
! make/java/zip/reorder-sparc
! make/java/zip/reorder-sparcv9
! make/sun/splashscreen/FILES_c.gmk
! make/sun/splashscreen/Makefile
- src/share/native/java/util/zip/zlib-1.1.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.1.3/README
- src/share/native/java/util/zip/zlib-1.1.3/compress.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.h
- src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc
- src/share/native/java/util/zip/zlib-1.1.3/example.c
- src/share/native/java/util/zip/zlib-1.1.3/gzio.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.h
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.c
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.h
- src/share/native/java/util/zip/zlib-1.1.3/inffast.c
- src/share/native/java/util/zip/zlib-1.1.3/inffast.h
- src/share/native/java/util/zip/zlib-1.1.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.1.3/inflate.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.1.3/infutil.c
- src/share/native/java/util/zip/zlib-1.1.3/infutil.h
- src/share/native/java/util/zip/zlib-1.1.3/minigzip.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.h
- src/share/native/java/util/zip/zlib-1.1.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.1.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.1.3/zconf.h
- src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.1.3/zlib.h
- src/share/native/java/util/zip/zlib-1.1.3/zutil.c
- src/share/native/java/util/zip/zlib-1.1.3/zutil.h
+ src/share/native/java/util/zip/zlib-1.2.3/ChangeLog
+ src/share/native/java/util/zip/zlib-1.2.3/README
+ src/share/native/java/util/zip/zlib-1.2.3/compress.c
+ src/share/native/java/util/zip/zlib-1.2.3/crc32.h
+ src/share/native/java/util/zip/zlib-1.2.3/deflate.c
+ src/share/native/java/util/zip/zlib-1.2.3/deflate.h
+ src/share/native/java/util/zip/zlib-1.2.3/gzio.c
+ src/share/native/java/util/zip/zlib-1.2.3/infback.c
+ src/share/native/java/util/zip/zlib-1.2.3/inffast.c
+ src/share/native/java/util/zip/zlib-1.2.3/inffast.h
+ src/share/native/java/util/zip/zlib-1.2.3/inffixed.h
+ src/share/native/java/util/zip/zlib-1.2.3/inflate.c
+ src/share/native/java/util/zip/zlib-1.2.3/inflate.h
+ src/share/native/java/util/zip/zlib-1.2.3/inftrees.c
+ src/share/native/java/util/zip/zlib-1.2.3/inftrees.h
+ src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java
+ src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff
+ src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff
+ src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff
+ src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff
+ src/share/native/java/util/zip/zlib-1.2.3/trees.c
+ src/share/native/java/util/zip/zlib-1.2.3/trees.h
+ src/share/native/java/util/zip/zlib-1.2.3/uncompr.c
+ src/share/native/java/util/zip/zlib-1.2.3/zadler32.c
+ src/share/native/java/util/zip/zlib-1.2.3/zconf.h
+ src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c
+ src/share/native/java/util/zip/zlib-1.2.3/zlib.h
+ src/share/native/java/util/zip/zlib-1.2.3/zutil.c
+ src/share/native/java/util/zip/zlib-1.2.3/zutil.h



From joe.darcy at sun.com  Tue Aug 25 23:48:52 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Tue, 25 Aug 2009 23:48:52 +0000
Subject: hg: jdk7/tl/langtools: 6872011: Update printing processor to support
	JSR 308
Message-ID: <20090825234859.40D4912576@hg.openjdk.java.net>

Changeset: 40aca381dcaf
Author:    darcy
Date:      2009-08-25 16:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/40aca381dcaf

6872011: Update printing processor to support JSR 308
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java



From Joe.Darcy at Sun.COM  Wed Aug 26 01:47:27 2009
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Tue, 25 Aug 2009 18:47:27 -0700
Subject: Code review request for trivial doc fix to remove a doc build warning
	on java.util.Properties
Message-ID: <4A94942F.2080105@sun.com>

Hello.

While making some other doc changes, I noticed that a javadoc build 
warning generated for java.util.Properties:

> ../../src/share/classes/java/util/Properties.java:116: warning - Tag 
> @see: missing final '>': "<a 
> href="../../../technotes/tools/windows/native2ascii.html">native2ascii 
> tool for Windows</a>
>
> <p>This class is thread-safe: multiple threads can share a single
> <tt>Properties</tt> object without the need for external 
> synchronization."

could be removed if the @see tags were moved to the convention position 
after the text of the main comment:

--- old/src/share/classes/java/util/Properties.java    2009-08-25 
18:44:26.000000000 -0700
+++ new/src/share/classes/java/util/Properties.java    2009-08-25 
18:44:26.000000000 -0700
@@ -101,12 +101,12 @@
 *    &lt;!ATTLIST entry key CDATA #REQUIRED&gt;
 * </pre>
 *
- * @see <a 
href="../../../technotes/tools/solaris/native2ascii.html">native2ascii 
tool for Solaris</a>
- * @see <a 
href="../../../technotes/tools/windows/native2ascii.html">native2ascii 
tool for Windows</a>
- *
 * <p>This class is thread-safe: multiple threads can share a single
 * <tt>Properties</tt> object without the need for external 
synchronization.
 *
+ * @see <a 
href="../../../technotes/tools/solaris/native2ascii.html">native2ascii 
tool for Solaris</a>
+ * @see <a 
href="../../../technotes/tools/windows/native2ascii.html">native2ascii 
tool for Windows</a>
+ *
 * @author  Arthur van Hoff
 * @author  Michael McCloskey
 * @author  Xueming Shen


The build warning is arguably spurious since the @see tag is properly 
formed, but since following conventions is recommended I think the 
change is fine.

-Joe


From martinrb at google.com  Wed Aug 26 01:50:19 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 25 Aug 2009 18:50:19 -0700
Subject: Code review request for trivial doc fix to remove a doc build 
	warning on java.util.Properties
In-Reply-To: <4A94942F.2080105@sun.com>
References: <4A94942F.2080105@sun.com>
Message-ID: <1ccfd1c10908251850s6133e44dy5c04a02ade1861ff@mail.gmail.com>

Approved.  Thanks for getting rid of this warning that has nagged
engineers for years now!

Martin

On Tue, Aug 25, 2009 at 18:47, Joe Darcy<Joe.Darcy at sun.com> wrote:
> Hello.
>
> While making some other doc changes, I noticed that a javadoc build warning
> generated for java.util.Properties:
>
>> ../../src/share/classes/java/util/Properties.java:116: warning - Tag @see:
>> missing final '>': "<a
>> href="../../../technotes/tools/windows/native2ascii.html">native2ascii tool
>> for Windows</a>
>>
>> <p>This class is thread-safe: multiple threads can share a single
>> <tt>Properties</tt> object without the need for external synchronization."
>
> could be removed if the @see tags were moved to the convention position
> after the text of the main comment:
>
> --- old/src/share/classes/java/util/Properties.java ? ?2009-08-25
> 18:44:26.000000000 -0700
> +++ new/src/share/classes/java/util/Properties.java ? ?2009-08-25
> 18:44:26.000000000 -0700
> @@ -101,12 +101,12 @@
> * ? ?&lt;!ATTLIST entry key CDATA #REQUIRED&gt;
> * </pre>
> *
> - * @see <a
> href="../../../technotes/tools/solaris/native2ascii.html">native2ascii tool
> for Solaris</a>
> - * @see <a
> href="../../../technotes/tools/windows/native2ascii.html">native2ascii tool
> for Windows</a>
> - *
> * <p>This class is thread-safe: multiple threads can share a single
> * <tt>Properties</tt> object without the need for external synchronization.
> *
> + * @see <a
> href="../../../technotes/tools/solaris/native2ascii.html">native2ascii tool
> for Solaris</a>
> + * @see <a
> href="../../../technotes/tools/windows/native2ascii.html">native2ascii tool
> for Windows</a>
> + *
> * @author ?Arthur van Hoff
> * @author ?Michael McCloskey
> * @author ?Xueming Shen
>
>
> The build warning is arguably spurious since the @see tag is properly
> formed, but since following conventions is recommended I think the change is
> fine.
>
> -Joe
>


From Lance.Andersen at Sun.COM  Wed Aug 26 02:16:38 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Tue, 25 Aug 2009 22:16:38 -0400
Subject: Code review request for trivial doc fix to remove a doc build
	warning	on java.util.Properties
In-Reply-To: <4A94942F.2080105@sun.com>
References: <4A94942F.2080105@sun.com>
Message-ID: <4A949B06.1080105@sun.com>

looks fine to me

Joe Darcy wrote:
> Hello.
>
> While making some other doc changes, I noticed that a javadoc build 
> warning generated for java.util.Properties:
>
>> ../../src/share/classes/java/util/Properties.java:116: warning - Tag 
>> @see: missing final '>': "<a 
>> href="../../../technotes/tools/windows/native2ascii.html">native2ascii 
>> tool for Windows</a>
>>
>> <p>This class is thread-safe: multiple threads can share a single
>> <tt>Properties</tt> object without the need for external 
>> synchronization."
>
> could be removed if the @see tags were moved to the convention 
> position after the text of the main comment:
>
> --- old/src/share/classes/java/util/Properties.java    2009-08-25 
> 18:44:26.000000000 -0700
> +++ new/src/share/classes/java/util/Properties.java    2009-08-25 
> 18:44:26.000000000 -0700
> @@ -101,12 +101,12 @@
> *    &lt;!ATTLIST entry key CDATA #REQUIRED&gt;
> * </pre>
> *
> - * @see <a 
> href="../../../technotes/tools/solaris/native2ascii.html">native2ascii 
> tool for Solaris</a>
> - * @see <a 
> href="../../../technotes/tools/windows/native2ascii.html">native2ascii 
> tool for Windows</a>
> - *
> * <p>This class is thread-safe: multiple threads can share a single
> * <tt>Properties</tt> object without the need for external 
> synchronization.
> *
> + * @see <a 
> href="../../../technotes/tools/solaris/native2ascii.html">native2ascii 
> tool for Solaris</a>
> + * @see <a 
> href="../../../technotes/tools/windows/native2ascii.html">native2ascii 
> tool for Windows</a>
> + *
> * @author  Arthur van Hoff
> * @author  Michael McCloskey
> * @author  Xueming Shen
>
>
> The build warning is arguably spurious since the @see tag is properly 
> formed, but since following conventions is recommended I think the 
> change is fine.
>
> -Joe


From Weijun.Wang at Sun.COM  Wed Aug 26 03:20:39 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Wed, 26 Aug 2009 11:20:39 +0800
Subject: URGENT: tl/jdk and tl-gate/jdk not identical
Message-ID: <FE878B9D-DDBB-4058-899B-6E86A18D11F1@sun.com>

http://hg.openjdk.java.net/jdk7/tl-gate/jdk/

79 minutes ago   darcy   6875861: javadoc build warning on  
java.util.Properites from unconventional @see ordering default
5 hours ago      sherman 4963968: zlib should be upgraded to current  
version of zlib
....

http://hg.openjdk.java.net/jdk7/tl/jdk/

5 hours ago      sherman 4963968: zlib should be upgraded to current  
version of zlib
....

For some reason Joe's changeset has not reached the final repo.

Thanks
Max



From Tim.Bell at Sun.COM  Wed Aug 26 04:11:28 2009
From: Tim.Bell at Sun.COM (Tim Bell)
Date: Tue, 25 Aug 2009 21:11:28 -0700
Subject: URGENT: tl/jdk and tl-gate/jdk not identical
In-Reply-To: <FE878B9D-DDBB-4058-899B-6E86A18D11F1@sun.com>
References: <FE878B9D-DDBB-4058-899B-6E86A18D11F1@sun.com>
Message-ID: <4A94B5F0.6050701@sun.com>

Hi Max:
> For some reason Joe's changeset has not reached the final repo.

Thanks for pointing it out.  I kick-started the gate push.

This should be sorted out, although it may take a few minutes
for the email notifications to catch up.

Tim





From tbell at hg.openjdk.java.net  Wed Aug 26 04:08:21 2009
From: tbell at hg.openjdk.java.net (tbell at hg.openjdk.java.net)
Date: Tue, 25 Aug 2009 21:08:21 -0700
Subject: hg: jdk7/tl/jdk: 6875861: javadoc build warning on
	java.util.Properites from unconventional @see ordering
Message-ID: <20090826040855.8D07A125A1@hg.openjdk.java.net>

Changeset: 196c7bb551e7
Author:    darcy
Date:      2009-08-25 18:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/196c7bb551e7

6875861: javadoc build warning on java.util.Properites from unconventional @see ordering
Reviewed-by: martin

! src/share/classes/java/util/Properties.java



From weijun.wang at sun.com  Wed Aug 26 04:23:44 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Wed, 26 Aug 2009 04:23:44 +0000
Subject: hg: jdk7/tl/jdk: 6868864: Kerberos tests fail under windows/cygwin
Message-ID: <20090826042359.EDEEC125A6@hg.openjdk.java.net>

Changeset: 2607e571a6d5
Author:    weijun
Date:      2009-08-26 12:17 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2607e571a6d5

6868864: Kerberos tests fail under windows/cygwin
Reviewed-by: wetmore

! test/sun/security/krb5/auto/basic.sh



From martinrb at google.com  Wed Aug 26 04:37:09 2009
From: martinrb at google.com (martinrb at google.com)
Date: Wed, 26 Aug 2009 04:37:09 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090826043733.62BE8125AF@hg.openjdk.java.net>

Changeset: 69396f593772
Author:    dl
Date:      2009-08-25 19:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69396f593772

6871697: LinkedBlockingQueue Iterator/remove/poll race
Summary: More checks for node.next == node
Reviewed-by: martin, dholmes, chegar

! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java

Changeset: aeaf7b138d90
Author:    dl
Date:      2009-08-25 19:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aeaf7b138d90

6868712: Improve concurrent queue tests
Summary: Fix all known flaky tests, plus minor maintenance
Reviewed-by: martin, chegar

! test/java/util/Collection/BiggernYours.java
! test/java/util/Collection/IteratorAtEnd.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collections/RacingCollections.java
! test/java/util/PriorityQueue/RemoveContains.java
! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java
! test/java/util/concurrent/BlockingQueue/Interrupt.java
+ test/java/util/concurrent/BlockingQueue/LastElement.java
! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java
! test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java
! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java
! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java
! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java
! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
! test/java/util/concurrent/ConcurrentQueues/GCRetention.java
! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java
+ test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java
! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java
- test/java/util/concurrent/LinkedBlockingQueue/LastElement.java
- test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java



From Ulf.Zibis at gmx.de  Wed Aug 26 09:59:54 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 26 Aug 2009 11:59:54 +0200
Subject: review request for 6798511/6860431: Include functionality of Surrogate
	in Character
Message-ID: <4A95079A.8080803@gmx.de>

Hi all,

I have put all important things of sun.nio.cs.Surrogate to java.* 
packages, I guess. We likely could get rid of it.

See: https://bugs.openjdk.java.net/show_bug.cgi?id=100104


Some comments:
================
     public static int toChars(int codePoint, char[] dst, int dstIndex) {
-        if (codePoint < 0 || codePoint > MAX_CODE_POINT) {
-            throw new IllegalArgumentException();
-        }
-        if (codePoint < MIN_SUPPLEMENTARY_CODE_POINT) {
-            dst[dstIndex] = (char) codePoint;
-            return 1;
-        }
-        toSurrogates(codePoint, dst, dstIndex);
+        if (codePoint >= MIN_CODE_POINT) {
+            if (codePoint < MIN_SUPPLEMENTARY_CODE_POINT) {
+                dst[dstIndex] = (char)codePoint;
+                return 1;
+            }
+            if (codePoint <= MAX_CODE_POINT)
+                return toSurrogates(codePoint, dst, dstIndex);
+        }
+        throw new IllegalArgumentException();
+    }
----------------
saves 1 compare in case of code point is in BMP
================
+    public static char[] toChars(int codePoint) {
+        if (codePoint >= MIN_CODE_POINT) {
+            char[] result;
+            if (codePoint < MIN_SUPPLEMENTARY_CODE_POINT) {
+                result = C1.clone();
----------------
I guess cloning is faster than new instantiation, as fresh one has to be 
initialized by 0s, but not sure
================
+    static int toSurrogates(int codePoint, char[] dst, int index) {
+        // We write elements "backwards" to guarantee all-or-nothing // 
TODO: isn't forward faster ?
+        dst[index+1] = lowSurrogate(codePoint);
+        dst[index] = highSurrogate(codePoint);
----------------
IMO this guarantee is nowhere needed, so why potentially waste performance ?
================
-        // Pass 2: Allocate and fill in char[]
-        char[] v = new char[n];
-        for (int i = offset, j = 0; i < offset + count; i++) {
-            int c = codePoints[i];
-            if (c < Character.MIN_SUPPLEMENTARY_CODE_POINT) {
-                v[j++] = (char) c;
-            } else {
-                Character.toSurrogates(c, v, j);
-                j += 2;
-            }
-        }
-
-        this.value  = v;
+        // Pass 2: Allocate and fill in char[]
+        for (int i = offset, j = 0; i < offset + count; i++) {
+            int c = codePoints[i];
+            if (c < Character.MIN_SUPPLEMENTARY_CODE_POINT)
+                value[j++] = (char)c;
+            else
+                j += Character.toSurrogates(c, value, j);
         }
----------------
I guess HotSpot is aware of immutability of String, so no need to 
locally buffer v expletive to save indirection and against concurrent 
modifications.
================


IMO code nesting should indent 4 spaces, but line continuation should 
indent 8 spaces

-Ulf




From Xueming.Shen at Sun.COM  Wed Aug 26 18:02:44 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Wed, 26 Aug 2009 11:02:44 -0700
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A95079A.8080803@gmx.de>
References: <4A95079A.8080803@gmx.de>
Message-ID: <4A9578C4.8060801@sun.com>

Ulf,

"get rid of sun.nio.cs.Surrogate" itself is not a sufficient enough 
reason to add bunch of new supplementary
support related APIs into Character and CharBuffer classes.  You 
probably need to demonstrate more use
scenarios to show/prove why these new APIs are needed, why they can not 
be easily achieved by using existing
APIs and especially you should ask yourself first if these APIs 
will/should be used/needed by "general public"
or they are just "specifically" needed by your current application/project.

For example, the isBMP(int), it might be convenient, but it can be 
easily archived by the one line code

(int)(char)codePoint == codePoint;

or more readable form

    codePoint < Character.MIN_SUPPLEMENTARY_COE_POINT;

I'm not saying we can NOT add isBMP() (I know icu4j's UCharacter class does have one), just
believe it's arguably not necessary.

Same as the pair

-- static char highSurrogate(int codePoint);
-- static char lowSurrogate(int codePoint);
-- CharBuffer.putCodePoint(int)

In "normal use case", the Character.toChars(int codePoint) is good enough cover them all.

Masayoshi is one of the lead engineers that designed most of the Unicode 
supplementary character
support APIs back in 1.5, he might give us some thoughts on this one.

Sherman

Ulf Zibis wrote:
> Hi all,
>
> I have put all important things of sun.nio.cs.Surrogate to java.* 
> packages, I guess. We likely could get rid of it.
>
> See: https://bugs.openjdk.java.net/show_bug.cgi?id=100104
>
>



From Xueming.Shen at Sun.COM  Wed Aug 26 19:01:15 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Wed, 26 Aug 2009 12:01:15 -0700
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A95079A.8080803@gmx.de>
References: <4A95079A.8080803@gmx.de>
Message-ID: <4A95867B.6070300@sun.com>

Ulf Zibis wrote:
> Hi all,
>
> I have put all important things of sun.nio.cs.Surrogate to java.* 
> packages, I guess. We likely could get rid of it.
>
> See: https://bugs.openjdk.java.net/show_bug.cgi?id=100104
>

- Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see
jdk1.7.0/src.zip)

Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the code in the
generated source file have exactly the same line number as they appear in the
original source file.

Sherman



From martinrb at google.com  Thu Aug 27 01:24:27 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Aug 2009 18:24:27 -0700
Subject: review request for 6798511/6860431: Include functionality of 
	Surrogate in Character
In-Reply-To: <4A95079A.8080803@gmx.de>
References: <4A95079A.8080803@gmx.de>
Message-ID: <1ccfd1c10908261824t2c56958eqe85c9c52feaae63a@mail.gmail.com>

On Wed, Aug 26, 2009 at 02:59, Ulf Zibis<Ulf.Zibis at gmx.de> wrote:
> Hi all,
>
> I have put all important things of sun.nio.cs.Surrogate to java.* packages,
> I guess. We likely could get rid of it.

I am in principle of adding the method isBMP to Character.java
(I did write it!) but I was hoping we can find a better name for it...
Hmmmmm..... The Unicode Glossary uses BMP consistently,
so maybe isBMP is the best we can come up with?

How about isBMPCodePoint?

http://unicode.org/glossary/#BMP_code_point

Yeah, I think that's not too bad.

Martin


> See: https://bugs.openjdk.java.net/show_bug.cgi?id=100104
>
>
> Some comments:
> ================
> ? ?public static int toChars(int codePoint, char[] dst, int dstIndex) {
> - ? ? ? ?if (codePoint < 0 || codePoint > MAX_CODE_POINT) {
> - ? ? ? ? ? ?throw new IllegalArgumentException();
> - ? ? ? ?}
> - ? ? ? ?if (codePoint < MIN_SUPPLEMENTARY_CODE_POINT) {
> - ? ? ? ? ? ?dst[dstIndex] = (char) codePoint;
> - ? ? ? ? ? ?return 1;
> - ? ? ? ?}
> - ? ? ? ?toSurrogates(codePoint, dst, dstIndex);
> + ? ? ? ?if (codePoint >= MIN_CODE_POINT) {
> + ? ? ? ? ? ?if (codePoint < MIN_SUPPLEMENTARY_CODE_POINT) {
> + ? ? ? ? ? ? ? ?dst[dstIndex] = (char)codePoint;
> + ? ? ? ? ? ? ? ?return 1;
> + ? ? ? ? ? ?}
> + ? ? ? ? ? ?if (codePoint <= MAX_CODE_POINT)
> + ? ? ? ? ? ? ? ?return toSurrogates(codePoint, dst, dstIndex);
> + ? ? ? ?}
> + ? ? ? ?throw new IllegalArgumentException();
> + ? ?}
> ----------------
> saves 1 compare in case of code point is in BMP

Yes.  A good change.

> ================
> + ? ?public static char[] toChars(int codePoint) {
> + ? ? ? ?if (codePoint >= MIN_CODE_POINT) {
> + ? ? ? ? ? ?char[] result;
> + ? ? ? ? ? ?if (codePoint < MIN_SUPPLEMENTARY_CODE_POINT) {
> + ? ? ? ? ? ? ? ?result = C1.clone();
> ----------------
> I guess cloning is faster than new instantiation, as fresh one has to be
> initialized by 0s, but not sure

Cloning has to initialize as well, with the original contents.
Often there is special support for zeroing newly allocated objects.
So I think this is a bad idea.

> ================
> + ? ?static int toSurrogates(int codePoint, char[] dst, int index) {
> + ? ? ? ?// We write elements "backwards" to guarantee all-or-nothing //
> TODO: isn't forward faster ?
> + ? ? ? ?dst[index+1] = lowSurrogate(codePoint);
> + ? ? ? ?dst[index] = highSurrogate(codePoint);
> ----------------
> IMO this guarantee is nowhere needed, so why potentially waste performance ?

All-or-nothing is a fundamental software reliability principle.
Why have your data structure in a corrupted state
if it is not too onerous to avoid it?
The difference in behavior is certainly user-visible.

> ================
> - ? ? ? ?// Pass 2: Allocate and fill in char[]
> - ? ? ? ?char[] v = new char[n];
> - ? ? ? ?for (int i = offset, j = 0; i < offset + count; i++) {
> - ? ? ? ? ? ?int c = codePoints[i];
> - ? ? ? ? ? ?if (c < Character.MIN_SUPPLEMENTARY_CODE_POINT) {
> - ? ? ? ? ? ? ? ?v[j++] = (char) c;
> - ? ? ? ? ? ?} else {
> - ? ? ? ? ? ? ? ?Character.toSurrogates(c, v, j);
> - ? ? ? ? ? ? ? ?j += 2;
> - ? ? ? ? ? ?}
> - ? ? ? ?}
> -
> - ? ? ? ?this.value ?= v;
> + ? ? ? ?// Pass 2: Allocate and fill in char[]
> + ? ? ? ?for (int i = offset, j = 0; i < offset + count; i++) {
> + ? ? ? ? ? ?int c = codePoints[i];
> + ? ? ? ? ? ?if (c < Character.MIN_SUPPLEMENTARY_CODE_POINT)
> + ? ? ? ? ? ? ? ?value[j++] = (char)c;
> + ? ? ? ? ? ?else
> + ? ? ? ? ? ? ? ?j += Character.toSurrogates(c, value, j);
> ? ? ? ?}
> ----------------
> I guess HotSpot is aware of immutability of String, so no need to locally
> buffer v expletive to save indirection and against concurrent modifications.

I like the simplification of this method a lot, but it actually helps
hotspot a little
to hold the new array in a local and assign it to a field at the end
of the constructor.
This sort of thing (copying a field into a local) is done in
java.util.concurrent a lot.

---

It would help to separate cosmetic and "real" changes to get them
reviewed and accepted.


Martin


From joe.darcy at sun.com  Thu Aug 27 02:36:18 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 27 Aug 2009 02:36:18 +0000
Subject: hg: jdk7/tl/langtools: 6548708: Annotation processing should free
	service loader if there are no processors
Message-ID: <20090827023623.CE60212647@hg.openjdk.java.net>

Changeset: 25f15fdd168a
Author:    darcy
Date:      2009-08-26 19:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/25f15fdd168a

6548708: Annotation processing should free service loader if there are no processors
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java



From gkorland at gmail.com  Thu Aug 27 12:31:13 2009
From: gkorland at gmail.com (Guy Korland)
Date: Thu, 27 Aug 2009 15:31:13 +0300
Subject: java.util.LinkedList clear() improvement
Message-ID: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>

Hi,


It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).

Meaning:


      308     public void clear() {

      309         Entry<E> e = header.next;

      310         while (e != header) {

      311             Entry<E> next = e.next;

      312             e.next = e.previous = null;

      313             e.element = null;

      314             e = next;

      315         }

      316         header.next = header.previous = header;

      317         size = 0;

      318         modCount++;

      319     }


A better implementations would be:


      308     public void clear() {

      309         header.next = header.previous = header;

      310         size = 0;

      311         modCount++;

      312     }


Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090827/c3e14567/attachment.html>

From otto at informatik.rwth-aachen.de  Thu Aug 27 12:35:15 2009
From: otto at informatik.rwth-aachen.de (Carsten Otto)
Date: Thu, 27 Aug 2009 14:35:15 +0200
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
Message-ID: <20090827123515.GX32718@daedalus.informatik.rwth-aachen.de>

On Thu, Aug 27, 2009 at 03:31:13PM +0300, Guy Korland wrote:
> It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).

With your solution one would be possible to continue working (traversing)
on an empty (read: emptied) list. I don't think this is desired.

Best regards,
-- 
Carsten Otto           otto at informatik.rwth-aachen.de
LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
RWTH Aachen            phone: +49 241 80-21211
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090827/e313b5e5/signature.asc>

From gkorland at gmail.com  Thu Aug 27 12:41:17 2009
From: gkorland at gmail.com (Guy Korland)
Date: Thu, 27 Aug 2009 15:41:17 +0300
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <20090827123515.GX32718@daedalus.informatik.rwth-aachen.de>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com> 
	<20090827123515.GX32718@daedalus.informatik.rwth-aachen.de>
Message-ID: <79be5fa30908270541s1248fb3embf95d6c4bbb930be@mail.gmail.com>

First, LinkedList by definition is not thread safe so there's no need
to care about concurrency.
Second this is what?modCount is all about, preventing an iterator to
keep on working.
Guy

On Thu, Aug 27, 2009 at 3:35 PM, Carsten Otto
<otto at informatik.rwth-aachen.de> wrote:
>
> On Thu, Aug 27, 2009 at 03:31:13PM +0300, Guy Korland wrote:
> > It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).
>
> With your solution one would be possible to continue working (traversing)
> on an empty (read: emptied) list. I don't think this is desired.
>
> Best regards,
> --
> Carsten Otto ? ? ? ? ? otto at informatik.rwth-aachen.de
> LuFG Informatik 2 ? ? ?http://verify.rwth-aachen.de/otto/
> RWTH Aachen ? ? ? ? ? ?phone: +49 241 80-21211
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkqWfYMACgkQjUF4jpCSQBQfnwCeIPkTnCT6XgmYUKBJFV/fhHQl
> vk0AoOh74vYjVStadJovFMgYuNnH7iQp
> =CWub
> -----END PGP SIGNATURE-----
>



--
Guy Korland


From maurizio.cimadamore at sun.com  Thu Aug 27 12:45:34 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Thu, 27 Aug 2009 12:45:34 +0000
Subject: hg: jdk7/tl/langtools: 6840638: Project Coin: Improved Type Inference
	for Generic Instance Creation (aka 'diamond')
Message-ID: <20090827124540.6B77212692@hg.openjdk.java.net>

Changeset: 8109aa93b212
Author:    mcimadamore
Date:      2009-08-27 13:40 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8109aa93b212

6840638: Project Coin: Improved Type Inference for Generic Instance Creation (aka 'diamond')
Summary: diamond operator implementation (simple approach)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/generics/diamond/neg/Neg01.java
+ test/tools/javac/generics/diamond/neg/Neg01.out
+ test/tools/javac/generics/diamond/neg/Neg02.java
+ test/tools/javac/generics/diamond/neg/Neg02.out
+ test/tools/javac/generics/diamond/neg/Neg03.java
+ test/tools/javac/generics/diamond/neg/Neg03.out
+ test/tools/javac/generics/diamond/neg/Neg04.java
+ test/tools/javac/generics/diamond/neg/Neg04.out
+ test/tools/javac/generics/diamond/neg/Neg05.java
+ test/tools/javac/generics/diamond/neg/Neg05.out
+ test/tools/javac/generics/diamond/pos/Pos01.java
+ test/tools/javac/generics/diamond/pos/Pos02.java
+ test/tools/javac/generics/diamond/pos/Pos03.java
+ test/tools/javac/generics/diamond/pos/Pos04.java



From Ulf.Zibis at gmx.de  Thu Aug 27 13:33:41 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 27 Aug 2009 15:33:41 +0200
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <1ccfd1c10908261824t2c56958eqe85c9c52feaae63a@mail.gmail.com>
References: <4A95079A.8080803@gmx.de>
	<1ccfd1c10908261824t2c56958eqe85c9c52feaae63a@mail.gmail.com>
Message-ID: <4A968B35.7020800@gmx.de>

Martin, thanks for your review ...


Am 27.08.2009 03:24, Martin Buchholz schrieb:
> On Wed, Aug 26, 2009 at 02:59, Ulf Zibis<Ulf.Zibis at gmx.de> wrote:
>   
>> Hi all,
>>
>> I have put all important things of sun.nio.cs.Surrogate to java.* packages,
>> I guess. We likely could get rid of it.
>>     
>
> I am in principle of adding the method isBMP to Character.java
> (I did write it!) but I was hoping we can find a better name for it...
>   

I had the same thought, but just referred to the elder. ;-)

> Hmmmmm..... The Unicode Glossary uses BMP consistently,
> so maybe isBMP is the best we can come up with?
>
> How about isBMPCodePoint?
>   

This feels best for me too.

> http://unicode.org/glossary/#BMP_code_point
>
> Yeah, I think that's not too bad.
>
> Martin
>
>
>   
>> See: https://bugs.openjdk.java.net/show_bug.cgi?id=100104
>>
>>
>> ================
>> +    public static char[] toChars(int codePoint) {
>> +        if (codePoint >= MIN_CODE_POINT) {
>> +            char[] result;
>> +            if (codePoint < MIN_SUPPLEMENTARY_CODE_POINT) {
>> +                result = C1.clone();
>> ----------------
>> I guess cloning is faster than new instantiation, as fresh one has to be
>> initialized by 0s, but not sure
>>     
>
> Cloning has to initialize as well, with the original contents.
> Often there is special support for zeroing newly allocated objects.
> So I think this is a bad idea.
>
>   

Sounds reasonable.
In case of more complicated objects but arrays, can cloning be faster?

>> ================
>> +    static int toSurrogates(int codePoint, char[] dst, int index) {
>> +        // We write elements "backwards" to guarantee all-or-nothing //
>> TODO: isn't forward faster ?
>> +        dst[index+1] = lowSurrogate(codePoint);
>> +        dst[index] = highSurrogate(codePoint);
>> ----------------
>> IMO this guarantee is nowhere needed, so why potentially waste performance ?
>>     
>
> All-or-nothing is a fundamental software reliability principle.
> Why have your data structure in a corrupted state
> if it is not too onerous to avoid it?
> The difference in behavior is certainly user-visible.
>   

OK, ...but if there is a speed advantage, we could note this in javadoc 
(as is just happens for invalid surrogate input in the calling method 
for the same reason).
Anyway, in current state of HotSpot optimization, there seems to be no 
advantage according Christian Thalinger.

>   
>> ================
>> -        // Pass 2: Allocate and fill in char[]
>> -        char[] v = new char[n];
>> -        for (int i = offset, j = 0; i < offset + count; i++) {
>> -            int c = codePoints[i];
>> -            if (c < Character.MIN_SUPPLEMENTARY_CODE_POINT) {
>> -                v[j++] = (char) c;
>> -            } else {
>> -                Character.toSurrogates(c, v, j);
>> -                j += 2;
>> -            }
>> -        }
>> -
>> -        this.value  = v;
>> +        // Pass 2: Allocate and fill in char[]
>> +        for (int i = offset, j = 0; i < offset + count; i++) {
>> +            int c = codePoints[i];
>> +            if (c < Character.MIN_SUPPLEMENTARY_CODE_POINT)
>> +                value[j++] = (char)c;
>> +            else
>> +                j += Character.toSurrogates(c, value, j);
>>        }
>> ----------------
>> I guess HotSpot is aware of immutability of String, so no need to locally
>> buffer v expletive to save indirection and against concurrent modifications.
>>     
>
> I like the simplification of this method a lot, but it actually helps
> hotspot a little
> to hold the new array in a local and assign it to a field at the end
> of the constructor.
>   

Okay, so we have to wait for HotSpot being able to "see" that
(1) first holding the variable locally would increase speed
(2) this is thread safe, as we are in constructor, so no concurrent 
modification can happen.
(3) no method in class String allows modification of content of array 
"value" after first initialization.

* Even javac could "see" that, and do the optimization on byte code 
level. (maybe anti-confusion technique is needed for the debugger, 
...but we also accept, that debugger runs into a StringBuilder#append() 
loop on base of a _single_ char[] in case of _multiple_ string 
concatenation.)


Martin, what do you think about adding code point accessors to 
java.nio.CharBuffer (see my X-Buffer patch) ?


-Ulf


> This sort of thing (copying a field into a local) is done in
> java.util.concurrent a lot.
>
> ---
>
> It would help to separate cosmetic and "real" changes to get them
> reviewed and accepted.
>
>
> Martin
>
>
>   



From Thomas.Hawtin at Sun.COM  Thu Aug 27 13:37:50 2009
From: Thomas.Hawtin at Sun.COM (Tom Hawtin)
Date: Thu, 27 Aug 2009 14:37:50 +0100
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
Message-ID: <4A968C2E.8020308@sun.com>

Guy Korland wrote:

> It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).

The code is like that on purpose(!). It was done to help GC, in mustang 
IIRC. There really isn't a problem with clear() being O(n) - it's going 
to take at least O(n) to populate it, and in reality *many* times more 
cycles.

Tom


From Ulf.Zibis at gmx.de  Thu Aug 27 13:49:33 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 27 Aug 2009 15:49:33 +0200
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A95867B.6070300@sun.com>
References: <4A95079A.8080803@gmx.de> <4A95867B.6070300@sun.com>
Message-ID: <4A968EED.7040700@gmx.de>

Am 26.08.2009 21:01, Xueming Shen schrieb:
>
> > - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see 
> jdk1.7.0/src.zip)
>
> Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the 
> code in the
> generated source file have exactly the same line number as they appear 
> in the
> original source file.

I have thought that before, but I _don't understand_ the *real value* 
against having "nice" code in externally delivered src.zip.
Some time ago it was always annoying to me when debugger ran in that 
code, or I was just looking, how it works. (endless scrolling and often 
I oversaw the tail behind numbers of blank lines (I don't have line 
numbers on in my editor)).
In contrast in generator output of SingleByte-X.java you don't care 
about line numbers, although it's in private sun package.

-Ulf




From gkorland at gmail.com  Thu Aug 27 14:18:55 2009
From: gkorland at gmail.com (Guy Korland)
Date: Thu, 27 Aug 2009 17:18:55 +0300
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <4A968C2E.8020308@sun.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com> 
	<4A968C2E.8020308@sun.com>
Message-ID: <79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com>

How does it help the GC?
As I understand the M&S algorithm, there's no real advantages in doing so.

In fact in many places to "null" references is considered to be an
anti pattern in java.

Guy

On Thu, Aug 27, 2009 at 4:37 PM, Tom Hawtin<Thomas.Hawtin at sun.com> wrote:
> Guy Korland wrote:
>
>> It seems like linkedList.clear() can be easily fixed to O(1) instead of
>> O(n).
>
> The code is like that on purpose(!). It was done to help GC, in mustang
> IIRC. There really isn't a problem with clear() being O(n) - it's going to
> take at least O(n) to populate it, and in reality *many* times more cycles.
>
> Tom
>



-- 
Guy Korland


From Ulf.Zibis at gmx.de  Thu Aug 27 16:03:19 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 27 Aug 2009 18:03:19 +0200
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A9578C4.8060801@sun.com>
References: <4A95079A.8080803@gmx.de> <4A9578C4.8060801@sun.com>
Message-ID: <4A96AE47.7020201@gmx.de>

Sherman,

thanks for your detailed review.

Am 26.08.2009 20:02, Xueming Shen schrieb:
> Ulf,
>
> "get rid of sun.nio.cs.Surrogate" itself is not a sufficient enough 
> reason to add bunch of new supplementary
> support related APIs into Character and CharBuffer classes.  You 
> probably need to demonstrate more use
> scenarios to show/prove why these new APIs are needed, why they can 
> not be easily achieved by using existing
> APIs and especially you should ask yourself first if these APIs 
> will/should be used/needed by "general public"
> or they are just "specifically" needed by your current 
> application/project.

Well yes, most of the use scenarios I see in charset processing.  ;-) I 
guess one can find more use scenarios in existing JDK e.g. visualization 
and keyboard input of  surrogate chars / supplementary code points in 
Swing package. On the other hand I have total code base and footprint 
size in mind.

Alternatively subclassing sun.nio.cs.Surrogate from Character would be 
straight forward. (Unfortunately Character class is final. Is that 
mandatory?)
... and this would not cover my enhancements in CharBuffer.

>
> For example, the isBMP(int), it might be convenient, but it can be 
> easily archived by the one line code
>
> (int)(char)codePoint == codePoint;

We still have isSupplementaryCodePoint(int), so IMHO additionally having 
isBMPCodePoint(int) would be a good pair.

On the other hand, there are still many public methods in the API witch 
can be "easily archived by one line code", especially in class 
Character, even plenty of duplicate (or XYZ+1 valued) public constants.

e.g:
        public static UnicodeBlock of(char c) {
            return of((int)c);
        }


>
> or more readable form
>
>    codePoint < Character.MIN_SUPPLEMENTARY_COE_POINT;

correction: ;-)
     codePoint >= MIN_CODE_POINT) && codePoint < 
MIN_SUPPLEMENTARY_CODE_POINT

>
> I'm not saying we can NOT add isBMP() (I know icu4j's UCharacter class 
> does have one), just
> believe it's arguably not necessary.
>
> Same as the pair
>
> -- static char highSurrogate(int codePoint);
> -- static char lowSurrogate(int codePoint);
> -- CharBuffer.putCodePoint(int)
>
> In "normal use case", the Character.toChars(int codePoint) is good 
> enough cover them all.

Hm, yes, but what's about performance ?
- instantiating a new char[]
- boxing the char(s) into
- invoking *bulk* method for just 1 (potentially, but rare 2) char(s)
   (resolves to put(char[], int, int) including checkBounds(int, int, int) )

And yes, we can make CharBuffer#putCodePoint(int) using /Charset 
helpers/ sun.nio.cs.Surrogate#high(int) + sun.nio.cs.Surrogate#low(int) 
if there is no correspondent in Character class. But is that good design ?


-Ulf




From Christopher.Hegarty at Sun.COM  Thu Aug 27 16:01:46 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland)
Date: Thu, 27 Aug 2009 17:01:46 +0100
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
	<4A968C2E.8020308@sun.com>
	<79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com>
Message-ID: <4A96ADEA.6040705@sun.com>

I think this change was made to address:

4863813: Stressing single LinkedList from multiple threads causes 
heapspace to completely

   http://bugs.sun.com/view_bug.do?bug_id=4863813

-Chris.

Guy Korland wrote:
> How does it help the GC?
> As I understand the M&S algorithm, there's no real advantages in doing so.
> 
> In fact in many places to "null" references is considered to be an
> anti pattern in java.
> 
> Guy
> 
> On Thu, Aug 27, 2009 at 4:37 PM, Tom Hawtin<Thomas.Hawtin at sun.com> wrote:
>> Guy Korland wrote:
>>
>>> It seems like linkedList.clear() can be easily fixed to O(1) instead of
>>> O(n).
>> The code is like that on purpose(!). It was done to help GC, in mustang
>> IIRC. There really isn't a problem with clear() being O(n) - it's going to
>> take at least O(n) to populate it, and in reality *many* times more cycles.
>>
>> Tom
>>
> 
> 
> 


From Ulf.Zibis at gmx.de  Thu Aug 27 16:07:53 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 27 Aug 2009 18:07:53 +0200
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <1ccfd1c10908261824t2c56958eqe85c9c52feaae63a@mail.gmail.com>
References: <4A95079A.8080803@gmx.de>
	<1ccfd1c10908261824t2c56958eqe85c9c52feaae63a@mail.gmail.com>
Message-ID: <4A96AF59.4030600@gmx.de>

Am 27.08.2009 03:24, Martin Buchholz schrieb:
>
> ---
>
> It would help to separate cosmetic and "real" changes to get them
> reviewed and accepted.
>
>
>   

I've thought of that, but how to deal best? 2 changesets for 1 Bug Id ?

-Ulf




From Kelly.Ohair at Sun.COM  Thu Aug 27 16:44:45 2009
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 27 Aug 2009 09:44:45 -0700
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A968EED.7040700@gmx.de>
References: <4A95079A.8080803@gmx.de> <4A95867B.6070300@sun.com>
	<4A968EED.7040700@gmx.de>
Message-ID: <4A96B7FD.1010305@sun.com>



Ulf Zibis wrote:
> Am 26.08.2009 21:01, Xueming Shen schrieb:
>>
>> > - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see 
>> jdk1.7.0/src.zip)
>>
>> Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the 
>> code in the
>> generated source file have exactly the same line number as they appear 
>> in the
>> original source file.
> 
> I have thought that before, but I _don't understand_ the *real value* 
> against having "nice" code in externally delivered src.zip.
> Some time ago it was always annoying to me when debugger ran in that 
> code, or I was just looking, how it works. (endless scrolling and often 
> I oversaw the tail behind numbers of blank lines (I don't have line 
> numbers on in my editor)).
> In contrast in generator output of SingleByte-X.java you don't care 
> about line numbers, although it's in private sun package.
> 
> -Ulf
> 
> 

Regardless of the outcome of this discussion, could we please consider
separating the changes to the make/tools files from the rest, unless
there is some dependency between the two.
So if at all possible, could we get separate changesets on these changes?

---

As I recall on the line numbers, the issue is that the classfiles will
permanently record line numbers for the source, so the goal was to make
sure that regardless where the classfiles came from (open or closed jdk)
and where the src.zip came from (open or closed jdk), it would all work
and any debugger will have a fighting chance of showing you the right
line in the source.
So these extra blank lines might not look 'nice', but having a debugger
point you at the wrong lines is much worse.

-kto


From gkorland at gmail.com  Thu Aug 27 17:23:19 2009
From: gkorland at gmail.com (Guy Korland)
Date: Thu, 27 Aug 2009 20:23:19 +0300
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <4A96ADEA.6040705@sun.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com> 
	<4A968C2E.8020308@sun.com>
	<79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com> 
	<4A96ADEA.6040705@sun.com>
Message-ID: <79be5fa30908271023j43634be4t4061599fe3ff9e03@mail.gmail.com>

First I don't think this is the same issue, in the clear case, there's
no reference from the root to any of the entries.
Second as I know any MarkAndSweep GC should not suffer from such issue.
Since the sweep phase should collect any unreachable entry no matter
how many dead references point to it.

Guy




On Thu, Aug 27, 2009 at 7:01 PM, Christopher Hegarty -Sun Microsystems
Ireland<Christopher.Hegarty at sun.com> wrote:
> I think this change was made to address:
>
> 4863813: Stressing single LinkedList from multiple threads causes heapspace
> to completely
>
> ?http://bugs.sun.com/view_bug.do?bug_id=4863813
>
> -Chris.
>
> Guy Korland wrote:
>>
>> How does it help the GC?
>> As I understand the M&S algorithm, there's no real advantages in doing so.
>>
>> In fact in many places to "null" references is considered to be an
>> anti pattern in java.
>>
>> Guy
>>
>> On Thu, Aug 27, 2009 at 4:37 PM, Tom Hawtin<Thomas.Hawtin at sun.com> wrote:
>>>
>>> Guy Korland wrote:
>>>
>>>> It seems like linkedList.clear() can be easily fixed to O(1) instead of
>>>> O(n).
>>>
>>> The code is like that on purpose(!). It was done to help GC, in mustang
>>> IIRC. There really isn't a problem with clear() being O(n) - it's going
>>> to
>>> take at least O(n) to populate it, and in reality *many* times more
>>> cycles.
>>>
>>> Tom
>>>
>>
>>
>>
>



-- 
Guy Korland


From martinrb at google.com  Thu Aug 27 17:24:04 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 27 Aug 2009 10:24:04 -0700
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <4A96ADEA.6040705@sun.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
	<4A968C2E.8020308@sun.com>
	<79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com>
	<4A96ADEA.6040705@sun.com>
Message-ID: <1ccfd1c10908271024u6efd300xc0ce74ede606dfaa@mail.gmail.com>

Very interesting - thanks for the pointer to the bug id.
Chris, could you update the bug report to contain a (public) diff
of the actual changes that were made?
The bug report does not mention clear().

Curiously, the jsr166 team has been working on fixing the same
kinds of issues in java.util.concurrent queue implementations recently.
At least one clear() implementation was intentionally
changed from O(1) to O(N) for correctness.

For LinkedList.clear(), I think we might be able to get an optimal
hybrid solution,
that would unlink just the 2 immediate neighbors of the header node (if any),
remaining O(1), but also being generational-GC-friendly (e.g. if an
existing Node
was tenured - avoid links from a dead tenured Node to a live Node).

Martin

On Thu, Aug 27, 2009 at 09:01, Christopher Hegarty -Sun Microsystems
Ireland<Christopher.Hegarty at sun.com> wrote:
> I think this change was made to address:
>
> 4863813: Stressing single LinkedList from multiple threads causes heapspace
> to completely
>
> ?http://bugs.sun.com/view_bug.do?bug_id=4863813
>
> -Chris.
>
> Guy Korland wrote:
>>
>> How does it help the GC?
>> As I understand the M&S algorithm, there's no real advantages in doing so.
>>
>> In fact in many places to "null" references is considered to be an
>> anti pattern in java.
>>
>> Guy
>>
>> On Thu, Aug 27, 2009 at 4:37 PM, Tom Hawtin<Thomas.Hawtin at sun.com> wrote:
>>>
>>> Guy Korland wrote:
>>>
>>>> It seems like linkedList.clear() can be easily fixed to O(1) instead of
>>>> O(n).
>>>
>>> The code is like that on purpose(!). It was done to help GC, in mustang
>>> IIRC. There really isn't a problem with clear() being O(n) - it's going
>>> to
>>> take at least O(n) to populate it, and in reality *many* times more
>>> cycles.
>>>
>>> Tom
>>>
>>
>>
>>
>


From martinrb at google.com  Thu Aug 27 17:27:56 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 27 Aug 2009 10:27:56 -0700
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <79be5fa30908271023j43634be4t4061599fe3ff9e03@mail.gmail.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
	<4A968C2E.8020308@sun.com>
	<79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com>
	<4A96ADEA.6040705@sun.com>
	<79be5fa30908271023j43634be4t4061599fe3ff9e03@mail.gmail.com>
Message-ID: <1ccfd1c10908271027t26406229x348ef950d936d149@mail.gmail.com>

On Thu, Aug 27, 2009 at 10:23, Guy Korland<gkorland at gmail.com> wrote:
> First I don't think this is the same issue, in the clear case, there's
> no reference from the root to any of the entries.
> Second as I know any MarkAndSweep GC should not suffer from such issue.
> Since the sweep phase should collect any unreachable entry no matter
> how many dead references point to it.

See my just posted email - unlinking dead older possibly tenured nodes
has been known to speedup real apps by a factor of two by
changing full gcs into young gen gcs.

Martin


From Xueming.Shen at Sun.COM  Thu Aug 27 18:03:38 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 27 Aug 2009 11:03:38 -0700
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A968EED.7040700@gmx.de>
References: <4A95079A.8080803@gmx.de> <4A95867B.6070300@sun.com>
	<4A968EED.7040700@gmx.de>
Message-ID: <4A96CA7A.8070603@sun.com>

Ulf Zibis wrote:
> Am 26.08.2009 21:01, Xueming Shen schrieb:
>>
>> > - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see 
>> jdk1.7.0/src.zip)
>>
>> Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the 
>> code in the
>> generated source file have exactly the same line number as they 
>> appear in the
>> original source file.
>
> I have thought that before, but I _don't understand_ the *real value* 
> against having "nice" code in externally delivered src.zip.
> Some time ago it was always annoying to me when debugger ran in that 
> code, or I was just looking, how it works. (endless scrolling and 
> often I oversaw the tail behind numbers of blank lines (I don't have 
> line numbers on in my editor)).
> In contrast in generator output of SingleByte-X.java you don't care 
> about line numbers, although it's in private sun package.
The original tool spp.sh has the goal of keeping the line numbers in 
both the generated source file and the original -X.java file the
same, most of the time "we" read the -X.java version when debugging. My 
re-writing follows that design/implementation.

In case of my SingleByte/DoubleByte-X, first those generated source 
files are not exported to public, second, most coding logic
is in SingleByte/DoubleByte.java, the generated code is "purely the 
holding bag of  constant string tables, it's unlikely anyone will
run into debugging of those files. So I decided it's not worth keeping 
the same like numbers in the output of SingleDoubleByte-X,
this is also one of the reasons that I keep them in the make/tools, not 
in the src tree.

sherman



From jonathan.gibbons at sun.com  Thu Aug 27 18:18:21 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 27 Aug 2009 18:18:21 +0000
Subject: hg: jdk7/tl/langtools: 6875336: some tests should use
	/nodynamiccopyright/
Message-ID: <20090827181829.28B39126CF@hg.openjdk.java.net>

Changeset: ed31953ca025
Author:    jjg
Date:      2009-08-27 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ed31953ca025

6875336: some tests should use /nodynamiccopyright/
Reviewed-by: darcy

! test/tools/javac/6521805/T6521805a.java
! test/tools/javac/6521805/T6521805a_1.out
! test/tools/javac/6521805/T6521805a_2.out
! test/tools/javac/6521805/T6521805d.java
! test/tools/javac/6521805/T6521805d.out
! test/tools/javac/6717241/T6717241a.java
! test/tools/javac/6717241/T6717241a.out
! test/tools/javac/6717241/T6717241b.java
! test/tools/javac/6717241/T6717241b.out
! test/tools/javac/6734819/T6734819c.java
! test/tools/javac/6734819/T6734819c.out
! test/tools/javac/6758789/T6758789a.java
! test/tools/javac/6758789/T6758789a.out
! test/tools/javac/6758789/T6758789b.java
! test/tools/javac/6758789/T6758789b.out
! test/tools/javac/6840059/T6840059.java
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/Diagnostics/6722234/T6722234a.java
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b.java
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.java
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6722234/T6722234d.java
! test/tools/javac/Diagnostics/6722234/T6722234d_1.out
! test/tools/javac/Diagnostics/6722234/T6722234d_2.out
! test/tools/javac/Diagnostics/6799605/T6799605.java
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/Diagnostics/6860795/T6860795.java
! test/tools/javac/Diagnostics/6860795/T6860795.out
! test/tools/javac/Diagnostics/6862608/T6862608a.java
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/Diagnostics/6862608/T6862608b.java
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/Diagnostics/6864382/T6864382.java
! test/tools/javac/Diagnostics/6864382/T6864382.out
! test/tools/javac/OverrideChecks/6199153/T6199153.java
! test/tools/javac/OverrideChecks/6199153/T6199153.out
! test/tools/javac/OverrideChecks/6400189/T6400189a.java
! test/tools/javac/OverrideChecks/6400189/T6400189a.out
! test/tools/javac/OverrideChecks/6400189/T6400189b.java
! test/tools/javac/OverrideChecks/6400189/T6400189b.out
! test/tools/javac/cast/6467183/T6467183a.java
! test/tools/javac/cast/6467183/T6467183a.out
! test/tools/javac/cast/6557182/T6557182.java
! test/tools/javac/cast/6557182/T6557182.out
! test/tools/javac/cast/6665356/T6665356.java
! test/tools/javac/cast/6665356/T6665356.out
! test/tools/javac/cast/6795580/T6795580.java
! test/tools/javac/cast/6795580/T6795580.out
! test/tools/javac/generics/5009937/T5009937.java
! test/tools/javac/generics/5009937/T5009937.out
! test/tools/javac/generics/6182950/T6182950a.java
! test/tools/javac/generics/6182950/T6182950a.out
! test/tools/javac/generics/6182950/T6182950b.java
! test/tools/javac/generics/6182950/T6182950b.out
! test/tools/javac/generics/6677785/T6677785.java
! test/tools/javac/generics/6677785/T6677785.out
! test/tools/javac/generics/6711619/T6711619a.java
! test/tools/javac/generics/6711619/T6711619a.out
! test/tools/javac/generics/6711619/T6711619b.java
! test/tools/javac/generics/6711619/T6711619b.out
! test/tools/javac/generics/6723444/T6723444.java
! test/tools/javac/generics/6723444/T6723444.out
! test/tools/javac/generics/inference/6315770/T6315770.java
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6611449/T6611449.java
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712a.java
! test/tools/javac/generics/inference/6638712/T6638712a.out
! test/tools/javac/generics/inference/6638712/T6638712b.java
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6638712/T6638712c.java
! test/tools/javac/generics/inference/6638712/T6638712c.out
! test/tools/javac/generics/inference/6638712/T6638712d.java
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.java
! test/tools/javac/generics/inference/6638712/T6638712e.out
! test/tools/javac/generics/inference/6718364/T6718364.java
! test/tools/javac/generics/inference/6718364/T6718364.out
! test/tools/javac/generics/rare/6665356/T6665356.java
! test/tools/javac/generics/rare/6665356/T6665356.out
! test/tools/javac/generics/typevars/6569404/T6569404b.java
! test/tools/javac/generics/typevars/6569404/T6569404b.out
! test/tools/javac/generics/typevars/6680106/T6680106.java
! test/tools/javac/generics/typevars/6680106/T6680106.out
! test/tools/javac/generics/typevars/6804733/T6804733.java
! test/tools/javac/generics/typevars/6804733/T6804733.out
! test/tools/javac/typeAnnotations/failures/AnnotationVersion.java
! test/tools/javac/typeAnnotations/failures/AnnotationVersion.out
! test/tools/javac/typeAnnotations/failures/IncompleteArray.java
! test/tools/javac/typeAnnotations/failures/IncompleteArray.out
! test/tools/javac/typeAnnotations/failures/IncompleteVararg.java
! test/tools/javac/typeAnnotations/failures/IncompleteVararg.out
! test/tools/javac/typeAnnotations/failures/IndexArray.java
! test/tools/javac/typeAnnotations/failures/IndexArray.out
! test/tools/javac/typeAnnotations/failures/LintCast.java
! test/tools/javac/typeAnnotations/failures/LintCast.out
! test/tools/javac/typeAnnotations/failures/Scopes.java
! test/tools/javac/typeAnnotations/failures/Scopes.out
! test/tools/javac/typeAnnotations/failures/StaticFields.java
! test/tools/javac/typeAnnotations/failures/StaticFields.out
! test/tools/javac/typeAnnotations/failures/StaticMethods.java
! test/tools/javac/typeAnnotations/failures/StaticMethods.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/target/Constructor.java
! test/tools/javac/typeAnnotations/failures/target/Constructor.out
! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java
! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out
! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java
! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out
! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java
! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out
! test/tools/javac/typeAnnotations/failures/target/VoidMethod.java
! test/tools/javac/typeAnnotations/failures/target/VoidMethod.out
! test/tools/javac/varargs/6806876/T6806876.java
! test/tools/javac/varargs/6806876/T6806876.out
! test/tools/javac/warnings/6747671/T6747671.java
! test/tools/javac/warnings/6747671/T6747671.out



From joe.darcy at sun.com  Thu Aug 27 18:57:21 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 27 Aug 2009 18:57:21 +0000
Subject: hg: jdk7/tl/jdk: 6876628: @throw instead of @throws in two
	ParagraphView classes
Message-ID: <20090827185812.93641126DC@hg.openjdk.java.net>

Changeset: 25371bf31658
Author:    darcy
Date:      2009-08-27 11:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25371bf31658

6876628: @throw instead of @throws in two ParagraphView classes
Reviewed-by: peterz

! src/share/classes/javax/swing/text/ParagraphView.java
! src/share/classes/javax/swing/text/html/ParagraphView.java



From Ulf.Zibis at gmx.de  Thu Aug 27 19:47:04 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 27 Aug 2009 21:47:04 +0200
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A96B7FD.1010305@sun.com>
References: <4A95079A.8080803@gmx.de> <4A95867B.6070300@sun.com>
	<4A968EED.7040700@gmx.de> <4A96B7FD.1010305@sun.com>
Message-ID: <4A96E2B8.2060308@gmx.de>

Am 27.08.2009 18:44, Kelly O'Hair schrieb:
>
> Ulf Zibis wrote:
>> Am 26.08.2009 21:01, Xueming Shen schrieb:
>>>
>>> > - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see 
>>> jdk1.7.0/src.zip)
>>>
>>> Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the 
>>> code in the
>>> generated source file have exactly the same line number as they 
>>> appear in the
>>> original source file.
>>
>> I have thought that before, but I _don't understand_ the *real value* 
>> against having "nice" code in externally delivered src.zip.
>> Some time ago it was always annoying to me when debugger ran in that 
>> code, or I was just looking, how it works. (endless scrolling and 
>> often I oversaw the tail behind numbers of blank lines (I don't have 
>> line numbers on in my editor)).
>> In contrast in generator output of SingleByte-X.java you don't care 
>> about line numbers, although it's in private sun package.
>>
>> -Ulf
>>
>>
>
> Regardless of the outcome of this discussion, could we please consider
> separating the changes to the make/tools files from the rest, unless
> there is some dependency between the two.
> So if at all possible, could we get separate changesets on these changes?

No problem, agreed!

>
> ---
>
> As I recall on the line numbers, the issue is that the classfiles will
> permanently record line numbers for the source, so the goal was to make
> sure that regardless where the classfiles came from (open or closed jdk)
> and where the src.zip came from (open or closed jdk), it would all work
> and any debugger will have a fighting chance of showing you the right
> line in the source.
> So these extra blank lines might not look 'nice', but having a debugger
> point you at the wrong lines is much worse.
>

Well, I never had this problem, as I always used matching .class <-> 
.java files, but I can see the point if others had that problem.
Anyway, if (open or closed jdk) sources are different in any other 
matter, the developer would have the same problem (think about different 
copyright headers), and should use matching .class <-> .java file pairs.

OK, next time I don't touch Spp.java, and try to live with blank areas 
on my screen. :-\

-Ulf




From gkorland at gmail.com  Thu Aug 27 19:54:14 2009
From: gkorland at gmail.com (Guy Korland)
Date: Thu, 27 Aug 2009 22:54:14 +0300
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <1ccfd1c10908271027t26406229x348ef950d936d149@mail.gmail.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com> 
	<4A968C2E.8020308@sun.com>
	<79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com> 
	<4A96ADEA.6040705@sun.com>
	<79be5fa30908271023j43634be4t4061599fe3ff9e03@mail.gmail.com> 
	<1ccfd1c10908271027t26406229x348ef950d936d149@mail.gmail.com>
Message-ID: <79be5fa30908271254l15e3f5e1u72f307b3ae500265@mail.gmail.com>

I understand the advantage and as you wrote there are cases where this
is a disadvantage.
The thing is one can't even extend this class according the needed
functionality, since header is defined as private.

Guy

On Thu, Aug 27, 2009 at 8:27 PM, Martin Buchholz<martinrb at google.com> wrote:
> On Thu, Aug 27, 2009 at 10:23, Guy Korland<gkorland at gmail.com> wrote:
>> First I don't think this is the same issue, in the clear case, there's
>> no reference from the root to any of the entries.
>> Second as I know any MarkAndSweep GC should not suffer from such issue.
>> Since the sweep phase should collect any unreachable entry no matter
>> how many dead references point to it.
>
> See my just posted email - unlinking dead older possibly tenured nodes
> has been known to speedup real apps by a factor of two by
> changing full gcs into young gen gcs.
>
> Martin
>



-- 
Guy Korland


From Ulf.Zibis at gmx.de  Thu Aug 27 19:55:39 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 27 Aug 2009 21:55:39 +0200
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A96CA7A.8070603@sun.com>
References: <4A95079A.8080803@gmx.de> <4A95867B.6070300@sun.com>
	<4A968EED.7040700@gmx.de> <4A96CA7A.8070603@sun.com>
Message-ID: <4A96E4BB.1070408@gmx.de>

Am 27.08.2009 20:03, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> Am 26.08.2009 21:01, Xueming Shen schrieb:
>>>
>>> > - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see 
>>> jdk1.7.0/src.zip)
>>>
>>> Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the 
>>> code in the
>>> generated source file have exactly the same line number as they 
>>> appear in the
>>> original source file.
>>
>> I have thought that before, but I _don't understand_ the *real value* 
>> against having "nice" code in externally delivered src.zip.
>> Some time ago it was always annoying to me when debugger ran in that 
>> code, or I was just looking, how it works. (endless scrolling and 
>> often I oversaw the tail behind numbers of blank lines (I don't have 
>> line numbers on in my editor)).
>> In contrast in generator output of SingleByte-X.java you don't care 
>> about line numbers, although it's in private sun package.
> The original tool spp.sh has the goal of keeping the line numbers in 
> both the generated source file and the original -X.java file the
> same, most of the time "we" read the -X.java version when debugging. 
> My re-writing follows that design/implementation.
>
> In case of my SingleByte/DoubleByte-X, first those generated source 
> files are not exported to public, second, most coding logic
> is in SingleByte/DoubleByte.java, the generated code is "purely the 
> holding bag of  constant string tables,

Have you seen my changes to SingleByte-X on 
https://bugs.openjdk.java.net/show_bug.cgi?id=100098 ? It's a step more 
to "purely" the holding bag of constant string tables.

> it's unlikely anyone will
> run into debugging of those files.

I am the guy who did this, but this is truly special case. :-)

> So I decided it's not worth keeping the same like numbers in the 
> output of SingleDoubleByte-X,
> this is also one of the reasons that I keep them in the make/tools, 
> not in the src tree.
>
> sherman
>
>

Sherman, Kelly,

thanks for explaining me the *real value* .


-Ulf




From Xueming.Shen at Sun.COM  Thu Aug 27 20:17:05 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 27 Aug 2009 13:17:05 -0700
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A96E4BB.1070408@gmx.de>
References: <4A95079A.8080803@gmx.de> <4A95867B.6070300@sun.com>
	<4A968EED.7040700@gmx.de> <4A96CA7A.8070603@sun.com>
	<4A96E4BB.1070408@gmx.de>
Message-ID: <4A96E9C1.4040400@sun.com>

Ulf Zibis wrote:
> Am 27.08.2009 20:03, Xueming Shen schrieb:
>> Ulf Zibis wrote:
>>> Am 26.08.2009 21:01, Xueming Shen schrieb:
>>>>
>>>> > - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see 
>>>> jdk1.7.0/src.zip)
>>>>
>>>> Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the 
>>>> code in the
>>>> generated source file have exactly the same line number as they 
>>>> appear in the
>>>> original source file.
>>>
>>> I have thought that before, but I _don't understand_ the *real 
>>> value* against having "nice" code in externally delivered src.zip.
>>> Some time ago it was always annoying to me when debugger ran in that 
>>> code, or I was just looking, how it works. (endless scrolling and 
>>> often I oversaw the tail behind numbers of blank lines (I don't have 
>>> line numbers on in my editor)).
>>> In contrast in generator output of SingleByte-X.java you don't care 
>>> about line numbers, although it's in private sun package.
>> The original tool spp.sh has the goal of keeping the line numbers in 
>> both the generated source file and the original -X.java file the
>> same, most of the time "we" read the -X.java version when debugging. 
>> My re-writing follows that design/implementation.
>>
>> In case of my SingleByte/DoubleByte-X, first those generated source 
>> files are not exported to public, second, most coding logic
>> is in SingleByte/DoubleByte.java, the generated code is "purely the 
>> holding bag of  constant string tables,
>
> Have you seen my changes to SingleByte-X on 
> https://bugs.openjdk.java.net/show_bug.cgi?id=100098 ? It's a step 
> more to "purely" the holding bag of constant string tables.
I'm reading all those 100xxx one by one. The problem is that you've 
mixed too many things together in one bag and there are
too many "dependencies" among them. There are lots of good 
idea/suggested changes, but it really takes time to figure out which
one is the real goal of one particular patch,  which one has the 
priority, and how to "extract" something out of hundreds of changes
to do it step by step. I can't not just take such huge changeset and 
throw into the JDK.

Sherman


From Ulf.Zibis at gmx.de  Thu Aug 27 20:59:02 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 27 Aug 2009 22:59:02 +0200
Subject: review request for 6798511/6860431: Include functionality of
	Surrogate in Character
In-Reply-To: <4A96E9C1.4040400@sun.com>
References: <4A95079A.8080803@gmx.de> <4A95867B.6070300@sun.com>
	<4A968EED.7040700@gmx.de> <4A96CA7A.8070603@sun.com>
	<4A96E4BB.1070408@gmx.de> <4A96E9C1.4040400@sun.com>
Message-ID: <4A96F396.5080402@gmx.de>

Am 27.08.2009 22:17, Xueming Shen schrieb:
> I'm reading all those 100xxx one by one. The problem is that you've 
> mixed too many things together in one bag and there are
> too many "dependencies" among them.

Yes, there are indeed many dependencies in 100098. The before 100098 
changes have been more simple, but unfortunately they are mostly 
obsolete in face of 100098.

> There are lots of good idea/suggested changes,

Thanks for the flowers :-)

> but it really takes time to figure out which
> one is the real goal of one particular patch,  which one has the 
> priority, and how to "extract" something out of hundreds of changes
> to do it step by step.

I can understand this. I tried to keep the amount "small", but after 
some time, I saw, that I had no idea how (OK, there are some 
supplementary cosmetics).
I "only" made the changes to a part of all charsets. As result I had to 
remain 3 different patterns for instantiation of charsets in 
ExternalCharsetProvider.
The changes to the UTF classes should be good candidate for extraction.

> I can't not just take such huge changeset and throw into the JDK.

That's reasonable. Should I make future changesets on base of the one 
before e.g. 100098 instead on base of tl forest?

-Ulf




From jonathan.gibbons at sun.com  Thu Aug 27 22:21:44 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 27 Aug 2009 22:21:44 +0000
Subject: hg: jdk7/tl/langtools: 6843707: bad tests generate files in the test/
	directory; ...
Message-ID: <20090827222149.77276126F1@hg.openjdk.java.net>

Changeset: 74760fd5197f
Author:    jjg
Date:      2009-08-27 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/74760fd5197f

6843707: bad tests generate files in the test/ directory
6876699: generated files in repository
Reviewed-by: darcy

- test/tools/javac/meth/InvokeMH_BAD68.java
- test/tools/javac/meth/InvokeMH_BAD72.java
! test/tools/javac/meth/MakeNegTests.sh
! test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/quid/QuotedIdent_BAD61.java
- test/tools/javac/quid/QuotedIdent_BAD62.java
- test/tools/javac/quid/QuotedIdent_BAD63.java



From jonathan.gibbons at sun.com  Fri Aug 28 00:47:54 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 28 Aug 2009 00:47:54 +0000
Subject: hg: jdk7/tl/langtools: 6876753: javap tests fail on Windows
Message-ID: <20090828004759.18548126F8@hg.openjdk.java.net>

Changeset: 2c20f17c429c
Author:    jjg
Date:      2009-08-27 17:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2c20f17c429c

6876753: javap tests fail on Windows
Reviewed-by: darcy

! test/tools/javap/T4975569.java
! test/tools/javap/T6729471.java
! test/tools/javap/pathsep.sh
! test/tools/javap/stackmap/T6271292.sh



From jonathan.gibbons at sun.com  Fri Aug 28 00:58:38 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 28 Aug 2009 00:58:38 +0000
Subject: hg: jdk7/tl/langtools: 6876755: apt tests fail on Windows
Message-ID: <20090828005843.2DE98126FD@hg.openjdk.java.net>

Changeset: f29068bfeaed
Author:    jjg
Date:      2009-08-27 17:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f29068bfeaed

6876755: apt tests fail on Windows
Reviewed-by: darcy

! test/tools/apt/Basics/apt.sh
! test/tools/apt/Basics/print.sh
! test/tools/apt/Compile/compile.sh



From Joe.Darcy at Sun.COM  Fri Aug 28 01:08:26 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 27 Aug 2009 18:08:26 -0700
Subject: Code review request to remove javadoc build warnings from
	javax.sql.rowset.BaseRowSet.java
Message-ID: <4A972E0A.9080507@sun.com>

Hello.

More cleanup of docs build warnings; this time from 
javax.sql.rowset.BaseRowSet.java where non-existent getter methods are 
repeatedly referenced.  Assuming someone approves the change, I'll file 
a bug and commit the fix.

-Joe

--- old/src/share/classes/javax/sql/rowset/BaseRowSet.java    2009-08-27 
18:04:08.000000000 -0700
+++ new/src/share/classes/javax/sql/rowset/BaseRowSet.java    2009-08-27 
18:04:08.000000000 -0700
@@ -168,8 +168,8 @@
  * The majority of methods for setting placeholder parameters take two 
parameters,
  *  with the first parameter
  * indicating which placeholder parameter is to be set, and the second 
parameter
- * giving the value to be set.  Methods such as <code>getInt</code>,
- * <code>getString</code>, <code>getBoolean</code>, and 
<code>getLong</code> fall into
+ * giving the value to be set.  Methods such as <code>setInt</code>,
+ * <code>setString</code>, <code>setBoolean</code>, and 
<code>setLong</code> fall into
  * this category.  After these methods have been called, a call to the 
method
  * <code>getParams</code> will return an array with the values that 
have been set. Each
  * element in the array is an <code>Object</code> instance representing the
@@ -3259,7 +3259,6 @@
     * @param x the parameter value
     * @exception SQLException if a database access error occurs or
     * this method is called on a closed <code>CallableStatement</code>
-    * @see #getBoolean
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
     * @since 1.4
@@ -3281,7 +3280,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getByte
     * @since 1.4
     */
    public void setByte(String parameterName, byte x) throws SQLException{
@@ -3301,7 +3299,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getShort
     * @since 1.4
     */
    public void setShort(String parameterName, short x) throws SQLException{
@@ -3320,7 +3317,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getInt
     * @since 1.4
     */
    public void setInt(String parameterName, int x) throws SQLException{
@@ -3339,7 +3335,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getLong
     * @since 1.4
     */
    public void setLong(String parameterName, long x) throws SQLException{
@@ -3358,7 +3353,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getFloat
     * @since 1.4
     */
    public void setFloat(String parameterName, float x) throws SQLException{
@@ -3377,7 +3371,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getDouble
     * @since 1.4
     */
    public void setDouble(String parameterName, double x) throws 
SQLException{
@@ -3398,7 +3391,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getBigDecimal
     * @since 1.4
     */
    public void setBigDecimal(String parameterName, BigDecimal x) throws 
SQLException{
@@ -3421,7 +3413,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getString
     * @since 1.4
     */
    public void setString(String parameterName, String x) throws 
SQLException{
@@ -3443,7 +3434,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getBytes
     * @since 1.4
     */
    public void setBytes(String parameterName, byte x[]) throws 
SQLException{
@@ -3464,7 +3454,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getTimestamp
     * @since 1.4
     */
    public void setTimestamp(String parameterName, java.sql.Timestamp x)
@@ -3712,7 +3701,6 @@
     * or  <code>STRUCT</code> data type and the JDBC driver does not 
support
     * this data type
     * @see Types
-    * @see #getObject
     * @since 1.4
     */
    public void setObject(String parameterName, Object x, int 
targetSqlType, int scale)
@@ -3740,7 +3728,6 @@
     *  <code>REF</code>, <code>ROWID</code>, <code>SQLXML</code>
     * or  <code>STRUCT</code> data type and the JDBC driver does not 
support
     * this data type
-    * @see #getObject
     * @since 1.4
     */
    public void setObject(String parameterName, Object x, int targetSqlType)
@@ -3782,7 +3769,6 @@
    *            <code>Object</code> parameter is ambiguous
    * @exception SQLFeatureNotSupportedException if the JDBC driver does 
not support
    * this method
-   * @see #getObject
    * @since 1.4
    */
   public void setObject(String parameterName, Object x) throws 
SQLException{
@@ -4064,7 +4050,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getDate
     * @since 1.4
     */
    public void setDate(String parameterName, java.sql.Date x)
@@ -4091,7 +4076,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getDate
     * @since 1.4
     */
    public void setDate(String parameterName, java.sql.Date x, Calendar cal)
@@ -4111,7 +4095,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getTime
     * @since 1.4
     */
    public void setTime(String parameterName, java.sql.Time x)
@@ -4138,7 +4121,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getTime
     * @since 1.4
     */
    public void setTime(String parameterName, java.sql.Time x, Calendar cal)
@@ -4165,7 +4147,6 @@
     * this method is called on a closed <code>CallableStatement</code>
     * @exception SQLFeatureNotSupportedException if the JDBC driver 
does not support
     * this method
-    * @see #getTimestamp
     * @since 1.4
     */
    public void setTimestamp(String parameterName, java.sql.Timestamp x, 
Calendar cal)



From jonathan.gibbons at sun.com  Fri Aug 28 01:33:54 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 28 Aug 2009 01:33:54 +0000
Subject: hg: jdk7/tl/langtools: 6876765: javah tests fail on Windows
Message-ID: <20090828013359.3F1511270A@hg.openjdk.java.net>

Changeset: 477c5bf1149c
Author:    jjg
Date:      2009-08-27 18:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/477c5bf1149c

6876765: javah tests fail on Windows
Reviewed-by: darcy

! test/tools/javah/6257087/foo.sh
! test/tools/javah/ConstMacroTest.sh
! test/tools/javah/MissingParamClassTest.sh
! test/tools/javah/ReadOldClass.sh



From Lance.Andersen at Sun.COM  Fri Aug 28 01:50:22 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Thu, 27 Aug 2009 21:50:22 -0400
Subject: Code review request to remove javadoc build warnings from
	javax.sql.rowset.BaseRowSet.java
In-Reply-To: <4A972E0A.9080507@sun.com>
References: <4A972E0A.9080507@sun.com>
Message-ID: <4A9737DE.9010709@sun.com>

Hi Joe,

I will look at this  get back to you.  There is already a CR for 
cleaning up the  rowset javadocs. 

I also need to compare the version in OpenJDK to what is in the Rowset 
workspace as there looks to be some differences in the javadocs for this 
class (where some of the errors below have been addressed).

Regards
Lance

Joseph D. Darcy wrote:
> Hello.
>
> More cleanup of docs build warnings; this time from 
> javax.sql.rowset.BaseRowSet.java where non-existent getter methods are 
> repeatedly referenced.  Assuming someone approves the change, I'll 
> file a bug and commit the fix.
>
> -Joe
>
> --- old/src/share/classes/javax/sql/rowset/BaseRowSet.java    
> 2009-08-27 18:04:08.000000000 -0700
> +++ new/src/share/classes/javax/sql/rowset/BaseRowSet.java    
> 2009-08-27 18:04:08.000000000 -0700
> @@ -168,8 +168,8 @@
>  * The majority of methods for setting placeholder parameters take two 
> parameters,
>  *  with the first parameter
>  * indicating which placeholder parameter is to be set, and the second 
> parameter
> - * giving the value to be set.  Methods such as <code>getInt</code>,
> - * <code>getString</code>, <code>getBoolean</code>, and 
> <code>getLong</code> fall into
> + * giving the value to be set.  Methods such as <code>setInt</code>,
> + * <code>setString</code>, <code>setBoolean</code>, and 
> <code>setLong</code> fall into
>  * this category.  After these methods have been called, a call to the 
> method
>  * <code>getParams</code> will return an array with the values that 
> have been set. Each
>  * element in the array is an <code>Object</code> instance 
> representing the
> @@ -3259,7 +3259,6 @@
>     * @param x the parameter value
>     * @exception SQLException if a database access error occurs or
>     * this method is called on a closed <code>CallableStatement</code>
> -    * @see #getBoolean
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
>     * @since 1.4
> @@ -3281,7 +3280,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getByte
>     * @since 1.4
>     */
>    public void setByte(String parameterName, byte x) throws SQLException{
> @@ -3301,7 +3299,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getShort
>     * @since 1.4
>     */
>    public void setShort(String parameterName, short x) throws 
> SQLException{
> @@ -3320,7 +3317,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getInt
>     * @since 1.4
>     */
>    public void setInt(String parameterName, int x) throws SQLException{
> @@ -3339,7 +3335,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getLong
>     * @since 1.4
>     */
>    public void setLong(String parameterName, long x) throws SQLException{
> @@ -3358,7 +3353,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getFloat
>     * @since 1.4
>     */
>    public void setFloat(String parameterName, float x) throws 
> SQLException{
> @@ -3377,7 +3371,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getDouble
>     * @since 1.4
>     */
>    public void setDouble(String parameterName, double x) throws 
> SQLException{
> @@ -3398,7 +3391,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getBigDecimal
>     * @since 1.4
>     */
>    public void setBigDecimal(String parameterName, BigDecimal x) 
> throws SQLException{
> @@ -3421,7 +3413,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getString
>     * @since 1.4
>     */
>    public void setString(String parameterName, String x) throws 
> SQLException{
> @@ -3443,7 +3434,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getBytes
>     * @since 1.4
>     */
>    public void setBytes(String parameterName, byte x[]) throws 
> SQLException{
> @@ -3464,7 +3454,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getTimestamp
>     * @since 1.4
>     */
>    public void setTimestamp(String parameterName, java.sql.Timestamp x)
> @@ -3712,7 +3701,6 @@
>     * or  <code>STRUCT</code> data type and the JDBC driver does not 
> support
>     * this data type
>     * @see Types
> -    * @see #getObject
>     * @since 1.4
>     */
>    public void setObject(String parameterName, Object x, int 
> targetSqlType, int scale)
> @@ -3740,7 +3728,6 @@
>     *  <code>REF</code>, <code>ROWID</code>, <code>SQLXML</code>
>     * or  <code>STRUCT</code> data type and the JDBC driver does not 
> support
>     * this data type
> -    * @see #getObject
>     * @since 1.4
>     */
>    public void setObject(String parameterName, Object x, int 
> targetSqlType)
> @@ -3782,7 +3769,6 @@
>    *            <code>Object</code> parameter is ambiguous
>    * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>    * this method
> -   * @see #getObject
>    * @since 1.4
>    */
>   public void setObject(String parameterName, Object x) throws 
> SQLException{
> @@ -4064,7 +4050,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getDate
>     * @since 1.4
>     */
>    public void setDate(String parameterName, java.sql.Date x)
> @@ -4091,7 +4076,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getDate
>     * @since 1.4
>     */
>    public void setDate(String parameterName, java.sql.Date x, Calendar 
> cal)
> @@ -4111,7 +4095,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getTime
>     * @since 1.4
>     */
>    public void setTime(String parameterName, java.sql.Time x)
> @@ -4138,7 +4121,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getTime
>     * @since 1.4
>     */
>    public void setTime(String parameterName, java.sql.Time x, Calendar 
> cal)
> @@ -4165,7 +4147,6 @@
>     * this method is called on a closed <code>CallableStatement</code>
>     * @exception SQLFeatureNotSupportedException if the JDBC driver 
> does not support
>     * this method
> -    * @see #getTimestamp
>     * @since 1.4
>     */
>    public void setTimestamp(String parameterName, java.sql.Timestamp 
> x, Calendar cal)
>


From xiaobin.lu at sun.com  Fri Aug 28 01:51:44 2009
From: xiaobin.lu at sun.com (xiaobin.lu at sun.com)
Date: Fri, 28 Aug 2009 01:51:44 +0000
Subject: hg: jdk7/tl/jdk: 6876282: BigDecimal's divide(BigDecimal bd,
	RoundingFormat r) produces incorrect result
Message-ID: <20090828015201.1255312717@hg.openjdk.java.net>

Changeset: 5342b0cdbf95
Author:    xlu
Date:      2009-08-27 18:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5342b0cdbf95

6876282: BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces incorrect result
Reviewed-by: darcy

! src/share/classes/java/math/BigDecimal.java
! test/java/math/BigDecimal/DivideTests.java



From gnu_andrew at member.fsf.org  Fri Aug 28 01:53:28 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 28 Aug 2009 02:53:28 +0100
Subject: Code review request to remove javadoc build warnings from 
	javax.sql.rowset.BaseRowSet.java
In-Reply-To: <4A972E0A.9080507@sun.com>
References: <4A972E0A.9080507@sun.com>
Message-ID: <17c6771e0908271853n4db0d5eak640ca9189456d121@mail.gmail.com>

2009/8/28 Joseph D. Darcy <Joe.Darcy at sun.com>:
> Hello.
>
> More cleanup of docs build warnings; this time from
> javax.sql.rowset.BaseRowSet.java where non-existent getter methods are
> repeatedly referenced. ?Assuming someone approves the change, I'll file a
> bug and commit the fix.
>
> -Joe
>
> --- old/src/share/classes/javax/sql/rowset/BaseRowSet.java ? ?2009-08-27
> 18:04:08.000000000 -0700
> +++ new/src/share/classes/javax/sql/rowset/BaseRowSet.java ? ?2009-08-27
> 18:04:08.000000000 -0700
> @@ -168,8 +168,8 @@
> ?* The majority of methods for setting placeholder parameters take two
> parameters,
> ?* ?with the first parameter
> ?* indicating which placeholder parameter is to be set, and the second
> parameter
> - * giving the value to be set. ?Methods such as <code>getInt</code>,
> - * <code>getString</code>, <code>getBoolean</code>, and
> <code>getLong</code> fall into
> + * giving the value to be set. ?Methods such as <code>setInt</code>,
> + * <code>setString</code>, <code>setBoolean</code>, and
> <code>setLong</code> fall into
> ?* this category. ?After these methods have been called, a call to the
> method
> ?* <code>getParams</code> will return an array with the values that have
> been set. Each
> ?* element in the array is an <code>Object</code> instance representing the
> @@ -3259,7 +3259,6 @@
> ? ?* @param x the parameter value
> ? ?* @exception SQLException if a database access error occurs or
> ? ?* this method is called on a closed <code>CallableStatement</code>
> - ? ?* @see #getBoolean
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> ? ?* @since 1.4
> @@ -3281,7 +3280,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getByte
> ? ?* @since 1.4
> ? ?*/
> ? public void setByte(String parameterName, byte x) throws SQLException{
> @@ -3301,7 +3299,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getShort
> ? ?* @since 1.4
> ? ?*/
> ? public void setShort(String parameterName, short x) throws SQLException{
> @@ -3320,7 +3317,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getInt
> ? ?* @since 1.4
> ? ?*/
> ? public void setInt(String parameterName, int x) throws SQLException{
> @@ -3339,7 +3335,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getLong
> ? ?* @since 1.4
> ? ?*/
> ? public void setLong(String parameterName, long x) throws SQLException{
> @@ -3358,7 +3353,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getFloat
> ? ?* @since 1.4
> ? ?*/
> ? public void setFloat(String parameterName, float x) throws SQLException{
> @@ -3377,7 +3371,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getDouble
> ? ?* @since 1.4
> ? ?*/
> ? public void setDouble(String parameterName, double x) throws SQLException{
> @@ -3398,7 +3391,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getBigDecimal
> ? ?* @since 1.4
> ? ?*/
> ? public void setBigDecimal(String parameterName, BigDecimal x) throws
> SQLException{
> @@ -3421,7 +3413,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getString
> ? ?* @since 1.4
> ? ?*/
> ? public void setString(String parameterName, String x) throws SQLException{
> @@ -3443,7 +3434,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getBytes
> ? ?* @since 1.4
> ? ?*/
> ? public void setBytes(String parameterName, byte x[]) throws SQLException{
> @@ -3464,7 +3454,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getTimestamp
> ? ?* @since 1.4
> ? ?*/
> ? public void setTimestamp(String parameterName, java.sql.Timestamp x)
> @@ -3712,7 +3701,6 @@
> ? ?* or ?<code>STRUCT</code> data type and the JDBC driver does not support
> ? ?* this data type
> ? ?* @see Types
> - ? ?* @see #getObject
> ? ?* @since 1.4
> ? ?*/
> ? public void setObject(String parameterName, Object x, int targetSqlType,
> int scale)
> @@ -3740,7 +3728,6 @@
> ? ?* ?<code>REF</code>, <code>ROWID</code>, <code>SQLXML</code>
> ? ?* or ?<code>STRUCT</code> data type and the JDBC driver does not support
> ? ?* this data type
> - ? ?* @see #getObject
> ? ?* @since 1.4
> ? ?*/
> ? public void setObject(String parameterName, Object x, int targetSqlType)
> @@ -3782,7 +3769,6 @@
> ? * ? ? ? ? ? ?<code>Object</code> parameter is ambiguous
> ? * @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? * this method
> - ? * @see #getObject
> ? * @since 1.4
> ? */
> ?public void setObject(String parameterName, Object x) throws SQLException{
> @@ -4064,7 +4050,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getDate
> ? ?* @since 1.4
> ? ?*/
> ? public void setDate(String parameterName, java.sql.Date x)
> @@ -4091,7 +4076,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getDate
> ? ?* @since 1.4
> ? ?*/
> ? public void setDate(String parameterName, java.sql.Date x, Calendar cal)
> @@ -4111,7 +4095,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getTime
> ? ?* @since 1.4
> ? ?*/
> ? public void setTime(String parameterName, java.sql.Time x)
> @@ -4138,7 +4121,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getTime
> ? ?* @since 1.4
> ? ?*/
> ? public void setTime(String parameterName, java.sql.Time x, Calendar cal)
> @@ -4165,7 +4147,6 @@
> ? ?* this method is called on a closed <code>CallableStatement</code>
> ? ?* @exception SQLFeatureNotSupportedException if the JDBC driver does not
> support
> ? ?* this method
> - ? ?* @see #getTimestamp
> ? ?* @since 1.4
> ? ?*/
> ? public void setTimestamp(String parameterName, java.sql.Timestamp x,
> Calendar cal)
>
>

Thanks for this.  The initial paragraph is particularly confusing at
present, referring to non-existent methods call getX in the context of
discussing setter methods.

I think the #getX references should actually point to #getParams
rather than being removed.  From the documentation:

'A call to the method getParams returns the values stored in the
Hashtable object as an array of Object instances. An element in this
array may be a simple Object instance or an array (which is a type of
Object). The particular setter method used determines whether an
element in this array is an Object or an array.'

So the code that would perform the equivalent of a getDate method
would be getParams()[n], where n is the integer passed to the setDate
method.

Thanks again,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Lance.Andersen at Sun.COM  Fri Aug 28 01:58:16 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Thu, 27 Aug 2009 21:58:16 -0400
Subject: Code review request to remove javadoc build warnings from
	javax.sql.rowset.BaseRowSet.java
In-Reply-To: <17c6771e0908271853n4db0d5eak640ca9189456d121@mail.gmail.com>
References: <4A972E0A.9080507@sun.com>
	<17c6771e0908271853n4db0d5eak640ca9189456d121@mail.gmail.com>
Message-ID: <4A9739B8.4020705@sun.com>



Andrew John Hughes wrote:
> 2009/8/28 Joseph D. Darcy <Joe.Darcy at sun.com>:
>   
>> Hello.
>>
>> More cleanup of docs build warnings; this time from
>> javax.sql.rowset.BaseRowSet.java where non-existent getter methods are
>> repeatedly referenced.  Assuming someone approves the change, I'll file a
>> bug and commit the fix.
>>
>> -Joe
>>
>> --- old/src/share/classes/javax/sql/rowset/BaseRowSet.java    2009-08-27
>> 18:04:08.000000000 -0700
>> +++ new/src/share/classes/javax/sql/rowset/BaseRowSet.java    2009-08-27
>> 18:04:08.000000000 -0700
>> @@ -168,8 +168,8 @@
>>  * The majority of methods for setting placeholder parameters take two
>> parameters,
>>  *  with the first parameter
>>  * indicating which placeholder parameter is to be set, and the second
>> parameter
>> - * giving the value to be set.  Methods such as <code>getInt</code>,
>> - * <code>getString</code>, <code>getBoolean</code>, and
>> <code>getLong</code> fall into
>> + * giving the value to be set.  Methods such as <code>setInt</code>,
>> + * <code>setString</code>, <code>setBoolean</code>, and
>> <code>setLong</code> fall into
>>  * this category.  After these methods have been called, a call to the
>> method
>>  * <code>getParams</code> will return an array with the values that have
>> been set. Each
>>  * element in the array is an <code>Object</code> instance representing the
>> @@ -3259,7 +3259,6 @@
>>    * @param x the parameter value
>>    * @exception SQLException if a database access error occurs or
>>    * this method is called on a closed <code>CallableStatement</code>
>> -    * @see #getBoolean
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>>    * @since 1.4
>> @@ -3281,7 +3280,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getByte
>>    * @since 1.4
>>    */
>>   public void setByte(String parameterName, byte x) throws SQLException{
>> @@ -3301,7 +3299,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getShort
>>    * @since 1.4
>>    */
>>   public void setShort(String parameterName, short x) throws SQLException{
>> @@ -3320,7 +3317,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getInt
>>    * @since 1.4
>>    */
>>   public void setInt(String parameterName, int x) throws SQLException{
>> @@ -3339,7 +3335,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getLong
>>    * @since 1.4
>>    */
>>   public void setLong(String parameterName, long x) throws SQLException{
>> @@ -3358,7 +3353,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getFloat
>>    * @since 1.4
>>    */
>>   public void setFloat(String parameterName, float x) throws SQLException{
>> @@ -3377,7 +3371,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getDouble
>>    * @since 1.4
>>    */
>>   public void setDouble(String parameterName, double x) throws SQLException{
>> @@ -3398,7 +3391,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getBigDecimal
>>    * @since 1.4
>>    */
>>   public void setBigDecimal(String parameterName, BigDecimal x) throws
>> SQLException{
>> @@ -3421,7 +3413,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getString
>>    * @since 1.4
>>    */
>>   public void setString(String parameterName, String x) throws SQLException{
>> @@ -3443,7 +3434,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getBytes
>>    * @since 1.4
>>    */
>>   public void setBytes(String parameterName, byte x[]) throws SQLException{
>> @@ -3464,7 +3454,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getTimestamp
>>    * @since 1.4
>>    */
>>   public void setTimestamp(String parameterName, java.sql.Timestamp x)
>> @@ -3712,7 +3701,6 @@
>>    * or  <code>STRUCT</code> data type and the JDBC driver does not support
>>    * this data type
>>    * @see Types
>> -    * @see #getObject
>>    * @since 1.4
>>    */
>>   public void setObject(String parameterName, Object x, int targetSqlType,
>> int scale)
>> @@ -3740,7 +3728,6 @@
>>    *  <code>REF</code>, <code>ROWID</code>, <code>SQLXML</code>
>>    * or  <code>STRUCT</code> data type and the JDBC driver does not support
>>    * this data type
>> -    * @see #getObject
>>    * @since 1.4
>>    */
>>   public void setObject(String parameterName, Object x, int targetSqlType)
>> @@ -3782,7 +3769,6 @@
>>   *            <code>Object</code> parameter is ambiguous
>>   * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>   * this method
>> -   * @see #getObject
>>   * @since 1.4
>>   */
>>  public void setObject(String parameterName, Object x) throws SQLException{
>> @@ -4064,7 +4050,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getDate
>>    * @since 1.4
>>    */
>>   public void setDate(String parameterName, java.sql.Date x)
>> @@ -4091,7 +4076,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getDate
>>    * @since 1.4
>>    */
>>   public void setDate(String parameterName, java.sql.Date x, Calendar cal)
>> @@ -4111,7 +4095,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getTime
>>    * @since 1.4
>>    */
>>   public void setTime(String parameterName, java.sql.Time x)
>> @@ -4138,7 +4121,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getTime
>>    * @since 1.4
>>    */
>>   public void setTime(String parameterName, java.sql.Time x, Calendar cal)
>> @@ -4165,7 +4147,6 @@
>>    * this method is called on a closed <code>CallableStatement</code>
>>    * @exception SQLFeatureNotSupportedException if the JDBC driver does not
>> support
>>    * this method
>> -    * @see #getTimestamp
>>    * @since 1.4
>>    */
>>   public void setTimestamp(String parameterName, java.sql.Timestamp x,
>> Calendar cal)
>>
>>
>>     
>
>   


> Thanks for this.  The initial paragraph is particularly confusing at
> present, referring to non-existent methods call getX in the context of
> discussing setter methods.
>
> I think the #getX references should actually point to #getParams
> rather than being removed.  From the documentation:
>
> 'A call to the method getParams returns the values stored in the
> Hashtable object as an array of Object instances. An element in this
> array may be a simple Object instance or an array (which is a type of
> Object). The particular setter method used determines whether an
> element in this array is an Object or an array.'
>   

Right this is why I have go to back and look at this closer to see what 
might have happened here.

-lance
> So the code that would perform the equivalent of a getDate method
> would be getParams()[n], where n is the integer passed to the setDate
> method.
>
> Thanks again,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090827/add17dea/attachment.html>

From Christopher.Hegarty at Sun.COM  Fri Aug 28 12:27:56 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Fri, 28 Aug 2009 13:27:56 +0100
Subject: java.util.LinkedList clear() improvement
In-Reply-To: <1ccfd1c10908271024u6efd300xc0ce74ede606dfaa@mail.gmail.com>
References: <79be5fa30908270531h2cbcb605o9c5fba5fc5eb41f6@mail.gmail.com>
	<4A968C2E.8020308@sun.com>
	<79be5fa30908270718x6321c504y401b11968b347900@mail.gmail.com>
	<4A96ADEA.6040705@sun.com>
	<1ccfd1c10908271024u6efd300xc0ce74ede606dfaa@mail.gmail.com>
Message-ID: <4A97CD4C.1090401@Sun.COM>

Hi Martin,

I put the diffs in the public comments of 4863813, but if you can't wait 
for bug.sun.com to catch up the diffs are attached.

-Chris.

On 27/08/2009 18:24, Martin Buchholz wrote:
> Very interesting - thanks for the pointer to the bug id.
> Chris, could you update the bug report to contain a (public) diff
> of the actual changes that were made?
> The bug report does not mention clear().
> 
> Curiously, the jsr166 team has been working on fixing the same
> kinds of issues in java.util.concurrent queue implementations recently.
> At least one clear() implementation was intentionally
> changed from O(1) to O(N) for correctness.
> 
> For LinkedList.clear(), I think we might be able to get an optimal
> hybrid solution,
> that would unlink just the 2 immediate neighbors of the header node (if any),
> remaining O(1), but also being generational-GC-friendly (e.g. if an
> existing Node
> was tenured - avoid links from a dead tenured Node to a live Node).
> 
> Martin
> 
> On Thu, Aug 27, 2009 at 09:01, Christopher Hegarty -Sun Microsystems
> Ireland<Christopher.Hegarty at sun.com> wrote:
>> I think this change was made to address:
>>
>> 4863813: Stressing single LinkedList from multiple threads causes heapspace
>> to completely
>>
>>  http://bugs.sun.com/view_bug.do?bug_id=4863813
>>
>> -Chris.
>>
>> Guy Korland wrote:
>>> How does it help the GC?
>>> As I understand the M&S algorithm, there's no real advantages in doing so.
>>>
>>> In fact in many places to "null" references is considered to be an
>>> anti pattern in java.
>>>
>>> Guy
>>>
>>> On Thu, Aug 27, 2009 at 4:37 PM, Tom Hawtin<Thomas.Hawtin at sun.com> wrote:
>>>> Guy Korland wrote:
>>>>
>>>>> It seems like linkedList.clear() can be easily fixed to O(1) instead of
>>>>> O(n).
>>>> The code is like that on purpose(!). It was done to help GC, in mustang
>>>> IIRC. There really isn't a problem with clear() being O(n) - it's going
>>>> to
>>>> take at least O(n) to populate it, and in reality *many* times more
>>>> cycles.
>>>>
>>>> Tom
>>>>
>>>
>>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: LinkedList4863813.diffs
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090828/1d3ccd39/LinkedList4863813.diffs>

From joe.darcy at sun.com  Fri Aug 28 18:19:24 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Fri, 28 Aug 2009 18:19:24 +0000
Subject: hg: jdk7/tl/jdk: 6877122: Many javadoc warnings from java.awt.Window, 
	other awt classes
Message-ID: <20090828182029.010BA1273E@hg.openjdk.java.net>

Changeset: 4a5f2147f953
Author:    darcy
Date:      2009-08-28 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a5f2147f953

6877122: Many javadoc warnings from java.awt.Window, other awt classes
Reviewed-by: anthony

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



From jonathan.gibbons at sun.com  Fri Aug 28 19:20:23 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 28 Aug 2009 19:20:23 +0000
Subject: hg: jdk7/tl/langtools: 6876782: two javadoc tests fail on Windows
Message-ID: <20090828192024.F100C1275E@hg.openjdk.java.net>

Changeset: 0ba956343648
Author:    jjg
Date:      2009-08-28 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0ba956343648

6876782: two javadoc tests fail on Windows
Reviewed-by: darcy

! test/com/sun/javadoc/lib/JavadocTester.java
! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java



From joe.darcy at sun.com  Fri Aug 28 21:18:52 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Fri, 28 Aug 2009 21:18:52 +0000
Subject: hg: jdk7/tl/jdk: 6261502: (reflect) Add the functionality to screen
	out the "inappropriate" modifier bits
Message-ID: <20090828211937.84EA112782@hg.openjdk.java.net>

Changeset: e0f79982edd2
Author:    darcy
Date:      2009-08-28 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0f79982edd2

6261502: (reflect) Add the functionality to screen out the "inappropriate" modifier bits
Reviewed-by: alanb

! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java



From jonathan.gibbons at sun.com  Fri Aug 28 21:57:03 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 28 Aug 2009 21:57:03 +0000
Subject: hg: jdk7/tl/langtools: 6877188: some javac shell tests do not work on
	Windows
Message-ID: <20090828215705.1A7311278D@hg.openjdk.java.net>

Changeset: f0c9fc46990b
Author:    jjg
Date:      2009-08-28 14:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f0c9fc46990b

6877188: some javac shell tests do not work on Windows
Reviewed-by: darcy

! test/tools/javac/4846262/Test.sh
! test/tools/javac/6302184/T6302184.sh
! test/tools/javac/ClassPathTest/ClassPathTest.sh
! test/tools/javac/ExtDirs/ExtDirs.sh
! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh
! test/tools/javac/javazip/Test.sh
! test/tools/javac/newlines/Newlines.sh
! test/tools/javac/unicode/SupplementaryJavaID6.sh



From tim.bell at sun.com  Sun Aug 30 06:14:09 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sun, 30 Aug 2009 06:14:09 +0000
Subject: hg: jdk7/tl: 4 new changesets
Message-ID: <20090830061409.8E2AF12804@hg.openjdk.java.net>

Changeset: 51a71c2c4b80
Author:    xdono
Date:      2009-08-13 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/51a71c2c4b80

Added tag jdk7-b69 for changeset 82e6c820c51a

! .hgtags

Changeset: 175cb3fe6159
Author:    tbell
Date:      2009-08-14 08:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/175cb3fe6159

Merge


Changeset: de7a3e98c159
Author:    xdono
Date:      2009-08-20 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/de7a3e98c159

Added tag jdk7-b70 for changeset 175cb3fe6159

! .hgtags

Changeset: 4c36e9853dda
Author:    tbell
Date:      2009-08-24 22:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/4c36e9853dda

Merge




From tim.bell at sun.com  Sun Aug 30 06:21:08 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sun, 30 Aug 2009 06:21:08 +0000
Subject: hg: jdk7/tl/corba: Added tag jdk7-b70 for changeset 175bd6877954
Message-ID: <20090830062110.A07C112809@hg.openjdk.java.net>

Changeset: 9f1959c73473
Author:    xdono
Date:      2009-08-20 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/9f1959c73473

Added tag jdk7-b70 for changeset 175bd6877954

! .hgtags



From tim.bell at sun.com  Sun Aug 30 06:29:56 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sun, 30 Aug 2009 06:29:56 +0000
Subject: hg: jdk7/tl/hotspot: 42 new changesets
Message-ID: <20090830063118.DB0C81280F@hg.openjdk.java.net>

Changeset: 50a704b1d838
Author:    xdono
Date:      2009-08-20 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/50a704b1d838

Added tag jdk7-b70 for changeset 0632c3e615a3

! .hgtags

Changeset: f753dffae23e
Author:    trims
Date:      2009-08-13 17:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f753dffae23e

6871765: Bump the HS16 build number to 08
Summary: Update the HS16 build number to 08
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 6a93908f268f
Author:    mchung
Date:      2009-07-10 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6a93908f268f

6857194: Add hotspot perf counters to aid class loading performance measurement
Summary: Add new jvmstat counters to measure detailed class loading time
Reviewed-by: acorn, kamg

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/includeDB_core
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/perfData.hpp
! src/share/vm/services/threadService.cpp
! src/share/vm/services/threadService.hpp

Changeset: 1413494da700
Author:    martin
Date:      2009-06-29 14:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1413494da700

6850957: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit
Summary: call report_java_out_of_memory("Requested array size exceeds VM limit")
Reviewed-by: tbell, dholmes, alanb, ysr
Contributed-by: jeremymanson at google.com

! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp

Changeset: 8c79517a9300
Author:    poonam
Date:      2009-07-16 18:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8c79517a9300

6840305: Discrepancy in system memory details (when 4G or greater) reported by JVM and Windows OS
Summary: GlobalMemoryStatus() does not report correct memory usage when the system has more than 4gb of RAM. GlobalMemoryStatusEx() should be used in place of GlobalMemoryStatus().
Reviewed-by: kamg, coleenp

! src/os/windows/vm/os_windows.cpp

Changeset: abe076e3636f
Author:    mchung
Date:      2009-07-27 09:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/abe076e3636f

6864003: Modify JVM_FindClassFromBootLoader to return null if class not found
Summary: JVM_FindClassFromBootLoader returns null if class not found
Reviewed-by: acorn, alanb, dholmes

! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h

Changeset: 494244ae0171
Author:    coleenp
Date:      2009-07-27 17:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/494244ae0171

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/includeDB_core
! src/share/vm/oops/objArrayKlass.cpp

Changeset: 2b4230d1e589
Author:    dcubed
Date:      2009-07-28 13:35 -0600
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2b4230d1e589

6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints)
Summary: Correctly count full GC operations for framework collectors. Add ForceFullGCJVMTIEpilogues as a future work around if needed.
Reviewed-by: jcoomes, alanb, ysr

! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 16c930df1e9b
Author:    dcubed
Date:      2009-07-28 13:50 -0600
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/16c930df1e9b

Merge

! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 66b0f834a440
Author:    coleenp
Date:      2009-07-30 15:06 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/66b0f834a440

Merge

! src/share/vm/classfile/classLoader.cpp

Changeset: 27f6a9b9c311
Author:    tonyp
Date:      2009-07-29 11:01 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/27f6a9b9c311

6864886: G1: rename -XX parameters related to update buffers
Summary: renaming a couple of update buffer-related parameters to make them more understandable and consistent.
Reviewed-by: iveresov, ysr

! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 83b687ce3090
Author:    tonyp
Date:      2009-07-30 14:50 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/83b687ce3090

6866591: G1: print update buffer processing stats more often
Summary: It adds parameter -XX:+G1SummarizeRSetStatsPeriod that causes update buffer processing information to be printed periodically. It also includes two small formatting changes.
Reviewed-by: jmasa, jcoomes, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 7f807f55161a
Author:    ysr
Date:      2009-07-31 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7f807f55161a

Merge

! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 061cd4d965fc
Author:    jmasa
Date:      2009-08-02 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/061cd4d965fc

6862534: -XX:NewRatio completely ignored when combined with -XX:+UseConcMarkSweepG
Summary: Use NewRatio if it is explicitly set.
Reviewed-by: ysr, jcoomes

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

Changeset: ff004bcd2596
Author:    jmasa
Date:      2009-08-02 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ff004bcd2596

6843292: "Expect to be beyond new region unless impacting another region" assertion too strong
Summary: In the assertion allow for collision with the guard page.
Reviewed-by: tonyp, ysr, jcoomes

! src/share/vm/memory/cardTableModRefBS.cpp

Changeset: 59726d16b30d
Author:    jmasa
Date:      2009-08-02 22:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/59726d16b30d

Merge


Changeset: 15c5903cf9e1
Author:    johnc
Date:      2009-08-03 12:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/15c5903cf9e1

6865703: G1: Parallelize hot card cache cleanup
Summary: Have the GC worker threads clear the hot card cache in parallel by having each worker thread claim a chunk of the card cache and process the cards in that chunk. The size of the chunks that each thread will claim is determined at VM initialization from the size of the card cache and the number of worker threads.
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 6cb8e9df7174
Author:    johnc
Date:      2009-08-04 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6cb8e9df7174

6819077: G1: first GC thread coming late into the GC.
Summary: The first worker thread is delayed when entering the GC because it clears the card count table that is used in identifying hot cards. Replace the card count table with a dynamically sized evicting hash table that includes an epoch based counter.
Reviewed-by: iveresov, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: 703065c670fa
Author:    ysr
Date:      2009-08-05 18:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/703065c670fa

6868991: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved
Summary: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved
Reviewed-by: jcoomes

! make/jprt.properties

Changeset: a94af87c3357
Author:    never
Date:      2009-07-24 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a94af87c3357

6861984: solaris version of libsaproc.so should support SA_ALTROOT directly
Reviewed-by: kvn, twisti

! agent/make/saenv.sh
! agent/make/saenv64.sh
! agent/src/os/solaris/proc/Makefile
! agent/src/os/solaris/proc/mapfile
! agent/src/os/solaris/proc/saproc.cpp
+ agent/src/os/solaris/proc/saproc_audit.cpp

Changeset: dd0a4e1e219b
Author:    kvn
Date:      2009-07-26 12:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dd0a4e1e219b

6851386: assert(b->find_node(def) < j,"uses must follow definitions")
Summary: Add additional check for a tight loop.
Reviewed-by: never

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

Changeset: 665be97e8704
Author:    kvn
Date:      2009-07-26 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/665be97e8704

6863420: os::javaTimeNanos() go backward on Solaris x86
Summary: Use new atomic long load method Atomic::load() to load max_hrtime.
Reviewed-by: never, ysr, johnc, phh, dcubed, acorn

! src/os/solaris/vm/os_solaris.cpp
! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp
! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/solaris_x86_32.il
! src/share/vm/runtime/atomic.hpp
+ test/compiler/6863420/Test.java

Changeset: 94b6d06fd759
Author:    twisti
Date:      2009-07-20 08:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/94b6d06fd759

6860920: serialize.cpp shouldn't use objArrayOopDesc::base_offset_in_bytes(T_BYTE)
Summary: serialize.cpp currently uses objArrayOopDesc::base_offset_in_bytes(T_BYTE), which seems to be wrong.
Reviewed-by: coleenp, kvn

! src/share/vm/memory/serialize.cpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/opto/library_call.cpp

Changeset: 1cef5ec3ca56
Author:    twisti
Date:      2009-07-27 06:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1cef5ec3ca56

Merge

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

Changeset: 52898b0c43e9
Author:    twisti
Date:      2009-07-28 09:02 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/52898b0c43e9

6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask)
Summary: Code compiled with server compiler generates an incorrect result.
Reviewed-by: cfang, never, kvn

! src/share/vm/opto/mulnode.cpp
+ test/compiler/6863155/Test6863155.java

Changeset: 60fea60a6db5
Author:    kvn
Date:      2009-07-30 16:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/60fea60a6db5

6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops
Summary: Always use "lea" instruction for narrow oop decoding instead of "shift".
Reviewed-by: never

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

Changeset: 55cb84cd1247
Author:    kvn
Date:      2009-07-31 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/55cb84cd1247

6865031: Application gives bad result (throws bad exception) with compressed oops
Summary: Produce narrow type for new Phi from the original Phi type.
Reviewed-by: cfang

! src/share/vm/opto/cfgnode.cpp
+ test/compiler/6865031/Test.java

Changeset: 9987d9d5eb0e
Author:    cfang
Date:      2009-07-31 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9987d9d5eb0e

6833129: specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot
Summary: developed a reexecute logic for the interpreter to reexecute the bytecode when deopt happens
Reviewed-by: kvn, never, jrose, twisti

! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/code/debugInfo.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/debugInfoRec.hpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/scopeDesc.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframeArray.hpp
! src/share/vm/runtime/vframe_hp.cpp
! src/share/vm/runtime/vframe_hp.hpp
+ test/compiler/6833129/Test.java

Changeset: 2b9164d13ce9
Author:    kvn
Date:      2009-08-04 17:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2b9164d13ce9

6868486: timouts and outOfMemory in regression tests
Summary: Increase timeout for tests and heap size for 6851282 test.
Reviewed-by: never, cfang

! test/compiler/6826736/Test.java
! test/compiler/6851282/Test.java

Changeset: fc2281ddce3c
Author:    cfang
Date:      2009-08-04 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc2281ddce3c

6868269: CompileTheWorld assertion failure introduced by the reexecute bit implementation
Summary: Improvement on reexecute implementation to fix the assertion failure
Reviewed-by: kvn, never

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

Changeset: 15bbd3f505c0
Author:    kvn
Date:      2009-08-06 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/15bbd3f505c0

Merge

! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframe_hp.cpp

Changeset: ef671fb22f73
Author:    never
Date:      2009-08-06 12:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ef671fb22f73

6868051: (SA) FreeChunk support for compressed oops is broken
Reviewed-by: kvn, dcubed

! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java

Changeset: bd2b1f617a4e
Author:    jrose
Date:      2009-08-06 14:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bd2b1f617a4e

6868487: EnableInvokeDynamic and EnableMethodHandles should not be visible flags in JDK6 or JDK7
Summary: switch them from product to experimental; 6817525 will toggle them and switch to diagnostic
Reviewed-by: kvn

! src/share/vm/runtime/globals.hpp

Changeset: 9c65a08a31a3
Author:    jrose
Date:      2009-08-06 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9c65a08a31a3

Merge


Changeset: 3ee342e25e57
Author:    jcoomes
Date:      2009-08-05 12:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3ee342e25e57

6821693: 64-bit TaskQueue capacity still too small
6821507: Alignment problem in GC taskqueue
Reviewed-by: tonyp, apetrusenko

! src/share/vm/utilities/taskqueue.hpp

Changeset: b1773b9a2ca1
Author:    ysr
Date:      2009-08-09 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b1773b9a2ca1

Merge


Changeset: b32a809aab08
Author:    jcoomes
Date:      2009-08-11 23:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b32a809aab08

6866585: debug code in ciObjectFactory too slow for large objects
Reviewed-by: ysr, never, kvn

! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 10d8c0d0d60e
Author:    jcoomes
Date:      2009-08-12 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/10d8c0d0d60e

6867645: java -Xshare:dump failed - read only space too small
Reviewed-by: iveresov, tonyp, ysr

! src/share/vm/runtime/globals.hpp

Changeset: 16314a31b961
Author:    trims
Date:      2009-08-13 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/16314a31b961

Merge


Changeset: 308762b2bf14
Author:    apetrusenko
Date:      2009-08-14 13:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/308762b2bf14

6872000: G1: compilation fails on linux/older gcc
Reviewed-by: jcoomes, tonyp

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: ac59d4e6dae5
Author:    trims
Date:      2009-08-14 17:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ac59d4e6dae5

Merge


Changeset: 50a95aa4a247
Author:    trims
Date:      2009-08-21 20:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/50a95aa4a247

Merge




From tim.bell at sun.com  Sun Aug 30 06:41:37 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sun, 30 Aug 2009 06:41:37 +0000
Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b70 for changeset c83f0106b78a
Message-ID: <20090830064140.8E3F112814@hg.openjdk.java.net>

Changeset: ff94d8ce0dad
Author:    xdono
Date:      2009-08-20 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ff94d8ce0dad

Added tag jdk7-b70 for changeset c83f0106b78a

! .hgtags



From tim.bell at sun.com  Sun Aug 30 06:47:50 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sun, 30 Aug 2009 06:47:50 +0000
Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b70 for changeset dd3c5f3ec28d
Message-ID: <20090830064753.4B11B1281B@hg.openjdk.java.net>

Changeset: 03314cf56a72
Author:    xdono
Date:      2009-08-20 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/03314cf56a72

Added tag jdk7-b70 for changeset dd3c5f3ec28d

! .hgtags



From tim.bell at sun.com  Sun Aug 30 06:54:57 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sun, 30 Aug 2009 06:54:57 +0000
Subject: hg: jdk7/tl/jdk: 16 new changesets
Message-ID: <20090830070022.D6A6B12820@hg.openjdk.java.net>

Changeset: fb51d4974400
Author:    uta
Date:      2009-07-31 17:24 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fb51d4974400

6851688: Hung up in applet application
Reviewed-by: art, dcherepanov

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

Changeset: e6f6765a20f2
Author:    yan
Date:      2009-08-06 01:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6f6765a20f2

Merge

- src/share/classes/com/sun/crypto/provider/JarVerifier.java
- src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java
- src/share/classes/sun/security/pkcs11/JarVerifier.java
- src/windows/classes/sun/security/mscapi/JarVerifier.java

Changeset: e066c998e4f3
Author:    yan
Date:      2009-08-12 00:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e066c998e4f3

Merge


Changeset: 4c6a5ea563ba
Author:    peytoia
Date:      2009-07-30 14:45 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4c6a5ea563ba

6866243: Javadoc for java.lang.Character still refers to Unicode 4 instead of 5
Reviewed-by: okutsu

! src/share/classes/java/lang/Character.java

Changeset: 389cecd0ca18
Author:    malenkov
Date:      2009-07-31 16:27 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/389cecd0ca18

6865565: Test failed: /test/closed/javax/swing/JInternalFrame/6325652/bug6325652.java
Reviewed-by: peterz

+ test/javax/swing/JInternalFrame/Test6325652.java
! test/javax/swing/JInternalFrame/Test6505027.java
! test/javax/swing/JInternalFrame/Test6802868.java
! test/javax/swing/JScrollPane/Test6526631.java
! test/javax/swing/SwingTest.java

Changeset: 23dfc2c451e3
Author:    gsm
Date:      2009-08-03 19:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23dfc2c451e3

6539700: JTextPane line wrap radically different from previous versions in jre 1.5.0_10+
Reviewed-by: peterz

! src/share/classes/javax/swing/text/GlyphView.java
! src/share/classes/javax/swing/text/ParagraphView.java
+ test/javax/swing/text/GlyphView/6539700/bug6539700.java

Changeset: e548894909dc
Author:    andrew
Date:      2009-08-06 16:04 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e548894909dc

6593649: Word wrap broken for JTextArea
Summary: Layout correctly resizes components based on actual dimensions of the window they are in.
Reviewed-by: gsm
Contributed-by: Lillian Angel <langel at redhat.com>

! src/share/classes/javax/swing/text/WrappedPlainView.java
+ test/javax/swing/JTextArea/Test6593649.java

Changeset: 7f2d92517f09
Author:    yan
Date:      2009-08-07 02:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7f2d92517f09

Merge

- src/share/classes/com/sun/crypto/provider/JarVerifier.java
! src/share/classes/java/lang/Character.java
- src/share/classes/sun/security/pkcs11/JarVerifier.java
- src/windows/classes/sun/security/mscapi/JarVerifier.java

Changeset: 082ffa4c6749
Author:    malenkov
Date:      2009-08-07 19:06 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/082ffa4c6749

6868189: Nested enum class with custom BeanInfo fails
Reviewed-by: peterz

! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java
+ test/java/beans/Introspector/Test6868189.java

Changeset: 6794e1f16729
Author:    rupashka
Date:      2009-08-10 14:55 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6794e1f16729

6461173: One JCK test([NewFolderAction0001]) failed on Windows due to lack of PropertyPermission(s)
Reviewed-by: peterz, malenkov

! src/share/classes/javax/swing/filechooser/FileSystemView.java
! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java

Changeset: 8e65977e4969
Author:    alexp
Date:      2009-08-10 16:29 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8e65977e4969

6822696: Integrating JXLayer component to Swing library
Reviewed-by: peterz, art

+ src/share/classes/javax/swing/JLayer.java
+ src/share/classes/javax/swing/plaf/LayerUI.java
+ test/javax/swing/JLayer/SerializationTest/SerializationTest.java

Changeset: 5ff018677b2d
Author:    yan
Date:      2009-08-12 00:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5ff018677b2d

Merge


Changeset: 893bcca951b7
Author:    yan
Date:      2009-08-18 23:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/893bcca951b7

Merge


Changeset: de49d1343d86
Author:    xdono
Date:      2009-08-20 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de49d1343d86

Added tag jdk7-b70 for changeset 893bcca951b7

! .hgtags

Changeset: b71a03c75515
Author:    tbell
Date:      2009-08-24 22:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b71a03c75515

Merge

- src/share/classes/sun/nio/ch/AbstractFuture.java

Changeset: 225aa5ee10da
Author:    tbell
Date:      2009-08-28 16:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/225aa5ee10da

Merge

! src/share/classes/javax/swing/text/ParagraphView.java
- src/share/native/java/util/zip/zlib-1.1.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.1.3/README
- src/share/native/java/util/zip/zlib-1.1.3/compress.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.c
- src/share/native/java/util/zip/zlib-1.1.3/deflate.h
- src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc
- src/share/native/java/util/zip/zlib-1.1.3/example.c
- src/share/native/java/util/zip/zlib-1.1.3/gzio.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.c
- src/share/native/java/util/zip/zlib-1.1.3/infblock.h
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.c
- src/share/native/java/util/zip/zlib-1.1.3/infcodes.h
- src/share/native/java/util/zip/zlib-1.1.3/inffast.c
- src/share/native/java/util/zip/zlib-1.1.3/inffast.h
- src/share/native/java/util/zip/zlib-1.1.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.1.3/inflate.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.1.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.1.3/infutil.c
- src/share/native/java/util/zip/zlib-1.1.3/infutil.h
- src/share/native/java/util/zip/zlib-1.1.3/minigzip.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.c
- src/share/native/java/util/zip/zlib-1.1.3/trees.h
- src/share/native/java/util/zip/zlib-1.1.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.1.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.1.3/zconf.h
- src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.1.3/zlib.h
- src/share/native/java/util/zip/zlib-1.1.3/zutil.c
- src/share/native/java/util/zip/zlib-1.1.3/zutil.h
- test/java/util/concurrent/LinkedBlockingQueue/LastElement.java
- test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java



From tim.bell at sun.com  Sun Aug 30 07:15:15 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sun, 30 Aug 2009 07:15:15 +0000
Subject: hg: jdk7/tl/langtools: 3 new changesets
Message-ID: <20090830071526.425A512827@hg.openjdk.java.net>

Changeset: 6f07b50a8796
Author:    xdono
Date:      2009-08-20 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6f07b50a8796

Added tag jdk7-b70 for changeset 97d06f3e8787

! .hgtags

Changeset: 33c8c38e1757
Author:    tbell
Date:      2009-08-24 22:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/33c8c38e1757

Merge


Changeset: ce5be4c09f2a
Author:    tbell
Date:      2009-08-28 16:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ce5be4c09f2a

Merge

- test/tools/javac/meth/InvokeMH_BAD68.java
- test/tools/javac/meth/InvokeMH_BAD72.java
- test/tools/javac/quid/QuotedIdent_BAD61.java
- test/tools/javac/quid/QuotedIdent_BAD62.java
- test/tools/javac/quid/QuotedIdent_BAD63.java



From jonathan.gibbons at sun.com  Mon Aug 31 19:44:54 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 31 Aug 2009 19:44:54 +0000
Subject: hg: jdk7/tl/langtools: 6877229: more javac tests fail on Windows
Message-ID: <20090831194459.68C0D128F4@hg.openjdk.java.net>

Changeset: d5e76d422509
Author:    jjg
Date:      2009-08-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d5e76d422509

6877229: more javac tests fail on Windows
Reviewed-by: darcy

! test/tools/javac/6589361/T6589361.java
! test/tools/javac/MissingInclude.sh
! test/tools/javac/T5090006/compiler.sh
! test/tools/javac/api/6440333/T6440333.java
! test/tools/javac/api/Sibling.java
! test/tools/javac/code/ArrayClone.java
! test/tools/javac/constDebug/ConstDebug.sh
! test/tools/javac/fatalErrors/NoJavaLang.sh
! test/tools/javac/innerClassFile/Driver.sh
! test/tools/javac/quid/QuotedIdent.java
! test/tools/javac/quid/QuotedIdent2.java
! test/tools/javac/stackmap/T4955930.sh



From martinrb at google.com  Mon Aug 31 22:11:31 2009
From: martinrb at google.com (martinrb at google.com)
Date: Mon, 31 Aug 2009 22:11:31 +0000
Subject: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)
Message-ID: <20090831221217.2CEFA12912@hg.openjdk.java.net>

Changeset: db5d6b4cbc11
Author:    martin
Date:      2009-08-31 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db5d6b4cbc11

6860431: Character.isSurrogate(char ch)
Summary: Add new method Character.isSurrogate(char ch)
Reviewed-by: sherman, darcy, okutsu

! src/share/classes/java/lang/Character.java
! src/share/classes/sun/io/CharToByteDBCS_ASCII.java
! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java
! src/share/classes/sun/nio/cs/ISO_8859_1.java
! src/share/classes/sun/nio/cs/SingleByte.java
! src/share/classes/sun/nio/cs/SingleByteEncoder.java
! src/share/classes/sun/nio/cs/Surrogate.java
! src/share/classes/sun/nio/cs/US_ASCII.java
! src/share/classes/sun/nio/cs/UTF_32Coder.java
! src/share/classes/sun/nio/cs/UTF_8.java
! src/share/classes/sun/nio/cs/UnicodeDecoder.java
! src/share/classes/sun/nio/cs/UnicodeEncoder.java
! src/share/classes/sun/nio/cs/ext/DoubleByte.java
! src/share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
! src/share/classes/sun/nio/cs/ext/EUC_JP.java
! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
! src/share/classes/sun/nio/cs/ext/EUC_TW.java
! src/share/classes/sun/nio/cs/ext/GB18030.java
! src/share/classes/sun/nio/cs/ext/ISCII91.java
! src/share/classes/sun/nio/cs/ext/ISO2022.java
! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java
! src/share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java