Error message I can't figure out
in [Java Programming]
|
Prev: UDF-8 Reading for URL - not working
Next: Java Swing Question: Robot Screenshot does odd things when close to the mouse cursor
From: Roedy Green on 25 Feb 2010 17:57 On Tue, 23 Feb 2010 16:50:43 -0800, "Mike Schilling" <mscottschilling(a)hotmail.com> wrote, quoted or indirectly quoted someone who said : >TreeMap$Values is an inner class, the type of the object returned from >TreeMap.values(). It's not used for anything else. In particular, it's not >involved when serializing a TreeMap. It's also not serializable. The only >way to get this error is to attempt to serialize the return from >TreeMap.values(). This will always fail, regardless of the types of the >objects in the map; in fact, it will fail even if the map is empty. For now, he will have to convert the result to an ordinary array which can be serialized. See the sample code at http://mindprod.com/jgloss/treemap.html -- Roedy Green Canadian Mind Products http://mindprod.com The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. ~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)
From: Joshua Cranmer on 25 Feb 2010 18:08 On 02/25/2010 05:42 PM, Roedy Green wrote: > Could Sun fix it just by adding an "implements Serializable" to the > Values nested class? The value set class (and those for the key and entry sets, FWIW) is defined as an inner class. Therefore, all of its constructors implicitly have an argument of TreeMap, which makes making the Serializable a little more problematic. Sun even gives the following warning: Note - Serialization of inner classes (i.e., nested classes that are not static member classes), including local and anonymous classes, is strongly discouraged for several reasons. As to why this was done, I cannot say for certain. The sub map return stuff is serializable on the other hand, which leads me to believe that the developers of Java decided that the value, key, and entry sets are merely views into the data of a TreeMap and should not live on their own while submaps of a TreeMap are full-fledged maps in their own rights and should be able to be divorced from the original. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Roedy Green on 25 Feb 2010 21:01 On Thu, 25 Feb 2010 18:08:56 -0500, Joshua Cranmer <Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted someone who said : >The value set class (and those for the key and entry sets, FWIW) is >defined as an inner class. Therefore, all of its constructors implicitly >have an argument of TreeMap, which makes making the Serializable a >little more problematic. It is a STATIC nested class, so you don't have THAT complication. -- Roedy Green Canadian Mind Products http://mindprod.com The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. ~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)
From: Joshua Cranmer on 25 Feb 2010 22:02 On 02/25/2010 09:01 PM, Roedy Green wrote: > On Thu, 25 Feb 2010 18:08:56 -0500, Joshua Cranmer > <Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted someone > who said : > >> The value set class (and those for the key and entry sets, FWIW) is >> defined as an inner class. Therefore, all of its constructors implicitly >> have an argument of TreeMap, which makes making the Serializable a >> little more problematic. > > It is a STATIC nested class, so you don't have THAT complication. Not according to my installation: $ javap -private java.util.TreeMap\$Values Compiled from "TreeMap.java" class java.util.TreeMap$Values extends java.util.AbstractCollection{ final java.util.TreeMap this$0; [ The signature of a non-static class ] Or, if you want the source code itself: class Values extends AbstractCollection<V> { I don't see no static there :-) -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Mike Schilling on 26 Feb 2010 15:13
Joshua Cranmer wrote: > On 02/25/2010 09:01 PM, Roedy Green wrote: >> On Thu, 25 Feb 2010 18:08:56 -0500, Joshua Cranmer >> <Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted >> someone who said : >> >>> The value set class (and those for the key and entry sets, FWIW) is >>> defined as an inner class. Therefore, all of its constructors >>> implicitly have an argument of TreeMap, which makes making the >>> Serializable a little more problematic. >> >> It is a STATIC nested class, so you don't have THAT complication. > > Not according to my installation: > $ javap -private java.util.TreeMap\$Values > Compiled from "TreeMap.java" > class java.util.TreeMap$Values extends java.util.AbstractCollection{ > final java.util.TreeMap this$0; > [ The signature of a non-static class ] > > Or, if you want the source code itself: > class Values extends AbstractCollection<V> { > > I don't see no static there :-) Since it's purpose is to be a view into a TreeMap, it would either need to be a non-static class of have a field of type TreeMap that pointed to its parent. [1]. Also, since its purpose is to be a view into a TreeMap, it would be a weird thing to serialize: If it were deserialized without its parent TreeMap, what good would it be? And if you're going to deserialize the TreeMap, you can just call values() on that . 1. Not that large a distinction, obviously. |