hg: jdk7/tl/jdk: 6907177: Update jdk tests to remove unncessary -source and -target options

[joe . darcy]

Changeset: 1755493c5774
Author:darcy
Date:  2009-12-03 18:19 -0800
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1755493c5774

6907177: Update jdk tests to remove unncessary -source and -target options
Reviewed-by: ohair

! test/demo/jvmti/hprof/CpuOldTest.java
! test/demo/jvmti/hprof/CpuSamplesTest.java
! test/demo/jvmti/hprof/CpuTimesDefineClassTest.java
! test/demo/jvmti/hprof/CpuTimesTest.java
! test/demo/jvmti/hprof/HeapAllTest.java
! test/demo/jvmti/hprof/HeapBinaryFormatTest.java
! test/demo/jvmti/hprof/HeapDumpTest.java
! test/demo/jvmti/hprof/HeapSitesTest.java
! test/demo/jvmti/hprof/OptionsTest.java
! test/java/io/Serializable/enum/array/Test.java
! test/java/io/Serializable/enum/badResolve/Write.java
! test/java/io/Serializable/enum/basic/Test.java
! test/java/io/Serializable/enum/classObject/Test.java
! test/java/io/Serializable/enum/constantSubclasses/Write.java
! test/java/io/Serializable/enum/ignoreSerializationFields/Test.java
! test/java/io/Serializable/enum/ignoreSerializationMethods/Test.java
! test/java/io/Serializable/enum/mismatchedTypecode/Test.java
! test/java/io/Serializable/enum/missingConstant/Write.java
! test/java/io/Serializable/enum/unshared/Test.java
! test/java/lang/Boolean/MakeBooleanComparable.java
! test/java/lang/Class/Cast.java
! test/java/lang/Class/IsEnum.java
! test/java/lang/Class/asSubclass/BasicUnit.java
! test/java/lang/ClassLoader/Assert.sh
! test/java/lang/Integer/BitTwiddle.java
! test/java/lang/Long/BitTwiddle.java
! test/java/lang/Math/Atan2Tests.java
! test/java/lang/Math/IeeeRecommendedTests.java
! test/java/lang/Math/PowTests.java
! test/java/lang/Math/TanTests.java
! test/java/lang/Runtime/exec/WinCommand.java
! test/java/lang/Thread/GenerifyStackTraces.java
! test/java/lang/Thread/UncaughtExceptions.sh
! test/java/lang/annotation/UnitTest.java
! test/java/lang/annotation/package-info.java
! test/java/lang/management/CompositeData/MemoryNotifInfoCompositeData.java
! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java
! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java
! test/java/lang/management/ManagementFactory/PlatformMBeanServerTest.java
! test/java/lang/management/ManagementFactory/ProxyExceptions.java
! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java
! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java
! test/java/lang/management/RuntimeMXBean/GetSystemProperties.java
! test/java/lang/management/RuntimeMXBean/TestInputArgument.sh
! test/java/lang/reflect/Constructor/GenericStringTest.java
! test/java/lang/reflect/Field/GenericStringTest.java
! test/java/lang/reflect/Generics/StringsAndBounds.java
! test/java/lang/reflect/Generics/TestC1.java
! test/java/lang/reflect/Generics/TestC2.java
! test/java/lang/reflect/Generics/TestN1.java
! test/java/lang/reflect/Generics/exceptionCauseTest.java
! test/java/lang/reflect/Generics/getAnnotationTest.java
! test/java/lang/reflect/Method/Equals.java
! test/java/lang/reflect/Method/GenericStringTest.java
! test/java/math/BigDecimal/DivideTests.java
! test/java/math/BigDecimal/IntegralDivisionTests.java
! test/java/math/BigDecimal/PowTests.java
! test/java/math/BigDecimal/ToPlainStringTests.java
! test/java/math/BigDecimal/ZeroScalingTests.java
! test/java/math/RoundingMode/RoundingModeTests.java
! test/java/net/ProxySelector/ProxyTest.java
! test/java/net/URL/PerConnectionProxy.java
! test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java
! test/java/security/cert/PKIXParameters/InvalidParameters.java
! test/java/util/AbstractList/CheckForComodification.java
! test/java/util/Collections/AddAll.java
! test/java/util/Collections/Disjoint.java
! test/java/util/Collections/Frequency.java
! test/java/util/EnumMap/EnumMapBash.java
! test/java/util/EnumSet/AllOf.java
! test/java/util/EnumSet/ComplementOf.java
! test/java/util/EnumSet/EnumSetBash.java
! test/java/util/EnumSet/JumboRange.java
! test/java/util/EnumSet/Range.java
! test/java/util/Formattable/StockName.java
! test/java/util/IdentityHashMap/ToString.java
! test/java/util/Locale/Bug4175998Test.java
! test/java/util/UUID/UUIDTest.java
! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java
! 
test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java
! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java
! 
test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java
! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java
! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java
! test/java/util/concurrent/Exchanger/ExchangeLoops.java
! 
test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java
! test/java/util/concurrent/FutureTask/CancelledFutureLoops.java
! test/java/util/concurrent/atomic/VMSupportsCS8.java
! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
! test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoop

