From edvard.wendelin at oracle.com Tue Mar 5 07:52:00 2013 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 05 Mar 2013 16:52:00 +0100 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <5125347C.5020006@redhat.com> References: <51139826.1040109@oracle.com> <93CD0593-08D2-4D2F-A4DA-402C457E26FE@oracle.com> <5125347C.5020006@redhat.com> Message-ID: <513614A0.1010904@oracle.com> Hi, The change in JAXP can be viewed here: http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While it's generated against JDK 8, the change in 6 is identical. I plan to push the changes today. Cheers, Edvard On 02/20/2013 09:39 PM, Omair Majid wrote: > Hi Edvard, > > Sorry, I accidentally sent this off-list the first time. > > On 02/12/2013 03:44 AM, Edvard Wendelin wrote: >> Here is an updated webrev: http://cr.openjdk.java.net/~ewendeli/6ssr.2/ > I compared this with what we added to icedtea6 and it looks fine to me. > > Is it customary to have the jaxp changes reviewed separately or > somewhere else? The patch just changes which jaxp bundle is used to > build openjdk6. > > Thanks, > Omair > From omajid at redhat.com Tue Mar 5 10:44:30 2013 From: omajid at redhat.com (Omair Majid) Date: Tue, 05 Mar 2013 13:44:30 -0500 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <513614A0.1010904@oracle.com> References: <51139826.1040109@oracle.com> <93CD0593-08D2-4D2F-A4DA-402C457E26FE@oracle.com> <5125347C.5020006@redhat.com> <513614A0.1010904@oracle.com> Message-ID: <51363D0E.7070104@redhat.com> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: > Hi, > > The change in JAXP can be viewed here: > http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While it's > generated against JDK 8, the change in 6 is identical. The JAXP changes look identical to what was pushed to jdk7u. Looks all good to me! > I plan to push the changes today. Thank you. It will be great to have all the security fixes in! Cheers, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From sean.coffey at oracle.com Tue Mar 5 11:37:19 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 05 Mar 2013 19:37:19 +0000 Subject: hg: jdk6/jdk6/corba: 4 new changesets Message-ID: <20130305193721.D60D947858@hg.openjdk.java.net> Changeset: c5203e9e0e07 Author: coffeys Date: 2012-12-08 18:49 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/c5203e9e0e07 8000631: Restrict access to class constructor Reviewed-by: alanb, ahgross ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/io/FVDCodeBaseImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdFactory.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java + src/share/classes/sun/corba/JavaCorbaAccess.java + src/share/classes/sun/corba/SharedSecrets.java Changeset: 42b1142b39b5 Author: ngmr Date: 2012-12-08 19:06 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/42b1142b39b5 8000540: Improve IIOP type reuse management Reviewed-by: alanb, ahgross, coffeys ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 58fdb67fcacc Author: coffeys Date: 2012-11-06 15:50 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/58fdb67fcacc 7201066: Change modifiers on unused fields Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/activation/ServerMain.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectStreamClass_1_3_1.java Changeset: 7eb471f1efdd Author: mbankal Date: 2012-12-13 03:08 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/7eb471f1efdd 7141694: Improving CORBA internals Reviewed-by: coffeys, ahgross ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java From sean.coffey at oracle.com Tue Mar 5 11:37:31 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 05 Mar 2013 19:37:31 +0000 Subject: hg: jdk6/jdk6/hotspot: 8001307: Modify ACC_SUPER behavior Message-ID: <20130305193733.6BC4747859@hg.openjdk.java.net> Changeset: 781104609348 Author: dcubed Date: 2013-01-07 12:56 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/781104609348 8001307: Modify ACC_SUPER behavior Summary: Disallow non-virtual calls even when ACC_SUPER is absent. Reviewed-by: dcubed Contributed-by: paul.nauman at oracle.com ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/globals.hpp From sean.coffey at oracle.com Tue Mar 5 11:37:41 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 05 Mar 2013 19:37:41 +0000 Subject: hg: jdk6/jdk6/jaxp: 8001236: Improve JAXP HTTP handling Message-ID: <20130305193741.404B04785A@hg.openjdk.java.net> Changeset: 7d6aeda6ba9b Author: joehw Date: 2012-12-12 14:11 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/7d6aeda6ba9b 8001236: Improve JAXP HTTP handling Reviewed-by: lancea, skoivu ! jaxp.properties From sean.coffey at oracle.com Tue Mar 5 11:38:05 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 05 Mar 2013 19:38:05 +0000 Subject: hg: jdk6/jdk6/jdk: 34 new changesets Message-ID: <20130305194257.22BEA4785C@hg.openjdk.java.net> Changeset: 6088f3510686 Author: dholmes Date: 2012-10-21 22:28 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/6088f3510686 6776941: Improve thread pool shutdown Reviewed-by: dl, skoivu ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java Changeset: 9c2a2aae44a4 Author: weijun Date: 2012-10-23 11:15 +0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/9c2a2aae44a4 8000210: Improve JarFile code quality Reviewed-by: ahgross, xuelei, mschoene ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/sun/security/util/DerIndefLenConverter.java Changeset: ce11c5c59cb8 Author: anthony Date: 2012-10-12 16:01 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ce11c5c59cb8 7173145: Improve in-memory representation of splashscreens Reviewed-by: bae, mschoene ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c Changeset: 1c8f90c6561b Author: rupashka Date: 2012-10-16 16:30 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/1c8f90c6561b 7186948: Improve Swing data validation Reviewed-by: art, ahgross ! src/share/classes/javax/swing/UIDefaults.java Changeset: f5cd977fb920 Author: rupashka Date: 2012-11-06 16:04 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f5cd977fb920 7200491: Tighten up JTable layout code Reviewed-by: art, skoivu ! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/JTable.java Changeset: 090f6ba7b0dc Author: coffeys Date: 2012-11-07 11:06 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/090f6ba7b0dc 7201068: Better handling of UI elements Reviewed-by: mullan, skoivu ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 51e0a30e4b19 Author: dmeetry Date: 2012-11-07 17:45 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/51e0a30e4b19 7186954: Improve connection performance Reviewed-by: khazra ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java Changeset: 4d8e68b2e189 Author: robm Date: 2012-11-13 15:13 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/4d8e68b2e189 7201071: InetSocketAddress serialization issue Reviewed-by: chegar ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/nio/channels/DatagramChannel/SendToUnresolved.java Changeset: 957761172aca Author: coffeys Date: 2012-11-15 22:42 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/957761172aca 7200500: Launcher better input validation Reviewed-by: ksrini ! src/share/bin/parse_manifest.c Changeset: cd583699f743 Author: bae Date: 2012-11-16 11:15 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/cd583699f743 8001972: Improve image processing Reviewed-by: prr, ahgross ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: aa0f90e27513 Author: bae Date: 2012-11-20 12:02 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/aa0f90e27513 8002325: Improve management of images Reviewed-by: prr, ahgross ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h Changeset: 66a5c3c654af Author: lana Date: 2012-10-26 14:32 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/66a5c3c654af Added tag jdk6-b27 for changeset 21487ef30163 ! .hgtags Changeset: ff61c0aad219 Author: ewendeli Date: 2012-11-25 12:56 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ff61c0aad219 8000537: Contextualize RequiredModelMBean class Reviewed-by: jbachorik Contributed-by: Andreas Eriksson ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Changeset: f39eab3d0067 Author: bagiras Date: 2012-11-22 18:20 +0300 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f39eab3d0067 7192977: Issue in toolkit thread Reviewed-by: skoivu, art ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: aaef49c4b7d3 Author: denis Date: 2012-11-26 20:24 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/aaef49c4b7d3 7186952: Improve clipboard access Reviewed-by: serb, ahgross ! src/share/classes/java/awt/TextComponent.java ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 1440897c4a5c Author: denis Date: 2012-12-03 14:06 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/1440897c4a5c 7201064: Better dialogue checking Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: f5e09db08f6a Author: miroslawzn Date: 2012-11-30 17:08 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f5e09db08f6a 7186945: Unpack200 improvement 7186957: Improve Pack200 data validation 7186946: Refine unpacker resource usage Reviewed-by: ksrini ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/jni.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: 42a6492ca02e Author: mbankal Date: 2012-12-11 03:49 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/42a6492ca02e 7192392: Better validation of client keys Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/DHCrypt.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java - src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/KeyUtil.java Changeset: 7c47d887ed89 Author: denis Date: 2012-12-11 16:08 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7c47d887ed89 8004341: Two JCK tests fails with 7u11 b06 Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: 151f9e47de23 Author: mbankal Date: 2012-12-11 22:43 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/151f9e47de23 7192393: Better Checking of order of TLS Messages Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: fa08d11c1f6a Author: mbankal Date: 2012-12-12 07:59 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/fa08d11c1f6a 7197546: (proxy) Reflect about creating reflective proxies Reviewed-by: mchung ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 2989574e04c1 Author: coffeys Date: 2012-12-12 14:31 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/2989574e04c1 7201070: Serialization to conform to protocol Reviewed-by: smarks, skoivu ! src/share/classes/java/io/ObjectInputStream.java Changeset: b3b83407c38f Author: coffeys Date: 2012-12-12 14:40 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b3b83407c38f 6563318: RMI data sanitization Reviewed-by: dmocek ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Changeset: 415970a151a9 Author: coffeys Date: 2012-12-12 14:42 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/415970a151a9 8001242: Improve RMI HTTP conformance Reviewed-by: dmocek ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java Changeset: e8bb85c4cd5f Author: coffeys Date: 2012-12-13 21:08 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e8bb85c4cd5f 6664509: Add logging context 6664528: Find log level matching its name or value given at construction time Reviewed-by: mchung ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/lib/security/java.security Changeset: 7649aa3f9af1 Author: coffeys Date: 2012-12-13 21:09 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7649aa3f9af1 8004175: Restricted packages added in java.security are missing in java.security-{macosx, solaris, windows} Reviewed-by: mchung ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 7e9a50897589 Author: coffeys Date: 2012-12-21 14:00 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7e9a50897589 8004302: javax/xml/soap/Test7013971.java fails since jdk6u39b01 Reviewed-by: mullan ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 3fddb653394e Author: coffeys Date: 2013-02-05 23:33 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/3fddb653394e 8005615: Java Logger fails to load tomcat logger implementation (JULI) Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/CustomLogManager.java + test/java/util/logging/CustomLogManagerTest.java + test/java/util/logging/SimpleLogManager.java Changeset: 8628a71cb65a Author: coffeys Date: 2013-02-14 16:50 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/8628a71cb65a 8007393: Possible race condition after JDK-6664509 Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: f6f2d25b9c9c Author: coffeys Date: 2013-02-14 17:11 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f6f2d25b9c9c 8007611: logging behavior in applet changed Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: 599af0e34c9b Author: coffeys Date: 2013-02-14 20:32 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/599af0e34c9b 8007688: Blacklist known bad certificate Reviewed-by: mullan ! src/share/classes/sun/security/util/UntrustedCertificates.java Changeset: c14ba5b2bd91 Author: coffeys Date: 2013-02-14 22:48 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c14ba5b2bd91 8006777: Improve TLS handling of invalid messages Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: b4b8cfb76ea5 Author: ewendeli Date: 2013-01-29 00:16 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b4b8cfb76ea5 8006446: Restrict MBeanServer access Reviewed-by: skoivu, dfuchs, sjiang Contributed-by: andreas.eriksson at oracle.com ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/sun/management/LockDataConverter.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java Changeset: b8b3916e20ed Author: coffeys Date: 2013-03-05 19:36 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b8b3916e20ed Merge From sean.coffey at oracle.com Tue Mar 5 12:02:46 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 05 Mar 2013 20:02:46 +0000 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <51363D0E.7070104@redhat.com> References: <51139826.1040109@oracle.com> <93CD0593-08D2-4D2F-A4DA-402C457E26FE@oracle.com> <5125347C.5020006@redhat.com> <513614A0.1010904@oracle.com> <51363D0E.7070104@redhat.com> Message-ID: <51364F66.4000103@oracle.com> February CPU pushes completed as reviewed in last round of webrevs. I'd like to push 2 extra fixes now for issues addressed in yesterday's JDK releases. webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ Good to push ? regards, Sean. On 05/03/2013 18:44, Omair Majid wrote: > On 03/05/2013 10:52 AM, Edvard Wendelin wrote: >> Hi, >> >> The change in JAXP can be viewed here: >> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While it's >> generated against JDK 8, the change in 6 is identical. > The JAXP changes look identical to what was pushed to jdk7u. Looks all > good to me! > >> I plan to push the changes today. > Thank you. It will be great to have all the security fixes in! > > Cheers, > Omair > From omajid at redhat.com Wed Mar 6 09:12:16 2013 From: omajid at redhat.com (Omair Majid) Date: Wed, 06 Mar 2013 12:12:16 -0500 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <51364F66.4000103@oracle.com> References: <51139826.1040109@oracle.com> <93CD0593-08D2-4D2F-A4DA-402C457E26FE@oracle.com> <5125347C.5020006@redhat.com> <513614A0.1010904@oracle.com> <51363D0E.7070104@redhat.com> <51364F66.4000103@oracle.com> Message-ID: <513778F0.8000406@redhat.com> On 03/05/2013 03:02 PM, Se?n Coffey wrote: > February CPU pushes completed as reviewed in last round of webrevs. > > I'd like to push 2 extra fixes now for issues addressed in yesterday's > JDK releases. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ The only difference I see between this and the fix in 7u-dev is the doTransform/LCMS.colorConvert changes, which seems expected. > Good to push ? Yes, please. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From sean.coffey at oracle.com Wed Mar 6 12:25:26 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 06 Mar 2013 20:25:26 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20130306202552.4F4DA478AF@hg.openjdk.java.net> Changeset: 44c99b68e36c Author: bae Date: 2013-02-14 19:51 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/44c99b68e36c 8007014: Improve image handling Reviewed-by: prr, mschoene, jgodinez ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/BytePackedRaster.java ! src/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c ! src/share/native/sun/awt/medialib/safe_alloc.h + src/share/native/sun/awt/medialib/safe_math.h Changeset: 9714f53ef173 Author: bae Date: 2013-03-02 23:49 +0300 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/9714f53ef173 8007675: Improve color conversion Reviewed-by: prr, jgodinez ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java From gnu.andrew at redhat.com Thu Mar 7 02:59:14 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Mar 2013 05:59:14 -0500 (EST) Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <51364F66.4000103@oracle.com> Message-ID: <1200107515.14371206.1362653954788.JavaMail.root@redhat.com> ----- Original Message ----- > February CPU pushes completed as reviewed in last round of webrevs. > > I'd like to push 2 extra fixes now for issues addressed in > yesterday's > JDK releases. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ > > Good to push ? > > regards, > Sean. > > On 05/03/2013 18:44, Omair Majid wrote: > > On 03/05/2013 10:52 AM, Edvard Wendelin wrote: > >> Hi, > >> > >> The change in JAXP can be viewed here: > >> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While it's > >> generated against JDK 8, the change in 6 is identical. > > The JAXP changes look identical to what was pushed to jdk7u. Looks > > all > > good to me! > > > >> I plan to push the changes today. > > Thank you. It will be great to have all the security fixes in! > > > > Cheers, > > Omair > > > > I notice that what was finally committed differs from this webrev (in a positive way). The version posted from the webrev failed to compile: 1. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 580) LCMS.colorConvert(this, srcIL, dstIL); ^^^^^ srcIL cannot be resolved to a variable ---------- 2. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 580) LCMS.colorConvert(this, srcIL, dstIL); ^^^^^ dstIL cannot be resolved to a variable ---------- 3. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 606) LCMS.colorConvert(this, srcIL, dstIL); ^^^^^ srcIL cannot be resolved to a variable ---------- 4. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 606) LCMS.colorConvert(this, srcIL, dstIL); ^^^^^ dstIL cannot be resolved to a variable but this seems to have been fixed in the committed version, presumably due to: - try { - LCMSImageLayout srcIL = new LCMSImageLayout( - src, src.length/getNumInComponents(), - LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | - LCMSImageLayout.BYTES_SH(1), getNumInComponents()); - - LCMSImageLayout dstIL = new LCMSImageLayout( - dst, dst.length/getNumOutComponents(), - LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | - LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); - } catch (ImageLayoutException e) { - throw new CMMException("Unable to convert data"); - } + LCMSImageLayout srcIL = new LCMSImageLayout( + src, src.length/getNumInComponents(), + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); + + LCMSImageLayout dstIL = new LCMSImageLayout( + dst, dst.length/getNumOutComponents(), + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | + LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); so srcIL and dstIL are now declared at a wider scope. I'll use the committed versions in IcedTea6 HEAD. Cheers, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sean.coffey at oracle.com Thu Mar 7 03:07:14 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 07 Mar 2013 11:07:14 +0000 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <1200107515.14371206.1362653954788.JavaMail.root@redhat.com> References: <1200107515.14371206.1362653954788.JavaMail.root@redhat.com> Message-ID: <513874E2.9010504@oracle.com> I'm only the proxy here but I created the webrev from the changesets that I pushed. I don't see any difference. t4 $diff LCMSTransform.java.webrev jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java t4 $ regards, Sean. On 07/03/2013 10:59, Andrew Hughes wrote: > ----- Original Message ----- >> February CPU pushes completed as reviewed in last round of webrevs. >> >> I'd like to push 2 extra fixes now for issues addressed in >> yesterday's >> JDK releases. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ >> >> Good to push ? >> >> regards, >> Sean. >> >> On 05/03/2013 18:44, Omair Majid wrote: >>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: >>>> Hi, >>>> >>>> The change in JAXP can be viewed here: >>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While it's >>>> generated against JDK 8, the change in 6 is identical. >>> The JAXP changes look identical to what was pushed to jdk7u. Looks >>> all >>> good to me! >>> >>>> I plan to push the changes today. >>> Thank you. It will be great to have all the security fixes in! >>> >>> Cheers, >>> Omair >>> >> > I notice that what was finally committed differs from this webrev (in a positive > way). The version posted from the webrev failed to compile: > > 1. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 580) > LCMS.colorConvert(this, srcIL, dstIL); > ^^^^^ > srcIL cannot be resolved to a variable > ---------- > 2. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 580) > LCMS.colorConvert(this, srcIL, dstIL); > ^^^^^ > dstIL cannot be resolved to a variable > ---------- > 3. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 606) > LCMS.colorConvert(this, srcIL, dstIL); > ^^^^^ > srcIL cannot be resolved to a variable > ---------- > 4. ERROR in ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java (at line 606) > LCMS.colorConvert(this, srcIL, dstIL); > ^^^^^ > dstIL cannot be resolved to a variable > > but this seems to have been fixed in the committed version, presumably due to: > > - try { > - LCMSImageLayout srcIL = new LCMSImageLayout( > - src, src.length/getNumInComponents(), > - LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > - LCMSImageLayout.BYTES_SH(1), getNumInComponents()); > - > - LCMSImageLayout dstIL = new LCMSImageLayout( > - dst, dst.length/getNumOutComponents(), > - LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | > - LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); > - } catch (ImageLayoutException e) { > - throw new CMMException("Unable to convert data"); > - } > + LCMSImageLayout srcIL = new LCMSImageLayout( > + src, src.length/getNumInComponents(), > + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); > + > + LCMSImageLayout dstIL = new LCMSImageLayout( > + dst, dst.length/getNumOutComponents(), > + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | > + LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); > > so srcIL and dstIL are now declared at a wider scope. I'll use the committed versions > in IcedTea6 HEAD. > > Cheers, From gnu.andrew at redhat.com Thu Mar 7 04:30:27 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Mar 2013 07:30:27 -0500 (EST) Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <513874E2.9010504@oracle.com> Message-ID: <1179210539.14431300.1362659427439.JavaMail.root@redhat.com> ----- Original Message ----- > I'm only the proxy here but I created the webrev from the changesets > that I pushed. I don't see any difference. > > t4 $diff LCMSTransform.java.webrev > jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > t4 $ > Indeed. I'm still seeing the same failure using the changesets pushed to OpenJDK6, yet the repository itself builds. Very odd. > regards, > Sean. > > On 07/03/2013 10:59, Andrew Hughes wrote: > > ----- Original Message ----- > >> February CPU pushes completed as reviewed in last round of > >> webrevs. > >> > >> I'd like to push 2 extra fixes now for issues addressed in > >> yesterday's > >> JDK releases. > >> > >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ > >> > >> Good to push ? > >> > >> regards, > >> Sean. > >> > >> On 05/03/2013 18:44, Omair Majid wrote: > >>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: > >>>> Hi, > >>>> > >>>> The change in JAXP can be viewed here: > >>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While > >>>> it's > >>>> generated against JDK 8, the change in 6 is identical. > >>> The JAXP changes look identical to what was pushed to jdk7u. > >>> Looks > >>> all > >>> good to me! > >>> > >>>> I plan to push the changes today. > >>> Thank you. It will be great to have all the security fixes in! > >>> > >>> Cheers, > >>> Omair > >>> > >> > > I notice that what was finally committed differs from this webrev > > (in a positive > > way). The version posted from the webrev failed to compile: > > > > 1. ERROR in > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > (at line 580) > > LCMS.colorConvert(this, srcIL, dstIL); > > ^^^^^ > > srcIL cannot be resolved to a variable > > ---------- > > 2. ERROR in > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > (at line 580) > > LCMS.colorConvert(this, srcIL, dstIL); > > ^^^^^ > > dstIL cannot be resolved to a variable > > ---------- > > 3. ERROR in > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > (at line 606) > > LCMS.colorConvert(this, srcIL, dstIL); > > ^^^^^ > > srcIL cannot be resolved to a variable > > ---------- > > 4. ERROR in > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > (at line 606) > > LCMS.colorConvert(this, srcIL, dstIL); > > ^^^^^ > > dstIL cannot be resolved to a variable > > > > but this seems to have been fixed in the committed version, > > presumably due to: > > > > - try { > > - LCMSImageLayout srcIL = new LCMSImageLayout( > > - src, src.length/getNumInComponents(), > > - LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > > | > > - LCMSImageLayout.BYTES_SH(1), > > getNumInComponents()); > > - > > - LCMSImageLayout dstIL = new LCMSImageLayout( > > - dst, dst.length/getNumOutComponents(), > > - LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > > | > > - LCMSImageLayout.BYTES_SH(1), > > getNumOutComponents()); > > - } catch (ImageLayoutException e) { > > - throw new CMMException("Unable to convert data"); > > - } > > + LCMSImageLayout srcIL = new LCMSImageLayout( > > + src, src.length/getNumInComponents(), > > + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > > + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); > > + > > + LCMSImageLayout dstIL = new LCMSImageLayout( > > + dst, dst.length/getNumOutComponents(), > > + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | > > + LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); > > > > so srcIL and dstIL are now declared at a wider scope. I'll use the > > committed versions > > in IcedTea6 HEAD. > > > > Cheers, > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 7 04:39:16 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Mar 2013 07:39:16 -0500 (EST) Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <1179210539.14431300.1362659427439.JavaMail.root@redhat.com> Message-ID: <663199846.14437234.1362659956753.JavaMail.root@redhat.com> ----- Original Message ----- > ----- Original Message ----- > > I'm only the proxy here but I created the webrev from the > > changesets > > that I pushed. I don't see any difference. > > > > t4 $diff LCMSTransform.java.webrev > > jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > t4 $ > > > > Indeed. I'm still seeing the same failure using the changesets > pushed > to OpenJDK6, yet the repository itself builds. Very odd. > The copy of OpenJDK6 I was looking at wasn't up-to-date, hence the diff. The patched version and upstream repo are identical when compared correctly. What's baffling is how this code compiles with the javac compiler as it looks clearly wrong to me, which is why ecj falls over on it. try { LCMSImageLayout srcIL = new LCMSImageLayout( src, src.length/getNumInComponents(), LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | LCMSImageLayout.BYTES_SH(2), getNumInComponents()*2); LCMSImageLayout dstIL = new LCMSImageLayout( dst, dst.length/getNumOutComponents(), LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | LCMSImageLayout.BYTES_SH(2), getNumOutComponents()*2); } catch (ImageLayoutException e) { throw new CMMException("Unable to convert data"); } synchronized(this) { LCMS.colorConvert(this, srcIL, dstIL); } srcIL and dstIL are declared inside the try block so aren't visible outside it. In the other colorConvert methods, these are declared at the top of the method. > > regards, > > Sean. > > > > On 07/03/2013 10:59, Andrew Hughes wrote: > > > ----- Original Message ----- > > >> February CPU pushes completed as reviewed in last round of > > >> webrevs. > > >> > > >> I'd like to push 2 extra fixes now for issues addressed in > > >> yesterday's > > >> JDK releases. > > >> > > >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ > > >> > > >> Good to push ? > > >> > > >> regards, > > >> Sean. > > >> > > >> On 05/03/2013 18:44, Omair Majid wrote: > > >>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: > > >>>> Hi, > > >>>> > > >>>> The change in JAXP can be viewed here: > > >>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While > > >>>> it's > > >>>> generated against JDK 8, the change in 6 is identical. > > >>> The JAXP changes look identical to what was pushed to jdk7u. > > >>> Looks > > >>> all > > >>> good to me! > > >>> > > >>>> I plan to push the changes today. > > >>> Thank you. It will be great to have all the security fixes in! > > >>> > > >>> Cheers, > > >>> Omair > > >>> > > >> > > > I notice that what was finally committed differs from this webrev > > > (in a positive > > > way). The version posted from the webrev failed to compile: > > > > > > 1. ERROR in > > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > > (at line 580) > > > LCMS.colorConvert(this, srcIL, dstIL); > > > ^^^^^ > > > srcIL cannot be resolved to a variable > > > ---------- > > > 2. ERROR in > > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > > (at line 580) > > > LCMS.colorConvert(this, srcIL, dstIL); > > > ^^^^^ > > > dstIL cannot be resolved to a variable > > > ---------- > > > 3. ERROR in > > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > > (at line 606) > > > LCMS.colorConvert(this, srcIL, dstIL); > > > ^^^^^ > > > srcIL cannot be resolved to a variable > > > ---------- > > > 4. ERROR in > > > ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > > > (at line 606) > > > LCMS.colorConvert(this, srcIL, dstIL); > > > ^^^^^ > > > dstIL cannot be resolved to a variable > > > > > > but this seems to have been fixed in the committed version, > > > presumably due to: > > > > > > - try { > > > - LCMSImageLayout srcIL = new LCMSImageLayout( > > > - src, src.length/getNumInComponents(), > > > - > > > LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > > > | > > > - LCMSImageLayout.BYTES_SH(1), > > > getNumInComponents()); > > > - > > > - LCMSImageLayout dstIL = new LCMSImageLayout( > > > - dst, dst.length/getNumOutComponents(), > > > - > > > LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > > > | > > > - LCMSImageLayout.BYTES_SH(1), > > > getNumOutComponents()); > > > - } catch (ImageLayoutException e) { > > > - throw new CMMException("Unable to convert data"); > > > - } > > > + LCMSImageLayout srcIL = new LCMSImageLayout( > > > + src, src.length/getNumInComponents(), > > > + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > > > + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); > > > + > > > + LCMSImageLayout dstIL = new LCMSImageLayout( > > > + dst, dst.length/getNumOutComponents(), > > > + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | > > > + LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); > > > > > > so srcIL and dstIL are now declared at a wider scope. I'll use > > > the > > > committed versions > > > in IcedTea6 HEAD. > > > > > > Cheers, > > > > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sean.coffey at oracle.com Thu Mar 7 05:20:36 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 07 Mar 2013 13:20:36 +0000 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <663199846.14437234.1362659956753.JavaMail.root@redhat.com> References: <663199846.14437234.1362659956753.JavaMail.root@redhat.com> Message-ID: <51389424.9040906@oracle.com> Yes - you're right. That does look like an issue. Andrew Brygin ran pre integration tests before pushing the changes internally and they were successful. However - I've traced back over the sources and what was run in his test build and what he pushed to internal repo differs. ( in 2 areas) - No doubt, it's the curse of the last minute change. Andrew Brygin, can you log a bug and get this corrected asap ? Thanks for the notice Andrew! Thanks, Sean. > public short[] colorConvert(short[] src, short[] dst) { > > if (dst == null) { > dst = new short > [(src.length/getNumInComponents())*getNumOutComponents()]; > } > > try { > LCMSImageLayout srcIL = new LCMSImageLayout( > src, src.length/getNumInComponents(), > LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > LCMSImageLayout.BYTES_SH(2), getNumInComponents()*2); > > LCMSImageLayout dstIL = new LCMSImageLayout( > dst, dst.length/getNumOutComponents(), > LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | > LCMSImageLayout.BYTES_SH(2), getNumOutComponents()*2); > > synchronized(this) { > LCMS.colorConvert(this, srcIL, dstIL); > } > } catch (ImageLayoutException e) { > throw new CMMException("Unable to convert data"); > } > > return dst; > } On 07/03/2013 12:39, Andrew Hughes wrote: > ----- Original Message ----- >> ----- Original Message ----- >>> I'm only the proxy here but I created the webrev from the >>> changesets >>> that I pushed. I don't see any difference. >>> >>> t4 $diff LCMSTransform.java.webrev >>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>> t4 $ >>> >> Indeed. I'm still seeing the same failure using the changesets >> pushed >> to OpenJDK6, yet the repository itself builds. Very odd. >> > The copy of OpenJDK6 I was looking at wasn't up-to-date, hence the diff. > The patched version and upstream repo are identical when compared correctly. > > What's baffling is how this code compiles with the javac compiler as it looks > clearly wrong to me, which is why ecj falls over on it. > > try { > LCMSImageLayout srcIL = new LCMSImageLayout( > src, src.length/getNumInComponents(), > LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > LCMSImageLayout.BYTES_SH(2), getNumInComponents()*2); > > LCMSImageLayout dstIL = new LCMSImageLayout( > dst, dst.length/getNumOutComponents(), > LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | > LCMSImageLayout.BYTES_SH(2), getNumOutComponents()*2); > } catch (ImageLayoutException e) { > throw new CMMException("Unable to convert data"); > } > > synchronized(this) { > LCMS.colorConvert(this, srcIL, dstIL); > } > > srcIL and dstIL are declared inside the try block so aren't visible outside it. > > In the other colorConvert methods, these are declared at the top of the method. > >>> regards, >>> Sean. >>> >>> On 07/03/2013 10:59, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> February CPU pushes completed as reviewed in last round of >>>>> webrevs. >>>>> >>>>> I'd like to push 2 extra fixes now for issues addressed in >>>>> yesterday's >>>>> JDK releases. >>>>> >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ >>>>> >>>>> Good to push ? >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 05/03/2013 18:44, Omair Majid wrote: >>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The change in JAXP can be viewed here: >>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While >>>>>>> it's >>>>>>> generated against JDK 8, the change in 6 is identical. >>>>>> The JAXP changes look identical to what was pushed to jdk7u. >>>>>> Looks >>>>>> all >>>>>> good to me! >>>>>> >>>>>>> I plan to push the changes today. >>>>>> Thank you. It will be great to have all the security fixes in! >>>>>> >>>>>> Cheers, >>>>>> Omair >>>>>> >>>> I notice that what was finally committed differs from this webrev >>>> (in a positive >>>> way). The version posted from the webrev failed to compile: >>>> >>>> 1. ERROR in >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>> (at line 580) >>>> LCMS.colorConvert(this, srcIL, dstIL); >>>> ^^^^^ >>>> srcIL cannot be resolved to a variable >>>> ---------- >>>> 2. ERROR in >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>> (at line 580) >>>> LCMS.colorConvert(this, srcIL, dstIL); >>>> ^^^^^ >>>> dstIL cannot be resolved to a variable >>>> ---------- >>>> 3. ERROR in >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>> (at line 606) >>>> LCMS.colorConvert(this, srcIL, dstIL); >>>> ^^^^^ >>>> srcIL cannot be resolved to a variable >>>> ---------- >>>> 4. ERROR in >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>> (at line 606) >>>> LCMS.colorConvert(this, srcIL, dstIL); >>>> ^^^^^ >>>> dstIL cannot be resolved to a variable >>>> >>>> but this seems to have been fixed in the committed version, >>>> presumably due to: >>>> >>>> - try { >>>> - LCMSImageLayout srcIL = new LCMSImageLayout( >>>> - src, src.length/getNumInComponents(), >>>> - >>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>>> | >>>> - LCMSImageLayout.BYTES_SH(1), >>>> getNumInComponents()); >>>> - >>>> - LCMSImageLayout dstIL = new LCMSImageLayout( >>>> - dst, dst.length/getNumOutComponents(), >>>> - >>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>> | >>>> - LCMSImageLayout.BYTES_SH(1), >>>> getNumOutComponents()); >>>> - } catch (ImageLayoutException e) { >>>> - throw new CMMException("Unable to convert data"); >>>> - } >>>> + LCMSImageLayout srcIL = new LCMSImageLayout( >>>> + src, src.length/getNumInComponents(), >>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>>> + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); >>>> + >>>> + LCMSImageLayout dstIL = new LCMSImageLayout( >>>> + dst, dst.length/getNumOutComponents(), >>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | >>>> + LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); >>>> >>>> so srcIL and dstIL are now declared at a wider scope. I'll use >>>> the >>>> committed versions >>>> in IcedTea6 HEAD. >>>> >>>> Cheers, >>> >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: 248BDC07 (https://keys.indymedia.org/) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> >> From gnu.andrew at redhat.com Thu Mar 7 05:51:21 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Mar 2013 08:51:21 -0500 (EST) Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <51389424.9040906@oracle.com> Message-ID: <1929636762.14494474.1362664281656.JavaMail.root@redhat.com> ----- Original Message ----- > Yes - you're right. That does look like an issue. Andrew Brygin ran > pre > integration tests before pushing the changes internally and they were > successful. However - I've traced back over the sources and what was > run > in his test build and what he pushed to internal repo differs. ( in 2 > areas) - No doubt, it's the curse of the last minute change. > > Andrew Brygin, can you log a bug and get this corrected asap ? > > Thanks for the notice Andrew! > I have a patch I can post if that would help. With that, this builds. I just need to clean up my workspace and post a webrev. > Thanks, > Sean. > > > > public short[] colorConvert(short[] src, short[] dst) { > > > > if (dst == null) { > > dst = new short > > [(src.length/getNumInComponents())*getNumOutComponents()]; > > } > > > > try { > > LCMSImageLayout srcIL = new LCMSImageLayout( > > src, src.length/getNumInComponents(), > > LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > > LCMSImageLayout.BYTES_SH(2), > > getNumInComponents()*2); > > > > LCMSImageLayout dstIL = new LCMSImageLayout( > > dst, dst.length/getNumOutComponents(), > > LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > > | > > LCMSImageLayout.BYTES_SH(2), > > getNumOutComponents()*2); > > > > synchronized(this) { > > LCMS.colorConvert(this, srcIL, dstIL); > > } > > } catch (ImageLayoutException e) { > > throw new CMMException("Unable to convert data"); > > } > > > > return dst; > > } > > On 07/03/2013 12:39, Andrew Hughes wrote: > > ----- Original Message ----- > >> ----- Original Message ----- > >>> I'm only the proxy here but I created the webrev from the > >>> changesets > >>> that I pushed. I don't see any difference. > >>> > >>> t4 $diff LCMSTransform.java.webrev > >>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>> t4 $ > >>> > >> Indeed. I'm still seeing the same failure using the changesets > >> pushed > >> to OpenJDK6, yet the repository itself builds. Very odd. > >> > > The copy of OpenJDK6 I was looking at wasn't up-to-date, hence the > > diff. > > The patched version and upstream repo are identical when compared > > correctly. > > > > What's baffling is how this code compiles with the javac compiler > > as it looks > > clearly wrong to me, which is why ecj falls over on it. > > > > try { > > LCMSImageLayout srcIL = new LCMSImageLayout( > > src, src.length/getNumInComponents(), > > LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > > | > > LCMSImageLayout.BYTES_SH(2), > > getNumInComponents()*2); > > > > LCMSImageLayout dstIL = new LCMSImageLayout( > > dst, dst.length/getNumOutComponents(), > > LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > > | > > LCMSImageLayout.BYTES_SH(2), > > getNumOutComponents()*2); > > } catch (ImageLayoutException e) { > > throw new CMMException("Unable to convert data"); > > } > > > > synchronized(this) { > > LCMS.colorConvert(this, srcIL, dstIL); > > } > > > > srcIL and dstIL are declared inside the try block so aren't visible > > outside it. > > > > In the other colorConvert methods, these are declared at the top of > > the method. > > > >>> regards, > >>> Sean. > >>> > >>> On 07/03/2013 10:59, Andrew Hughes wrote: > >>>> ----- Original Message ----- > >>>>> February CPU pushes completed as reviewed in last round of > >>>>> webrevs. > >>>>> > >>>>> I'd like to push 2 extra fixes now for issues addressed in > >>>>> yesterday's > >>>>> JDK releases. > >>>>> > >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ > >>>>> > >>>>> Good to push ? > >>>>> > >>>>> regards, > >>>>> Sean. > >>>>> > >>>>> On 05/03/2013 18:44, Omair Majid wrote: > >>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> The change in JAXP can be viewed here: > >>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While > >>>>>>> it's > >>>>>>> generated against JDK 8, the change in 6 is identical. > >>>>>> The JAXP changes look identical to what was pushed to jdk7u. > >>>>>> Looks > >>>>>> all > >>>>>> good to me! > >>>>>> > >>>>>>> I plan to push the changes today. > >>>>>> Thank you. It will be great to have all the security fixes in! > >>>>>> > >>>>>> Cheers, > >>>>>> Omair > >>>>>> > >>>> I notice that what was finally committed differs from this > >>>> webrev > >>>> (in a positive > >>>> way). The version posted from the webrev failed to compile: > >>>> > >>>> 1. ERROR in > >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>> (at line 580) > >>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>> ^^^^^ > >>>> srcIL cannot be resolved to a variable > >>>> ---------- > >>>> 2. ERROR in > >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>> (at line 580) > >>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>> ^^^^^ > >>>> dstIL cannot be resolved to a variable > >>>> ---------- > >>>> 3. ERROR in > >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>> (at line 606) > >>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>> ^^^^^ > >>>> srcIL cannot be resolved to a variable > >>>> ---------- > >>>> 4. ERROR in > >>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>> (at line 606) > >>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>> ^^^^^ > >>>> dstIL cannot be resolved to a variable > >>>> > >>>> but this seems to have been fixed in the committed version, > >>>> presumably due to: > >>>> > >>>> - try { > >>>> - LCMSImageLayout srcIL = new LCMSImageLayout( > >>>> - src, src.length/getNumInComponents(), > >>>> - > >>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > >>>> | > >>>> - LCMSImageLayout.BYTES_SH(1), > >>>> getNumInComponents()); > >>>> - > >>>> - LCMSImageLayout dstIL = new LCMSImageLayout( > >>>> - dst, dst.length/getNumOutComponents(), > >>>> - > >>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>> | > >>>> - LCMSImageLayout.BYTES_SH(1), > >>>> getNumOutComponents()); > >>>> - } catch (ImageLayoutException e) { > >>>> - throw new CMMException("Unable to convert data"); > >>>> - } > >>>> + LCMSImageLayout srcIL = new LCMSImageLayout( > >>>> + src, src.length/getNumInComponents(), > >>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > >>>> + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); > >>>> + > >>>> + LCMSImageLayout dstIL = new LCMSImageLayout( > >>>> + dst, dst.length/getNumOutComponents(), > >>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>> | > >>>> + LCMSImageLayout.BYTES_SH(1), > >>>> getNumOutComponents()); > >>>> > >>>> so srcIL and dstIL are now declared at a wider scope. I'll use > >>>> the > >>>> committed versions > >>>> in IcedTea6 HEAD. > >>>> > >>>> Cheers, > >>> > >> -- > >> Andrew :) > >> > >> Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > >> > >> > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sean.coffey at oracle.com Thu Mar 7 05:55:48 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 07 Mar 2013 13:55:48 +0000 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <1929636762.14494474.1362664281656.JavaMail.root@redhat.com> References: <1929636762.14494474.1362664281656.JavaMail.root@redhat.com> Message-ID: <51389C64.7010409@oracle.com> Even better if you want to push the change ? I haven't heard from Andrew B. yet. I've logged 8009641 to track this. You could use that ID if you want. 8009641: OpenJDK 6 build broken via 8007675 fix regards, Sean. On 07/03/2013 13:51, Andrew Hughes wrote: > > ----- Original Message ----- >> Yes - you're right. That does look like an issue. Andrew Brygin ran >> pre >> integration tests before pushing the changes internally and they were >> successful. However - I've traced back over the sources and what was >> run >> in his test build and what he pushed to internal repo differs. ( in 2 >> areas) - No doubt, it's the curse of the last minute change. >> >> Andrew Brygin, can you log a bug and get this corrected asap ? >> >> Thanks for the notice Andrew! >> > I have a patch I can post if that would help. With that, this builds. > I just need to clean up my workspace and post a webrev. > >> Thanks, >> Sean. >> >> >>> public short[] colorConvert(short[] src, short[] dst) { >>> >>> if (dst == null) { >>> dst = new short >>> [(src.length/getNumInComponents())*getNumOutComponents()]; >>> } >>> >>> try { >>> LCMSImageLayout srcIL = new LCMSImageLayout( >>> src, src.length/getNumInComponents(), >>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>> LCMSImageLayout.BYTES_SH(2), >>> getNumInComponents()*2); >>> >>> LCMSImageLayout dstIL = new LCMSImageLayout( >>> dst, dst.length/getNumOutComponents(), >>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>> | >>> LCMSImageLayout.BYTES_SH(2), >>> getNumOutComponents()*2); >>> >>> synchronized(this) { >>> LCMS.colorConvert(this, srcIL, dstIL); >>> } >>> } catch (ImageLayoutException e) { >>> throw new CMMException("Unable to convert data"); >>> } >>> >>> return dst; >>> } >> On 07/03/2013 12:39, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> ----- Original Message ----- >>>>> I'm only the proxy here but I created the webrev from the >>>>> changesets >>>>> that I pushed. I don't see any difference. >>>>> >>>>> t4 $diff LCMSTransform.java.webrev >>>>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>> t4 $ >>>>> >>>> Indeed. I'm still seeing the same failure using the changesets >>>> pushed >>>> to OpenJDK6, yet the repository itself builds. Very odd. >>>> >>> The copy of OpenJDK6 I was looking at wasn't up-to-date, hence the >>> diff. >>> The patched version and upstream repo are identical when compared >>> correctly. >>> >>> What's baffling is how this code compiles with the javac compiler >>> as it looks >>> clearly wrong to me, which is why ecj falls over on it. >>> >>> try { >>> LCMSImageLayout srcIL = new LCMSImageLayout( >>> src, src.length/getNumInComponents(), >>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>> | >>> LCMSImageLayout.BYTES_SH(2), >>> getNumInComponents()*2); >>> >>> LCMSImageLayout dstIL = new LCMSImageLayout( >>> dst, dst.length/getNumOutComponents(), >>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>> | >>> LCMSImageLayout.BYTES_SH(2), >>> getNumOutComponents()*2); >>> } catch (ImageLayoutException e) { >>> throw new CMMException("Unable to convert data"); >>> } >>> >>> synchronized(this) { >>> LCMS.colorConvert(this, srcIL, dstIL); >>> } >>> >>> srcIL and dstIL are declared inside the try block so aren't visible >>> outside it. >>> >>> In the other colorConvert methods, these are declared at the top of >>> the method. >>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 07/03/2013 10:59, Andrew Hughes wrote: >>>>>> ----- Original Message ----- >>>>>>> February CPU pushes completed as reviewed in last round of >>>>>>> webrevs. >>>>>>> >>>>>>> I'd like to push 2 extra fixes now for issues addressed in >>>>>>> yesterday's >>>>>>> JDK releases. >>>>>>> >>>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ >>>>>>> >>>>>>> Good to push ? >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>> On 05/03/2013 18:44, Omair Majid wrote: >>>>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The change in JAXP can be viewed here: >>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While >>>>>>>>> it's >>>>>>>>> generated against JDK 8, the change in 6 is identical. >>>>>>>> The JAXP changes look identical to what was pushed to jdk7u. >>>>>>>> Looks >>>>>>>> all >>>>>>>> good to me! >>>>>>>> >>>>>>>>> I plan to push the changes today. >>>>>>>> Thank you. It will be great to have all the security fixes in! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Omair >>>>>>>> >>>>>> I notice that what was finally committed differs from this >>>>>> webrev >>>>>> (in a positive >>>>>> way). The version posted from the webrev failed to compile: >>>>>> >>>>>> 1. ERROR in >>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>> (at line 580) >>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>> ^^^^^ >>>>>> srcIL cannot be resolved to a variable >>>>>> ---------- >>>>>> 2. ERROR in >>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>> (at line 580) >>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>> ^^^^^ >>>>>> dstIL cannot be resolved to a variable >>>>>> ---------- >>>>>> 3. ERROR in >>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>> (at line 606) >>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>> ^^^^^ >>>>>> srcIL cannot be resolved to a variable >>>>>> ---------- >>>>>> 4. ERROR in >>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>> (at line 606) >>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>> ^^^^^ >>>>>> dstIL cannot be resolved to a variable >>>>>> >>>>>> but this seems to have been fixed in the committed version, >>>>>> presumably due to: >>>>>> >>>>>> - try { >>>>>> - LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>> - src, src.length/getNumInComponents(), >>>>>> - >>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>>>>> | >>>>>> - LCMSImageLayout.BYTES_SH(1), >>>>>> getNumInComponents()); >>>>>> - >>>>>> - LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>> - dst, dst.length/getNumOutComponents(), >>>>>> - >>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>> | >>>>>> - LCMSImageLayout.BYTES_SH(1), >>>>>> getNumOutComponents()); >>>>>> - } catch (ImageLayoutException e) { >>>>>> - throw new CMMException("Unable to convert data"); >>>>>> - } >>>>>> + LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>> + src, src.length/getNumInComponents(), >>>>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>>>>> + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); >>>>>> + >>>>>> + LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>> + dst, dst.length/getNumOutComponents(), >>>>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>> | >>>>>> + LCMSImageLayout.BYTES_SH(1), >>>>>> getNumOutComponents()); >>>>>> >>>>>> so srcIL and dstIL are now declared at a wider scope. I'll use >>>>>> the >>>>>> committed versions >>>>>> in IcedTea6 HEAD. >>>>>> >>>>>> Cheers, >>>> -- >>>> Andrew :) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>> >>>> >> From gnu.andrew at redhat.com Thu Mar 7 07:12:34 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Mar 2013 10:12:34 -0500 (EST) Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <5138A65F.1050502@oracle.com> Message-ID: <1776346126.14557839.1362669154732.JavaMail.root@redhat.com> ----- Original Message ----- > Hello, > > please review a fix for the build failure: > > http://cr.openjdk.java.net/~bae/8009641/webrev.00/ > Looks good to me and better than what I had as the synchronized blocks were still outside the try (so the variables could end up being null). Ok to commit. > Thanks, > Andrew > > On 3/7/2013 5:55 PM, Se?n Coffey wrote: > > Even better if you want to push the change ? I haven't heard from > > Andrew B. yet. > > > > I've logged 8009641 to track this. You could use that ID if you > > want. > > > > 8009641: OpenJDK 6 build broken via 8007675 fix > > > > regards, > > Sean. > > > > On 07/03/2013 13:51, Andrew Hughes wrote: > >> > >> ----- Original Message ----- > >>> Yes - you're right. That does look like an issue. Andrew Brygin > >>> ran > >>> pre > >>> integration tests before pushing the changes internally and they > >>> were > >>> successful. However - I've traced back over the sources and what > >>> was > >>> run > >>> in his test build and what he pushed to internal repo differs. ( > >>> in 2 > >>> areas) - No doubt, it's the curse of the last minute change. > >>> > >>> Andrew Brygin, can you log a bug and get this corrected asap ? > >>> > >>> Thanks for the notice Andrew! > >>> > >> I have a patch I can post if that would help. With that, this > >> builds. > >> I just need to clean up my workspace and post a webrev. > >> > >>> Thanks, > >>> Sean. > >>> > >>> > >>>> public short[] colorConvert(short[] src, short[] dst) { > >>>> > >>>> if (dst == null) { > >>>> dst = new short > >>>> [(src.length/getNumInComponents())*getNumOutComponents()]; > >>>> } > >>>> > >>>> try { > >>>> LCMSImageLayout srcIL = new LCMSImageLayout( > >>>> src, src.length/getNumInComponents(), > >>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > >>>> LCMSImageLayout.BYTES_SH(2), > >>>> getNumInComponents()*2); > >>>> > >>>> LCMSImageLayout dstIL = new LCMSImageLayout( > >>>> dst, dst.length/getNumOutComponents(), > >>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>> | > >>>> LCMSImageLayout.BYTES_SH(2), > >>>> getNumOutComponents()*2); > >>>> > >>>> synchronized(this) { > >>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>> } > >>>> } catch (ImageLayoutException e) { > >>>> throw new CMMException("Unable to convert data"); > >>>> } > >>>> > >>>> return dst; > >>>> } > >>> On 07/03/2013 12:39, Andrew Hughes wrote: > >>>> ----- Original Message ----- > >>>>> ----- Original Message ----- > >>>>>> I'm only the proxy here but I created the webrev from the > >>>>>> changesets > >>>>>> that I pushed. I don't see any difference. > >>>>>> > >>>>>> t4 $diff LCMSTransform.java.webrev > >>>>>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>> t4 $ > >>>>>> > >>>>> Indeed. I'm still seeing the same failure using the changesets > >>>>> pushed > >>>>> to OpenJDK6, yet the repository itself builds. Very odd. > >>>>> > >>>> The copy of OpenJDK6 I was looking at wasn't up-to-date, hence > >>>> the > >>>> diff. > >>>> The patched version and upstream repo are identical when > >>>> compared > >>>> correctly. > >>>> > >>>> What's baffling is how this code compiles with the javac > >>>> compiler > >>>> as it looks > >>>> clearly wrong to me, which is why ecj falls over on it. > >>>> > >>>> try { > >>>> LCMSImageLayout srcIL = new LCMSImageLayout( > >>>> src, src.length/getNumInComponents(), > >>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > >>>> | > >>>> LCMSImageLayout.BYTES_SH(2), > >>>> getNumInComponents()*2); > >>>> > >>>> LCMSImageLayout dstIL = new LCMSImageLayout( > >>>> dst, dst.length/getNumOutComponents(), > >>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>> | > >>>> LCMSImageLayout.BYTES_SH(2), > >>>> getNumOutComponents()*2); > >>>> } catch (ImageLayoutException e) { > >>>> throw new CMMException("Unable to convert data"); > >>>> } > >>>> > >>>> synchronized(this) { > >>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>> } > >>>> > >>>> srcIL and dstIL are declared inside the try block so aren't > >>>> visible > >>>> outside it. > >>>> > >>>> In the other colorConvert methods, these are declared at the top > >>>> of > >>>> the method. > >>>> > >>>>>> regards, > >>>>>> Sean. > >>>>>> > >>>>>> On 07/03/2013 10:59, Andrew Hughes wrote: > >>>>>>> ----- Original Message ----- > >>>>>>>> February CPU pushes completed as reviewed in last round of > >>>>>>>> webrevs. > >>>>>>>> > >>>>>>>> I'd like to push 2 extra fixes now for issues addressed in > >>>>>>>> yesterday's > >>>>>>>> JDK releases. > >>>>>>>> > >>>>>>>> webrev : > >>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ > >>>>>>>> > >>>>>>>> Good to push ? > >>>>>>>> > >>>>>>>> regards, > >>>>>>>> Sean. > >>>>>>>> > >>>>>>>> On 05/03/2013 18:44, Omair Majid wrote: > >>>>>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> The change in JAXP can be viewed here: > >>>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ > >>>>>>>>>> While > >>>>>>>>>> it's > >>>>>>>>>> generated against JDK 8, the change in 6 is identical. > >>>>>>>>> The JAXP changes look identical to what was pushed to > >>>>>>>>> jdk7u. > >>>>>>>>> Looks > >>>>>>>>> all > >>>>>>>>> good to me! > >>>>>>>>> > >>>>>>>>>> I plan to push the changes today. > >>>>>>>>> Thank you. It will be great to have all the security fixes > >>>>>>>>> in! > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Omair > >>>>>>>>> > >>>>>>> I notice that what was finally committed differs from this > >>>>>>> webrev > >>>>>>> (in a positive > >>>>>>> way). The version posted from the webrev failed to compile: > >>>>>>> > >>>>>>> 1. ERROR in > >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>> (at line 580) > >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>> ^^^^^ > >>>>>>> srcIL cannot be resolved to a variable > >>>>>>> ---------- > >>>>>>> 2. ERROR in > >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>> (at line 580) > >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>> ^^^^^ > >>>>>>> dstIL cannot be resolved to a variable > >>>>>>> ---------- > >>>>>>> 3. ERROR in > >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>> (at line 606) > >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>> ^^^^^ > >>>>>>> srcIL cannot be resolved to a variable > >>>>>>> ---------- > >>>>>>> 4. ERROR in > >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>> (at line 606) > >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>> ^^^^^ > >>>>>>> dstIL cannot be resolved to a variable > >>>>>>> > >>>>>>> but this seems to have been fixed in the committed version, > >>>>>>> presumably due to: > >>>>>>> > >>>>>>> - try { > >>>>>>> - LCMSImageLayout srcIL = new LCMSImageLayout( > >>>>>>> - src, src.length/getNumInComponents(), > >>>>>>> - > >>>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > >>>>>>> | > >>>>>>> - LCMSImageLayout.BYTES_SH(1), > >>>>>>> getNumInComponents()); > >>>>>>> - > >>>>>>> - LCMSImageLayout dstIL = new LCMSImageLayout( > >>>>>>> - dst, dst.length/getNumOutComponents(), > >>>>>>> - > >>>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>>>>> | > >>>>>>> - LCMSImageLayout.BYTES_SH(1), > >>>>>>> getNumOutComponents()); > >>>>>>> - } catch (ImageLayoutException e) { > >>>>>>> - throw new CMMException("Unable to convert > >>>>>>> data"); > >>>>>>> - } > >>>>>>> + LCMSImageLayout srcIL = new LCMSImageLayout( > >>>>>>> + src, src.length/getNumInComponents(), > >>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > >>>>>>> + LCMSImageLayout.BYTES_SH(1), > >>>>>>> getNumInComponents()); > >>>>>>> + > >>>>>>> + LCMSImageLayout dstIL = new LCMSImageLayout( > >>>>>>> + dst, dst.length/getNumOutComponents(), > >>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>>>>> | > >>>>>>> + LCMSImageLayout.BYTES_SH(1), > >>>>>>> getNumOutComponents()); > >>>>>>> > >>>>>>> so srcIL and dstIL are now declared at a wider scope. I'll > >>>>>>> use > >>>>>>> the > >>>>>>> committed versions > >>>>>>> in IcedTea6 HEAD. > >>>>>>> > >>>>>>> Cheers, > >>>>> -- > >>>>> Andrew :) > >>>>> > >>>>> Free Java Software Engineer > >>>>> Red Hat, Inc. (http://www.redhat.com) > >>>>> > >>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B > >>>>> DC07 > >>>>> > >>>>> > >>> > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 7 07:19:00 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Mar 2013 10:19:00 -0500 (EST) Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <5138AEF0.50602@oracle.com> Message-ID: <1498957034.14562163.1362669540723.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Andrew, > > thanks for the review. I am pushing the change. > > Sorry for the mess. > It's ok. I'm still baffled that javac misses it. I was able to build with OpenJDK6, just not with IcedTea's bootstrapping setup, which uses ecj. Thanks for the quick fix. > Thanks, > Andrew > > On 3/7/2013 7:12 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hello, > >> > >> please review a fix for the build failure: > >> > >> http://cr.openjdk.java.net/~bae/8009641/webrev.00/ > >> > > Looks good to me and better than what I had as the synchronized > > blocks were still outside the try > > (so the variables could end up being null). > > > > Ok to commit. > > > >> Thanks, > >> Andrew > >> > >> On 3/7/2013 5:55 PM, Se?n Coffey wrote: > >>> Even better if you want to push the change ? I haven't heard from > >>> Andrew B. yet. > >>> > >>> I've logged 8009641 to track this. You could use that ID if you > >>> want. > >>> > >>> 8009641: OpenJDK 6 build broken via 8007675 fix > >>> > >>> regards, > >>> Sean. > >>> > >>> On 07/03/2013 13:51, Andrew Hughes wrote: > >>>> ----- Original Message ----- > >>>>> Yes - you're right. That does look like an issue. Andrew > >>>>> Brygin > >>>>> ran > >>>>> pre > >>>>> integration tests before pushing the changes internally and > >>>>> they > >>>>> were > >>>>> successful. However - I've traced back over the sources and > >>>>> what > >>>>> was > >>>>> run > >>>>> in his test build and what he pushed to internal repo differs. > >>>>> ( > >>>>> in 2 > >>>>> areas) - No doubt, it's the curse of the last minute change. > >>>>> > >>>>> Andrew Brygin, can you log a bug and get this corrected asap ? > >>>>> > >>>>> Thanks for the notice Andrew! > >>>>> > >>>> I have a patch I can post if that would help. With that, this > >>>> builds. > >>>> I just need to clean up my workspace and post a webrev. > >>>> > >>>>> Thanks, > >>>>> Sean. > >>>>> > >>>>> > >>>>>> public short[] colorConvert(short[] src, short[] dst) { > >>>>>> > >>>>>> if (dst == null) { > >>>>>> dst = new short > >>>>>> [(src.length/getNumInComponents())*getNumOutComponents()]; > >>>>>> } > >>>>>> > >>>>>> try { > >>>>>> LCMSImageLayout srcIL = new LCMSImageLayout( > >>>>>> src, src.length/getNumInComponents(), > >>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > >>>>>> LCMSImageLayout.BYTES_SH(2), > >>>>>> getNumInComponents()*2); > >>>>>> > >>>>>> LCMSImageLayout dstIL = new LCMSImageLayout( > >>>>>> dst, dst.length/getNumOutComponents(), > >>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>>>> | > >>>>>> LCMSImageLayout.BYTES_SH(2), > >>>>>> getNumOutComponents()*2); > >>>>>> > >>>>>> synchronized(this) { > >>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>> } > >>>>>> } catch (ImageLayoutException e) { > >>>>>> throw new CMMException("Unable to convert > >>>>>> data"); > >>>>>> } > >>>>>> > >>>>>> return dst; > >>>>>> } > >>>>> On 07/03/2013 12:39, Andrew Hughes wrote: > >>>>>> ----- Original Message ----- > >>>>>>> ----- Original Message ----- > >>>>>>>> I'm only the proxy here but I created the webrev from the > >>>>>>>> changesets > >>>>>>>> that I pushed. I don't see any difference. > >>>>>>>> > >>>>>>>> t4 $diff LCMSTransform.java.webrev > >>>>>>>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>>> t4 $ > >>>>>>>> > >>>>>>> Indeed. I'm still seeing the same failure using the > >>>>>>> changesets > >>>>>>> pushed > >>>>>>> to OpenJDK6, yet the repository itself builds. Very odd. > >>>>>>> > >>>>>> The copy of OpenJDK6 I was looking at wasn't up-to-date, hence > >>>>>> the > >>>>>> diff. > >>>>>> The patched version and upstream repo are identical when > >>>>>> compared > >>>>>> correctly. > >>>>>> > >>>>>> What's baffling is how this code compiles with the javac > >>>>>> compiler > >>>>>> as it looks > >>>>>> clearly wrong to me, which is why ecj falls over on it. > >>>>>> > >>>>>> try { > >>>>>> LCMSImageLayout srcIL = new LCMSImageLayout( > >>>>>> src, src.length/getNumInComponents(), > >>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > >>>>>> | > >>>>>> LCMSImageLayout.BYTES_SH(2), > >>>>>> getNumInComponents()*2); > >>>>>> > >>>>>> LCMSImageLayout dstIL = new LCMSImageLayout( > >>>>>> dst, dst.length/getNumOutComponents(), > >>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>>>> | > >>>>>> LCMSImageLayout.BYTES_SH(2), > >>>>>> getNumOutComponents()*2); > >>>>>> } catch (ImageLayoutException e) { > >>>>>> throw new CMMException("Unable to convert > >>>>>> data"); > >>>>>> } > >>>>>> > >>>>>> synchronized(this) { > >>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>> } > >>>>>> > >>>>>> srcIL and dstIL are declared inside the try block so aren't > >>>>>> visible > >>>>>> outside it. > >>>>>> > >>>>>> In the other colorConvert methods, these are declared at the > >>>>>> top > >>>>>> of > >>>>>> the method. > >>>>>> > >>>>>>>> regards, > >>>>>>>> Sean. > >>>>>>>> > >>>>>>>> On 07/03/2013 10:59, Andrew Hughes wrote: > >>>>>>>>> ----- Original Message ----- > >>>>>>>>>> February CPU pushes completed as reviewed in last round of > >>>>>>>>>> webrevs. > >>>>>>>>>> > >>>>>>>>>> I'd like to push 2 extra fixes now for issues addressed in > >>>>>>>>>> yesterday's > >>>>>>>>>> JDK releases. > >>>>>>>>>> > >>>>>>>>>> webrev : > >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ > >>>>>>>>>> > >>>>>>>>>> Good to push ? > >>>>>>>>>> > >>>>>>>>>> regards, > >>>>>>>>>> Sean. > >>>>>>>>>> > >>>>>>>>>> On 05/03/2013 18:44, Omair Majid wrote: > >>>>>>>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: > >>>>>>>>>>>> Hi, > >>>>>>>>>>>> > >>>>>>>>>>>> The change in JAXP can be viewed here: > >>>>>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ > >>>>>>>>>>>> While > >>>>>>>>>>>> it's > >>>>>>>>>>>> generated against JDK 8, the change in 6 is identical. > >>>>>>>>>>> The JAXP changes look identical to what was pushed to > >>>>>>>>>>> jdk7u. > >>>>>>>>>>> Looks > >>>>>>>>>>> all > >>>>>>>>>>> good to me! > >>>>>>>>>>> > >>>>>>>>>>>> I plan to push the changes today. > >>>>>>>>>>> Thank you. It will be great to have all the security > >>>>>>>>>>> fixes > >>>>>>>>>>> in! > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> Omair > >>>>>>>>>>> > >>>>>>>>> I notice that what was finally committed differs from this > >>>>>>>>> webrev > >>>>>>>>> (in a positive > >>>>>>>>> way). The version posted from the webrev failed to > >>>>>>>>> compile: > >>>>>>>>> > >>>>>>>>> 1. ERROR in > >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>>>> (at line 580) > >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>>>> ^^^^^ > >>>>>>>>> srcIL cannot be resolved to a variable > >>>>>>>>> ---------- > >>>>>>>>> 2. ERROR in > >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>>>> (at line 580) > >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>>>> ^^^^^ > >>>>>>>>> dstIL cannot be resolved to a variable > >>>>>>>>> ---------- > >>>>>>>>> 3. ERROR in > >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>>>> (at line 606) > >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>>>> ^^^^^ > >>>>>>>>> srcIL cannot be resolved to a variable > >>>>>>>>> ---------- > >>>>>>>>> 4. ERROR in > >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java > >>>>>>>>> (at line 606) > >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); > >>>>>>>>> ^^^^^ > >>>>>>>>> dstIL cannot be resolved to a variable > >>>>>>>>> > >>>>>>>>> but this seems to have been fixed in the committed version, > >>>>>>>>> presumably due to: > >>>>>>>>> > >>>>>>>>> - try { > >>>>>>>>> - LCMSImageLayout srcIL = new LCMSImageLayout( > >>>>>>>>> - src, src.length/getNumInComponents(), > >>>>>>>>> - > >>>>>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) > >>>>>>>>> | > >>>>>>>>> - LCMSImageLayout.BYTES_SH(1), > >>>>>>>>> getNumInComponents()); > >>>>>>>>> - > >>>>>>>>> - LCMSImageLayout dstIL = new LCMSImageLayout( > >>>>>>>>> - dst, dst.length/getNumOutComponents(), > >>>>>>>>> - > >>>>>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>>>>>>> | > >>>>>>>>> - LCMSImageLayout.BYTES_SH(1), > >>>>>>>>> getNumOutComponents()); > >>>>>>>>> - } catch (ImageLayoutException e) { > >>>>>>>>> - throw new CMMException("Unable to convert > >>>>>>>>> data"); > >>>>>>>>> - } > >>>>>>>>> + LCMSImageLayout srcIL = new LCMSImageLayout( > >>>>>>>>> + src, src.length/getNumInComponents(), > >>>>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | > >>>>>>>>> + LCMSImageLayout.BYTES_SH(1), > >>>>>>>>> getNumInComponents()); > >>>>>>>>> + > >>>>>>>>> + LCMSImageLayout dstIL = new LCMSImageLayout( > >>>>>>>>> + dst, dst.length/getNumOutComponents(), > >>>>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) > >>>>>>>>> | > >>>>>>>>> + LCMSImageLayout.BYTES_SH(1), > >>>>>>>>> getNumOutComponents()); > >>>>>>>>> > >>>>>>>>> so srcIL and dstIL are now declared at a wider scope. I'll > >>>>>>>>> use > >>>>>>>>> the > >>>>>>>>> committed versions > >>>>>>>>> in IcedTea6 HEAD. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>> -- > >>>>>>> Andrew :) > >>>>>>> > >>>>>>> Free Java Software Engineer > >>>>>>> Red Hat, Inc. (http://www.redhat.com) > >>>>>>> > >>>>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >>>>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B > >>>>>>> DC07 > >>>>>>> > >>>>>>> > >> > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From andrew.brygin at oracle.com Thu Mar 7 06:04:51 2013 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Thu, 07 Mar 2013 18:04:51 +0400 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <51389424.9040906@oracle.com> References: <663199846.14437234.1362659956753.JavaMail.root@redhat.com> <51389424.9040906@oracle.com> Message-ID: <51389E83.2000607@oracle.com> Sorry, it was my mistake, I pushed changes without build failure correction. May I push a fix for this into the same repo? Thanks, Andrew On 3/7/2013 5:20 PM, Se?n Coffey wrote: > Yes - you're right. That does look like an issue. Andrew Brygin ran > pre integration tests before pushing the changes internally and they > were successful. However - I've traced back over the sources and what > was run in his test build and what he pushed to internal repo differs. > ( in 2 areas) - No doubt, it's the curse of the last minute change. > > Andrew Brygin, can you log a bug and get this corrected asap ? > > Thanks for the notice Andrew! > > Thanks, > Sean. > > >> public short[] colorConvert(short[] src, short[] dst) { >> >> if (dst == null) { >> dst = new short >> [(src.length/getNumInComponents())*getNumOutComponents()]; >> } >> >> try { >> LCMSImageLayout srcIL = new LCMSImageLayout( >> src, src.length/getNumInComponents(), >> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >> LCMSImageLayout.BYTES_SH(2), getNumInComponents()*2); >> >> LCMSImageLayout dstIL = new LCMSImageLayout( >> dst, dst.length/getNumOutComponents(), >> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | >> LCMSImageLayout.BYTES_SH(2), getNumOutComponents()*2); >> >> synchronized(this) { >> LCMS.colorConvert(this, srcIL, dstIL); >> } >> } catch (ImageLayoutException e) { >> throw new CMMException("Unable to convert data"); >> } >> >> return dst; >> } > > On 07/03/2013 12:39, Andrew Hughes wrote: >> ----- Original Message ----- >>> ----- Original Message ----- >>>> I'm only the proxy here but I created the webrev from the >>>> changesets >>>> that I pushed. I don't see any difference. >>>> >>>> t4 $diff LCMSTransform.java.webrev >>>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>> t4 $ >>>> >>> Indeed. I'm still seeing the same failure using the changesets >>> pushed >>> to OpenJDK6, yet the repository itself builds. Very odd. >>> >> The copy of OpenJDK6 I was looking at wasn't up-to-date, hence the diff. >> The patched version and upstream repo are identical when compared >> correctly. >> >> What's baffling is how this code compiles with the javac compiler as >> it looks >> clearly wrong to me, which is why ecj falls over on it. >> >> try { >> LCMSImageLayout srcIL = new LCMSImageLayout( >> src, src.length/getNumInComponents(), >> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >> LCMSImageLayout.BYTES_SH(2), getNumInComponents()*2); >> >> LCMSImageLayout dstIL = new LCMSImageLayout( >> dst, dst.length/getNumOutComponents(), >> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | >> LCMSImageLayout.BYTES_SH(2), getNumOutComponents()*2); >> } catch (ImageLayoutException e) { >> throw new CMMException("Unable to convert data"); >> } >> >> synchronized(this) { >> LCMS.colorConvert(this, srcIL, dstIL); >> } >> >> srcIL and dstIL are declared inside the try block so aren't visible >> outside it. >> >> In the other colorConvert methods, these are declared at the top of >> the method. >> >>>> regards, >>>> Sean. >>>> >>>> On 07/03/2013 10:59, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> February CPU pushes completed as reviewed in last round of >>>>>> webrevs. >>>>>> >>>>>> I'd like to push 2 extra fixes now for issues addressed in >>>>>> yesterday's >>>>>> JDK releases. >>>>>> >>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ >>>>>> >>>>>> Good to push ? >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 05/03/2013 18:44, Omair Majid wrote: >>>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The change in JAXP can be viewed here: >>>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While >>>>>>>> it's >>>>>>>> generated against JDK 8, the change in 6 is identical. >>>>>>> The JAXP changes look identical to what was pushed to jdk7u. >>>>>>> Looks >>>>>>> all >>>>>>> good to me! >>>>>>> >>>>>>>> I plan to push the changes today. >>>>>>> Thank you. It will be great to have all the security fixes in! >>>>>>> >>>>>>> Cheers, >>>>>>> Omair >>>>>>> >>>>> I notice that what was finally committed differs from this webrev >>>>> (in a positive >>>>> way). The version posted from the webrev failed to compile: >>>>> >>>>> 1. ERROR in >>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>> (at line 580) >>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>> ^^^^^ >>>>> srcIL cannot be resolved to a variable >>>>> ---------- >>>>> 2. ERROR in >>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>> (at line 580) >>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>> ^^^^^ >>>>> dstIL cannot be resolved to a variable >>>>> ---------- >>>>> 3. ERROR in >>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>> (at line 606) >>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>> ^^^^^ >>>>> srcIL cannot be resolved to a variable >>>>> ---------- >>>>> 4. ERROR in >>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>> (at line 606) >>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>> ^^^^^ >>>>> dstIL cannot be resolved to a variable >>>>> >>>>> but this seems to have been fixed in the committed version, >>>>> presumably due to: >>>>> >>>>> - try { >>>>> - LCMSImageLayout srcIL = new LCMSImageLayout( >>>>> - src, src.length/getNumInComponents(), >>>>> - >>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>>>> | >>>>> - LCMSImageLayout.BYTES_SH(1), >>>>> getNumInComponents()); >>>>> - >>>>> - LCMSImageLayout dstIL = new LCMSImageLayout( >>>>> - dst, dst.length/getNumOutComponents(), >>>>> - >>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>> | >>>>> - LCMSImageLayout.BYTES_SH(1), >>>>> getNumOutComponents()); >>>>> - } catch (ImageLayoutException e) { >>>>> - throw new CMMException("Unable to convert data"); >>>>> - } >>>>> + LCMSImageLayout srcIL = new LCMSImageLayout( >>>>> + src, src.length/getNumInComponents(), >>>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>>>> + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); >>>>> + >>>>> + LCMSImageLayout dstIL = new LCMSImageLayout( >>>>> + dst, dst.length/getNumOutComponents(), >>>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) | >>>>> + LCMSImageLayout.BYTES_SH(1), getNumOutComponents()); >>>>> >>>>> so srcIL and dstIL are now declared at a wider scope. I'll use >>>>> the >>>>> committed versions >>>>> in IcedTea6 HEAD. >>>>> >>>>> Cheers, >>>> >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> >>> > From andrew.brygin at oracle.com Thu Mar 7 06:38:23 2013 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Thu, 07 Mar 2013 18:38:23 +0400 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <51389C64.7010409@oracle.com> References: <1929636762.14494474.1362664281656.JavaMail.root@redhat.com> <51389C64.7010409@oracle.com> Message-ID: <5138A65F.1050502@oracle.com> Hello, please review a fix for the build failure: http://cr.openjdk.java.net/~bae/8009641/webrev.00/ Thanks, Andrew On 3/7/2013 5:55 PM, Se?n Coffey wrote: > Even better if you want to push the change ? I haven't heard from > Andrew B. yet. > > I've logged 8009641 to track this. You could use that ID if you want. > > 8009641: OpenJDK 6 build broken via 8007675 fix > > regards, > Sean. > > On 07/03/2013 13:51, Andrew Hughes wrote: >> >> ----- Original Message ----- >>> Yes - you're right. That does look like an issue. Andrew Brygin ran >>> pre >>> integration tests before pushing the changes internally and they were >>> successful. However - I've traced back over the sources and what was >>> run >>> in his test build and what he pushed to internal repo differs. ( in 2 >>> areas) - No doubt, it's the curse of the last minute change. >>> >>> Andrew Brygin, can you log a bug and get this corrected asap ? >>> >>> Thanks for the notice Andrew! >>> >> I have a patch I can post if that would help. With that, this builds. >> I just need to clean up my workspace and post a webrev. >> >>> Thanks, >>> Sean. >>> >>> >>>> public short[] colorConvert(short[] src, short[] dst) { >>>> >>>> if (dst == null) { >>>> dst = new short >>>> [(src.length/getNumInComponents())*getNumOutComponents()]; >>>> } >>>> >>>> try { >>>> LCMSImageLayout srcIL = new LCMSImageLayout( >>>> src, src.length/getNumInComponents(), >>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>>> LCMSImageLayout.BYTES_SH(2), >>>> getNumInComponents()*2); >>>> >>>> LCMSImageLayout dstIL = new LCMSImageLayout( >>>> dst, dst.length/getNumOutComponents(), >>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>> | >>>> LCMSImageLayout.BYTES_SH(2), >>>> getNumOutComponents()*2); >>>> >>>> synchronized(this) { >>>> LCMS.colorConvert(this, srcIL, dstIL); >>>> } >>>> } catch (ImageLayoutException e) { >>>> throw new CMMException("Unable to convert data"); >>>> } >>>> >>>> return dst; >>>> } >>> On 07/03/2013 12:39, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> ----- Original Message ----- >>>>>> I'm only the proxy here but I created the webrev from the >>>>>> changesets >>>>>> that I pushed. I don't see any difference. >>>>>> >>>>>> t4 $diff LCMSTransform.java.webrev >>>>>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>> t4 $ >>>>>> >>>>> Indeed. I'm still seeing the same failure using the changesets >>>>> pushed >>>>> to OpenJDK6, yet the repository itself builds. Very odd. >>>>> >>>> The copy of OpenJDK6 I was looking at wasn't up-to-date, hence the >>>> diff. >>>> The patched version and upstream repo are identical when compared >>>> correctly. >>>> >>>> What's baffling is how this code compiles with the javac compiler >>>> as it looks >>>> clearly wrong to me, which is why ecj falls over on it. >>>> >>>> try { >>>> LCMSImageLayout srcIL = new LCMSImageLayout( >>>> src, src.length/getNumInComponents(), >>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>>> | >>>> LCMSImageLayout.BYTES_SH(2), >>>> getNumInComponents()*2); >>>> >>>> LCMSImageLayout dstIL = new LCMSImageLayout( >>>> dst, dst.length/getNumOutComponents(), >>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>> | >>>> LCMSImageLayout.BYTES_SH(2), >>>> getNumOutComponents()*2); >>>> } catch (ImageLayoutException e) { >>>> throw new CMMException("Unable to convert data"); >>>> } >>>> >>>> synchronized(this) { >>>> LCMS.colorConvert(this, srcIL, dstIL); >>>> } >>>> >>>> srcIL and dstIL are declared inside the try block so aren't visible >>>> outside it. >>>> >>>> In the other colorConvert methods, these are declared at the top of >>>> the method. >>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 07/03/2013 10:59, Andrew Hughes wrote: >>>>>>> ----- Original Message ----- >>>>>>>> February CPU pushes completed as reviewed in last round of >>>>>>>> webrevs. >>>>>>>> >>>>>>>> I'd like to push 2 extra fixes now for issues addressed in >>>>>>>> yesterday's >>>>>>>> JDK releases. >>>>>>>> >>>>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ >>>>>>>> >>>>>>>> Good to push ? >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>> On 05/03/2013 18:44, Omair Majid wrote: >>>>>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> The change in JAXP can be viewed here: >>>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ While >>>>>>>>>> it's >>>>>>>>>> generated against JDK 8, the change in 6 is identical. >>>>>>>>> The JAXP changes look identical to what was pushed to jdk7u. >>>>>>>>> Looks >>>>>>>>> all >>>>>>>>> good to me! >>>>>>>>> >>>>>>>>>> I plan to push the changes today. >>>>>>>>> Thank you. It will be great to have all the security fixes in! >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Omair >>>>>>>>> >>>>>>> I notice that what was finally committed differs from this >>>>>>> webrev >>>>>>> (in a positive >>>>>>> way). The version posted from the webrev failed to compile: >>>>>>> >>>>>>> 1. ERROR in >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>> (at line 580) >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>> ^^^^^ >>>>>>> srcIL cannot be resolved to a variable >>>>>>> ---------- >>>>>>> 2. ERROR in >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>> (at line 580) >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>> ^^^^^ >>>>>>> dstIL cannot be resolved to a variable >>>>>>> ---------- >>>>>>> 3. ERROR in >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>> (at line 606) >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>> ^^^^^ >>>>>>> srcIL cannot be resolved to a variable >>>>>>> ---------- >>>>>>> 4. ERROR in >>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>> (at line 606) >>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>> ^^^^^ >>>>>>> dstIL cannot be resolved to a variable >>>>>>> >>>>>>> but this seems to have been fixed in the committed version, >>>>>>> presumably due to: >>>>>>> >>>>>>> - try { >>>>>>> - LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>>> - src, src.length/getNumInComponents(), >>>>>>> - >>>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>>>>>> | >>>>>>> - LCMSImageLayout.BYTES_SH(1), >>>>>>> getNumInComponents()); >>>>>>> - >>>>>>> - LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>>> - dst, dst.length/getNumOutComponents(), >>>>>>> - >>>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>>> | >>>>>>> - LCMSImageLayout.BYTES_SH(1), >>>>>>> getNumOutComponents()); >>>>>>> - } catch (ImageLayoutException e) { >>>>>>> - throw new CMMException("Unable to convert data"); >>>>>>> - } >>>>>>> + LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>>> + src, src.length/getNumInComponents(), >>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>>>>>> + LCMSImageLayout.BYTES_SH(1), getNumInComponents()); >>>>>>> + >>>>>>> + LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>>> + dst, dst.length/getNumOutComponents(), >>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>>> | >>>>>>> + LCMSImageLayout.BYTES_SH(1), >>>>>>> getNumOutComponents()); >>>>>>> >>>>>>> so srcIL and dstIL are now declared at a wider scope. I'll use >>>>>>> the >>>>>>> committed versions >>>>>>> in IcedTea6 HEAD. >>>>>>> >>>>>>> Cheers, >>>>> -- >>>>> Andrew :) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>>> >>>>> >>> > From andrew.brygin at oracle.com Thu Mar 7 07:14:56 2013 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Thu, 07 Mar 2013 19:14:56 +0400 Subject: Request for approval to sync Feb 2013 CPU fixes into jdk6-open In-Reply-To: <1776346126.14557839.1362669154732.JavaMail.root@redhat.com> References: <1776346126.14557839.1362669154732.JavaMail.root@redhat.com> Message-ID: <5138AEF0.50602@oracle.com> Hi Andrew, thanks for the review. I am pushing the change. Sorry for the mess. Thanks, Andrew On 3/7/2013 7:12 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Hello, >> >> please review a fix for the build failure: >> >> http://cr.openjdk.java.net/~bae/8009641/webrev.00/ >> > Looks good to me and better than what I had as the synchronized blocks were still outside the try > (so the variables could end up being null). > > Ok to commit. > >> Thanks, >> Andrew >> >> On 3/7/2013 5:55 PM, Se?n Coffey wrote: >>> Even better if you want to push the change ? I haven't heard from >>> Andrew B. yet. >>> >>> I've logged 8009641 to track this. You could use that ID if you >>> want. >>> >>> 8009641: OpenJDK 6 build broken via 8007675 fix >>> >>> regards, >>> Sean. >>> >>> On 07/03/2013 13:51, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> Yes - you're right. That does look like an issue. Andrew Brygin >>>>> ran >>>>> pre >>>>> integration tests before pushing the changes internally and they >>>>> were >>>>> successful. However - I've traced back over the sources and what >>>>> was >>>>> run >>>>> in his test build and what he pushed to internal repo differs. ( >>>>> in 2 >>>>> areas) - No doubt, it's the curse of the last minute change. >>>>> >>>>> Andrew Brygin, can you log a bug and get this corrected asap ? >>>>> >>>>> Thanks for the notice Andrew! >>>>> >>>> I have a patch I can post if that would help. With that, this >>>> builds. >>>> I just need to clean up my workspace and post a webrev. >>>> >>>>> Thanks, >>>>> Sean. >>>>> >>>>> >>>>>> public short[] colorConvert(short[] src, short[] dst) { >>>>>> >>>>>> if (dst == null) { >>>>>> dst = new short >>>>>> [(src.length/getNumInComponents())*getNumOutComponents()]; >>>>>> } >>>>>> >>>>>> try { >>>>>> LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>> src, src.length/getNumInComponents(), >>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>>>>> LCMSImageLayout.BYTES_SH(2), >>>>>> getNumInComponents()*2); >>>>>> >>>>>> LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>> dst, dst.length/getNumOutComponents(), >>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>> | >>>>>> LCMSImageLayout.BYTES_SH(2), >>>>>> getNumOutComponents()*2); >>>>>> >>>>>> synchronized(this) { >>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>> } >>>>>> } catch (ImageLayoutException e) { >>>>>> throw new CMMException("Unable to convert data"); >>>>>> } >>>>>> >>>>>> return dst; >>>>>> } >>>>> On 07/03/2013 12:39, Andrew Hughes wrote: >>>>>> ----- Original Message ----- >>>>>>> ----- Original Message ----- >>>>>>>> I'm only the proxy here but I created the webrev from the >>>>>>>> changesets >>>>>>>> that I pushed. I don't see any difference. >>>>>>>> >>>>>>>> t4 $diff LCMSTransform.java.webrev >>>>>>>> jdk/src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>>> t4 $ >>>>>>>> >>>>>>> Indeed. I'm still seeing the same failure using the changesets >>>>>>> pushed >>>>>>> to OpenJDK6, yet the repository itself builds. Very odd. >>>>>>> >>>>>> The copy of OpenJDK6 I was looking at wasn't up-to-date, hence >>>>>> the >>>>>> diff. >>>>>> The patched version and upstream repo are identical when >>>>>> compared >>>>>> correctly. >>>>>> >>>>>> What's baffling is how this code compiles with the javac >>>>>> compiler >>>>>> as it looks >>>>>> clearly wrong to me, which is why ecj falls over on it. >>>>>> >>>>>> try { >>>>>> LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>> src, src.length/getNumInComponents(), >>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>>>>> | >>>>>> LCMSImageLayout.BYTES_SH(2), >>>>>> getNumInComponents()*2); >>>>>> >>>>>> LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>> dst, dst.length/getNumOutComponents(), >>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>> | >>>>>> LCMSImageLayout.BYTES_SH(2), >>>>>> getNumOutComponents()*2); >>>>>> } catch (ImageLayoutException e) { >>>>>> throw new CMMException("Unable to convert data"); >>>>>> } >>>>>> >>>>>> synchronized(this) { >>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>> } >>>>>> >>>>>> srcIL and dstIL are declared inside the try block so aren't >>>>>> visible >>>>>> outside it. >>>>>> >>>>>> In the other colorConvert methods, these are declared at the top >>>>>> of >>>>>> the method. >>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>> On 07/03/2013 10:59, Andrew Hughes wrote: >>>>>>>>> ----- Original Message ----- >>>>>>>>>> February CPU pushes completed as reviewed in last round of >>>>>>>>>> webrevs. >>>>>>>>>> >>>>>>>>>> I'd like to push 2 extra fixes now for issues addressed in >>>>>>>>>> yesterday's >>>>>>>>>> JDK releases. >>>>>>>>>> >>>>>>>>>> webrev : >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.6open.mar5/ >>>>>>>>>> >>>>>>>>>> Good to push ? >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Sean. >>>>>>>>>> >>>>>>>>>> On 05/03/2013 18:44, Omair Majid wrote: >>>>>>>>>>> On 03/05/2013 10:52 AM, Edvard Wendelin wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The change in JAXP can be viewed here: >>>>>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk8/8001235/webrev/ >>>>>>>>>>>> While >>>>>>>>>>>> it's >>>>>>>>>>>> generated against JDK 8, the change in 6 is identical. >>>>>>>>>>> The JAXP changes look identical to what was pushed to >>>>>>>>>>> jdk7u. >>>>>>>>>>> Looks >>>>>>>>>>> all >>>>>>>>>>> good to me! >>>>>>>>>>> >>>>>>>>>>>> I plan to push the changes today. >>>>>>>>>>> Thank you. It will be great to have all the security fixes >>>>>>>>>>> in! >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Omair >>>>>>>>>>> >>>>>>>>> I notice that what was finally committed differs from this >>>>>>>>> webrev >>>>>>>>> (in a positive >>>>>>>>> way). The version posted from the webrev failed to compile: >>>>>>>>> >>>>>>>>> 1. ERROR in >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>>>> (at line 580) >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>>>> ^^^^^ >>>>>>>>> srcIL cannot be resolved to a variable >>>>>>>>> ---------- >>>>>>>>> 2. ERROR in >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>>>> (at line 580) >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>>>> ^^^^^ >>>>>>>>> dstIL cannot be resolved to a variable >>>>>>>>> ---------- >>>>>>>>> 3. ERROR in >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>>>> (at line 606) >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>>>> ^^^^^ >>>>>>>>> srcIL cannot be resolved to a variable >>>>>>>>> ---------- >>>>>>>>> 4. ERROR in >>>>>>>>> ../../../src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java >>>>>>>>> (at line 606) >>>>>>>>> LCMS.colorConvert(this, srcIL, dstIL); >>>>>>>>> ^^^^^ >>>>>>>>> dstIL cannot be resolved to a variable >>>>>>>>> >>>>>>>>> but this seems to have been fixed in the committed version, >>>>>>>>> presumably due to: >>>>>>>>> >>>>>>>>> - try { >>>>>>>>> - LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>>>>> - src, src.length/getNumInComponents(), >>>>>>>>> - >>>>>>>>> LCMSImageLayout.CHANNELS_SH(getNumInComponents()) >>>>>>>>> | >>>>>>>>> - LCMSImageLayout.BYTES_SH(1), >>>>>>>>> getNumInComponents()); >>>>>>>>> - >>>>>>>>> - LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>>>>> - dst, dst.length/getNumOutComponents(), >>>>>>>>> - >>>>>>>>> LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>>>>> | >>>>>>>>> - LCMSImageLayout.BYTES_SH(1), >>>>>>>>> getNumOutComponents()); >>>>>>>>> - } catch (ImageLayoutException e) { >>>>>>>>> - throw new CMMException("Unable to convert >>>>>>>>> data"); >>>>>>>>> - } >>>>>>>>> + LCMSImageLayout srcIL = new LCMSImageLayout( >>>>>>>>> + src, src.length/getNumInComponents(), >>>>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumInComponents()) | >>>>>>>>> + LCMSImageLayout.BYTES_SH(1), >>>>>>>>> getNumInComponents()); >>>>>>>>> + >>>>>>>>> + LCMSImageLayout dstIL = new LCMSImageLayout( >>>>>>>>> + dst, dst.length/getNumOutComponents(), >>>>>>>>> + LCMSImageLayout.CHANNELS_SH(getNumOutComponents()) >>>>>>>>> | >>>>>>>>> + LCMSImageLayout.BYTES_SH(1), >>>>>>>>> getNumOutComponents()); >>>>>>>>> >>>>>>>>> so srcIL and dstIL are now declared at a wider scope. I'll >>>>>>>>> use >>>>>>>>> the >>>>>>>>> committed versions >>>>>>>>> in IcedTea6 HEAD. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>> -- >>>>>>> Andrew :) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B >>>>>>> DC07 >>>>>>> >>>>>>> >> From andrew.brygin at oracle.com Thu Mar 7 07:22:30 2013 From: andrew.brygin at oracle.com (andrew.brygin at oracle.com) Date: Thu, 07 Mar 2013 15:22:30 +0000 Subject: hg: jdk6/jdk6/jdk: 8009641: OpenJDK 6 build broken via 8007675 fix Message-ID: <20130307152248.5FFA147DF3@hg.openjdk.java.net> Changeset: c73944a23b44 Author: bae Date: 2013-03-07 18:20 +0300 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c73944a23b44 8009641: OpenJDK 6 build broken via 8007675 fix Reviewed-by: andrew ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java From aph at redhat.com Wed Mar 13 10:02:29 2013 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Mar 2013 17:02:29 +0000 Subject: The future of OpenJDK6 Message-ID: <5140B125.5030605@redhat.com> Oracle ended public updates of JDK6 at the end of last month. Many people seem to have concluded that the OpenJDK6 project will therefore end at the same time. This is incorrect: OpenJDK6 will continue, but will be maintained by the community outside Oracle. This will require some infrastructure changes. In particular, because we are to maintain OpenJDK6 outside Oracle we need a bug database to which we have full access. At present, only people inside Oracle can create and update bug reports. Oracle intend to rectify this situation sometime in the summer, but in the meantime we need something we can use. I therefore propose to create an OpenJDK 6 project on java.net and use a JIRA bug database there. Once Oracle has a fully-open bug database we can transfer bugs to it. While I'm aware that this is not ideal, I believe it is the only way that we can run this project independently of Oracle. A few questions I've been asked: * What will be the policy for future changes? OpenJDK 6 is a legacy project. People only use it because they want long-term stability and compatibility. Therefore, only changes that fix significant bugs should be made. This is not a policy change from that discussed on http://openjdk.java.net/projects/jdk6/ * What about security updates? We'll back-port them as they arrive and commit them to OpenJDK 6. However, there may be some delay because of the effort and testing that back-porting requires. Therefore, if you want the most secure and up-to-date version of OpenJDK, you should update to OpenJDK 7. We'll also fix any security bugs that are found in OpenJDK 6 alone, but again there may be some delay. * What about Windows/Mac/etc builds? I really don't know. If the Windows/Mac/etc community want to get involved, then there will be updates for those platforms. If not, there won't be. It's up to them. * How long will this project continue for? The duration of support for OpenJDK 6 depends on how active its developers remain as part of the OpenJDK community. As things stand today, Red Hat (my current employer) is taking the lead in supporting the OpenJDK 6 project. It is conceivable that this project will be maintained beyond the duration of Red Hat's commitment. That ultimately depends on the community. Finally, this is a significant moment for OpenJDK. We look forward to working with the wider community of OpenJDK 6 users and developers on this project. Andrew. From gnu.andrew at redhat.com Wed Mar 13 12:47:13 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 15:47:13 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <5140B125.5030605@redhat.com> Message-ID: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> ----- Original Message ----- > Oracle ended public updates of JDK6 at the end of last month. Many > people seem to have concluded that the OpenJDK6 project will > therefore > end at the same time. This is incorrect: OpenJDK6 will continue, but > will be maintained by the community outside Oracle. > > This will require some infrastructure changes. In particular, > because > we are to maintain OpenJDK6 outside Oracle we need a bug database to > which we have full access. At present, only people inside Oracle can > create and update bug reports. Oracle intend to rectify this > situation sometime in the summer, but in the meantime we need > something we can use. I therefore propose to create an OpenJDK 6 > project on java.net and use a JIRA bug database there. Once Oracle > has a fully-open bug database we can transfer bugs to it. While I'm > aware that this is not ideal, I believe it is the only way that we > can > run this project independently of Oracle. > > A few questions I've been asked: > > * What will be the policy for future changes? > > OpenJDK 6 is a legacy project. People only use it because they want > long-term stability and compatibility. Therefore, only changes that > fix significant bugs should be made. This is not a policy change > from > that discussed on http://openjdk.java.net/projects/jdk6/ > > * What about security updates? > > We'll back-port them as they arrive and commit them to OpenJDK 6. > However, there may be some delay because of the effort and testing > that back-porting requires. Therefore, if you want the most secure > and up-to-date version of OpenJDK, you should update to OpenJDK 7. > We'll also fix any security bugs that are found in OpenJDK 6 alone, > but again there may be some delay. > > * What about Windows/Mac/etc builds? > > I really don't know. If the Windows/Mac/etc community want to get > involved, then there will be updates for those platforms. If not, > there won't be. It's up to them. > > * How long will this project continue for? > > The duration of support for OpenJDK 6 depends on how active its > developers remain as part of the OpenJDK community. As things stand > today, Red Hat (my current employer) is taking the lead in supporting > the OpenJDK 6 project. It is conceivable that this project will be > maintained beyond the duration of Red Hat's commitment. That > ultimately depends on the community. > > Finally, this is a significant moment for OpenJDK. We look forward > to > working with the wider community of OpenJDK 6 users and developers on > this project. > > Andrew. > A couple of questions: 1. Oracle had three main roles in relation to OpenJDK 6; acting as gatekeeper over which patches were accepted into the repository, providing security updates and making releases. The third of these doesn't seem to be addressed above. Will new releases of OpenJDK 6 be made? IcedTea for OpenJDK 6 uses release tarballs as a base so, unless there are further releases, none of the changes made upstream in OpenJDK 6 will be consumed by IcedTea downstream. I believe we are already overdue a new release as there is no release of OpenJDK 6 containing the last three sets of security updates. 2. What many people actually see as OpenJDK 6 at present, in the form of their GNU/Linux distribution package, is actually IcedTea for OpenJDK 6. Unlike 7, where the changes in IcedTea are just to make it "distro-ready" (using system libraries, etc.), there are now so many backports and other fixes local to IcedTea 6 that it is effectively a different beast altogether. Will OpenJDK 6 be open to accepting some of these fixes, many of which were added to the proprietary version of JDK 6 maintained by Oracle a long time ago, so the two can eventually be in sync? 3. The largest contributions to OpenJDK 6 from Red Hat have been the merges of new versions of HotSpot, upgrading it from 11 through 14, 16 and 19, to its current version of 20. Given appropriate testing, is moving to a newer version of HotSpot a possibility? We've already started testing HotSpot 23 in IcedTea: http://blog.fuseyism.com/index.php/2013/03/13/hotspot-23-in-icedtea-for-openjdk-6/ and this shows promise, though we would probably want to go with a later version in OpenJDK 6 which again has a working Zero assembler port. 4. Finally, this is just a thought, and I realise it may run contrary to your promise of long-term stability and compatibility, but I've been giving some thought to the long running issues we've had with javac in OpenJDK 6. For those who are unaware, the javac in OpenJDK 6 is not the same as in Oracle's proprietary JDK 6, but rather an early development version of the one used in OpenJDK 7. I've been wondering if the best way of supporting this long-term would be to use the tools from 7 in OpenJDK 6, with appropriate reversions to make it compatible with 6 (defaulting to 6 source/target, having builds pass the 6 TCK), rather than continuing to maintain the hybrid we have now. This would also mean we'd be able to benefit more directly from any bug fixes or security updates directed at the langtools present in 7. In closing, I'd like to welcome this new chapter in the life of OpenJDK 6 and I hope it is successful in continuing existing community involvement, and hopefully taking things even further. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From jonathan.gibbons at oracle.com Wed Mar 13 13:47:24 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Mar 2013 13:47:24 -0700 Subject: The future of OpenJDK6 In-Reply-To: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> Message-ID: <5140E5DC.5060100@oracle.com> On 03/13/2013 12:47 PM, Andrew Hughes wrote: > 4. Finally, this is just a thought, and I realise it may run contrary to your > promise of long-term stability and compatibility, but I've been giving some thought > to the long running issues we've had with javac in OpenJDK 6. For those who are > unaware, the javac in OpenJDK 6 is not the same as in Oracle's proprietary JDK 6, > but rather an early development version of the one used in OpenJDK 7. I've been > wondering if the best way of supporting this long-term would be to use the tools > from 7 in OpenJDK 6, with appropriate reversions to make it compatible with 6 > (defaulting to 6 source/target, having builds pass the 6 TCK), rather than continuing > to maintain the hybrid we have now. This would also mean we'd be able to benefit > more directly from any bug fixes or security updates directed at the langtools > present in 7. You might want to bring this up on compiler-dev. -- Jon From joe.darcy at oracle.com Wed Mar 13 13:52:27 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 13 Mar 2013 13:52:27 -0700 Subject: The future of OpenJDK6 In-Reply-To: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> Message-ID: <5140E70B.6070204@oracle.com> Responding to one point below, On 3/13/2013 12:47 PM, Andrew Hughes wrote: > ----- Original Message ----- [snip] > 4. Finally, this is just a thought, and I realise it may run contrary > to your promise of long-term stability and compatibility, but I've > been giving some thought to the long running issues we've had with > javac in OpenJDK 6. What concrete issues with OpenJDK 6 javac are you referring to? Are there bugs for them? > For those who are unaware, the javac in OpenJDK 6 is not the same as > in Oracle's proprietary JDK 6, but rather an early development version > of the one used in OpenJDK 7. The above is an incorrect categorization of the javac in OpenJDK 6 and more broadly the langtools repository in OpenJDK 6. All of OpenJDK 6 initially branched off of (Open)JDK 7 build 20 or so. There were fixes in javac and more broadly langtools at that time compared to JDK 6 GA. Those fixes were largely appropriate to a Java SE 6 comiler and therefore kept in; inappropriate changes were backed out. At least during the 3+ year tenure when I was release manager of OpenJDK 6, the langtools team made sure that all javac fixes that went into the Sun/Oracle proprietary JDK 6 also went into OpenJDK 6. Therefore, the OpenJDK 6 javac has had a strict superset of the fixes in Sun/Oracle JDK 6. The compilers in both OpenJDK 6 and JDK 6 pass the relevant JCK tests. The OpenJDK 6 javac and JDK 6 javac are different, but I would argue the OpenJDK 6 javac was and is better. The differences between the OpenJDK 6 and JDK 6 versions of other components vary by repository and area. As you noted, for some time RedHat has kept the hotspot repo of OpenJDK 6 generally in sync with the stabilized HotSpot express releases. At least times in the past, the jaxp, jaxws, and cobra OpenJDK 6 repos have been functionally identical to their JDK 6 counterparts. Some of this is detailed in an old blog post: "OpenJDK 6: Logistics of Partial Merge with 6u10" https://blogs.oracle.com/darcy/entry/openjdk_6_logistics_of_partial That leaves the "jdk" repo where most of the core libraries live (java.lang, java.util, java.awt, etc.). There has never been an analagous grand merge between what would logically be the jdk repo of the JDK 6 train and the jdk repo of OpenJDK 6. However, this has not seemed to be too much of an impediment to usability or to backporting security patches and other fixes as needed. > I've been wondering if the best way of supporting this long-term would > be to use the tools from 7 in OpenJDK 6, with appropriate reversions > to make it compatible with 6 (defaulting to 6 source/target, having > builds pass the 6 TCK), rather than continuing to maintain the hybrid > we have now. This would also mean we'd be able to benefit more > directly from any bug fixes or security updates directed at the > langtools present in 7. In closing, I'd like to welcome this new > chapter in the life of OpenJDK 6 and I hope it is successful in > continuing existing community involvement, and hopefully taking things > even further. Thanks, The code in the (Open)JDK 7 uses the Java SE 7 versions of the javax.lang.model.* API, which differ from the Java SE 6 versions. It would be a "small matter of programming" to adjust the rest of the javac sources accordingly. Note that some portions of the langtools repo in OpenJDK 7 outside of parts involved in bootstrapping may rely on Java SE 7 APIs. Whether or not undertaking this exercise would lead to lower long-term maintenance costs I cannot say, but it is not clear to me that it would. -Joe From alex.kasko.lists at gmail.com Wed Mar 13 14:14:20 2013 From: alex.kasko.lists at gmail.com (Alex Kasko) Date: Thu, 14 Mar 2013 01:14:20 +0400 Subject: The future of OpenJDK6 In-Reply-To: <5140B125.5030605@redhat.com> References: <5140B125.5030605@redhat.com> Message-ID: <5140EC2C.4070703@gmail.com> Hello, On 03/13/2013 09:02 PM, Andrew Haley wrote: > Oracle ended public updates of JDK6 at the end of last month. Many > people seem to have concluded that the OpenJDK6 project will therefore > end at the same time. This is incorrect: OpenJDK6 will continue, but > will be maintained by the community outside Oracle. > > This will require some infrastructure changes. In particular, because > we are to maintain OpenJDK6 outside Oracle we need a bug database to > which we have full access. At present, only people inside Oracle can > create and update bug reports. Oracle intend to rectify this > situation sometime in the summer, but in the meantime we need > something we can use. I therefore propose to create an OpenJDK 6 > project on java.net and use a JIRA bug database there. Once Oracle > has a fully-open bug database we can transfer bugs to it. While I'm > aware that this is not ideal, I believe it is the only way that we can > run this project independently of Oracle. > > A few questions I've been asked: > > * What will be the policy for future changes? > > OpenJDK 6 is a legacy project. People only use it because they want > long-term stability and compatibility. Therefore, only changes that > fix significant bugs should be made. This is not a policy change from > that discussed on http://openjdk.java.net/projects/jdk6/ Question about two features, that are not bugfixes, but may be useful in jdk6: 1) unlimited crypto support: - makefile patch from jdk7 [1] - maillist thread [2] 2) missed copyMemory method in sun.misc.Unsafe: - maillist thread [3] - patch that I'm using in my local jdk6 builds [4] - original patch that removed proper copyMemory method [5] Are there any chances for them to be included into jdk6? > > * What about security updates? > > We'll back-port them as they arrive and commit them to OpenJDK 6. > However, there may be some delay because of the effort and testing > that back-porting requires. Therefore, if you want the most secure > and up-to-date version of OpenJDK, you should update to OpenJDK 7. > We'll also fix any security bugs that are found in OpenJDK 6 alone, > but again there may be some delay. > > * What about Windows/Mac/etc builds? > > I really don't know. If the Windows/Mac/etc community want to get > involved, then there will be updates for those platforms. If not, > there won't be. It's up to them. > > * How long will this project continue for? > > The duration of support for OpenJDK 6 depends on how active its > developers remain as part of the OpenJDK community. As things stand > today, Red Hat (my current employer) is taking the lead in supporting > the OpenJDK 6 project. It is conceivable that this project will be > maintained beyond the duration of Red Hat's commitment. That > ultimately depends on the community. > > Finally, this is a significant moment for OpenJDK. We look forward to > working with the wider community of OpenJDK 6 users and developers on > this project. > > Andrew. [1] http://cr.openjdk.java.net/~andrew/100062/webrev.01/make/javax/crypto/Makefile.udiff.html [2] http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006798.html [3] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-January/002836.html [4] https://gist.github.com/alexkasko/5156174 [5] http://hg.openjdk.java.net/jdk6/jdk6/jdk/diff/39e8fe7a0af1/src/share/classes/sun/misc/Unsafe.java -- Regards, Alex Kasko From gnu.andrew at redhat.com Wed Mar 13 14:47:34 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 17:47:34 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <5140EC2C.4070703@gmail.com> Message-ID: <133261403.18232950.1363211254158.JavaMail.root@redhat.com> ----- Original Message ----- > Hello, > > On 03/13/2013 09:02 PM, Andrew Haley wrote: > > Oracle ended public updates of JDK6 at the end of last month. Many > > people seem to have concluded that the OpenJDK6 project will > > therefore > > end at the same time. This is incorrect: OpenJDK6 will continue, > > but > > will be maintained by the community outside Oracle. > > > > This will require some infrastructure changes. In particular, > > because > > we are to maintain OpenJDK6 outside Oracle we need a bug database > > to > > which we have full access. At present, only people inside Oracle > > can > > create and update bug reports. Oracle intend to rectify this > > situation sometime in the summer, but in the meantime we need > > something we can use. I therefore propose to create an OpenJDK 6 > > project on java.net and use a JIRA bug database there. Once Oracle > > has a fully-open bug database we can transfer bugs to it. While > > I'm > > aware that this is not ideal, I believe it is the only way that we > > can > > run this project independently of Oracle. > > > > A few questions I've been asked: > > > > * What will be the policy for future changes? > > > > OpenJDK 6 is a legacy project. People only use it because they > > want > > long-term stability and compatibility. Therefore, only changes > > that > > fix significant bugs should be made. This is not a policy change > > from > > that discussed on http://openjdk.java.net/projects/jdk6/ > Question about two features, that are not bugfixes, but may be useful > in > jdk6: > > 1) unlimited crypto support: > - makefile patch from jdk7 [1] > - maillist thread [2] > We already do this in IcedTea, but in a more brutal way which is why it was never upstreamed. I'd have to test out to see if the same small fix is enough on 6 as it is on 7, because the crypto code relating to this was simplified somewhat in 7. The same fix may not work on 6. > 2) missed copyMemory method in sun.misc.Unsafe: > - maillist thread [3] > - patch that I'm using in my local jdk6 builds [4] > - original patch that removed proper copyMemory method [5] > If you read the thread, you'll see I already pretty much agreed this would be ok, but I don't think I ever got chance to test it out. > Are there any chances for them to be included into jdk6? > They'd both be good candidates. > > > > * What about security updates? > > > > We'll back-port them as they arrive and commit them to OpenJDK 6. > > However, there may be some delay because of the effort and testing > > that back-porting requires. Therefore, if you want the most secure > > and up-to-date version of OpenJDK, you should update to OpenJDK 7. > > We'll also fix any security bugs that are found in OpenJDK 6 alone, > > but again there may be some delay. > > > > * What about Windows/Mac/etc builds? > > > > I really don't know. If the Windows/Mac/etc community want to get > > involved, then there will be updates for those platforms. If not, > > there won't be. It's up to them. > > > > * How long will this project continue for? > > > > The duration of support for OpenJDK 6 depends on how active its > > developers remain as part of the OpenJDK community. As things > > stand > > today, Red Hat (my current employer) is taking the lead in > > supporting > > the OpenJDK 6 project. It is conceivable that this project will be > > maintained beyond the duration of Red Hat's commitment. That > > ultimately depends on the community. > > > > Finally, this is a significant moment for OpenJDK. We look forward > > to > > working with the wider community of OpenJDK 6 users and developers > > on > > this project. > > > > Andrew. > > [1] > http://cr.openjdk.java.net/~andrew/100062/webrev.01/make/javax/crypto/Makefile.udiff.html > [2] > http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006798.html > [3] > http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-January/002836.html > [4] https://gist.github.com/alexkasko/5156174 > [5] > http://hg.openjdk.java.net/jdk6/jdk6/jdk/diff/39e8fe7a0af1/src/share/classes/sun/misc/Unsafe.java > > -- > Regards, > Alex Kasko > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Wed Mar 13 14:42:36 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 17:42:36 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <5140E70B.6070204@oracle.com> Message-ID: <1760028389.18232510.1363210956231.JavaMail.root@redhat.com> ----- Original Message ----- > Responding to one point below, > > On 3/13/2013 12:47 PM, Andrew Hughes wrote: > > ----- Original Message ----- > > [snip] > > > 4. Finally, this is just a thought, and I realise it may run > > contrary > > to your promise of long-term stability and compatibility, but I've > > been giving some thought to the long running issues we've had with > > javac in OpenJDK 6. > > > What concrete issues with OpenJDK 6 javac are you referring to? Are > there bugs for them? > We tend to come across inferencing issues which don't appear on either the proprietary JDK 6 compiler or the OpenJDK 7 one e.g. http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-September/002008.html > > For those who are unaware, the javac in OpenJDK 6 is not the same > > as > > in Oracle's proprietary JDK 6, but rather an early development > > version > > of the one used in OpenJDK 7. > > The above is an incorrect categorization of the javac in OpenJDK 6 > and > more broadly the langtools repository in OpenJDK 6. > > All of OpenJDK 6 initially branched off of (Open)JDK 7 build 20 or > so. > There were fixes in javac and more broadly langtools at that time > compared to JDK 6 GA. Those fixes were largely appropriate to a Java > SE > 6 comiler and therefore kept in; inappropriate changes were backed > out. > At least during the 3+ year tenure when I was release manager of > OpenJDK > 6, the langtools team made sure that all javac fixes that went into > the > Sun/Oracle proprietary JDK 6 also went into OpenJDK 6. Therefore, the > OpenJDK 6 javac has had a strict superset of the fixes in Sun/Oracle > JDK > 6. The compilers in both OpenJDK 6 and JDK 6 pass the relevant JCK > tests. > > The OpenJDK 6 javac and JDK 6 javac are different, but I would argue > the > OpenJDK 6 javac was and is better. > I apologise. I should have clarified that with 'was originally based on an early development version'. I'm aware it's had work since. Backports even caused TCK6 failures for us at least once :) What I do know is that there are issues that only appear on *that* javac. It also has been maintained in that way of late. The last non-tag commit is: changeset: 126:6fa1f24a215a tag: jdk6-b25 user: jjg date: Fri Sep 16 16:18:46 2011 -0700 summary: 7091528: javadoc attempts to parse .class files about 18 months ago. > The differences between the OpenJDK 6 and JDK 6 versions of other > components vary by repository and area. As you noted, for some time > Red Hat has kept the hotspot repo of OpenJDK 6 generally in sync with > the > stabilized HotSpot express releases. At least times in the past, the > jaxp, jaxws, and cobra OpenJDK 6 repos have been functionally > identical > to their JDK 6 counterparts. Some of this is detailed in an old blog > post: > > "OpenJDK 6: Logistics of Partial Merge with 6u10" > https://blogs.oracle.com/darcy/entry/openjdk_6_logistics_of_partial > > That leaves the "jdk" repo where most of the core libraries live > (java.lang, java.util, java.awt, etc.). There has never been an > analagous grand merge between what would logically be the jdk repo of > the JDK 6 train and the jdk repo of OpenJDK 6. However, this has not > seemed to be too much of an impediment to usability or to backporting > security patches and other fixes as needed. I can't really comment on the proprietary JDK 6 codebase any more than what I can infer as I obviously can't see the code. I know we've backported quite a few changes from 7 to 6 (nearly all JDK) which were ported to 7 from the proprietary 6 codebase by Sun/Oracle before that. However, there's been no structure to this. It's just been a case of seeing a commit to 7 which references coming from the proprietary 6 tree, or finding a bug that indicates the fix was committed there. I have no idea how complete things are. > > > I've been wondering if the best way of supporting this long-term > > would > > be to use the tools from 7 in OpenJDK 6, with appropriate > > reversions > > to make it compatible with 6 (defaulting to 6 source/target, having > > builds pass the 6 TCK), rather than continuing to maintain the > > hybrid > > we have now. This would also mean we'd be able to benefit more > > directly from any bug fixes or security updates directed at the > > langtools present in 7. In closing, I'd like to welcome this new > > chapter in the life of OpenJDK 6 and I hope it is successful in > > continuing existing community involvement, and hopefully taking > > things > > even further. Thanks, > > The code in the (Open)JDK 7 uses the Java SE 7 versions of the > javax.lang.model.* API, which differ from the Java SE 6 versions. It > would be a "small matter of programming" to adjust the rest of the > javac > sources accordingly. Note that some portions of the langtools repo in > OpenJDK 7 outside of parts involved in bootstrapping may rely on Java > SE > 7 APIs. > Yes, these are the reversions I was referring to i.e. enough to get it building and passing the 6 TCK. My naive thought is that this would be a more stable process than attempting to backport random changesets from 7, as it's already been applied once to create the original 6 javac. > Whether or not undertaking this exercise would lead to lower > long-term > maintenance costs I cannot say, but it is not clear to me that it > would. > As I say, I was just musing on the idea rather than committing to it. We'd have to investigate it in more detail first. I was just throwing the thought out there and your feedback has been very helpful. >From what you've said, it sounds like the javac is closer to the one in 7 than I'd imagined. > -Joe > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From martinrb at google.com Wed Mar 13 20:25:07 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Mar 2013 20:25:07 -0700 Subject: The future of OpenJDK6 In-Reply-To: <5140E5DC.5060100@oracle.com> References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> <5140E5DC.5060100@oracle.com> Message-ID: Our experience at Google has been that javac7 is a stricter compiler than javac6. It is a significant effort migrating from javac6 to javac7 with a large code base. Since openjdk6 is all about stability, I would resist updating the javac in openjdk6. Some of the "bugs" in javac6 allow user code to compile successfully! On Wed, Mar 13, 2013 at 1:47 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > On 03/13/2013 12:47 PM, Andrew Hughes wrote: > >> 4. Finally, this is just a thought, and I realise it may run contrary to >> your >> promise of long-term stability and compatibility, but I've been giving >> some thought >> to the long running issues we've had with javac in OpenJDK 6. For those >> who are >> unaware, the javac in OpenJDK 6 is not the same as in Oracle's >> proprietary JDK 6, >> but rather an early development version of the one used in OpenJDK 7. >> I've been >> wondering if the best way of supporting this long-term would be to use >> the tools >> from 7 in OpenJDK 6, with appropriate reversions to make it compatible >> with 6 >> (defaulting to 6 source/target, having builds pass the 6 TCK), rather >> than continuing >> to maintain the hybrid we have now. This would also mean we'd be able to >> benefit >> more directly from any bug fixes or security updates directed at the >> langtools >> present in 7. >> > > You might want to bring this up on compiler-dev. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20130313/8c299cb3/attachment.html From joe.darcy at oracle.com Wed Mar 13 22:57:59 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 13 Mar 2013 22:57:59 -0700 Subject: The future of OpenJDK6 In-Reply-To: References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> <5140E5DC.5060100@oracle.com> Message-ID: <514166E7.9060905@oracle.com> Removing discuss at openjdk.java.net from the distribution list. On 3/13/2013 8:25 PM, Martin Buchholz wrote: > Our experience at Google has been that javac7 is a stricter compiler > than javac6. It is a significant effort migrating from javac6 to > javac7 with a large code base. Since openjdk6 is all about stability, > I would resist updating the javac in openjdk6. Some of the "bugs" in > javac6 allow user code to compile successfully! The command $JDK7/bin/javac -source 6 -target 6 -bootclasspath $JDK7-RT.JAR should be a fine Java SE 6 compiler, but I'm not surprised Martin and company have found that it is stricter than the compilers shipped in JDK 6, besides the Project Coin features, lots of fixes went into JDK 7 too. If one can abide the stricter checks, the JDK 7 series compiler offers much improved error messages in some cases. For the consideration of the current managers of OpenJDK 6, I've gone through the JDK bug database and found bug fixes applied to the JDK 7/7 update and 6 update trains but *not* to OpenJDK 6; the list is below. (These fixes date from after my time as OpenJDK 6 release manager; I stepped down in February 2011 and 6u27 was released in August 2011.) 6u27 JDK-6718364 inference fails when a generic method is invoked with raw arguments http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/30a415f8667f 6u30 JDK-6682380 Foreach loop with generics inside finally block crashes javac with -target 1.5 http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ec29a1a284ca 6u30 JDK-7046929 tools/javac/api/T6397104.java fails http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/592c30109bbe 6u30 JDK-7024568 Very long method resolution causing OOM error http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/74f0c05c51eb 6u32 JDK-7003595 IncompatibleClassChangeError with unreferenced local class with subclass http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/41a303cb946e 6u34 JDK-6500343 compiler generates bad code when translating conditional expressions http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ddd110646d21 Cheers, -Joe > > > On Wed, Mar 13, 2013 at 1:47 PM, Jonathan Gibbons > > wrote: > > On 03/13/2013 12:47 PM, Andrew Hughes wrote: > > 4. Finally, this is just a thought, and I realise it may run > contrary to your > promise of long-term stability and compatibility, but I've > been giving some thought > to the long running issues we've had with javac in OpenJDK 6. > For those who are > unaware, the javac in OpenJDK 6 is not the same as in Oracle's > proprietary JDK 6, > but rather an early development version of the one used in > OpenJDK 7. I've been > wondering if the best way of supporting this long-term would > be to use the tools > from 7 in OpenJDK 6, with appropriate reversions to make it > compatible with 6 > (defaulting to 6 source/target, having builds pass the 6 TCK), > rather than continuing > to maintain the hybrid we have now. This would also mean we'd > be able to benefit > more directly from any bug fixes or security updates directed > at the langtools > present in 7. > > > You might want to bring this up on compiler-dev. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20130313/50436501/attachment.html From aph at redhat.com Thu Mar 14 02:18:21 2013 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2013 09:18:21 +0000 Subject: The future of OpenJDK6 In-Reply-To: <5140EC2C.4070703@gmail.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> Message-ID: <514195DD.6020202@redhat.com> On 03/13/2013 09:14 PM, Alex Kasko wrote: > On 03/13/2013 09:02 PM, Andrew Haley wrote: >> >> OpenJDK 6 is a legacy project. People only use it because they want >> long-term stability and compatibility. Therefore, only changes that >> fix significant bugs should be made. This is not a policy change from >> that discussed on http://openjdk.java.net/projects/jdk6/ > > Question about two features, that are not bugfixes, but may be useful in > jdk6: > > 1) unlimited crypto support: > - makefile patch from jdk7 [1] > - maillist thread [2] > > 2) missed copyMemory method in sun.misc.Unsafe: > - maillist thread [3] > - patch that I'm using in my local jdk6 builds [4] > - original patch that removed proper copyMemory method [5] > > Are there any chances for them to be included into jdk6? I would strongly prefer it if neither of these patches went in, but I am open to argument. Almost nothing would persuade me to accept 2). This is an internal method that no application should use. Andrew. From aph at redhat.com Thu Mar 14 02:27:33 2013 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2013 09:27:33 +0000 Subject: The future of OpenJDK6 In-Reply-To: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com> Message-ID: <51419805.90704@redhat.com> On 03/13/2013 07:47 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Oracle ended public updates of JDK6 at the end of last month. Many >> people seem to have concluded that the OpenJDK6 project will >> therefore >> end at the same time. This is incorrect: OpenJDK6 will continue, but >> will be maintained by the community outside Oracle. > > 1. Oracle had three main roles in relation to OpenJDK 6; acting as > gatekeeper over which patches were accepted into the repository, > providing security updates and making releases. The third of these > doesn't seem to be addressed above. Will new releases of OpenJDK 6 > be made? IcedTea for OpenJDK 6 uses release tarballs as a base so, > unless there are further releases, none of the changes made upstream > in OpenJDK 6 will be consumed by IcedTea downstream. I believe we > are already overdue a new release as there is no release of OpenJDK > 6 containing the last three sets of security updates. Indeed, we need to make a new release of OpenJDK 6 with the security patches. There may be infrastructure issues here as we don't AFAIK have access to Oracle servers on which to place release tarballs. Or do we? > 2. What many people actually see as OpenJDK 6 at present, in the > form of their GNU/Linux distribution package, is actually IcedTea > for OpenJDK 6. Unlike 7, where the changes in IcedTea are just to > make it "distro-ready" (using system libraries, etc.), there are now > so many backports and other fixes local to IcedTea 6 that it is > effectively a different beast altogether. Will OpenJDK 6 be open to > accepting some of these fixes, many of which were added to the > proprietary version of JDK 6 maintained by Oracle a long time ago, > so the two can eventually be in sync? That would, in my view, be a huge waste of effort. It also risks breaking things for no net gain. > 3. The largest contributions to OpenJDK 6 from Red Hat have been > the merges of new versions of HotSpot, upgrading it from 11 through > 14, 16 and 19, to its current version of 20. Given appropriate > testing, is moving to a newer version of HotSpot a possibility? Yes. I believe that it is necessary to make some small changes to HotSpot to make it fully Java SE 6 compatible, but we should do this. > 4. Finally, this is just a thought, and I realise it may run > contrary to your promise of long-term stability and compatibility, > but I've been giving some thought to the long running issues we've > had with javac in OpenJDK 6. For those who are unaware, the javac > in OpenJDK 6 is not the same as in Oracle's proprietary JDK 6, but > rather an early development version of the one used in OpenJDK 7. > I've been wondering if the best way of supporting this long-term > would be to use the tools from 7 in OpenJDK 6, with appropriate > reversions to make it compatible with 6 (defaulting to 6 > source/target, having builds pass the 6 TCK), rather than continuing > to maintain the hybrid we have now. No. As explained by the Javac team, javac 7 does not accept precisely the same language, even in "Java 6" mode, and such a change would risk breaking builds all over the place. This is exactly the kind of change that I wish to prevent. > In closing, I'd like to welcome this new chapter in the life of > OpenJDK 6 and I hope it is successful in continuing existing > community involvement, and hopefully taking things even further. I hope so too. Andrew. From alex.kasko.lists at gmail.com Thu Mar 14 05:14:59 2013 From: alex.kasko.lists at gmail.com (Alex Kasko) Date: Thu, 14 Mar 2013 16:14:59 +0400 Subject: The future of OpenJDK6 In-Reply-To: <514195DD.6020202@redhat.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> Message-ID: <5141BF43.5010204@gmail.com> On 03/14/2013 01:18 PM, Andrew Haley wrote: > On 03/13/2013 09:14 PM, Alex Kasko wrote: >> On 03/13/2013 09:02 PM, Andrew Haley wrote: >>> >>> OpenJDK 6 is a legacy project. People only use it because they want >>> long-term stability and compatibility. Therefore, only changes that >>> fix significant bugs should be made. This is not a policy change from >>> that discussed on http://openjdk.java.net/projects/jdk6/ >> >> Question about two features, that are not bugfixes, but may be useful in >> jdk6: >> >> 1) unlimited crypto support: >> - makefile patch from jdk7 [1] >> - maillist thread [2] >> >> 2) missed copyMemory method in sun.misc.Unsafe: >> - maillist thread [3] >> - patch that I'm using in my local jdk6 builds [4] >> - original patch that removed proper copyMemory method [5] >> >> Are there any chances for them to be included into jdk6? > > I would strongly prefer it if neither of these patches went in, but I > am open to argument. I'm OK with it, I'm maintaining public windows builds of openjdk6 and going to add these patches into my next build anyway (so I've asked about them). > > Almost nothing would persuade me to accept 2). This is an internal > method that no application should use. Not arguing, just for your information, situation happened to me some weeks ago. My teammate C++ programmer with little java knowledge was working on Snappy [1] compatibility with C++ streams. He wanted to build Snappy on his Linux box using openjdk6 from packets and was not able to do it - got NoSuchMethodError. At the same time it compiles fine with later versions of Oracle JDK6. Yes, this Snappy implementation uses undocumented API (for optimization purposes) and it has fallback implementation and will run on openjdk6. But it cannot be compiled with default java6 in Linux without downloading Oracle JDK6 and this caused some frustration. Also sun.misc.Unsafe usage is quite popular for specific optimizations, I've even seen it once in java job position requirements (as additional point). > > Andrew. [1] https://github.com/dain/snappy -- Regards, Alex Kasko From omajid at redhat.com Thu Mar 14 07:56:02 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Thu, 14 Mar 2013 14:56:02 +0000 Subject: hg: jdk6/jdk6: 8008765: Relax bugid checks in 6-open repositories Message-ID: <20130314145602.D54A94813E@hg.openjdk.java.net> Changeset: 97c0c8b9eab2 Author: omajid Date: 2013-03-14 10:50 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/97c0c8b9eab2 8008765: Relax bugid checks in 6-open repositories Reviewed-by: ohair ! .jcheck/conf From omajid at redhat.com Thu Mar 14 07:56:07 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Thu, 14 Mar 2013 14:56:07 +0000 Subject: hg: jdk6/jdk6/corba: 8008765: Relax bugid checks in 6-open repositories Message-ID: <20130314145609.BA5484813F@hg.openjdk.java.net> Changeset: 1260b4e54a23 Author: omajid Date: 2013-03-14 10:51 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/1260b4e54a23 8008765: Relax bugid checks in 6-open repositories Reviewed-by: ohair ! .jcheck/conf From omajid at redhat.com Thu Mar 14 07:56:27 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Thu, 14 Mar 2013 14:56:27 +0000 Subject: hg: jdk6/jdk6/jaxp: 8008765: Relax bugid checks in 6-open repositories Message-ID: <20130314145627.3F61A48141@hg.openjdk.java.net> Changeset: 8299b980d2e1 Author: omajid Date: 2013-03-14 10:52 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/8299b980d2e1 8008765: Relax bugid checks in 6-open repositories Reviewed-by: ohair ! .jcheck/conf From omajid at redhat.com Thu Mar 14 07:56:31 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Thu, 14 Mar 2013 14:56:31 +0000 Subject: hg: jdk6/jdk6/jaxws: 8008765: Relax bugid checks in 6-open repositories Message-ID: <20130314145631.D4F4148142@hg.openjdk.java.net> Changeset: 5c734e43475d Author: omajid Date: 2013-03-14 10:52 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/5c734e43475d 8008765: Relax bugid checks in 6-open repositories Reviewed-by: ohair ! .jcheck/conf From omajid at redhat.com Thu Mar 14 07:56:16 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Thu, 14 Mar 2013 14:56:16 +0000 Subject: hg: jdk6/jdk6/hotspot: 8008765: Relax bugid checks in 6-open repositories Message-ID: <20130314145621.D4FA148140@hg.openjdk.java.net> Changeset: 62993f16dce2 Author: omajid Date: 2013-03-14 10:51 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/62993f16dce2 8008765: Relax bugid checks in 6-open repositories Reviewed-by: ohair ! .jcheck/conf From omajid at redhat.com Thu Mar 14 07:56:37 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Thu, 14 Mar 2013 14:56:37 +0000 Subject: hg: jdk6/jdk6/jdk: 8008765: Relax bugid checks in 6-open repositories Message-ID: <20130314145703.7051548143@hg.openjdk.java.net> Changeset: 0d99d61882b7 Author: omajid Date: 2013-03-14 10:52 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0d99d61882b7 8008765: Relax bugid checks in 6-open repositories Reviewed-by: ohair ! .jcheck/conf From omajid at redhat.com Thu Mar 14 07:57:10 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Thu, 14 Mar 2013 14:57:10 +0000 Subject: hg: jdk6/jdk6/langtools: 8008765: Relax bugid checks in 6-open repositories Message-ID: <20130314145712.E17E848144@hg.openjdk.java.net> Changeset: fb349e2cf7b6 Author: omajid Date: 2013-03-14 10:53 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/fb349e2cf7b6 8008765: Relax bugid checks in 6-open repositories Reviewed-by: ohair ! .jcheck/conf From jvanek at redhat.com Thu Mar 14 08:09:54 2013 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 14 Mar 2013 16:09:54 +0100 Subject: [rfc] backport of fix for bug 7197906 Message-ID: <5141E842.5060103@redhat.com> Hi! I would like to backport this fix http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/ for bug 7197906 to jdk6. I applied with small offset, was build, and is working fine. The webrev of applied patch can be found here: http://jvanek.fedorapeople.org/oracle/jdk6/hs/ J. From omajid at redhat.com Thu Mar 14 08:07:21 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 11:07:21 -0400 Subject: [PATCH] Make it easier to push commits into OpenJDK6 In-Reply-To: <5128140A.9060207@redhat.com> References: <51266250.1070601@redhat.com> <9198D4CF-7A80-483B-88D6-7D923FB8FEFA@oracle.com> <5127F77B.7050206@redhat.com> <5128140A.9060207@redhat.com> Message-ID: <5141E7A9.20908@redhat.com> On 02/22/2013 07:57 PM, Omair Majid wrote: > On 02/22/2013 07:17 PM, Kelly O'Hair wrote: >> On Feb 22, 2013, at 2:55 PM, Omair Majid wrote: >>> Now, for the funny part: could I get a bug id so I can push this change? :) >> >> Oh sorry... >> >> Here: >> >> 8008765: Relax bugid checks in 6-open repositories > > Thank you. > > I will wait for all the February security fixes to be pushed first > before pushing this. > I have pushed these changes now. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Thu Mar 14 07:44:57 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 10:44:57 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <51419805.90704@redhat.com> Message-ID: <1403039949.18704359.1363272297081.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/13/2013 07:47 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Oracle ended public updates of JDK6 at the end of last month. > >> Many > >> people seem to have concluded that the OpenJDK6 project will > >> therefore > >> end at the same time. This is incorrect: OpenJDK6 will continue, > >> but > >> will be maintained by the community outside Oracle. > > > > 1. Oracle had three main roles in relation to OpenJDK 6; acting as > > gatekeeper over which patches were accepted into the repository, > > providing security updates and making releases. The third of these > > doesn't seem to be addressed above. Will new releases of OpenJDK 6 > > be made? IcedTea for OpenJDK 6 uses release tarballs as a base so, > > unless there are further releases, none of the changes made > > upstream > > in OpenJDK 6 will be consumed by IcedTea downstream. I believe we > > are already overdue a new release as there is no release of OpenJDK > > 6 containing the last three sets of security updates. > > Indeed, we need to make a new release of OpenJDK 6 with the security > patches. There may be infrastructure issues here as we don't AFAIK > have access to Oracle servers on which to place release tarballs. Or > do we? > Not as far as I know, but I don't see how it matters where they are located, as long as people are notified of the location. I'm more concerned that they happen promptly and tarballs are produced with the same form and contents. Hopefully, there is some obscure Makefile target that creates them but I'm not aware of it offhand. > > 2. What many people actually see as OpenJDK 6 at present, in the > > form of their GNU/Linux distribution package, is actually IcedTea > > for OpenJDK 6. Unlike 7, where the changes in IcedTea are just to > > make it "distro-ready" (using system libraries, etc.), there are > > now > > so many backports and other fixes local to IcedTea 6 that it is > > effectively a different beast altogether. Will OpenJDK 6 be open > > to > > accepting some of these fixes, many of which were added to the > > proprietary version of JDK 6 maintained by Oracle a long time ago, > > so the two can eventually be in sync? > > That would, in my view, be a huge waste of effort. It also risks > breaking things for no net gain. The gain would be to shift the focus from IcedTea6 to OpenJDK6. Pretty much no-one uses OpenJDK6 directly, as far as I'm aware. All the distro packages I've seen use IcedTea6 to build it with these patches applied. When I last tried OpenJDK6, I had to push four changesets upstream just to get it to build on a modern system. If things were broken with these patches, we'd surely know about it because everyone using OpenJDK 6 packages is using them with these patches. I agree it's a lot of wasted effort for no technical gain. It would be simpler and easier to just stick with IcedTea. But that does make OpenJDK 6 a bit pointless, to be frank. > > > 3. The largest contributions to OpenJDK 6 from Red Hat have been > > the merges of new versions of HotSpot, upgrading it from 11 through > > 14, 16 and 19, to its current version of 20. Given appropriate > > testing, is moving to a newer version of HotSpot a possibility? > > Yes. I believe that it is necessary to make some small changes to > HotSpot to make it fully Java SE 6 compatible, but we should do this. Well, as I say in the blog, it builds and passes the jtreg tests with hs23. You're welcome to validate it further with the proprietary tests in the TCK. > > > 4. Finally, this is just a thought, and I realise it may run > > contrary to your promise of long-term stability and compatibility, > > but I've been giving some thought to the long running issues we've > > had with javac in OpenJDK 6. For those who are unaware, the javac > > in OpenJDK 6 is not the same as in Oracle's proprietary JDK 6, but > > rather an early development version of the one used in OpenJDK 7. > > I've been wondering if the best way of supporting this long-term > > would be to use the tools from 7 in OpenJDK 6, with appropriate > > reversions to make it compatible with 6 (defaulting to 6 > > source/target, having builds pass the 6 TCK), rather than > > continuing > > to maintain the hybrid we have now. > > No. As explained by the Javac team, javac 7 does not accept > precisely > the same language, even in "Java 6" mode, and such a change would > risk > breaking builds all over the place. This is exactly the kind of > change that I wish to prevent. > > > In closing, I'd like to welcome this new chapter in the life of > > OpenJDK 6 and I hope it is successful in continuing existing > > community involvement, and hopefully taking things even further. > > I hope so too. > > Andrew. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Thu Mar 14 08:10:21 2013 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2013 15:10:21 +0000 Subject: The future of OpenJDK6 In-Reply-To: <5141BF43.5010204@gmail.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> Message-ID: <5141E85D.60702@redhat.com> On 03/14/2013 12:14 PM, Alex Kasko wrote: > On 03/14/2013 01:18 PM, Andrew Haley wrote: >> On 03/13/2013 09:14 PM, Alex Kasko wrote: >>> On 03/13/2013 09:02 PM, Andrew Haley wrote: >>>> >>>> OpenJDK 6 is a legacy project. People only use it because they want >>>> long-term stability and compatibility. Therefore, only changes that >>>> fix significant bugs should be made. This is not a policy change from >>>> that discussed on http://openjdk.java.net/projects/jdk6/ >>> >>> Question about two features, that are not bugfixes, but may be useful in >>> jdk6: >>> >>> 1) unlimited crypto support: >>> - makefile patch from jdk7 [1] >>> - maillist thread [2] >>> >>> 2) missed copyMemory method in sun.misc.Unsafe: >>> - maillist thread [3] >>> - patch that I'm using in my local jdk6 builds [4] >>> - original patch that removed proper copyMemory method [5] >>> >>> Are there any chances for them to be included into jdk6? >> >> I would strongly prefer it if neither of these patches went in, but I >> am open to argument. > > I'm OK with it, I'm maintaining public windows builds of openjdk6 and > going to add these patches into my next build anyway (so I've asked > about them). > >> Almost nothing would persuade me to accept 2). This is an internal >> method that no application should use. > > Not arguing, just for your information, situation happened to me some > weeks ago. > My teammate C++ programmer with little java knowledge was working on > Snappy [1] compatibility with C++ streams. He wanted to build Snappy on > his Linux box using openjdk6 from packets and was not able to do it - > got NoSuchMethodError. At the same time it compiles fine with later > versions of Oracle JDK6. Yes, this Snappy implementation uses > undocumented API (for optimization purposes) and it has fallback > implementation and will run on openjdk6. But it cannot be compiled with > default java6 in Linux without downloading Oracle JDK6 and this caused > some frustration. Ah, that is a pain. Maybe I'm starting to persuade myself this should go in. The right way for upstream to handle this would be so use reflection to probe for the method in question: then this program wouldn't have any problems. But if upstream won't do that, I'll accept a patch that re- enables copyMemory. > Also sun.misc.Unsafe usage is quite popular for specific optimizations, > I've even seen it once in java job position requirements (as additional > point). Good lord. Unsafe is probably going to disappear from view when modularization happens, so people had better get used to its absence. Andrew. From aph at redhat.com Thu Mar 14 08:16:12 2013 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2013 15:16:12 +0000 Subject: The future of OpenJDK6 In-Reply-To: <1403039949.18704359.1363272297081.JavaMail.root@redhat.com> References: <1403039949.18704359.1363272297081.JavaMail.root@redhat.com> Message-ID: <5141E9BC.406@redhat.com> On 03/14/2013 02:44 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 03/13/2013 07:47 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Oracle ended public updates of JDK6 at the end of last month. >>>> Many >>>> people seem to have concluded that the OpenJDK6 project will >>>> therefore >>>> end at the same time. This is incorrect: OpenJDK6 will continue, >>>> but >>>> will be maintained by the community outside Oracle. >>> >>> 1. Oracle had three main roles in relation to OpenJDK 6; acting as >>> gatekeeper over which patches were accepted into the repository, >>> providing security updates and making releases. The third of these >>> doesn't seem to be addressed above. Will new releases of OpenJDK 6 >>> be made? IcedTea for OpenJDK 6 uses release tarballs as a base so, >>> unless there are further releases, none of the changes made >>> upstream >>> in OpenJDK 6 will be consumed by IcedTea downstream. I believe we >>> are already overdue a new release as there is no release of OpenJDK >>> 6 containing the last three sets of security updates. >> >> Indeed, we need to make a new release of OpenJDK 6 with the security >> patches. There may be infrastructure issues here as we don't AFAIK >> have access to Oracle servers on which to place release tarballs. Or >> do we? > > Not as far as I know, but I don't see how it matters where they are located, > as long as people are notified of the location. > > I'm more concerned that they happen promptly and tarballs are produced with > the same form and contents. Hopefully, there is some obscure Makefile target > that creates them but I'm not aware of it offhand. OK. >>> 2. What many people actually see as OpenJDK 6 at present, in the >>> form of their GNU/Linux distribution package, is actually IcedTea >>> for OpenJDK 6. Unlike 7, where the changes in IcedTea are just to >>> make it "distro-ready" (using system libraries, etc.), there are >>> now so many backports and other fixes local to IcedTea 6 that it >>> is effectively a different beast altogether. Will OpenJDK 6 be >>> open to accepting some of these fixes, many of which were added to >>> the proprietary version of JDK 6 maintained by Oracle a long time >>> ago, so the two can eventually be in sync? >> >> That would, in my view, be a huge waste of effort. It also risks >> breaking things for no net gain. > > The gain would be to shift the focus from IcedTea6 to OpenJDK6. > Pretty much no-one uses OpenJDK6 directly, as far as I'm aware. All > the distro packages I've seen use IcedTea6 to build it with these > patches applied. When I last tried OpenJDK6, I had to push four > changesets upstream just to get it to build on a modern system. > > If things were broken with these patches, we'd surely know about it > because everyone using OpenJDK 6 packages is using them with these > patches. > > I agree it's a lot of wasted effort for no technical gain. It would > be simpler and easier to just stick with IcedTea. But that does > make OpenJDK 6 a bit pointless, to be frank. I think we'll have to agree to differ on that question. Andrew. From gnu.andrew at redhat.com Thu Mar 14 08:46:56 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 11:46:56 -0400 (EDT) Subject: [rfc] backport of fix for bug 7197906 In-Reply-To: <5141E842.5060103@redhat.com> Message-ID: <480171950.18811697.1363276016024.JavaMail.root@redhat.com> ----- Original Message ----- > Hi! > > I would like to backport this fix > http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/ for bug > 7197906 to jdk6. > I applied with small offset, was build, and is working fine. > > The webrev of applied patch can be found here: > http://jvanek.fedorapeople.org/oracle/jdk6/hs/ > > > J. > This looks fine; it's the same change in both webrevs. You don't seem to have an OpenJDK account. I can commit this on your behalf, but I see no reason why you wouldn't be classed as a contributor (http://openjdk.java.net/bylaws#contributor) and given at least author status on this project. I suggest contacting registrar at openjdk.java.net to find out how to obtain an account for future patches. FYI, it's worth including the "webrev" on the end of the URL so it goes straight to the right page: http://jvanek.fedorapeople.org/oracle/jdk6/hs/webrev/ Thanks for your contribution, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 09:00:04 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 12:00:04 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <5141E9BC.406@redhat.com> Message-ID: <843655731.18837982.1363276804634.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/14/2013 02:44 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 03/13/2013 07:47 PM, Andrew Hughes wrote: > >>> ----- Original Message ----- > >>>> Oracle ended public updates of JDK6 at the end of last month. > >>>> Many > >>>> people seem to have concluded that the OpenJDK6 project will > >>>> therefore > >>>> end at the same time. This is incorrect: OpenJDK6 will > >>>> continue, > >>>> but > >>>> will be maintained by the community outside Oracle. > >>> > >>> 1. Oracle had three main roles in relation to OpenJDK 6; acting > >>> as > >>> gatekeeper over which patches were accepted into the repository, > >>> providing security updates and making releases. The third of > >>> these > >>> doesn't seem to be addressed above. Will new releases of OpenJDK > >>> 6 > >>> be made? IcedTea for OpenJDK 6 uses release tarballs as a base > >>> so, > >>> unless there are further releases, none of the changes made > >>> upstream > >>> in OpenJDK 6 will be consumed by IcedTea downstream. I believe > >>> we > >>> are already overdue a new release as there is no release of > >>> OpenJDK > >>> 6 containing the last three sets of security updates. > >> > >> Indeed, we need to make a new release of OpenJDK 6 with the > >> security > >> patches. There may be infrastructure issues here as we don't > >> AFAIK > >> have access to Oracle servers on which to place release tarballs. > >> Or > >> do we? > > > > Not as far as I know, but I don't see how it matters where they are > > located, > > as long as people are notified of the location. > > > > I'm more concerned that they happen promptly and tarballs are > > produced with > > the same form and contents. Hopefully, there is some obscure > > Makefile target > > that creates them but I'm not aware of it offhand. > > OK. > > >>> 2. What many people actually see as OpenJDK 6 at present, in the > >>> form of their GNU/Linux distribution package, is actually IcedTea > >>> for OpenJDK 6. Unlike 7, where the changes in IcedTea are just > >>> to > >>> make it "distro-ready" (using system libraries, etc.), there are > >>> now so many backports and other fixes local to IcedTea 6 that it > >>> is effectively a different beast altogether. Will OpenJDK 6 be > >>> open to accepting some of these fixes, many of which were added > >>> to > >>> the proprietary version of JDK 6 maintained by Oracle a long time > >>> ago, so the two can eventually be in sync? > >> > >> That would, in my view, be a huge waste of effort. It also risks > >> breaking things for no net gain. > > > > The gain would be to shift the focus from IcedTea6 to OpenJDK6. > > Pretty much no-one uses OpenJDK6 directly, as far as I'm aware. > > All > > the distro packages I've seen use IcedTea6 to build it with these > > patches applied. When I last tried OpenJDK6, I had to push four > > changesets upstream just to get it to build on a modern system. > > > > If things were broken with these patches, we'd surely know about it > > because everyone using OpenJDK 6 packages is using them with these > > patches. > > > > I agree it's a lot of wasted effort for no technical gain. It > > would > > be simpler and easier to just stick with IcedTea. But that does > > make OpenJDK 6 a bit pointless, to be frank. > > I think we'll have to agree to differ on that question. > Ok. Maybe you could explain what kind of changes you do foresee going into OpenJDK? Changes from IcedTea6 were proceeding upstream under Oracle's leadership (albeit very slowly) and your original e-mail suggested the acceptance policy, in general, wouldn't be changing. > Andrew. > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Thu Mar 14 09:05:37 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 12:05:37 -0400 Subject: Testing changesets with OpenJDK6 bug ids Message-ID: <5141F551.9000707@redhat.com> Hi, I have just pushed changesets [1] that will allow us to use bug ids from the OpenJDK6 JIRA [2] when pushing to the jdk6 forest. I would like to make sure that this is in fact, working. The attached patch (sorry, webrev is not playing nice with me today) is a NOP change that adds and removes a file from jdk6/hotspot repo to verify that the commits are working. Andrew, can I list you as a reviewer? Kelly suggested that _only_ bug ids from the OpenJDK6 JIRA should be used once we switch over. Does this sounds sensible to others? Any other suggestions to avoid confusion about where to look for more information on a bug. Any suggestions, thoughts or comments? Thanks, Omair [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0d99d61882b7 [1] http://java.net/jira/browse/OPENJDK6 -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -------------- next part -------------- A non-text attachment was scrubbed... Name: test.patch Type: text/x-patch Size: 826 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20130314/b8d0e826/test.patch From martinrb at google.com Thu Mar 14 09:35:06 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Mar 2013 09:35:06 -0700 Subject: The future of OpenJDK6 In-Reply-To: <5141BF43.5010204@gmail.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> Message-ID: On Thu, Mar 14, 2013 at 5:14 AM, Alex Kasko wrote: > >> >> Almost nothing would persuade me to accept 2). This is an internal >> method that no application should use. >> > Not arguing, just for your information, situation happened to me some > weeks ago. > My teammate C++ programmer with little java knowledge was working on > Snappy [1] compatibility with C++ streams. He wanted to build Snappy on his > Linux box using openjdk6 from packets and was not able to do it - got > NoSuchMethodError. At the same time it compiles fine with later versions of > Oracle JDK6. Yes, this Snappy implementation uses undocumented API (for > optimization purposes) and it has fallback implementation and will run on > openjdk6. But it cannot be compiled with default java6 in Linux without > downloading Oracle JDK6 and this caused some frustration. > Also sun.misc.Unsafe usage is quite popular for specific optimizations, > I've even seen it once in java job position requirements (as additional > point). > I also think that this change (adding a missing method to Unsafe) is a perfectly reasonable thing to add to openjdk6. It is a performance+stability improvement, with a low likelihood of breakage (unlike updating to javac7, which *intentionally* will break some builds). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20130314/f346ff5c/attachment.html From alex.kasko.lists at gmail.com Thu Mar 14 09:42:33 2013 From: alex.kasko.lists at gmail.com (Alex Kasko) Date: Thu, 14 Mar 2013 20:42:33 +0400 Subject: The future of OpenJDK6 In-Reply-To: <5141E85D.60702@redhat.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> <5141E85D.60702@redhat.com> Message-ID: <5141FDF9.8010208@gmail.com> On 03/14/2013 07:10 PM, Andrew Haley wrote: > On 03/14/2013 12:14 PM, Alex Kasko wrote: >> On 03/14/2013 01:18 PM, Andrew Haley wrote: >>> On 03/13/2013 09:14 PM, Alex Kasko wrote: >>>> On 03/13/2013 09:02 PM, Andrew Haley wrote: >>>>> >>>>> OpenJDK 6 is a legacy project. People only use it because they want >>>>> long-term stability and compatibility. Therefore, only changes that >>>>> fix significant bugs should be made. This is not a policy change from >>>>> that discussed on http://openjdk.java.net/projects/jdk6/ >>>> >>>> Question about two features, that are not bugfixes, but may be useful in >>>> jdk6: >>>> >>>> 1) unlimited crypto support: >>>> - makefile patch from jdk7 [1] >>>> - maillist thread [2] >>>> >>>> 2) missed copyMemory method in sun.misc.Unsafe: >>>> - maillist thread [3] >>>> - patch that I'm using in my local jdk6 builds [4] >>>> - original patch that removed proper copyMemory method [5] >>>> >>>> Are there any chances for them to be included into jdk6? >>> >>> I would strongly prefer it if neither of these patches went in, but I >>> am open to argument. >> >> I'm OK with it, I'm maintaining public windows builds of openjdk6 and >> going to add these patches into my next build anyway (so I've asked >> about them). >> >>> Almost nothing would persuade me to accept 2). This is an internal >>> method that no application should use. >> >> Not arguing, just for your information, situation happened to me some >> weeks ago. >> My teammate C++ programmer with little java knowledge was working on >> Snappy [1] compatibility with C++ streams. He wanted to build Snappy on >> his Linux box using openjdk6 from packets and was not able to do it - >> got NoSuchMethodError. At the same time it compiles fine with later >> versions of Oracle JDK6. Yes, this Snappy implementation uses >> undocumented API (for optimization purposes) and it has fallback >> implementation and will run on openjdk6. But it cannot be compiled with >> default java6 in Linux without downloading Oracle JDK6 and this caused >> some frustration. > > Ah, that is a pain. Maybe I'm starting to persuade myself this should > go in. > > The right way for upstream to handle this would be so use reflection > to probe for the method in question: then this program wouldn't have > any problems. I'm sorry, I mistakenly said about NoSuchMethodError. It was compilation error: copyMemory(long,long,long) in sun.misc.Unsafe cannot be applied to (byte[],long,byte[],long,int) . Snappy uses reflection to load classes that depends on sun.misc.Unsafe [1] and checks for proper copyMemory availability [2] and uses fallback implementation otherwise. So it runs fine (maybe somewhat slower) on openjdk6, but cannot be compiled with it (without explicit exclusion of some sources). > But if upstream won't do that, I'll accept a patch that > re- enables copyMemory. The code part of the patch (without comments) is: - public native void copyMemory(long srcAddress, long destAddress, long bytes); + public native void copyMemory(Object srcBase, long srcOffset, Object destBase, long destOffset, long bytes); + public void copyMemory(long srcAddress, long destAddress, long bytes) { + copyMemory(null, srcAddress, null, destAddress, bytes); + } I can prepare webrev/OCA if necessary. > >> Also sun.misc.Unsafe usage is quite popular for specific optimizations, >> I've even seen it once in java job position requirements (as additional >> point). > > Good lord. Unsafe is probably going to disappear from view when > modularization happens, so people had better get used to its absence. > > Andrew. > > [1] https://github.com/dain/snappy/blob/e1fd96830b86df6c2e2874628373d9a644498ced/src/main/java/org/iq80/snappy/SnappyInternalUtils.java#L28 [2] https://github.com/dain/snappy/blob/01f0a37ca40196e08336532ea6d328eb3ed22b67/src/main/java/org/iq80/snappy/UnsafeMemory.java#L28 -- Regards, Alex Kasko From jeroen at sumatra.nl Thu Mar 14 09:47:54 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Thu, 14 Mar 2013 16:47:54 +0000 Subject: The future of OpenJDK6 In-Reply-To: <5141E85D.60702@redhat.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> <5141E85D.60702@redhat.com> Message-ID: Andrew Haley wrote: > Good lord. Unsafe is probably going to disappear from view when > modularization happens, so people had better get used to its absence. I desperately hope so, but it is probably not realistic given how many high profile frameworks use it. Regards, Jeroen From gnu.andrew at redhat.com Thu Mar 14 10:01:57 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 13:01:57 -0400 (EDT) Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <5141F551.9000707@redhat.com> Message-ID: <504042289.18925240.1363280517044.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > I have just pushed changesets [1] that will allow us to use bug ids > from > the OpenJDK6 JIRA [2] when pushing to the jdk6 forest. > > I would like to make sure that this is in fact, working. The attached > patch (sorry, webrev is not playing nice with me today) is a NOP > change > that adds and removes a file from jdk6/hotspot repo to verify that > the > commits are working. > > Andrew, can I list you as a reviewer? > I don't see any problem with the patches as a test and you can list me as reviewer too if you wish. Wouldn't it be better to use some leading zeros in the bug ID with a view to future formatting? i.e. 000001 rather than just 1? > Kelly suggested that _only_ bug ids from the OpenJDK6 JIRA should be > used once we switch over. Does this sounds sensible to others? Any > other > suggestions to avoid confusion about where to look for more > information > on a bug. > I don't see how this would work. In fact, it'll already be broken by the patch I approved for Jiri. Most of the patches are going to be backports with Oracle bug IDs. I don't see many cases where you'd commit something ONLY to 6 and not 7 or 8. I wonder if it's worth having an identifier at the front to separate the bug IDs from the purely numerical Oracle ones? So maybe OJ0001 or OJ60001 though that looks a bit ugly... > Any suggestions, thoughts or comments? > > Thanks, > Omair > > [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0d99d61882b7 > [1] http://java.net/jira/browse/OPENJDK6 > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 10:03:40 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 13:03:40 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: Message-ID: <965953070.18925746.1363280620244.JavaMail.root@redhat.com> ----- Original Message ----- > > > > On Thu, Mar 14, 2013 at 5:14 AM, Alex Kasko < > alex.kasko.lists at gmail.com > wrote: > > > > > > > > Almost nothing would persuade me to accept 2). This is an internal > method that no application should use. > Not arguing, just for your information, situation happened to me some > weeks ago. > My teammate C++ programmer with little java knowledge was working on > Snappy [1] compatibility with C++ streams. He wanted to build Snappy > on his Linux box using openjdk6 from packets and was not able to do > it - got NoSuchMethodError. At the same time it compiles fine with > later versions of Oracle JDK6. Yes, this Snappy implementation uses > undocumented API (for optimization purposes) and it has fallback > implementation and will run on openjdk6. But it cannot be compiled > with default java6 in Linux without downloading Oracle JDK6 and this > caused some frustration. > Also sun.misc.Unsafe usage is quite popular for specific > optimizations, I've even seen it once in java job position > requirements (as additional point). > > > > I also think that this change (adding a missing method to Unsafe) is > a perfectly reasonable thing to add to openjdk6. It is a > performance+stability improvement, with a low likelihood of breakage > (unlike updating to javac7, which *intentionally* will break some > builds). That was my thought on this patch when it was originally posted for review. As to javac7... I was just testing the waters and I take the hint ;) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From joe.darcy at oracle.com Thu Mar 14 10:23:00 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 14 Mar 2013 10:23:00 -0700 Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <504042289.18925240.1363280517044.JavaMail.root@redhat.com> References: <504042289.18925240.1363280517044.JavaMail.root@redhat.com> Message-ID: <51420774.8080609@oracle.com> On 3/14/2013 10:01 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi, >> >> I have just pushed changesets [1] that will allow us to use bug ids >> from >> the OpenJDK6 JIRA [2] when pushing to the jdk6 forest. >> >> I would like to make sure that this is in fact, working. The attached >> patch (sorry, webrev is not playing nice with me today) is a NOP >> change >> that adds and removes a file from jdk6/hotspot repo to verify that >> the >> commits are working. >> >> Andrew, can I list you as a reviewer? >> > I don't see any problem with the patches as a test and you can list me > as reviewer too if you wish. > > Wouldn't it be better to use some leading zeros in the bug ID with a > view to future formatting? i.e. 000001 rather than just 1? > >> Kelly suggested that _only_ bug ids from the OpenJDK6 JIRA should be >> used once we switch over. Does this sounds sensible to others? Any >> other >> suggestions to avoid confusion about where to look for more >> information >> on a bug. >> > I don't see how this would work. In fact, it'll already be broken by > the patch I approved for Jiri. Most of the patches are going to be > backports with Oracle bug IDs. I don't see many cases where you'd > commit something ONLY to 6 and not 7 or 8. > > I wonder if it's worth having an identifier at the front to separate > the bug IDs from the purely numerical Oracle ones? So maybe OJ0001 > or OJ60001 though that looks a bit ugly... > > If you want to stick with just numbers, there are numerical ranges that will not conflict with any Sun/Oracle bug such as 3xxxxxx. (If you have sufficient configuration control over your JIRA instance, you can set the starting bud id.) You could also use the full JIRA id of your bugs, $PROJNAME-NUMBER. -Joe From omajid at redhat.com Thu Mar 14 10:51:29 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 13:51:29 -0400 Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <51420774.8080609@oracle.com> References: <504042289.18925240.1363280517044.JavaMail.root@redhat.com> <51420774.8080609@oracle.com> Message-ID: <51420E21.20901@redhat.com> On 03/14/2013 01:23 PM, Joe Darcy wrote: > If you want to stick with just numbers, there are numerical ranges that > will not conflict with any Sun/Oracle bug such as 3xxxxxx. (If you have > sufficient configuration control over your JIRA instance, you can set > the starting bud id.) Kelly also suggested this (except with 99xxxxx, so we could, if we really wanted to, fold these bugs into the OpenJDK JIRA when it becomes public). The admins at java.net informed me that this is is not possible for the JIRA instance at http://java.net/jira/browse/OPENJDK6 :( > You could also use the full JIRA id of your bugs, > $PROJNAME-NUMBER. That sounds perfectly good to me. I wonder if others have any concerns about this? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From joe.darcy at oracle.com Thu Mar 14 10:55:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 14 Mar 2013 10:55:36 -0700 Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <51420E21.20901@redhat.com> References: <504042289.18925240.1363280517044.JavaMail.root@redhat.com> <51420774.8080609@oracle.com> <51420E21.20901@redhat.com> Message-ID: <51420F18.2060000@oracle.com> On 3/14/2013 10:51 AM, Omair Majid wrote: > On 03/14/2013 01:23 PM, Joe Darcy wrote: >> If you want to stick with just numbers, there are numerical ranges that >> will not conflict with any Sun/Oracle bug such as 3xxxxxx. (If you have >> sufficient configuration control over your JIRA instance, you can set >> the starting bud id.) > Kelly also suggested this (except with 99xxxxx, so we could, if we > really wanted to, fold these bugs into the OpenJDK JIRA when it becomes > public). FYI, it is not feasible to preserve bug ids on import into the OpenJDK JIRA anymore. That capability was lost after we did the bulk import of the Sun bugtraq bugs and started issuing new bug ids. -Joe From gnu.andrew at redhat.com Thu Mar 14 11:41:13 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 14:41:13 -0400 (EDT) Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <51420E21.20901@redhat.com> Message-ID: <2111935.18983008.1363286473261.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/14/2013 01:23 PM, Joe Darcy wrote: > > If you want to stick with just numbers, there are numerical ranges > > that > > will not conflict with any Sun/Oracle bug such as 3xxxxxx. (If you > > have > > sufficient configuration control over your JIRA instance, you can > > set > > the starting bud id.) > > Kelly also suggested this (except with 99xxxxx, so we could, if we > really wanted to, fold these bugs into the OpenJDK JIRA when it > becomes > public). The admins at java.net informed me that this is is not > possible > for the JIRA instance at http://java.net/jira/browse/OPENJDK6 :( > > > You could also use the full JIRA id of your bugs, > > $PROJNAME-NUMBER. > > That sounds perfectly good to me. I wonder if others have any > concerns > about this? > Fine by me. I'm more concerned about this idea of not allowing the use of Oracle bug IDs. > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 11:41:46 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 14:41:46 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <514166E7.9060905@oracle.com> Message-ID: <579810853.18983086.1363286506166.JavaMail.root@redhat.com> ----- Original Message ----- > Removing discuss at openjdk.java.net from the distribution list. > > > On 3/13/2013 8:25 PM, Martin Buchholz wrote: > > > > Our experience at Google has been that javac7 is a stricter compiler > than javac6. It is a significant effort migrating from javac6 to > javac7 with a large code base. Since openjdk6 is all about > stability, I would resist updating the javac in openjdk6. Some of > the "bugs" in javac6 allow user code to compile successfully! > The command > > $JDK7/bin/javac -source 6 -target 6 -bootclasspath $JDK7-RT.JAR > > > should be a fine Java SE 6 compiler, but I'm not surprised Martin and > company have found that it is stricter than the compilers shipped in > JDK 6, besides the Project Coin features, lots of fixes went into > JDK 7 too. If one can abide the stricter checks, the JDK 7 series > compiler offers much improved error messages in some cases. > > For the consideration of the current managers of OpenJDK 6, I've gone > through the JDK bug database and found bug fixes applied to the JDK > 7/7 update and 6 update trains but *not* to OpenJDK 6; the list is > below. (These fixes date from after my time as OpenJDK 6 release > manager; I stepped down in February 2011 and 6u27 was released in > August 2011.) > > 6u27 JDK-6718364 inference fails when a generic method is invoked > with raw arguments > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/30a415f8667f > > 6u30 JDK-6682380 Foreach loop with generics inside finally block > crashes javac with -target 1.5 > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ec29a1a284ca > > 6u30 JDK-7046929 tools/javac/api/T6397104.java fails > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/592c30109bbe > > 6u30 JDK-7024568 Very long method resolution causing OOM error > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/74f0c05c51eb > > 6u32 JDK-7003595 IncompatibleClassChangeError with unreferenced local > class with subclass > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/41a303cb946e > > 6u34 JDK-6500343 compiler generates bad code when translating > conditional expressions > http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ddd110646d21 > Many thanks Joe!!! This is excellent. > Cheers, > > -Joe > > > > > > > > On Wed, Mar 13, 2013 at 1:47 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com > wrote: > > > > On 03/13/2013 12:47 PM, Andrew Hughes wrote: > > > 4. Finally, this is just a thought, and I realise it may run contrary > to your > promise of long-term stability and compatibility, but I've been > giving some thought > to the long running issues we've had with javac in OpenJDK 6. For > those who are > unaware, the javac in OpenJDK 6 is not the same as in Oracle's > proprietary JDK 6, > but rather an early development version of the one used in OpenJDK 7. > I've been > wondering if the best way of supporting this long-term would be to > use the tools > from 7 in OpenJDK 6, with appropriate reversions to make it > compatible with 6 > (defaulting to 6 source/target, having builds pass the 6 TCK), rather > than continuing > to maintain the hybrid we have now. This would also mean we'd be able > to benefit > more directly from any bug fixes or security updates directed at the > langtools > present in 7. > > You might want to bring this up on compiler-dev. > > -- Jon > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Thu Mar 14 18:56:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 11:56:46 +1000 Subject: [rfc] backport of fix for bug 7197906 In-Reply-To: <480171950.18811697.1363276016024.JavaMail.root@redhat.com> References: <480171950.18811697.1363276016024.JavaMail.root@redhat.com> Message-ID: <51427FDE.5040404@oracle.com> On 15/03/2013 1:46 AM, Andrew Hughes wrote: > You don't seem to have an OpenJDK account. I can commit this on > your behalf, but I see no reason why you wouldn't be classed > as a contributor (http://openjdk.java.net/bylaws#contributor) and > given at least author status on this project. > > I suggest contacting registrar at openjdk.java.net to find out how > to obtain an account for future patches. Please see "Becoming an Author" on http://openjdk.java.net/projects/ David ----- > FYI, it's worth including the "webrev" on the end of the URL so > it goes straight to the right page: > > http://jvanek.fedorapeople.org/oracle/jdk6/hs/webrev/ > > Thanks for your contribution, > From david.holmes at oracle.com Thu Mar 14 19:02:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 12:02:49 +1000 Subject: The future of OpenJDK6 In-Reply-To: References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> <5141E85D.60702@redhat.com> Message-ID: <51428149.8000301@oracle.com> Going OT somewhat ... On 15/03/2013 2:47 AM, Jeroen Frijters wrote: > Andrew Haley wrote: >> Good lord. Unsafe is probably going to disappear from view when >> modularization happens, so people had better get used to its absence. > > I desperately hope so, but it is probably not realistic given how many high profile frameworks use it. Unsafe will never go from OpenJDK6, 7 or 8. In a modular world the relevant API's will need to be promoted to full supported status. Cheers, David > Regards, > Jeroen > From gnu.andrew at redhat.com Thu Mar 14 20:51:08 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 23:51:08 -0400 (EDT) Subject: [rfc] backport of fix for bug 7197906 In-Reply-To: <51427FDE.5040404@oracle.com> Message-ID: <2037363342.19119544.1363319468965.JavaMail.root@redhat.com> ----- Original Message ----- > On 15/03/2013 1:46 AM, Andrew Hughes wrote: > > You don't seem to have an OpenJDK account. I can commit this on > > your behalf, but I see no reason why you wouldn't be classed > > as a contributor (http://openjdk.java.net/bylaws#contributor) and > > given at least author status on this project. > > > > I suggest contacting registrar at openjdk.java.net to find out how > > to obtain an account for future patches. > > Please see "Becoming an Author" on > > http://openjdk.java.net/projects/ > This is great. Thanks. I wasn't aware of this. > David > ----- > > > FYI, it's worth including the "webrev" on the end of the URL so > > it goes straight to the right page: > > > > http://jvanek.fedorapeople.org/oracle/jdk6/hs/webrev/ > > > > Thanks for your contribution, > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Fri Mar 15 01:53:30 2013 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Mar 2013 08:53:30 +0000 Subject: The future of OpenJDK6 In-Reply-To: <51428149.8000301@oracle.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> <5141E85D.60702@redhat.com> <51428149.8000301@oracle.com> Message-ID: <5142E18A.4030201@redhat.com> On 03/15/2013 02:02 AM, David Holmes wrote: > Going OT somewhat ... > > On 15/03/2013 2:47 AM, Jeroen Frijters wrote: >> Andrew Haley wrote: >>> Good lord. Unsafe is probably going to disappear from view when >>> modularization happens, so people had better get used to its absence. >> >> I desperately hope so, but it is probably not realistic given how many high profile frameworks use it. > > Unsafe will never go from OpenJDK6, 7 or 8. In a modular world the > relevant API's will need to be promoted to full supported status. Fully supported? How? Unsafe interacts with the VM in somewhat unpredictable ways by doing things underneath its feet. In order for this API to be supported we'd have to define what it actually does in terms of the JMM. I guess we could simply say that all of the, er, interesting cases are UB, in which case supporting it becomes easy. Andrew. From aph at redhat.com Fri Mar 15 02:17:35 2013 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Mar 2013 09:17:35 +0000 Subject: The future of OpenJDK6 In-Reply-To: <843655731.18837982.1363276804634.JavaMail.root@redhat.com> References: <843655731.18837982.1363276804634.JavaMail.root@redhat.com> Message-ID: <5142E72F.3020304@redhat.com> On 03/14/2013 04:00 PM, Andrew Hughes wrote: > > Ok. Maybe you could explain what kind of changes you do foresee going > into OpenJDK? Changes from IcedTea6 were proceeding upstream > under Oracle's leadership (albeit very slowly) and your original e-mail > suggested the acceptance policy, in general, wouldn't be changing. I think I've already stated what kind of changes I forsee going into OpenJDK 6. It's explained quite well on the JDK 6 Project page. If an IcedTea6 patch qualifies under those criteria then it can be considered, but because stability is the primary concern there is necessarily a high bar. Andrew. From david.holmes at oracle.com Fri Mar 15 04:07:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 21:07:25 +1000 Subject: The future of OpenJDK6 In-Reply-To: <5142E18A.4030201@redhat.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> <5141E85D.60702@redhat.com> <51428149.8000301@oracle.com> <5142E18A.4030201@redhat.com> Message-ID: <514300ED.4060605@oracle.com> On 15/03/2013 6:53 PM, Andrew Haley wrote: > On 03/15/2013 02:02 AM, David Holmes wrote: >> Going OT somewhat ... >> >> On 15/03/2013 2:47 AM, Jeroen Frijters wrote: >>> Andrew Haley wrote: >>>> Good lord. Unsafe is probably going to disappear from view when >>>> modularization happens, so people had better get used to its absence. >>> >>> I desperately hope so, but it is probably not realistic given how many high profile frameworks use it. >> >> Unsafe will never go from OpenJDK6, 7 or 8. In a modular world the >> relevant API's will need to be promoted to full supported status. > > Fully supported? How? Unsafe interacts with the VM in somewhat > unpredictable ways by doing things underneath its feet. In order for > this API to be supported we'd have to define what it actually does in > terms of the JMM. A lot of the "unsafe" API's are quite predictable if used in the intended way - they are afterall used by the core libraries themselves (atomic ops and volatile ops as key examples). Obviously anything actually "unsafe" must be exposed only in a safe manner or else not exposed (like the direct memory pokes). In some cases that may negate the performance benefits that direct use of Unsafe has. These are the challenges to be addressed. David ----- I guess we could simply say that all of the, er, > interesting cases are UB, in which case supporting it becomes easy. > > Andrew. > From jvanek at redhat.com Fri Mar 15 07:19:21 2013 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 15 Mar 2013 15:19:21 +0100 Subject: [rfc] backport of fix for bug 7197906 In-Reply-To: <2037363342.19119544.1363319468965.JavaMail.root@redhat.com> References: <2037363342.19119544.1363319468965.JavaMail.root@redhat.com> Message-ID: <51432DE9.7010300@redhat.com> On 03/15/2013 04:51 AM, Andrew Hughes wrote: > ----- Original Message ----- >> On 15/03/2013 1:46 AM, Andrew Hughes wrote: >>> You don't seem to have an OpenJDK account. I can commit this on >>> your behalf, but I see no reason why you wouldn't be classed >>> as a contributor (http://openjdk.java.net/bylaws#contributor) and >>> given at least author status on this project. >>> >>> I suggest contacting registrar at openjdk.java.net to find out how >>> to obtain an account for future patches. >> >> Please see "Becoming an Author" on >> >> http://openjdk.java.net/projects/ >> Reading above I don't Think I have fulfil all the prerequisites - as this is my second contribution to openjdk directly (and first one is still not approved) and icedteas do not count;) So can you please push? Thank you for review and hints! J. > > This is great. Thanks. I wasn't aware of this. > >> >>> FYI, it's worth including the "webrev" on the end of the URL so >>> it goes straight to the right page: >>> >>> http://jvanek.fedorapeople.org/oracle/jdk6/hs/webrev/ >>> >>> Thanks for your contribution, >>> >> > From gnu.andrew at redhat.com Mon Mar 18 09:42:30 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 18 Mar 2013 12:42:30 -0400 (EDT) Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <5141F551.9000707@redhat.com> Message-ID: <1214785297.20422818.1363624950092.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > I have just pushed changesets [1] that will allow us to use bug ids > from > the OpenJDK6 JIRA [2] when pushing to the jdk6 forest. > > I would like to make sure that this is in fact, working. The attached > patch (sorry, webrev is not playing nice with me today) is a NOP > change > that adds and removes a file from jdk6/hotspot repo to verify that > the > commits are working. > > Andrew, can I list you as a reviewer? > > Kelly suggested that _only_ bug ids from the OpenJDK6 JIRA should be > used once we switch over. Does this sounds sensible to others? Any > other > suggestions to avoid confusion about where to look for more > information > on a bug. > > Any suggestions, thoughts or comments? > > Thanks, > Omair > > [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0d99d61882b7 > [1] http://java.net/jira/browse/OPENJDK6 > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > With respect to the JIRA, even as a logged-in java.net user, I get: PERMISSION VIOLATION ERROR It seems that you have tried to perform an operation which you are not permitted to perform. If you think this message is wrong, please consult your administrators about getting the necessary permissions. The Oracle bug database this is replacing had viewable bugs without any login necessary. Can we please have the same for this JIRA? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Mon Mar 18 09:41:04 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 18 Mar 2013 12:41:04 -0400 (EDT) Subject: [rfc] backport of fix for bug 7197906 In-Reply-To: <51432DE9.7010300@redhat.com> Message-ID: <1750596491.20422242.1363624864628.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/15/2013 04:51 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 15/03/2013 1:46 AM, Andrew Hughes wrote: > >>> You don't seem to have an OpenJDK account. I can commit this on > >>> your behalf, but I see no reason why you wouldn't be classed > >>> as a contributor (http://openjdk.java.net/bylaws#contributor) and > >>> given at least author status on this project. > >>> > >>> I suggest contacting registrar at openjdk.java.net to find out how > >>> to obtain an account for future patches. > >> > >> Please see "Becoming an Author" on > >> > >> http://openjdk.java.net/projects/ > >> > > Reading above I don't Think I have fulfil all the prerequisites - > as this is my second contribution to openjdk directly (and first one > is still not approved) and icedteas do not count;) > Yes, I was thinking of contributor not author. > So can you please push? > Sure. > Thank you for review and hints! > > > J. > > > > > > This is great. Thanks. I wasn't aware of this. > > > >> > >>> FYI, it's worth including the "webrev" on the end of the URL so > >>> it goes straight to the right page: > >>> > >>> http://jvanek.fedorapeople.org/oracle/jdk6/hs/webrev/ > >>> > >>> Thanks for your contribution, > >>> > >> > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Mon Mar 18 10:53:20 2013 From: omajid at redhat.com (Omair Majid) Date: Mon, 18 Mar 2013 13:53:20 -0400 Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <1214785297.20422818.1363624950092.JavaMail.root@redhat.com> References: <1214785297.20422818.1363624950092.JavaMail.root@redhat.com> Message-ID: <51475490.2080200@redhat.com> On 03/18/2013 12:42 PM, Andrew Hughes wrote: > The Oracle bug database this is replacing had viewable bugs without > any login necessary. Can we please have the same for this JIRA? I dug through the docs on java.net and they indicate that this should already be the default. I have sent a request to the admins of the JIRA instance to sort this out. I will update you when I hear back from them. Sorry about this. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Mon Mar 18 11:06:13 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 18 Mar 2013 14:06:13 -0400 (EDT) Subject: Testing changesets with OpenJDK6 bug ids In-Reply-To: <51475490.2080200@redhat.com> Message-ID: <997179100.20471202.1363629973795.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/18/2013 12:42 PM, Andrew Hughes wrote: > > The Oracle bug database this is replacing had viewable bugs without > > any login necessary. Can we please have the same for this JIRA? > > I dug through the docs on java.net and they indicate that this should > already be the default. I have sent a request to the admins of the > JIRA > instance to sort this out. I will update you when I hear back from > them. > > Sorry about this. > It's ok, not your fault by the sound of it. I do actually have a OpenJDK6-only bug we can test this with :-) (the proper fix for 7017193 by just adding free: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html) > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Wed Mar 20 03:17:24 2013 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Mar 2013 10:17:24 +0000 Subject: The future of OpenJDK6 In-Reply-To: <5141FDF9.8010208@gmail.com> References: <5140B125.5030605@redhat.com> <5140EC2C.4070703@gmail.com> <514195DD.6020202@redhat.com> <5141BF43.5010204@gmail.com> <5141E85D.60702@redhat.com> <5141FDF9.8010208@gmail.com> Message-ID: <51498CB4.5040200@redhat.com> On 03/14/2013 04:42 PM, Alex Kasko wrote: >> > But if upstream won't do that, I'll accept a patch that >> > re- enables copyMemory. > The code part of the patch (without comments) is: > > - public native void copyMemory(long srcAddress, long destAddress, > long bytes); > + public native void copyMemory(Object srcBase, long srcOffset, > Object destBase, long destOffset, long bytes); > + public void copyMemory(long srcAddress, long destAddress, long > bytes) { > + copyMemory(null, srcAddress, null, destAddress, bytes); > + } > > I can prepare webrev/OCA if necessary. Please do, or maybe someone who is already an OpenJDK 6 committer can prepare one. Andrew. From gnu.andrew at redhat.com Wed Mar 20 07:28:47 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Mar 2013 10:28:47 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <51498CB4.5040200@redhat.com> Message-ID: <517733369.21776485.1363789727251.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/14/2013 04:42 PM, Alex Kasko wrote: > >> > But if upstream won't do that, I'll accept a patch that > >> > re- enables copyMemory. > > The code part of the patch (without comments) is: > > > > - public native void copyMemory(long srcAddress, long > > destAddress, > > long bytes); > > + public native void copyMemory(Object srcBase, long srcOffset, > > Object destBase, long destOffset, long bytes); > > + public void copyMemory(long srcAddress, long destAddress, > > long > > bytes) { > > + copyMemory(null, srcAddress, null, destAddress, bytes); > > + } > > > > I can prepare webrev/OCA if necessary. > > Please do, or maybe someone who is already an OpenJDK 6 committer can > prepare one. > > Andrew. > > > http://cr.openjdk.java.net/~andrew/jdk6/copymemory/webrev.01/ The patched version of OpenJDK6 can build Snappy. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Wed Mar 20 07:42:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Mar 2013 14:42:56 +0000 Subject: The future of OpenJDK6 In-Reply-To: <517733369.21776485.1363789727251.JavaMail.root@redhat.com> References: <517733369.21776485.1363789727251.JavaMail.root@redhat.com> Message-ID: <5149CAF0.6090607@oracle.com> On 20/03/2013 14:28, Andrew Hughes wrote: > : > http://cr.openjdk.java.net/~andrew/jdk6/copymemory/webrev.01/ > > The patched version of OpenJDK6 can build Snappy. I wonder if the @since should be changed. -Alan From aph at redhat.com Wed Mar 20 10:55:23 2013 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Mar 2013 17:55:23 +0000 Subject: The future of OpenJDK6 In-Reply-To: <517733369.21776485.1363789727251.JavaMail.root@redhat.com> References: <517733369.21776485.1363789727251.JavaMail.root@redhat.com> Message-ID: <5149F80B.70306@redhat.com> On 03/20/2013 02:28 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/jdk6/copymemory/webrev.01/ > > The patched version of OpenJDK6 can build Snappy. That's great, thanks. Andrew. From gnu.andrew at redhat.com Wed Mar 20 11:47:57 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Mar 2013 14:47:57 -0400 (EDT) Subject: The future of OpenJDK6 In-Reply-To: <5149CAF0.6090607@oracle.com> Message-ID: <1330013018.21953652.1363805277189.JavaMail.root@redhat.com> ----- Original Message ----- > On 20/03/2013 14:28, Andrew Hughes wrote: > > : > > http://cr.openjdk.java.net/~andrew/jdk6/copymemory/webrev.01/ > > > > The patched version of OpenJDK6 can build Snappy. > I wonder if the @since should be changed. > > -Alan > I'd be happy to just drop that line. Seemed odd to me too, but I was just making this a straight reversion of the appropriate fragment of: changeset: 2:39e8fe7a0af1 tag: jdk6-b00 user: ohair date: Fri Jan 30 16:05:57 2009 -0800 summary: 6755277: All initial changes to jdk7 to create openjdk 6 build 0 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Wed Mar 20 15:45:45 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Mar 2013 18:45:45 -0400 (EDT) Subject: [PATCH FOR REVIEW] OPENJDK6-3: Fix small memory leak in get_stack_bounds In-Reply-To: <1361454052.22036053.1363819425034.JavaMail.root@redhat.com> Message-ID: <1195069049.22037302.1363819545514.JavaMail.root@redhat.com> A small memory leak was found in get_stack_bounds when getline returned with an error code, but it was fixed in OpenJDK 7 & 8 in a way that introduced worse issues: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008695.html This webrev adds a simpler fix, just adding the necessary free call: http://cr.openjdk.java.net/~andrew/jdk6/03/webrev.01/ I filed a bug for this here: http://java.net/jira/browse/OPENJDK6-3 Ok for OpenJDK 6? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Thu Mar 21 04:52:34 2013 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Mar 2013 11:52:34 +0000 Subject: [PATCH FOR REVIEW] OPENJDK6-3: Fix small memory leak in get_stack_bounds In-Reply-To: <1195069049.22037302.1363819545514.JavaMail.root@redhat.com> References: <1195069049.22037302.1363819545514.JavaMail.root@redhat.com> Message-ID: <514AF482.30704@redhat.com> On 03/20/2013 10:45 PM, Andrew Hughes wrote: > A small memory leak was found in get_stack_bounds when getline returned with an error code, > but it was fixed in OpenJDK 7 & 8 in a way that introduced worse issues: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008695.html > > This webrev adds a simpler fix, just adding the necessary free call: > > http://cr.openjdk.java.net/~andrew/jdk6/03/webrev.01/ > > I filed a bug for this here: http://java.net/jira/browse/OPENJDK6-3 > > Ok for OpenJDK 6? Yes, thanks. I don't know why I missed this one. Andrew. From gnu.andrew at redhat.com Thu Mar 21 06:49:12 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 21 Mar 2013 09:49:12 -0400 (EDT) Subject: [PATCH FOR REVIEW] OPENJDK6-3: Fix small memory leak in get_stack_bounds In-Reply-To: <514AF482.30704@redhat.com> Message-ID: <1365098062.22274565.1363873752958.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/20/2013 10:45 PM, Andrew Hughes wrote: > > A small memory leak was found in get_stack_bounds when getline > > returned with an error code, > > but it was fixed in OpenJDK 7 & 8 in a way that introduced worse > > issues: > > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008695.html > > > > This webrev adds a simpler fix, just adding the necessary free > > call: > > > > http://cr.openjdk.java.net/~andrew/jdk6/03/webrev.01/ > > > > I filed a bug for this here: http://java.net/jira/browse/OPENJDK6-3 > > > > Ok for OpenJDK 6? > > Yes, thanks. I don't know why I missed this one. > > Andrew. > > > Thanks. remote: > OPENJDK6-3: Fix memory leak in get_stack_bounds remote: > Summary: Memory is allocated by getline but not freed if it fails remote: > Reviewed-by: aph remote: remote: Incomplete comment: Missing bugid line remote: Incomplete comment: Missing reviewer attribution remote: Extraneous text in comment Omair? I thought we disabled this? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Thu Mar 21 08:42:59 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Mar 2013 11:42:59 -0400 Subject: [PATCH FOR REVIEW] OPENJDK6-3: Fix small memory leak in get_stack_bounds In-Reply-To: <1365098062.22274565.1363873752958.JavaMail.root@redhat.com> References: <1365098062.22274565.1363873752958.JavaMail.root@redhat.com> Message-ID: <514B2A83.6000804@redhat.com> On 03/21/2013 09:49 AM, Andrew Hughes wrote: > > remote: > OPENJDK6-3: Fix memory leak in get_stack_bounds > remote: > Summary: Memory is allocated by getline but not freed if it fails > remote: > Reviewed-by: aph > remote: > remote: Incomplete comment: Missing bugid line > remote: Incomplete comment: Missing reviewer attribution > remote: Extraneous text in comment > > Omair? I thought we disabled this? > Yes and no. I modified the jcheck configuration so we would accept any numeric bug ids. I hadn't considered using bug ids of the form OPENJDK6-X. Now that I check, "OPENJDK6-X" doesn't work with jcheck. I am trying to fix jcheck to allow this (while enforcing things like Summary/Reviewed-by/Contributed-by). Sorry about this. Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681