summaryrefslogtreecommitdiff
path: root/test/files/run/t8549.scala
Commit message (Collapse)AuthorAgeFilesLines
* Make AnyRefMap serializableJason Zaugg2015-09-251-2/+3
|
* SI-6938 Use mutable red-black tree in TreeSetRui Gonçalves2015-07-281-1/+4
| | | | | | | | The previous implementation of `mutable.TreeSet` uses a mutable reference to an immutable red-black tree as its underlying data structure. That leads to unnecessary objects being created, which can be a problem in systems with limited resources. It also has reduced performance when compared with common mutable implementations. In this commit `mutable.TreeSet` is changed so that it uses the recently created `mutable.RedBlackTree` as its underlying data structure. Specialized red-black tree methods were created for working with keys for efficiency reasons. The new implementation is source-compatible with the previous one, although its serialized representation obviously changes. Closes [SI-6938](https://issues.scala-lang.org/browse/SI-6938).
* SI-8911 scala.collection.convert.Wrappers$MapWrapper not serializableRex Kerr2015-07-191-1/+14
| | | | | | | | Added `with Serializable` to `MapWrapper` and `SetWrapper`. Test verifies that serialization works in the simplest case. Also updated tests in t8549 to check that serialization works and doesn't change.
* SI-4147 Add an implementation of `mutable.TreeMap`Rui Gonçalves2015-05-301-1/+4
| | | | | | | | | | This commit contains an implementation of a mutable red-black tree with focus on performance. It also contains a new `mutable.TreeMap` Scala collection that is backed by the aforementioned tree. The common generic factories and traits related to mutable sorted maps didn't exist yet, so this commit also adds them. Regarding performance, `TreeMap` overrides (from `MapLike` and `SortedMapLike`) all of the most common methods for maps and also those whose default implementations are asymptotically worse than direct red-black tree algorithms (e.g. `last`, `clear`). The `rangeImpl` method of `TreeMap` returns an instance of `TreeMapView`, an inner class of `TreeMap`. This view is backed by the same `RedBlackTree.Tree` instance, and therefore changes to the original map are reflected in the view and vice-versa. The semantics of mutating a view by adding and removing keys outside the view's range are the same of the current `mutable.TreeSet`. A bit less focus was given on the performance of views - in particular, getting the `size` of a `TreeMapView` is O(n) on the number of elements inside the view bounds. That can be improved in the future. In a future commit, `mutable.TreeSet` can be changed to be backed by this red-black tree implementation.
* Fix t8549 under -Ydelambdafy:methodLukas Rytz2014-10-101-1/+4
| | | | | | | | | | | | | | | | | | the structure of Option.class generated by delambdafy:method is slightly different. For example, lambdas declared within Option are not emitted as nested classes, so under delambdafy:method there's no inner class entry for anonfun classes. The test failed because serializing a ClassTag involves serializing an Option. Option did not have a `@SerialVersionUID`, and the classfile generated by delambdafy:method has a different value. The annotation is required on the parent class (Option) as well as the subclasses (Some / None). De-serializing a Some will fail if Option has a different SerialVersionUID. Relates to SI-8576. We should probably have more SVUID annotations in the library.
* SI-8576 Temporarily disable part of serialization testJason Zaugg2014-05-101-23/+34
| | | | | | | | | | | | | | | | | Parts of this test fail if testing a library built with -Xcheckinit. The failures seem to be in two categories: - A component of the serialized structure does not have a declared SerialVersionUID, meaning that the extra field added to track initialization results in a different ID. This manifests as a `java.io.InvalidClassException` when deserializing the blobs of data saved in the test case. - Spurious `UnitializedFieldErrors` when calling methods on the object that has been serialized and then deserialized. Until we figure out the right course of action (more @SerialVersionUID annotations / weaker tests / ...), this commit disabled those tests.
* SI-8549 Enforce serialization stability for selected collectionsJason Zaugg2014-05-051-0/+175
To date, we've been hesidant to offer any guarantees about Java serialization of standard library types among heteregenous Scala versions. Nonetheless, we have added `SerialVersionUID` annotations to parts of the standard library, to offer some stability. This protects against two winds of change: automatic calculation of this UID might differ between JVM versions, or it might differ due to otherwise immaterial changes to the library in Scala releases. With this commit, we strengthen the guarantees. Classes marked with `SerialVersionUID` will be serialization compatible within minor releases of Scala. This is backed up by the enclosed test. After major releases, we reserve the right to break this. But the test will serve to avoid *accidental* changes. Specifically, the test case checks: - deserialize(serialize(x)) == x - serialize(x) is stable over time I have included values of all types marked with `@SerialVersionUID` in the library. For some types, I've added variations in the values to exercise different subclasses, such as `Set1` / `Set2`. This found that that the serialized form of predefined `ClassTags` included the cached identity hash code and failed the stability test. This wasn't an issue for correctness as they also provide `readResolve`, but I marked those fields as `@transient` in any case to comply with the test expectations. That whole area is good example of a serialization worst-practice: using anonymous classes in code like: val Object: Manifest[java.lang.Object] = new PhantomManifest[...](...) { private def readResolve(): Any = Manifest.AnyVal } ... will lead to instability if these declarations are shifted around in the file. Named classes would be preferred. I've noted this in a TODO comment for 2.12.