Re: Code review request for 6907177 "Update jdk tests to remove unncessary -source and -target options"

[Kelly O'Hair]

Looks fine Joe. I also have some of these same changes, on the jvmti demo
tests but they should merge fine when I get your changeset.

-kto

Joe Darcy wrote:

Hello.

The fix for 6907177 "Update jdk tests to remove unncessary -source and 
-target options" alters about 100 regression tests in the jdk repository 
that have inappropriate "-source" options to compile code to earlier 
source levels.  Often these directives were created in JDK 5 before the 
default source level was raised to 5 in that release; therefore, such 
directives were necessary in those tests to enable the new language 
features to be used at the time.  Generally, such directives should be 
removed so that the latest source level is exercised.  In a few cases, 
the directives are just updated to allow a test to keep passing; the 
test/java/security/cert/PKIX* tests have not been been generified so 
they stay at -source 4 and test/java/util/Locale/Bug4175998Test.java 
won't compile with javac higher than -source 5 since the file contains 
an encoding error and starting with -source 6 javac treats encoding 
errors as fatal.


Patch below; webrev at
http://cr.openjdk.java.net/~darcy/6907177.0/

Thanks,

-Joe

--- old/test/demo/jvmti/hprof/CpuOldTest.java2009-12-03 
16:44:34.0 -0800
+++ new/test/demo/jvmti/hprof/CpuOldTest.java2009-12-03 
16:44:34.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java ../DemoRun.java
+ * @compile -g HelloWorld.java ../DemoRun.java
 * @build CpuOldTest
 * @run main CpuOldTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/CpuSamplesTest.java2009-12-03 
16:44:35.0 -0800
+++ new/test/demo/jvmti/hprof/CpuSamplesTest.java2009-12-03 
16:44:35.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5012882
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g:lines HelloWorld.java ../DemoRun.java
+ * @compile -g:lines HelloWorld.java ../DemoRun.java
 * @build CpuSamplesTest
 * @run main CpuSamplesTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/CpuTimesDefineClassTest.java2009-12-03 
16:44:36.0 -0800
+++ new/test/demo/jvmti/hprof/CpuTimesDefineClassTest.java2009-12-03 
16:44:36.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5097131 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java DefineClass.java 
../DemoRun.java

+ * @compile -g HelloWorld.java DefineClass.java ../DemoRun.java
 * @build CpuTimesDefineClassTest
 * @run main CpuTimesDefineClassTest DefineClass
 *
--- old/test/demo/jvmti/hprof/CpuTimesTest.java2009-12-03 
16:44:37.0 -0800
+++ new/test/demo/jvmti/hprof/CpuTimesTest.java2009-12-03 
16:44:37.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java ../DemoRun.java
+ * @compile -g HelloWorld.java ../DemoRun.java
 * @build CpuTimesTest
 * @run main CpuTimesTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapAllTest.java2009-12-03 
16:44:38.0 -0800
+++ new/test/demo/jvmti/hprof/HeapAllTest.java2009-12-03 
16:44:38.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java ../DemoRun.java
+ * @compile -g HelloWorld.java ../DemoRun.java
 * @build HeapAllTest
 * @run main HeapAllTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapBinaryFormatTest.java2009-12-03 
16:44:39.0 -0800
+++ new/test/demo/jvmti/hprof/HeapBinaryFormatTest.java2009-12-03 
16:44:39.0 -0800

@@ -26,7 +26,7 @@
 * @bug 4965057 6313381
 * @summary Test jvmti hprof format=b
 *
- * @compile -source 1.5 -g:source HelloWorld.java ../DemoRun.java
+ * @compile -g:source HelloWorld.java ../DemoRun.java
 * @build HeapBinaryFormatTest
 * @run main HeapBinaryFormatTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapDumpTest.java2009-12-03 
16:44:40.0 -0800
+++ new/test/demo/jvmti/hprof/HeapDumpTest.java2009-12-03 
16:44:40.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g:source HelloWorld.java ../DemoRun.java
+ * @compile -g:source HelloWorld.java ../DemoRun.java
 * @build HeapDumpTest
 * @run main HeapDumpTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapSitesTest.java2009-12-03 
16:44:41.0 -0800
+++ new/test/demo/jvmti/hprof/HeapSitesTest.java2009-12-03 
16:44:40.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g:vars HelloWorld.java ../DemoRun.java
+ * @compile -g:vars HelloWorld.java ../DemoRun.java
 * @build HeapSitesTest
 * @run main HeapSitesTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/OptionsTest.java2009-12-03 
16:44:42.0 -0800
+++ new/test/demo/jvmti/hprof/OptionsTest.java2009-12-03 
16:44:41.0 -0800

@@ -26,7 +26,7 @@
 * @bug 5083441 6299047
 * @summary Test jvmti hprof
 *
- * @com

Code review request for 6907177 "Update jdk tests to remove unncessary -source and -target options"

[Joe Darcy]

Hello.

The fix for 6907177 "Update jdk tests to remove unncessary -source and 
-target options" alters about 100 regression tests in the jdk repository 
that have inappropriate "-source" options to compile code to earlier 
source levels.  Often these directives were created in JDK 5 before the 
default source level was raised to 5 in that release; therefore, such 
directives were necessary in those tests to enable the new language 
features to be used at the time.  Generally, such directives should be 
removed so that the latest source level is exercised.  In a few cases, 
the directives are just updated to allow a test to keep passing; the 
test/java/security/cert/PKIX* tests have not been been generified so 
they stay at -source 4 and test/java/util/Locale/Bug4175998Test.java 
won't compile with javac higher than -source 5 since the file contains 
an encoding error and starting with -source 6 javac treats encoding 
errors as fatal.


Patch below; webrev at
http://cr.openjdk.java.net/~darcy/6907177.0/

Thanks,

-Joe

--- old/test/demo/jvmti/hprof/CpuOldTest.java   2009-12-03 16:44:34.0 
-0800
+++ new/test/demo/jvmti/hprof/CpuOldTest.java   2009-12-03 16:44:34.0 
-0800
@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java ../DemoRun.java
+ * @compile -g HelloWorld.java ../DemoRun.java
 * @build CpuOldTest
 * @run main CpuOldTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/CpuSamplesTest.java   2009-12-03 
16:44:35.0 -0800
+++ new/test/demo/jvmti/hprof/CpuSamplesTest.java   2009-12-03 
16:44:35.0 -0800
@@ -26,7 +26,7 @@
 * @bug 5012882
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g:lines HelloWorld.java ../DemoRun.java
+ * @compile -g:lines HelloWorld.java ../DemoRun.java
 * @build CpuSamplesTest
 * @run main CpuSamplesTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/CpuTimesDefineClassTest.java  2009-12-03 
16:44:36.0 -0800
+++ new/test/demo/jvmti/hprof/CpuTimesDefineClassTest.java  2009-12-03 
16:44:36.0 -0800
@@ -26,7 +26,7 @@
 * @bug 5097131 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java DefineClass.java ../DemoRun.java
+ * @compile -g HelloWorld.java DefineClass.java ../DemoRun.java
 * @build CpuTimesDefineClassTest
 * @run main CpuTimesDefineClassTest DefineClass
 *
--- old/test/demo/jvmti/hprof/CpuTimesTest.java 2009-12-03 16:44:37.0 
-0800
+++ new/test/demo/jvmti/hprof/CpuTimesTest.java 2009-12-03 16:44:37.0 
-0800
@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java ../DemoRun.java
+ * @compile -g HelloWorld.java ../DemoRun.java
 * @build CpuTimesTest
 * @run main CpuTimesTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapAllTest.java  2009-12-03 16:44:38.0 
-0800
+++ new/test/demo/jvmti/hprof/HeapAllTest.java  2009-12-03 16:44:38.0 
-0800
@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g HelloWorld.java ../DemoRun.java
+ * @compile -g HelloWorld.java ../DemoRun.java
 * @build HeapAllTest
 * @run main HeapAllTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapBinaryFormatTest.java 2009-12-03 
16:44:39.0 -0800
+++ new/test/demo/jvmti/hprof/HeapBinaryFormatTest.java 2009-12-03 
16:44:39.0 -0800
@@ -26,7 +26,7 @@
 * @bug 4965057 6313381
 * @summary Test jvmti hprof format=b
 *
- * @compile -source 1.5 -g:source HelloWorld.java ../DemoRun.java
+ * @compile -g:source HelloWorld.java ../DemoRun.java
 * @build HeapBinaryFormatTest
 * @run main HeapBinaryFormatTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapDumpTest.java 2009-12-03 16:44:40.0 
-0800
+++ new/test/demo/jvmti/hprof/HeapDumpTest.java 2009-12-03 16:44:40.0 
-0800
@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g:source HelloWorld.java ../DemoRun.java
+ * @compile -g:source HelloWorld.java ../DemoRun.java
 * @build HeapDumpTest
 * @run main HeapDumpTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/HeapSitesTest.java2009-12-03 
16:44:41.0 -0800
+++ new/test/demo/jvmti/hprof/HeapSitesTest.java2009-12-03 
16:44:40.0 -0800
@@ -26,7 +26,7 @@
 * @bug 5012882 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g:vars HelloWorld.java ../DemoRun.java
+ * @compile -g:vars HelloWorld.java ../DemoRun.java
 * @build HeapSitesTest
 * @run main HeapSitesTest HelloWorld
 */
--- old/test/demo/jvmti/hprof/OptionsTest.java  2009-12-03 16:44:42.0 
-0800
+++ new/test/demo/jvmti/hprof/OptionsTest.java  2009-12-03 16:44:41.0 
-0800
@@ -26,7 +26,7 @@
 * @bug 5083441 6299047
 * @summary Test jvmti hprof
 *
- * @compile -source 1.5 -g:lines HelloWorld.java ../DemoRun.java
+ * @compile -g:lines HelloWorld.java ../DemoRun.java
 * @build OptionsTest
 * @run main OptionsTest HelloWorld
 */
--- ol

hg: jdk7/tl/langtools: 6906748: Project Coin: Minor strings in switch cleanup

[joe . darcy]

Changeset: 121e0ebf1658
Author:darcy
Date:  2009-12-03 14:03 -0800
URL:   http://hg.openjdk.java.net/jdk7/tl/langtools/rev/121e0ebf1658

6906748: Project Coin: Minor strings in switch cleanup
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java

hg: jdk7/tl/jdk: 6906854: SSL/Krb5 testcase should not use a fixed port number

[vincent . ryan]

Changeset: bc12627832e0
Author:vinnie
Date:  2009-12-03 21:30 +
URL:   http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc12627832e0

6906854: SSL/Krb5 testcase should not use a fixed port number
Reviewed-by: alanb

! test/ProblemList.txt
! test/sun/security/krb5/auto/SSL.java

Re: final transient fields serialization

[David M. Lloyd]

This is exactly the solution I present to users of JBoss Marshalling.  The 
access check performed verifies that the field being updated is a 
non-static instance field (final or otherwise, any access level) of the 
caller's class; IllegalAccessException is then not thrown at "runtime" when 
the field is changed.  Setting the field can be done via the same 
assortment of set methods found on Field (set, setByte, setBoolean, ...).


- DML

On 12/03/2009 04:57 AM, Tom Hawtin wrote:

Peter Jones wrote:


Regarding a language solution, though, I don't see how to avoid making
a [...]


`readObject` is a `psuedo-constructor`. Ideally it would be a real
constructor (with choice of defaultReadObject/readFields similar to
super), but that would require significant changes to the JLS.

Similar problems appear for JAXB, ORMs, etc. Dependency Inject also has
problems with construction. Construction often involves way too much
boilerplate. There are lots of issues here, most I have little
experience with.


So I think that the best hope is an improved reflective library
solution. Thinking out loud: say, a factory method that looks up a [...]


I guess something like

class MyClass implements Serializable {
private final transient Thing thing;
private static final FieldRead THING_READER =
FieldRead.newInstance("thing");
...
private void readObject(...) ... {
in.defaultReadObject();
Thing thing = (Thing)in.readObject();
THING_READER.set(thing);
}
}

Gratuitous use of immediate caller. I just know people will attempt to
take client supplied arguments. Best we can do is put a few static
checks in javac and static analysis tools, and runtime checks into the
serialisation mechanism.

(Notes:
FieldRead.newInstance
- must be called by static initialiser
(dynamic and perhaps static check).
- static analysis (inc. javac) can check field name, type and assignment).
- errors by unchecked exception
FieldRead.read
- Dynamic check that called from readObject on this instance (can cheat).
- Dynamic check for no reassignment.
- Dynamic check after readObject call for definite assignment.
- Could also add static checks as well.
)

