summaryrefslogtreecommitdiff
path: root/test/junit/scala/util
Commit message (Collapse)AuthorAgeFilesLines
* Revert "SI-9750 isJavaAtLeast(Int)"Jason Zaugg2016-11-161-8/+3
| | | | | | This reverts commit 656162bb48fbbd703790a2c94d4563e40ddfdfc2. Adding new APIs is not possible until a major release.
* Merge pull request #5276 from som-snytt/issue/9750Seth Tisue2016-10-261-28/+74
|\ | | | | SI-9750 scala.util.Properties.isJavaAtLeast works with JDK9
| * SI-9750 Spec check major.minor.securitySom Snytt2016-07-211-8/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't assume spec is just major, but allow arbitrary version number for both spec value and user value to check. Only the first three dot-separated fields are considered, after skipping optional leading value "1" in legacy format. Minimal validity checks of user arg are applied. Leading three fields, if present, must be number values, but subsequent fields are ignored. Note that a version number is not a version string, which optionally includes pre and build info, `9-ea+109`.
| * SI-9750 isJavaAtLeast(Int)Som Snytt2016-07-151-2/+7
| | | | | | | | | | A good opportunity to simplify the API. Versions are strings, but a spec version is just a number.
| * SI-9750 Tweak tests for what is a numberSom Snytt2016-07-151-21/+4
| | | | | | | | | | | | | | Leaves the error string as is, but adds test to show how it looks. Java calls it a version number. `Not a version: 1.9`. Don't strip `1.` prefix recursively. (That was Snytt's fault.)
| * SI-9750 scala.util.Properties.isJavaAtLeast works with JDK9Pavel Petlinsky2016-07-131-17/+39
| | | | | | | | | | | | | | | | | | | | The utility method compares javaSpecVersion, which has the form "1.8" previously and "9" going forward. The method accepts "1.n" for n < 9. More correctly, the string argument should be a single number. Supports JEP-223.
* | SI-9827 MatchIterator advances itselfSom Snytt2016-07-181-1/+69
|/ | | | | | | | | | To avoid caveats about calling `next` (or `hasNext`) before using `MatchData` methods on `MatchIterator`, just do it internally as necessary. Note `MatchIterator` behavior in the docs. Added tests showing what people cried about.
* SI-9666: Use inline group names in Regex (#4990)som-snytt2016-05-111-0/+64
| | | | | | | | | | | | | | | | | | | | | Delegate `Match group name` to the underlying `matcher`. If that fails, try explicit group names as a fall back. No attempt is made to correlate inline and explicit names. In the following case, either name is accepted: ``` new Regex("a(?<Bar>b*)c", "Bee") ``` But if names are reversed, the error is undetected: ``` new Regex("a(?<Bee>b*)(?<Bar>c)", "Bar", "Bee") ``` Throw IllegalArg on bad group name to be consistent with Java.
* Add initial unit test for Catch and augment documentationJanek Bogucki2016-03-311-0/+42
| | | | | | - Add unit test for andFinally - Reduce code duplication in andFinally - Extend documentation
* SI-9583: Update SystemProperties.empty to return a mutable.Map to fix buildersShane Delmore2015-12-101-0/+27
|
* Clean implementation of sorts for scala.util.Sorting.Rex Kerr2015-06-011-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed code based on Sun JDK sorts and implemented new (basic) sorts from scratch. Deferred to Java Arrays.sort whenever practical. Behavior of `scala.util.Sorting` should be unchanged, but changed documentation to specify when the Java methods are being used (as they're typically very fast). A JUnit test is provided. Performance is important for sorts. Everything is better with this patch, though it could be better yet, as described below. Below are sort times (in microseconds, SEM < 5%) for various 1024-element arrays of small case classes that compare on an int field (quickSort), or int arrays that use custom ordering (stableSort). Note: "degenerate" means there are only 16 values possible, so there are lots of ties. Times are all with fresh data (no re-using cache from run to run). Results: ``` random sorted reverse degenerate big:64k tiny:16 Old Sorting.quickSort 234 181 178 103 25,700 1.4 New Sorting.quickSort 170 27 115 74 18,600 0.8 Old Sorting.stableSort 321 234 236 282 32,600 2.1 New Sorting.stableSort 239 16 194 194 25,100 1.2 java.util.Arrays.sort 124 4 8 105 13,500 0.8 java.util.Arrays.sort|Box 126 15 13 112 13,200 0.9 ``` The new versions are uniformly faster, but uniformly slower than Java sorting. scala.util.Sorting has use cases that don't map easily in to Java unless everything is pre-boxed, but the overhead of pre-boxing is minimal compared to the sort. A snapshot of some of my benchmarking code is below. (Yes, lots of repeating myself--it's dangerous not to when trying to get somewhat accurate benchmarks.) ``` import java.util.Arrays import java.util.Comparator import math.Ordering import util.Sorting import reflect.ClassTag val th = ichi.bench.Thyme.warmed() case class N(i: Int, j: Int) {} val a = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt, i)) ) var ai = 0 val b = Array.fill(1024)( Array.tabulate(1024)(i => N(i, i)) ) var bi = 0 val c = Array.fill(1024)( Array.tabulate(1024)(i => N(1024-i, i)) ) var ci = 0 val d = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt(16), i)) ) var di = 0 val e = Array.fill(16)( Array.tabulate(65536)(i => N(util.Random.nextInt, i)) ) var ei = 0 val f = Array.fill(65535)( Array.tabulate(16)(i => N(util.Random.nextInt, i)) ) var fi = 0 val o = new Ordering[N]{ def compare(a: N, b: N) = if (a.i < b.i) -1 else if (a.i > b.i) 1 else 0 } for (s <- Seq("one", "two", "three")) { println(s) th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Sorting.quickSort(x)(o); x(x.length/3) } } def ix(ns: Array[N]) = { val is = new Array[Int](ns.length) var i = 0 while (i < ns.length) { is(i) = ns(i).i i += 1 } is } val p = new Ordering[Int]{ def compare(a: Int, b: Int) = if (a > b) 1 else if (a < b) -1 else 0 } for (s <- Seq("one", "two", "three")) { println(s) val tag: ClassTag[Int] = implicitly[ClassTag[Int]] th.pbench{ val x = ix(a(ai)); ai = (ai+1)%a.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(b(bi)); bi = (bi+1)%b.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(c(ci)); ci = (ci+1)%c.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(d(di)); di = (di+1)%d.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(e(ei)); ei = (ei+1)%e.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(f(fi)); fi = (fi+1)%f.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } } for (s <- Seq("one", "two", "three")) { println(s) th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Arrays.sort(x, o); x(x.length/3) } } def bx(is: Array[Int]): Array[java.lang.Integer] = { val Is = new Array[java.lang.Integer](is.length) var i = 0 while (i < is.length) { Is(i) = java.lang.Integer.valueOf(is(i)) i += 1 } Is } def xb(Is: Array[java.lang.Integer]): Array[Int] = { val is = new Array[Int](Is.length) var i = 0 while (i < is.length) { is(i) = Is(i).intValue i += 1 } is } val q = new Comparator[java.lang.Integer]{ def compare(a: java.lang.Integer, b: java.lang.Integer) = o.compare(a.intValue, b.intValue) } for (s <- Seq("one", "two", "three")) { println(s) val tag: ClassTag[Int] = implicitly[ClassTag[Int]] th.pbench{ val x = bx(ix(a(ai))); ai = (ai+1)%a.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(b(bi))); bi = (bi+1)%b.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(c(ci))); ci = (ci+1)%c.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(d(di))); di = (di+1)%d.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(e(ei))); ei = (ei+1)%e.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(f(fi))); fi = (fi+1)%f.length; Arrays.sort(x, q); xb(x)(x.length/3) } } ```
* SI-9059 Random.alphanumeric is inefficientDenton Cockburn2015-02-131-0/+15
| | | | | | | | | Generate alphanumeric values by taking random element of string containing all alphanumerics. Instead of generating nextPrintableChar then filtering for alphanumerics, we can just take from a string containing all alphanumerics. This provides a significant performance improvement.
* Better ant / junit interactionAntoine Gourlay2014-09-292-3/+1
| | | | | | | | | | | | | Currently junit test sources are always rebuilt, that's wasteful. The second dependency on the junit task is there so that the first can be skipped if sources haven't changed. Also normalize package names versus location in the `test/junit` folder: ant isn't very clever when it comes to selectively recompiling tests, so now editing a test will only cause that one to be recompiled (instead of ~13 files every time). This makes TDD with junit even faster.
* SI-8787 If you love nulls, so does RegexSom Snytt2014-08-081-0/+17
| | | | Regex is robust when unapplying null. A null never matches.
* SI-6455 util.Try supports withFilterAdriaan Moors2014-02-241-0/+35
|
* SI-8022 Backwards compatibility for Regex#unapplySeqJason Zaugg2013-12-011-0/+30
| | | | | | | | | | | | | | | The change in ce1bbfe / SI-6406 introduced overloads of `unapplySeq` with wider static and dynmaic result types than the now-deprecated alternative that accepted `Any`. This is subtly source incompatible and the change was noticed in Specs2. This commit uses `List` as the static and runtime type for the new overloads. For consistency, the same is done for the new method added in SI-7737 / 93e9623.
* Merge pull request #2819 from som-snytt/issue/regextract-charAdriaan Moors2013-08-141-0/+58
|\ | | | | SI-7737 Regex matches Char
| * SI-7737 Regex matches CharSom Snytt2013-08-101-0/+58
| | | | | | | | | | | Enables Char extraction by regex. ``` val r = """(\p{Lower})""".r "cat"(0) match { case r(x) => true } val nc = """\p{Lower}""".r "cat"(0) match { case nc() => true } ```
* SI-7265 javaSpecVersion, adjust isJava... testsSom Snytt2013-08-011-0/+59
Make this and related properties public, because they are useful. This change ought to have been committed at 2.11 and then backported with restrictions, rather than vice-versa. Note that they are defined in the order, version, vendor and name, which is the order from the underlying javadoc. It would be a neat feature of the PR validator, as previously imagined, to run a "pending" test and then, on success and merge, to move it automatically to the canonical suite.