| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
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.
|