Tom Hawtin

Re: Gap Buffer based AbstractStringBuilder implementation

[Goktug Gokdogan]

On Tue, Dec 1, 2009 at 2:16 AM, Martin Buchholz  wrote:

> On Thu, Nov 26, 2009 at 00:57, Goktug Gokdogan  wrote:
> > I think, we can overcome the slowdown. The point of my prototype is to
> check
> > the general performance characteristics. Slowdown is more likely due to
> the
> > poorly optimized extra method call to keep all logic in one place.
> Normally
> > the gap buffer algorithm should add only one comparison overhead to the
> > common case which will not to be observable in benchmarks.
>
> I am coming to like the gap buffer idea.
>
> You can optimize for append mode - append methods do not have to
> check for the existence or length of an internal gap.
>
> An extra comparison overhead is likely to be cheap, but it is nevertheless
> likely to be a measurable slowdown.
> But as I said, it more and more seems to me the right thing to do.
>
> If done right, StringBuilder can start to strongly resemble an Emacs
> buffer,
> and be useful for largish amounts of data with internal modifications.
>
> > I have previously thought about implementing a similar behavior in other
> > array-based growing structures, but it is not worth it. You can easily
> use
> > your previous data structures for pre-appending algorithms - just by
> > appending to end and iterating from reverse. But you can't do that in a
> > StringBuilder because StringBuilder itself is the composed data. So, in
> my
> > opinion, ArrayList is not a good analogy for this case.
> > StringBuilder, as its name suggests, is for building strings and building
> > string by appending to end is only one of the ways of doing it.
> > I think we should go for this if we can do it without an observable
> > slowdown.
>
> I didn't understand this argument. StringBuilder and ArrayList still
> seem to me conceptually similar.
>
> Martin
>
>
Let me try to explain my argument in another way.

