Re: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream
Hi Alan, The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null isFree == false so we won't need create a readObject method. Thanks for your suggestion for isFree, I will correct it later. Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. Thanks a lot! On 09/21/2012 04:37 PM, Alan Bateman wrote: On 21/09/2012 04:21, Deven You wrote: Hi Lance, I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. I have create a new webre[1] for this task, please review it. [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ http://cr.openjdk.java.net/%7Eyoudwei/OJDK-576/webrev.01/ PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. Have you considered buf == null to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). A small point is that isFree is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. -Alan.
hg: jdk8/tl/jdk: 8001621: Update awk scripts that check output from jps/jcmd
Changeset: d1ffbdf7e3c6 Author:sla Date: 2012-10-29 09:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1ffbdf7e3c6 8001621: Update awk scripts that check output from jps/jcmd Reviewed-by: alanb ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk
Re: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream
Hi Deven, I will address the needed updates a bit later. Thank you for your input Best Lance On Oct 29, 2012, at 3:51 AM, Deven You wrote: Hi Alan, The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null isFree == false so we won't need create a readObject method. Thanks for your suggestion for isFree, I will correct it later. Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. Thanks a lot! On 09/21/2012 04:37 PM, Alan Bateman wrote: On 21/09/2012 04:21, Deven You wrote: Hi Lance, I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. I have create a new webre[1] for this task, please review it. [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ http://cr.openjdk.java.net/%7Eyoudwei/OJDK-576/webrev.01/ PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. Have you considered buf == null to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). A small point is that isFree is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/corba: 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK.
Changeset: 643e7612cf6d Author:ohrstrom Date: 2012-10-29 14:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/643e7612cf6d 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK. Reviewed-by: alanb, wetmore ! src/share/classes/com/sun/corba/se/impl/util/IdentityHashtable.java + src/share/classes/com/sun/corba/se/impl/util/IdentityHashtableEntry.java
hg: jdk8/tl/jdk: 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK
Changeset: 17384fc6b31f Author:ohrstrom Date: 2012-10-29 14:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17384fc6b31f 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, wetmore + make/tools/src/build/tools/generatenimbus/AbstractGradient.java + make/tools/src/build/tools/generatenimbus/Border.java + make/tools/src/build/tools/generatenimbus/Canvas.java + make/tools/src/build/tools/generatenimbus/ComponentColor.java + make/tools/src/build/tools/generatenimbus/Dimension.java + make/tools/src/build/tools/generatenimbus/Ellipse.java + make/tools/src/build/tools/generatenimbus/Gradient.java + make/tools/src/build/tools/generatenimbus/GradientStop.java + make/tools/src/build/tools/generatenimbus/Insets.java + make/tools/src/build/tools/generatenimbus/Layer.java + make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/Path.java + make/tools/src/build/tools/generatenimbus/Point.java + make/tools/src/build/tools/generatenimbus/RadialGradient.java + make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/Typeface.java + make/tools/src/build/tools/generatenimbus/UIColor.java + make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIFont.java + make/tools/src/build/tools/generatenimbus/UIIconRegion.java + make/tools/src/build/tools/generatenimbus/UIProperty.java + make/tools/src/build/tools/generatenimbus/UIRegion.java + make/tools/src/build/tools/generatenimbus/UIState.java + make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! src/share/classes/javax/management/timer/Timer.java + src/share/classes/javax/management/timer/TimerAlarmClock.java + src/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/share/classes/sun/awt/im/InputMethodManager.java + src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/net/httpserver/Event.java + src/share/classes/sun/net/httpserver/WriteFinishedEvent.java + src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java + src/share/classes/sun/security/ssl/ExtensionType.java + src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java + src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java + src/share/classes/sun/security/ssl/ServerNameExtension.java + src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java + src/share/classes/sun/security/ssl/UnknownExtension.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java + src/solaris/classes/sun/awt/X11/XChoicePeerListener.java + src/solaris/classes/sun/font/DelegateStrike.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java + src/solaris/classes/sun/java2d/jules/TileTrapContainer.java
hg: jdk8/tl/jdk: 8000997: Multiple locale sensitive services cannot be loaded
Changeset: 7fa45c455034 Author:naoto Date: 2012-10-29 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fa45c455034 8000997: Multiple locale sensitive services cannot be loaded Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider
Re: Review/comment needed for the new public java.util.Base64 class
Hi Sherman, can you give me a short answer please? -Ulf Am 23.10.2012 16:57, schrieb Ulf Zibis: Am 23.10.2012 15:04, schrieb Alan Bateman: I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason is that the method name makes it sound like it returns a URLEncoder or or at least an encoder for HTML forms. While more verbose, getBase64UrlEncoder is clear that it returns a base64url encoder. I'm wondering, why there are those get... methods at all. Alternatively you could make the appropriate constructors and predifined static variants public. So one only should use: Base64.Encoder encoder = new Base64.Encoder(...); Base64.Encoder urlEncoder = Base64.Encoder.RFC4648_URLSAFE; No need for those looong method names. -Ulf
RFR: 6594697 - varargs message and Throwable methods for java.util.Logger
Please review http://cr.openjdk.java.net/~jgish/Bug6594697-AddLogThrowable/ http://cr.openjdk.java.net/%7Ejgish/Bug6594697-AddLogThrowable/ This change adds three new methods to Logger that provide a Throwable along with a varags Object list as parameters to the log message. In addition, it makes a small refactoring change to the existing log message to better enable sub-classing of Logger. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
Re: RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration
Jim, The logging deadlock issue is subtle and complex. Do we have a test case that verifies your fix that is deadlock-free? I can't tell for sure but looks like it smells the potential deadlock if Logger.getGlobal() triggers the LogManager class initialization but LogManager.clinit calls Logger.getLogger().setLogManager(). Maybe you already see this - 4994705 may give you some idea of the deadlock problem. Hope this helps. Mandy On 10/24/2012 4:13 PM, Jim Gish wrote: Please review http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/ In JDK7, Logger.global was deprecated because of potential deadlock problems. The method getGlobal() was introduced as a convenience method to get the global logger in lieu of this or calling Logger.getLogger(Logger.GLOBAL_LOGGER_NAME). Unfortunately, this was broken out of the gate. getGlobal() simply used the deprecated static variable global, but this had the result of returning the global logger without initializing the logging system. As a result, simply calling Logger.getGlobal().INFO(msg) does nothing. So much for the convenience of a simple global logger for devs to use ootb without any setup required. This simple fix simply returns Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is called and hence results in proper setup of the logging sytem /and /a working global logger with no assembly required :-) Thanks, Jim
Re: RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration
Hi Mandy, I don't understand your second sentence. Could you please clarify? Thanks, Jim On 10/29/2012 06:05 PM, Mandy Chung wrote: Jim, The logging deadlock issue is subtle and complex. Do we have a test case that verifies your fix that is deadlock-free? I can't tell for sure but looks like it smells the potential deadlock if Logger.getGlobal() triggers the LogManager class initialization but LogManager.clinit calls Logger.getLogger().setLogManager(). Maybe you already see this - 4994705 may give you some idea of the deadlock problem. Hope this helps. Mandy On 10/24/2012 4:13 PM, Jim Gish wrote: Please review http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/ In JDK7, Logger.global was deprecated because of potential deadlock problems. The method getGlobal() was introduced as a convenience method to get the global logger in lieu of this or calling Logger.getLogger(Logger.GLOBAL_LOGGER_NAME). Unfortunately, this was broken out of the gate. getGlobal() simply used the deprecated static variable global, but this had the result of returning the global logger without initializing the logging system. As a result, simply calling Logger.getGlobal().INFO(msg) does nothing. So much for the convenience of a simple global logger for devs to use ootb without any setup required. This simple fix simply returns Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is called and hence results in proper setup of the logging sytem /and /a working global logger with no assembly required :-) Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
hg: jdk8/tl/jdk: 6206780: (str) Forwarding append methods in String{Buffer, Builder} are inconsistent
Changeset: e2f976a73afb
Author:jgish
Date: 2012-10-29 16:51 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2f976a73afb
6206780: (str) Forwarding append methods in String{Buffer,Builder} are
inconsistent
Summary: update StringBuilder StringBuffer to consistently handle forwarding
to AbstractStringBuilder. Some additional cleanup (removal of refs to
sub-classes from AbstractStringBuilder)
Reviewed-by: chegar, alanb, mduigou
! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/StringBuffer.java
! src/share/classes/java/lang/StringBuilder.java
+ test/java/lang/StringBuffer/AppendStringBuilder.java
+ test/java/lang/StringBuffer/BufferForwarding.java
+ test/java/lang/StringBuffer/TestSynchronization.java
+ test/java/lang/StringBuilder/AppendStringBuffer.java
+ test/java/lang/StringBuilder/BuilderForwarding.java
Re: RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration
What I mean is when multiple threads are using j.u.logging and one calls Logger.getGlobal() but the LogManager class initialization is calling Logger.getGlobal(), what will happen? similar to what the LoggingDeadlock.java test does [1]. This is the code in LogManager I'm referring to. // Adding the global Logger. Doing so in the Logger.clinit // would deadlock with the LogManager.clinit. Logger.getGlobal().setLogManager(manager); manager.addLogger(Logger.getGlobal()); Also, the logging initialization is fragile. I would suggest to verify if logging using the global logger by multiple threads print all log messages correctly. There are several test/java/util/logging/LoggingDeadlock* tests that you should check out if they adequately verify your fix. Mandy [1] http://hg.openjdk.java.net/jdk8/tl/jdk/file/00cd9dc3c2b5/test/java/util/logging/LoggingDeadlock.java On 10/29/2012 3:30 PM, Jim Gish wrote: Hi Mandy, I don't understand your second sentence. Could you please clarify? Thanks, Jim On 10/29/2012 06:05 PM, Mandy Chung wrote: Jim, The logging deadlock issue is subtle and complex. Do we have a test case that verifies your fix that is deadlock-free? I can't tell for sure but looks like it smells the potential deadlock if Logger.getGlobal() triggers the LogManager class initialization but LogManager.clinit calls Logger.getLogger().setLogManager(). Maybe you already see this - 4994705 may give you some idea of the deadlock problem. Hope this helps. Mandy On 10/24/2012 4:13 PM, Jim Gish wrote: Please review http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/ In JDK7, Logger.global was deprecated because of potential deadlock problems. The method getGlobal() was introduced as a convenience method to get the global logger in lieu of this or calling Logger.getLogger(Logger.GLOBAL_LOGGER_NAME). Unfortunately, this was broken out of the gate. getGlobal() simply used the deprecated static variable global, but this had the result of returning the global logger without initializing the logging system. As a result, simply calling Logger.getGlobal().INFO(msg) does nothing. So much for the convenience of a simple global logger for devs to use ootb without any setup required. This simple fix simply returns Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is called and hence results in proper setup of the logging sytem /and /a working global logger with no assembly required :-) Thanks, Jim
Re: Review/comment needed for the new public java.util.Base64 class
Ulf, my apology. Some how I missed your email. We tried various prototypes for this simple utility class. See http://cr.openjdk.java.net/~sherman/base64/ The v4 might be close to the static constant approach you suggested. While It's hard to draw a clear line on which one is better, we concluded that the proposed approach provides the best balance among usability, readability and extensibility. For example, the get approach allows us to hide the singleton choice to the implementation. It provides a consistent interface fixed basic/url/mime type en/decoder and the configurable floating length/linefeed encoder. -Sherman On 10/29/12 11:15 AM, Ulf Zibis wrote: Hi Sherman, can you give me a short answer please? -Ulf Am 23.10.2012 16:57, schrieb Ulf Zibis: Am 23.10.2012 15:04, schrieb Alan Bateman: I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason is that the method name makes it sound like it returns a URLEncoder or or at least an encoder for HTML forms. While more verbose, getBase64UrlEncoder is clear that it returns a base64url encoder. I'm wondering, why there are those get... methods at all. Alternatively you could make the appropriate constructors and predifined static variants public. So one only should use: Base64.Encoder encoder = new Base64.Encoder(...); Base64.Encoder urlEncoder = Base64.Encoder.RFC4648_URLSAFE; No need for those looong method names. -Ulf
