| e41ef90 | Ben Liblit | 31 March 2024, 17:56:14 UTC | Use new API for updating collection properties More details [here](better-api-for-updating-collection-properties). (cherry picked from commit 3a2ca2e599e1cf72073ed64d5cf5839dea93bf71) | 31 March 2024, 18:39:03 UTC |
| d4fa4ca | Ben Liblit | 31 March 2024, 17:56:12 UTC | Upgrade to Gradle 8.7 (cherry picked from commit d7bd366ee5d2ca151e5aff07aa3f50bef8b9d08f) | 31 March 2024, 18:39:03 UTC |
| 889b0c7 | Ben Liblit | 31 March 2024, 17:56:09 UTC | Add automated tests on Apple Silicon M1 CPU | 31 March 2024, 18:39:03 UTC |
| 0028826 | Ben Liblit | 31 March 2024, 17:55:58 UTC | Remove customizations for macOS on Apple Silicon These tweaks used to be needed to work around [a Gradle bug](https://github.com/gradle/gradle/issues/18876). That bug is still open, but I find that all native components build and pass their tests just fine without these hacks. | 31 March 2024, 18:39:03 UTC |
| 00e4c16 | Manu Sridharan | 28 March 2024, 20:11:27 UTC | Prepare next development version. | 28 March 2024, 20:11:27 UTC |
| 7352031 | Manu Sridharan | 28 March 2024, 20:05:41 UTC | Prepare for release 1.6.4. | 28 March 2024, 20:05:41 UTC |
| 49d9fc9 | Manu Sridharan | 28 March 2024, 18:21:57 UTC | Revert Gradle 8.7 upgrade (#1385) This caused configuration issues on M1 Macs; see #1383 | 28 March 2024, 18:21:57 UTC |
| ab9f2e2 | Raffi Khatchadourian | 28 March 2024, 16:37:12 UTC | Refactor `EclipseSourceFileModule` to make it more extension-friendly (#1382) The removed null checks seem to happen further up the class hierarchy. Replace the static construction method with a public constructor. A lone private constructor basically makes it basically impossible to subclass. | 28 March 2024, 16:37:12 UTC |
| 3a2ca2e | Ben Liblit | 24 March 2024, 21:37:02 UTC | Use new API for updating collection properties More details [here](better-api-for-updating-collection-properties). | 24 March 2024, 23:54:58 UTC |
| d7bd366 | Ben Liblit | 24 March 2024, 21:08:27 UTC | Upgrade to Gradle 8.7 | 24 March 2024, 23:54:58 UTC |
| 8927f91 | Raffi Khatchadourian | 21 March 2024, 18:38:33 UTC | Write `AbstractScriptEntity.toString()` in terms of `getName()` (#1380) Fixes https://github.com/wala/WALA/issues/1378. | 21 March 2024, 18:38:33 UTC |
| 8a8f874 | Manu Sridharan | 21 March 2024, 17:10:29 UTC | Switch to ConcurrentHashMap in SeqClassHierarchyFactory (#1379) I believe this should address #1377. See https://github.com/wala/WALA/commit/74b6c744926146ecaeaae5da5a74e18c95891fff. For some reason at that point we decided not to use the type system to enforce use of a `ConcurrentHashMap` always. In this spirit of trying not to break things I didn't do that here, but instead changed `SeqClassHierarchyFactory` to use `ConcurrentHashMap`. Fixes #1377 (though we can reopen if the crash still happens) | 21 March 2024, 17:10:29 UTC |
| 45fa20f | Manu Sridharan | 10 March 2024, 17:43:47 UTC | Update to NullAway 0.10.24 and enable experimental JSpecify mode (#1374) NullAway's JSpecify mode does greater checking around generic types. It is still experimental, but I will ensure that future fixes in JSpecify mode won't break WALA's build. | 10 March 2024, 17:43:47 UTC |
| ae3b95d | Aakash Gnanakumar | 07 March 2024, 18:38:50 UTC | analysisScope toJson function (#1355) Added a new function to serialize an `AnalysisScope` to JSON format. --------- Co-authored-by: Manu Sridharan <msridhar@gmail.com> | 07 March 2024, 18:38:50 UTC |
| 0e3068a | Ben Liblit | 04 March 2024, 18:43:54 UTC | Upgrade to Gradle Download Task 5.6.0 | 04 March 2024, 19:24:34 UTC |
| dc54ebc | Manu Sridharan | 02 March 2024, 22:30:20 UTC | Update to Error Prone 2.25.0 and NullAway 0.10.23 (#1371) Just to stay up to date | 02 March 2024, 22:30:20 UTC |
| be01a46 | Ben Liblit | 09 February 2024, 03:07:45 UTC | Correct and simplify access to Javadoc directory The previous approach was needlessly complicated. It was also flat-out wrong, since it turned a property (rather than a property's value) into a `String` for use in a `File` name. | 09 February 2024, 04:58:40 UTC |
| 95e4563 | Ben Liblit | 15 January 2024, 17:32:21 UTC | Simplify access to single properties If we only need to fetch a single property, then we don't need to build an entire mutable `Map` that represents all properties. | 09 February 2024, 03:28:57 UTC |
| 130b92c | Manu Sridharan | 28 January 2024, 03:35:47 UTC | Fix issue 1356 (#1367) Change how we access the `TypeAbstraction` in a `Context` to avoid a `ClassCastException`. Fixes #1356 | 28 January 2024, 03:35:47 UTC |
| 675cee8 | Manu Sridharan | 22 January 2024, 22:41:26 UTC | Add some generic type arguments (#1365) Everything seems to compile fine with these changes. Let's us get rid of a rawtypes suppression. | 22 January 2024, 22:41:26 UTC |
| f7f4df0 | Manu Sridharan | 21 January 2024, 17:57:03 UTC | Version updates: Error Prone, NullAway, Gradle Error Prone Plugin (#1364) To stay up to date | 21 January 2024, 17:57:03 UTC |
| e370e9c | Ben Liblit | 15 January 2024, 18:45:38 UTC | Update JSON dependency to pick up a CVE fix | 15 January 2024, 23:36:28 UTC |
| aa8fdfd | Ben Liblit | 15 January 2024, 18:42:24 UTC | Remove obsolete dependency tweaks We needed each of these dependency tweaks at some point, but everything builds fine now without them. | 15 January 2024, 22:51:43 UTC |
| f908bdd | Ben Liblit | 15 January 2024, 18:40:52 UTC | We're not currently using any unstable Gradle APIs | 15 January 2024, 22:13:06 UTC |
| 42d606b | Ben Liblit | 15 January 2024, 18:12:58 UTC | Use an explicit setter to help IntelliJ IDEA For some reason, IntelliJ IDEA's Kotlin support does not recognize that `destinationDir = ...` is a correct invocation of the `setDestinationDir` setter. That works just fine when run in Gradle, but IntelliJ IDEA flags it as an error. To keep IntelliJ IDEA happy, we can write this property assignment as an explicit setter call instead. | 15 January 2024, 22:04:16 UTC |
| a153f4c | Ben Liblit | 15 January 2024, 17:30:57 UTC | Simplify access to current project's members there's no need to explicitly use `project.` to get the current project when that project is already a Kotlin implicit receiver. | 15 January 2024, 21:44:30 UTC |
| b2f7fc7 | Manu Sridharan | 15 January 2024, 02:49:23 UTC | Update to R8 8.2.46 (#1358) https://issuetracker.google.com/issues/316744331 has been fixed in this version, so we can remove our hack that allowed for extra Java call graph edges in one test. | 15 January 2024, 02:49:23 UTC |
| c8424c8 | Ben Liblit | 15 January 2024, 00:57:52 UTC | Document required Java versions for building or using WALA | 15 January 2024, 01:24:14 UTC |
| 78cb53b | Ben Liblit | 14 January 2024, 23:21:39 UTC | Upgrade to Eclipse 4.30.0 This newer Eclipse release requires Java 17 or better. However, we still prefer to keep most of WALA compatible with Java 11. Therefore, this Eclipse upgrade adds nontrivial build infrastructure to let us use a newer Java release only where Eclipse dependencies require it. A new `com.ibm.wala.jdk-version` property in `gradle.properties` allows setting the default Java version used throughout WALA. If this property is set to 17 or higher, then that same version is used both for Eclipse-dependent and Eclipse-independent WALA components. However, if this property is set to 16 or earlier, then it is only used for WALA's Eclipse-independent components; the Eclipse-dependent components will override this and use Java 17 instead. In a default configuration, most of WALA will be compiled with (and for) Java 11, with the Eclipse-dependent components using Java 17 instead. Resolves #1354. | 15 January 2024, 01:24:14 UTC |
| b04124b | Manu Sridharan | 03 January 2024, 15:26:17 UTC | Prepare next development version. | 03 January 2024, 15:26:17 UTC |
| 9766eb9 | Manu Sridharan | 03 January 2024, 15:20:52 UTC | Prepare for release 1.6.3 | 03 January 2024, 15:20:52 UTC |
| 59e1e1b | Manu Sridharan | 29 December 2023, 18:09:20 UTC | Update R8 and enable Dalvik tests on JDK 21 (#1353) Updating to the latest R8 version lets us run the Dalvik tests on JDK 21. We disable one check due to https://issuetracker.google.com/issues/316744331; we'll have to update R8 again once that is fixed. We also needed to tweak how we construct the test jar for use with Dalvik. My best guess is some classes caused issues with D8 before, but they no longer do so. Finally, we performed some cleanup in `JVMLDalvikComparisonTest` to make failures easier to understand. Fixes #1349 | 29 December 2023, 18:09:20 UTC |
| 7784c3d | Manu Sridharan | 29 December 2023, 00:18:31 UTC | Update versions for Guava, NullAway, and Gradle versions plugin (#1352) Just to stay up to date | 29 December 2023, 00:18:31 UTC |
| a4bd269 | Manu Sridharan | 24 December 2023, 21:01:06 UTC | Re-add YourKit acknowledgement to README (#1351) We previously had this on the WALA MediaWiki home page. | 24 December 2023, 21:01:06 UTC |
| e2fcdf3 | Manu Sridharan | 21 December 2023, 18:01:34 UTC | Update to Error Prone 2.24.0 (#1350) Just to stay up to date | 21 December 2023, 18:01:34 UTC |
| b5f3d51 | Manu Sridharan | 18 December 2023, 02:48:59 UTC | Support building on JDK 21, and don't crash on JDK 21 bytecodes (#1339) With these changes, WALA builds and runs on JDK 21, and our regression tests pass, except for the Dalvik tests. The Dalvik test issue is tracked as #1349. I think it's best to land these changes now, since they include important fixes for JDK 21 support. We can then fix Dalvik in a follow-up. The main logic fix was to update the native models for `java.lang.Thread` to account for implementation changes there. Also there are a bunch of changes due to the deprecation of the `URL(String)` constructor. | 18 December 2023, 02:48:59 UTC |
| 7a13052 | Ben Liblit | 09 December 2023, 22:30:45 UTC | Upgrade to Spotless 6.23.3 In addition to the usual automated tests, I've also manually verified that `./gradlew compile{,Test}Java` succeeds and correctly uses the configuration cache on an M2 macOS machine using either Java 11 or 17. So these changes should not cause a regression of #1230 or #1278. | 09 December 2023, 23:54:51 UTC |
| b681c87 | Ben Liblit | 09 December 2023, 22:06:31 UTC | Upgrade to Kotlin 1.9.20 | 09 December 2023, 22:49:41 UTC |
| 2c80c5d | Ben Liblit | 09 December 2023, 21:53:04 UTC | Use Kotlin DSL type-safe accessors I find these to be a bit more readable than `the<T>` and `configure<T>`. | 09 December 2023, 22:38:25 UTC |
| e9e561e | Ben Liblit | 09 December 2023, 21:04:58 UTC | Remove an unnecessary argument injection We don't need to inject a `Project` argument into this custom task's constructor. The `JavaExec` superclass already has a perfectly good `getProject` method, and the value that it returns will already have been initialized before we are initializing this custom task's fields. | 09 December 2023, 22:01:46 UTC |
| 380b3df | Ben Liblit | 09 December 2023, 19:43:33 UTC | Use structured KDoc comments Also conform to KDoc conventions: initial capital letter and trailing period for the first sentence. | 09 December 2023, 21:54:00 UTC |
| 1144a18 | Manu Sridharan | 08 December 2023, 22:33:26 UTC | Bump the goomph plugin version (#1343) Fixes #1278, as a fix for https://github.com/diffplug/goomph/issues/211 has landed in this release. 🎉 | 08 December 2023, 22:33:26 UTC |
| 9fb344a | Manu Sridharan | 05 December 2023, 18:34:52 UTC | Update logo URL in README (#1342) Fixes #1340. I recovered the logo from the Internet Archive! New URL is https://wala.github.io/logos/WALA-banner.png. | 05 December 2023, 18:34:52 UTC |
| bbede74 | Manu Sridharan | 05 December 2023, 17:56:26 UTC | Update Error Prone and NullAway (#1341) Just to stay up to date | 05 December 2023, 17:56:26 UTC |
| a8e0f96 | Manu Sridharan | 01 December 2023, 20:06:00 UTC | Update to Gradle 8.5 (#1338) | 01 December 2023, 20:06:00 UTC |
| 5aa300b | Manu Sridharan | 08 November 2023, 18:06:00 UTC | Update URLs for tutorial slides (#1336) The old URLs pointing to Sourceforge no longer work. Fixes #1335 | 08 November 2023, 18:06:00 UTC |
| d7b4089 | Ben Liblit | 15 October 2023, 23:19:39 UTC | Don't call toString unless actually needed For each of these assertions, if the check succeeds, then no diagnostic message will be formed and there's no need to call `toString`. | 31 October 2023, 01:43:53 UTC |
| 6b4aff9 | Ben Liblit | 15 October 2023, 23:34:23 UTC | Expose some types that are used in exposed APIs `com.ibm.wala.cast.test.TestCAstTranslator.checkAssertions` is a `public` method that takes an argument of type `com.ibm.wala.cast.test.TestCAstTranslator.TranslatorAssertions`. The latter, therefore, needs to be `public` as well or else the checkAssertions` method can never be called. Similarly, `com.ibm.wala.core.tests.shrike.DynamicCallGraphTestBase.check` is a `protected` method that takes an argument of type `com.ibm.wala.core.tests.shrike.DynamicCallGraphTestBase.EdgesTest`. The latter must at least have `protected` visibility too, or else the `check` method can never be called. | 16 October 2023, 04:28:27 UTC |
| 28b06aa | Ben Liblit | 07 October 2023, 16:21:10 UTC | Upgrade to Gradle 8.4 | 08 October 2023, 00:24:15 UTC |
| f32887d | Ben Liblit | 10 September 2023, 01:47:39 UTC | Set Javadoc doclet options during task configuration This task's doclet options are inputs to the task. We should set them during task configuration time for more precise caching. | 10 September 2023, 02:13:19 UTC |
| 1139fe7 | Ben Liblit | 10 September 2023, 01:46:54 UTC | Set executable during task configuration This task's `executable` is an input to the task. We should set it during task configuration time for more precise caching. | 10 September 2023, 02:13:19 UTC |
| 3e083a5 | Ben Liblit | 10 September 2023, 01:20:14 UTC | Simplify setting a property This property setting is simple and speedy. We may as well do it eagerly, at configuration time, so that it can be recorded as a task input. | 10 September 2023, 02:13:19 UTC |
| 36fc03d | Manu Sridharan | 07 September 2023, 23:13:50 UTC | Update to NullAway 0.10.14 (#1325) | 07 September 2023, 23:13:50 UTC |
| 2666617 | Ben Liblit | 06 September 2023, 01:11:41 UTC | Remove redundant initializers In most of these cases, the initializer is redundant because some other assignment to the same location appears after the initialization but before any use. In a few cases involving fields, the explicit initialization value is identical to what would be used implicitly. | 06 September 2023, 18:21:42 UTC |
| 9962d3c | Ben Liblit | 04 September 2023, 18:51:31 UTC | Avoid memory leak for thread-local values Setting the thread-local value to `null` is not the same as removing it. The former retains an entry mapping the current thread's value to `null` in a hidden global map. The latter removes the current thread's entry entirely. | 06 September 2023, 01:13:44 UTC |
| e8967ec | Ben Liblit | 04 September 2023, 18:39:18 UTC | Conform to Python naming conventions Python local variables generally use `snake_case` names. | 05 September 2023, 22:56:30 UTC |
| 4369ca2 | Ben Liblit | 04 September 2023, 18:45:09 UTC | Add explicit Kotlin types These values are returned from Java code without nullability information. Kotlin needs a little extra help to know whether those Java APIs can return `null` here or not. | 05 September 2023, 21:57:22 UTC |
| 1f962e6 | Ben Liblit | 04 September 2023, 18:46:47 UTC | Suppress warnings about safe `this` leaks Leaking `this` before the constructor has completed can be dangerous in general, specifically if any methods are called or not-yet-initialized fields are used. However, in the specific cases addressed here, the escaping `this` is merely recorded in fields of other objects for later use. Members of `this` instance are not actually used during construction, so these escapes are safe. | 05 September 2023, 21:39:05 UTC |
| ab4e3e8 | Ben Liblit | 04 September 2023, 19:03:53 UTC | Suppress warnings about unstable Gradle APIs We're intentionally using [an unstable Gradle Kotlin feature that allows direct `... = ...` assignment to `Property` instances](https://blog.gradle.org/simpler-kotlin-dsl-property-assignment). This feature may be considered unstable, but it's stable enough to have been [enabled by default since Gradle 8.2](https://docs.gradle.org/8.2.1/release-notes.html#simple-property-assignment-in-kotlin-dsl-enabled-by-default). | 05 September 2023, 20:18:44 UTC |
| df52cbb | Ben Liblit | 04 September 2023, 18:10:36 UTC | Correct redundant escaping Whoever wrote these `String.replaceAll` calls was a bit confused about how backslashes behave in the replacement text. They actually behave less like backslashes in generic `String` literals, and more like backslashes in regular expressions. For example, to replace a newline with a backslash followed by an `n`, the replacement text should be `\\\\n`, not `\\n`. I've added a test for `com.ibm.wala.types.generics.MethodTypeSignature.getArguments()` to affirm that my changes there leave us with an implementation that has the intended effects. I haven't added a `com.ibm.wala.cast.js.html.DomLessSourceExtractor.HtmlCallback.quotify(String)` test, though, because this method is buried too deep inside `protected` APIs that are difficult for a unit test to get access to. Instead, to argue that the new code matches the original `quotify` authors' likely intent, contrast these two JShell approximations: * old code: ```plain jshell> System.out.println("foo\n\"bar".replaceAll("\"", "\\\"").replaceAll("\n", "\\n")) foon"bar ``` * new code: ```plain System.out.println("foo\n\"bar".replaceAll("\"", "\\\\\"").replaceAll("\n", "\\\\n")) foo\n\"bar ``` | 04 September 2023, 19:08:16 UTC |
| 6a24203 | Ben Liblit | 27 August 2023, 21:06:28 UTC | Simplify emptiness checks Don't ask for the exact size of a `Collection` or length of a `String` when all we really care about is (non-)emptiness. | 04 September 2023, 16:29:48 UTC |
| 7a2a511 | Ben Liblit | 27 August 2023, 20:49:07 UTC | Prefer indexing over explicit `get` | 04 September 2023, 02:35:29 UTC |
| c7e83e3 | Ben Liblit | 27 August 2023, 19:41:49 UTC | Upgrade Error Prone | 02 September 2023, 19:49:18 UTC |
| c7ebf42 | Ben Liblit | 27 August 2023, 19:43:12 UTC | Upgrade GSON | 02 September 2023, 19:49:18 UTC |
| a42c9ae | Ben Liblit | 27 August 2023, 19:43:04 UTC | Upgrade Guava | 02 September 2023, 19:49:18 UTC |
| 7164ff7 | Ben Liblit | 27 August 2023, 19:42:33 UTC | Upgrade SLF4J | 02 September 2023, 19:49:18 UTC |
| 38b8f71 | Ben Liblit | 27 August 2023, 19:35:18 UTC | Upgrade Apache Commons IO | 02 September 2023, 19:49:18 UTC |
| 9e6d96f | Ben Liblit | 27 August 2023, 19:34:03 UTC | Upgrade JUnit | 02 September 2023, 19:49:18 UTC |
| c0ded51 | Ben Liblit | 27 August 2023, 19:32:24 UTC | Upgrade Ant | 02 September 2023, 19:49:18 UTC |
| a35e8d8 | Ben Liblit | 27 August 2023, 19:31:03 UTC | Upgrade ktfmt (Kotlin formatter) | 02 September 2023, 19:49:18 UTC |
| e19fffb | Ben Liblit | 27 August 2023, 19:30:34 UTC | Upgrade Spotless | 02 September 2023, 19:49:18 UTC |
| 31c872e | Ben Liblit | 27 August 2023, 19:28:14 UTC | Update Google Java formatter Also use this updated formatter to bulk reformat all Java code. | 02 September 2023, 19:49:18 UTC |
| cafc137 | Ben Liblit | 27 August 2023, 19:22:08 UTC | Upgrade gradle-download-task | 02 September 2023, 19:49:18 UTC |
| bb323c0 | Manu Sridharan | 20 August 2023, 18:08:17 UTC | Update configuration-cache-for-platform-specific-build plugin (#1312) Follow up to #1311. I didn't realize I had to update this version number in two places. #1278 remains as an issue even after this update. | 20 August 2023, 18:08:17 UTC |
| 09c8899 | Manu Sridharan | 20 August 2023, 17:18:07 UTC | Update Gradle Goomph plugin (#1311) Fixes #1278. I can't reproduce that problem on this latest version. | 20 August 2023, 17:18:07 UTC |
| c3f2352 | Ben Liblit | 19 August 2023, 21:32:32 UTC | Upgrade to Gradle 8.3 | 20 August 2023, 16:26:17 UTC |
| 891491c | Ben Liblit | 19 August 2023, 18:57:30 UTC | Tag additional slow tests Empirically, these tests start but take a long time to finish on my personal laptop. Some of them wedge the entire laptop, requiring that I cycle power to recover. Granted, my laptop is a bit old and not the most powerful. I think it's reasonable to skip a few tests to make development on this laptop feasible. We still run the full test suite, including "slow"-tagged tests, in our GitHub Actions workflows. | 20 August 2023, 01:05:17 UTC |
| caffc53 | Ben Liblit | 05 August 2023, 21:26:32 UTC | Remember to close a test jar file The `instrumenter.nextClass()` call in this test helper method opens the jar file that is identified by `instrumentedJarLocation`. Previously, nothing subsequently closed that jar file. This open-file leak causes trouble on Windows: Windows refuses to delete an open file, which then causes post-test `@TempDir` cleanup to fail. Now we explicitly close `instrumenter`, which in turn closes the jar file, which in turn allows post-test `@TempDir` cleanup to succeed on Windows. | 06 August 2023, 21:42:21 UTC |
| dce789a | Ben Liblit | 05 August 2023, 18:44:39 UTC | Let JUnit 5 manage tests' temporary files This change implements [a suggestion previously made by @msridhar](https://github.com/wala/WALA/pull/1301#discussion_r1275297725), not just in the class originally under review, but in several other test (and test fixture) classes as well. | 06 August 2023, 21:42:21 UTC |
| aaefe9b | Ben Liblit | 05 August 2023, 19:48:53 UTC | Stop using Project.getBuildDir() [`Project.getBuildDir()` will likely be deprecated in Gradle 8.3.](https://github.com/gradle/gradle/issues/20210) Fortunately we only had a few remaining uses of this getter, all easily modernized. | 05 August 2023, 21:28:26 UTC |
| 1138313 | Manu Sridharan | 04 August 2023, 17:47:24 UTC | Prepare next development version. | 04 August 2023, 17:47:24 UTC |
| bdd7d44 | Manu Sridharan | 04 August 2023, 17:39:43 UTC | Prepare for release 1.6.2. | 04 August 2023, 17:39:43 UTC |
| ccd4fcb | Manu Sridharan | 02 August 2023, 21:30:51 UTC | Update NullAway to 0.10.12 (#1305) Just to stay up to date | 02 August 2023, 21:30:51 UTC |
| dee8a7e | Ben Liblit | 31 July 2023, 07:19:35 UTC | Remove JUnit 4 dependency All tests and test infrastructure have been migrated or ported to JUnit 5. Nothing remains that uses JUnit 4. | 31 July 2023, 21:29:44 UTC |
| 9c4529e | Ben Liblit | 31 July 2023, 06:21:35 UTC | Port soft assertions from JUnit 4 to JUnit 5 + AssertJ JUnit 5 itself offers only a very limited API for soft assertions. The rigid structure of this API does not align well with ways that WALA already uses soft assertions. AssertJ offers much more flexibility, if we're willing to pick that up as an additional dependency. | 31 July 2023, 14:47:00 UTC |
| 0c311d9 | Ben Liblit | 23 July 2023, 22:54:40 UTC | Port WalaTestCase.justThisTest from JUnit 4 to JUnit 5 `WalaTestCase.justThisTest` offers a convenient way to run a single test class as a `main` application. Previously this worked using JUnit 4; now it uses JUnit 5. | 31 July 2023, 04:09:49 UTC |
| 4f39c61 | Ben Liblit | 23 July 2023, 22:20:51 UTC | Migrate parameterized DroidBench tests from JUnit 4 to JUnit 5 IntelliJ IDEA does not know how to migrate parameterized tests, so these test classes were migrated by hand. | 31 July 2023, 01:38:55 UTC |
| 70eb6e9 | Ben Liblit | 26 July 2023, 02:23:55 UTC | Port a few JUnit 4 odds and ends to JUnit 5 These miscellaneous uses of JUnit 4 escaped my attention in other recent conversion passes. | 26 July 2023, 17:43:49 UTC |
| 63f3303 | Ben Liblit | 23 July 2023, 23:17:27 UTC | Migrate slow tests from JUnit 4 to JUnit 5 These tests were all migrated by hand, including updating the Gradle logic for conditionally excluding them. | 26 July 2023, 04:07:22 UTC |
| b4806b9 | Ben Liblit | 23 July 2023, 23:45:46 UTC | Migrate a few test classes from JUnit 4 to JUnit 5 IntelliJ IDEA does not know how to migrate tests that are expected to fail, so these were ported by hand. | 26 July 2023, 03:22:21 UTC |
| 7b8d005 | Ben Liblit | 23 July 2023, 19:48:56 UTC | Migrate many tests from JUnit 4 to JUnit 5 Most of these migrations were mechanized using IntelliJ IDEA followed by some manual cleanups. A few were migrated entirely manually, such as the expected-to-fail tests in `FieldBasedComparisonTest`. | 26 July 2023, 01:46:35 UTC |
| cdeb11d | Ben Liblit | 26 July 2023, 00:31:59 UTC | Generate a summary test report for all builds My intent is for this summary report to increase our confidence that we're not accidentally dropping any tests or dramatically hurting test performance as we [migrate from JUnit 4 to JUnit 5](https://github.com/orgs/wala/projects/2). The summary report may also turn out to be useful if anyone posts a pull request that causes new test failures, though that's rare from what I've observed. | 26 July 2023, 00:52:52 UTC |
| f0d63fd | Ben Liblit | 24 July 2023, 22:39:42 UTC | Generate a summary test report for all builds My intent is for this summary report to increase our confidence that we're not accidentally dropping any tests or dramatically hurting test performance as we [migrate from JUnit 4 to JUnit 5](https://github.com/orgs/wala/projects/2). The summary report may also turn out to be useful if anyone posts a pull request that causes new test failures, though that's rare from what I've observed. Full disclosure: I do not actually understand all the instructions on configuring the report generator to [Support fork repositories and dependabot branches](https://github.com/EnricoMi/publish-unit-test-result-action#support-fork-repositories-and-dependabot-branches) or for [Running with multiple event types (pull_request, push, schedule, …)](https://github.com/EnricoMi/publish-unit-test-result-action#support-fork-repositories-and-dependabot-branches). I'm probably not doing everything correctly here. It seems to be working just fine, though, even in my forked repository. So let's just charge ahead and see what fails, if anything. | 26 July 2023, 00:52:52 UTC |
| e8bda11 | Ben Liblit | 25 July 2023, 17:18:40 UTC | Remove more debugging output produced during testing Also, turn `com.ibm.wala.cast.ipa.callgraph.CAstCallGraphUtil.AVOID_DUMP` into a thread-local flag. We should be able to turn it on or off without potential interference from different threads (e.g., during concurrent test execution) that have conflicting opinions. | 25 July 2023, 22:10:35 UTC |
| a05945e | Ben Liblit | 25 July 2023, 00:44:03 UTC | Avoid printing some call graphs during testing Following up #1294 by removing a few more rarely examined graph dumps. | 25 July 2023, 02:40:00 UTC |
| 7ac9913 | Ben Liblit | 25 July 2023, 00:44:03 UTC | Avoid printing many call graphs during testing These graph dumps add hundreds of megabytes to test logs, and presumably are manually inspected approximately never. Let's turn them off. Anyone chasing a specific bug or regression can add more debug output in their local working tree, as needed, but there's no benefit to dumping all of this data on every automated test run. Furthermore, I'm exploring an option for getting a nice test summaries after each GitHub actions workflow run. Unfortunately, the tool I am considering has some limits on the sizes `CDATA` sections it can read in JUnit's XML test logs. When our test logs include call graph dumps, several of them exceed these limits. | 25 July 2023, 01:36:37 UTC |
| 486c4a2 | Ben Liblit | 23 July 2023, 02:30:51 UTC | Always use static imports for org.junit.Assert `org.junit.Assert` provides static JUnit 4 assertion methods. Many of these methods have JUnit 5 analogues in `org.junit.jupiter.api.Assertions`, but we're not switching over to the latter yet. Instead, we're just changing to using static imports to get the same `org.junit.Assert` methods we were already using. By switching to static imports now, we make it easier to change from JUnit 4 to JUnit 5 later. In most cases, we'll just have to change the top-of-file static imports, not the code that actually calls the imported methods. That should make diffs in subsequent pull requests smaller and easier to review. | 23 July 2023, 19:23:45 UTC |
| 41501d7 | Ben Liblit | 23 July 2023, 18:10:57 UTC | Update IntelliJ IDEA project metadata for Kotlin 1.9.0 | 23 July 2023, 18:56:00 UTC |
| e6b22b9 | Ben Liblit | 23 July 2023, 01:45:34 UTC | Migrate one test class from JUnit 4 to JUnit 5 The migration was mostly automated by IntelliJ IDEA. We're starting with just a single test class so that we have a clear demonstration of the kinds of changes that will later be applied more broadly. It's also good to verify here, by manual inspection, that we are correctly running a mix of `core` tests from JUnit 5 (`ExtensionGraphTest`) and JUnit 4 (all the rest). This confirms that it's OK to use multiple `TestEngine`s at the same time, which in turn confirms that it's OK to migrate tests from JUnit 4 to JUnit 5 incrementally rather than in one giant batch. | 23 July 2023, 18:07:31 UTC |
| 53835b2 | Ben Liblit | 22 July 2023, 18:15:09 UTC | Use JUnit 5 to find and run tests The tests themselves are still written using JUnit 4, so we're using JUnit 5's Vintage component to discover and run those tests. Hooray for backward compatibility! Eventually we can try porting JUnit 4 tests forward to JUnit 5, but this is a decent first step. | 23 July 2023, 17:19:24 UTC |