StringBuilder, similar to the other builder pattern implementations, is for
constructing an object, not to collect some data. When append/insert/delete
etc. called on a StringBuilder object, the goal is to shape the final state
of the resulting String. At the end, you call toString method and you are
done.
But ArrayList is more flexible in a way that you are able to reinterpret the
result. For example, you can iterate the items in reverse order or skip some
of them etc.. So, with this point of view, I believe that StringBuilder and
ArrayList are conceptually different.

While building a String with StringBuilder, as it is the builder class for
String, I expect it to provide good performance for different building
scenarios. If I was designing it in the first place, I would start with an
implementation that performs well in general (e.g. gap buffer), then I would
check the performance for the common case (ie. appending to end) . If it
does not perform well and can not be optimized, then I would consider adding
another builder class to API that performs well on the common case before
replacing the original.
But in our case, as the previous codes already depends on the current
performance characteristics of StringBuilder, I totally agree that we are
good to replace it, iff it still performs as good as the previous one. This
is why I suggested the change in the first place.

Goktug.


> >
> > On Thu, Nov 26, 2009 at 1:02 AM, Martin Buchholz 
> > wrote:
> >>
> >> On Wed, Nov 25, 2009 at 21:24, Martin Buchholz 
> >> wrote:
> >> > On Mon, Nov 23, 2009 at 22:51, Goktug Gokdogan 
> >> > wrote:
> >> >> Nobody is interested or everybody is busy?
> >> >
> >> > I think there's a place for a StringBuilder-like
> >> > abstraction that uses a gap buffer,
> >> > but it shouldn't replace StringBuilder.
> >>
> >> Let me qualify that.
> >>
> >> It is hard to sell the small slowdown in the common case
> >> to make other (rare?) operations much faster.
> >> ArrayList should have been implemented to allow
> >> O(1) insert at both ends, like ArrayDeque,
> >> but it is hard to persuade the maintainers
> >> that such a change is worth making today,
> >> when the benchmarks all exercise only the common case.
> >> Similarily for a hypothetical GapArrayList.
> >> On the other hand, on modern cpus
> >> arithmetic is ever closer to being "free",
> >> so it is easier to justify the extra computation.
> >>
> >> Martin
> >
> >
>

Re: final transient fields serialization

[Tom Hawtin]

Peter Jones wrote:

Regarding a language solution, though, I don't see how to avoid making a 
[...]


`readObject` is a `psuedo-constructor`. Ideally it would be a real 
constructor (with choice of defaultReadObject/readFields similar to 
super), but that would require significant changes to the JLS.


Similar problems appear for JAXB, ORMs, etc. Dependency Inject also has 
problems with construction. Construction often involves way too much 
boilerplate. There are lots of issues here, most I have little 
experience with.


So I think that the best hope is an improved reflective library 
solution.  Thinking out loud: say, a factory method that looks up a 
[...]


I guess something like

class MyClass implements Serializable {
private final transient Thing thing;
private static final FieldRead THING_READER =
FieldRead.newInstance("thing");
...
private void readObject(...) ... {
in.defaultReadObject();
Thing thing = (Thing)in.readObject();
THING_READER.set(thing);
}
}

Gratuitous use of immediate caller. I just know people will attempt to 
take client supplied arguments. Best we can do is put a few static 
checks in javac and static analysis tools, and runtime checks into the 
serialisation mechanism.


(Notes:
   FieldRead.newInstance
 - must be called by static initialiser
 (dynamic and perhaps static check).
 - static analysis (inc. javac) can check field name, type and 
assignment).

 - errors by unchecked exception
   FieldRead.read
 - Dynamic check that called from readObject on this instance (can 
cheat).

 - Dynamic check for no reassignment.
 - Dynamic check after readObject call for definite assignment.
 - Could also add static checks as well.
)

Tom Hawtin