JaCoCo is a free Java code coverage library distributed under the Eclipse Public License. Check the project homepage for downloads, documentation and feedback.
Please use our mailing list for questions regarding JaCoCo which are not already covered by the extensive documentation.
JaCoCo should support configurable filtering options for code coverage analysis. This page lists of use cases and requirements: https://github.com/jacoco/jacoco/wiki/FilteringOptions
type: enhancement component: core.filtersWe have had issues with gaining accurate cross module code coverage numbers with jacoco. For instance when code in module A is touched during tests from module B, in our case when they are both part of a multi-module build.
This pull request makes it possible to report coverage numbers on classes outside of the current module. By adding a list of sourceFolders and classFolders which is a list of source and class folders outside of the current module to be scanned for classes to report coverage on.
The aggregate-report then concatenates the jacoco.exec files from reactor projects so that a unified report can be created.
type: enhancement component: mavenLatest snapshot build: Snapshot Repository
We need a new ASM version which supports class file version 52.0. ASM 5.0_BETA is released to Maven central repo.
JaCoCo needs to be adjusted to ASM5 APIs. This has been done on a experimental branch.
The ModifiedSystemClassRuntime does not work any more with JRE 8. So an alternative Runtime has to be selected. The UrlStreamHandlerRuntime seems to do the job.
With JDK 8 JavaDoc generated by Maven fails to compile due to Lint checks. As a workaround we can disable this check for the Maven plugin.
The JDK 8 compiler missed line number information in certain cases which makes our integration tests fail (and also leads to wrong line coverage results).
type: enhancement component: coreVersion info: Gradle 2.2.1 Android Gradle plugin 1.0.1 Robolectric Gradle plugin 0.14.1 JUnit 4.10 Robolectric 2.4
Setting up a simple test using a configuration like:
apply plugin: 'jacoco'
jacoco.toolVersion = project.property('jacocoVersion')
and running my unit tests with:
$ ./gradlew -PjacocoVersion=0.7.1.+ clean :testDebug :jacocoTestDebugReport
...
$ ls -l build/jacoco/testDebug.exec
-rw-r--r--+ 1 jhansche staff 278218 Feb 26 16:45 build/jacoco/testDebug.exec
$ strings build/jacoco/testDebug.exec | wc -l
4325
This all works correctly, and I get a proper JaCoCo report generated. Changing nothing else but the toolVersion, however, breaks the execution data that is gathered:
$ ./gradlew -PjacocoVersion=0.7.4-SNAPSHOT clean :testDebug :jacocoTestDebugReport
...
$ ls -l build/jacoco/testDebug.exec
-rw-r--r--+ 1 jhansche staff 36910 Feb 26 16:56 build/jacoco/testDebug.exec
$ strings build/jacoco/testDebug.exec | wc -l
639
You can see that the execution data file is much smaller, and contains far fewer strings. Looking at the "Sessions" link in the top-right of the HTML report lists only one class from my application's package (the Android app's R$styleable class). The majority of the classes listed are in one of the org.gradle, org.junit, or org.robolectric packages. Using 0.7.1, it included all the android.** classes, and more importantly, the classes from my application.
However, when I set the test.jacoco.classDumpFile = file("${project.buildDir}/jacoco/dump") property, I do see most of my application's (tested) classes listed in that directory -- they just don't show up in the execution data file.
One other difference that I notice in the dump/ directory (for a single example test class):
0.7.1: build/jacoco/dump//com/example/MyClass.class build/jacoco/dump//com/example/MyClassTest.class
0.7.4: build/jacoco/dump//com/example/MyClass.9b700a23ba643d32.class build/jacoco/dump//com/example/MyClassTest.22115a9aa9d0d3ee.class
I'm in a difficult position as now I am forced to use two different versions of JaCoCo: 0.7.1 with Robolectric+JUnit to get coverage of unit tests on the local JVM; and 0.7.3+ with Calabash to get coverage of instrumentation tests running on the device's runtime -- I am forced to update to 0.7.3 in order to allow support for the Android ART runtime, as otherwise the instrumented classes cannot be installed on a Lollipop device.
What other information can I provide to help track down what is going wrong here? If it's not a bug in JaCoCo, then who is to blame? (I realize there is a very long list of potential candidates for where it should be fixed).
type: bug :bug: component: coreHi, recently I used Jacoco 0.7.2 to test our AppServer, Encountered such a problem:
java.nio.channels.OverlappingFileLockException
at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1030)
at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
at org.jacoco.agent.rt.internal_e6e56f0.output.FileOutput.openFile(FileOutput.java:69)
at org.jacoco.agent.rt.internal_e6e56f0.output.FileOutput.writeExecutionData(FileOutput.java:53)
at org.jacoco.agent.rt.internal_e6e56f0.Agent.shutdown(Agent.java:137)
at org.jacoco.agent.rt.internal_e6e56f0.Agent$1.run(Agent.java:54)
In Jacoco Offline, are there different threads to synchronisation/write locking for jacoco.exec in one JVM? In order to avoid concurrent writes from different threads running in parallel in one JVM, I changed some code, it can solve our problem temporarily, as below:
private OutputStream openFile() throws IOException {
final FileOutputStream file = new FileOutputStream(destFile, append);
int retries = 5;//retries 5 times
// Avoid concurrent writes from different agents running in parallel:
for (int t = 0; t < retries; t++)
try{
file.getChannel().lock();
break;
}catch(OverlappingFileLockException ofe){
System.out.println("[JACOCO][RT] Got OverlappingFileLockException, re-trying.");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
//ignore
}
}
return file;
}
Please help to check the issue.
type: enhancement component: coreThis is an alternative approach to the PR proposed in #261. The objective is to improve covered result in case implicit exceptions are thrown by method invocations. Instead of adding a extra probe for every method invocation this PR adds probes only between source lines -- and only if the subsequent line contains at least one method invocation.
This reduces the number of extra probes needed and at the same time provides better results in case of implicit exceptions in multi-line blocks.
type: enhancement component: coreJaCoCo cannot re-calculate stackmap frames as this is an expensive operation and would require knowing the type hierarchy (which is not available). Also ASM default implementation for the type hierarchy actually loads(!) the classes.
Therefore in JaCoCo special care has been taken to incrementally update the stackmap frames during instrumentation.
It has been reported that the stackmap frame are re-calculated anyways is special situations, stack trace:
java.lang.ClassNotFoundException: javax.servlet.jsp.tagext.BodyContent
at org.jacoco.asm.ClassWriter.getCommonSuperClass(Unknown Source)
at org.jacoco.asm.ClassWriter.a(Unknown Source)
at org.jacoco.asm.Frame.a(Unknown Source)
at org.jacoco.asm.Frame.a(Unknown Source)
at org.jacoco.asm.MethodWriter.visitMaxs(Unknown Source)
at org.jacoco.asm.ClassReader.a(Unknown Source)
at org.jacoco.asm.ClassReader.b(Unknown Source)
at org.jacoco.asm.ClassReader.accept(Unknown Source)
at org.jacoco.asm.ClassReader.accept(Unknown Source)
at org.jacoco.asm.ClassWriter.toByteArray(Unknown Source)
at org.jacoco.core.instr.Instrumenter.instrument(Instrumenter.java:79)
at org.jacoco.core.instr.Instrumenter.instrument(Instrumenter.java:139)
Looking at ASM source code it turned out that ASM triggers a frame re-calculation if the methods exceeds a certain size. See MethodWriter.resizeInstructions(). Shit.
Corresponding ASM issue: http://forge.ow2.org/tracker/?func=detail&aid=317551&group_id=23&atid=100023
type: bug :bug: component: coreThis is a issue tracker. Please use our mailing list for general questions: https://groups.google.com/forum/?fromgroups=#!forum/jacoco
Also check FAQ before opening an issue: http://www.jacoco.org/jacoco/trunk/doc/faq.html
Create a javaagent which loads the UUID class and use that agent prior to JaCoCo.
JaCoCo should run normally
JaCoCo fails with an error similar to the following:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:401)
Caused by: java.lang.RuntimeException: Class java/util/UUID could not be instrumented.
at org.jacoco.agent.rt.internal_6effb9e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138)
at org.jacoco.agent.rt.internal_6effb9e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:99)
at org.jacoco.agent.rt.internal_6effb9e.PreMain.createRuntime(PreMain.java:55)
at org.jacoco.agent.rt.internal_6effb9e.PreMain.premain(PreMain.java:47)
... 6 more
Caused by: java.lang.NoSuchFieldException: $jacocoAccess
at java.lang.Class.getField(Class.java:1690)
at org.jacoco.agent.rt.internal_6effb9e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:136)
... 9 more
FATAL ERROR in native method: processing of -javaagent failed
Exception in thread "main"
To finally offer a solution for multi module Maven projects (#18) I did a detailed analysis of the issue together with @jwloka. We documented the results here:
https://github.com/jacoco/jacoco/wiki/MavenMultiModule
As part of the analysis we also reviewed the existing PR #97. We came up with a different solution which should cover the described use cases and should be more robust in terms of build configuration and execution.
Please feel free to add comments regarding the general approach as well as the implementation
type: enhancement component: maven
argLine set to -javaagent:/home/devel/tools/maven/repo/org/jacoco/org.jacoco.agent/0.6.0.201210061924/org.jacoco.agent-0.6.0.201210061924-runtime.jar=destfile=/home/devel/projects/micro/webapp/target/jacoco-unit.execargLine set to -javaagent:/home/devel/tools/maven/repo/org/jacoco/org.jacoco.agent/0.6.0.201210061924/org.jacoco.agent-0.6.0.201210061924-runtime.jar=destfile=/home/devel/projects/micro/webapp/../target/jacoco-it.exec -javaagent:/home/devel/tools/maven/repo/org/jacoco/org.jacoco.agent/0.6.0.201210061924/org.jacoco.agent-0.6.0.201210061924-runtime.jar=destfile=/home/devel/projects/micro/webapp/target/jacoco-unit.exec
As you can see there are two javaagents what results in:
java.lang.instrument.IllegalClassFormatException: Error while instrumenting class org/apache/maven/surefire/booter/ForkedBooter. Caused by: java.lang.IllegalStateException: Class org/apache/maven/surefire/booter/ForkedBooter is already instrumented.
When we remove second javaagent (by defining it in the argLine property in the failsafe-plugin configuration it works great.Example pom's:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.4</version>
<configuration>
<excludedGroups>gui,arquillian</excludedGroups>
</configuration>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<id>jacoco-initialize</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<destFile>${project.basedir}/target/jacoco-unit.exec</destFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profile>
<id>arquillian</id>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<id>pre-integration-test</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<phase>pre-integration-test</phase>
<configuration>
<destFile>${project.basedir}/../target/jacoco-it.exec</destFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.12.4</version>
<configuration>
<groups>gui,arquillian</groups>
<includes>
<include>**/*.java</include>
</includes>
</configuration>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Currently FieldProbeArrayStrategy creates static final field $jacocoData, value for which is set by bytecode instruction putstatic in method $jacocoInit, but according to JVMS:
if the field is final the instruction must occur in the < clinit > method of the current class. Otherwise, an IllegalAccessError is thrown.
Starting with OpenJDK 9 EA b127 this condition is checked for class files with version >=53 - http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c558d46c1af2#l11.76 Unfortunately we compile classes into 52 even with JDK 9, because maven-shade-plugin can't handle 53, and that's why we don't get failure in core validation tests, but later in integration tests for Ant on one of JDK classes:
Exception in thread "main" java.lang.IllegalAccessError: Update to static final field java.sql.Timestamp.$jacocoData attempted from a different method (java.sql.Timestamp) than the initializer method <clinit>
at java.sql.Timestamp.$jacocoInit(java.sql@9-ea/Timestamp.java)
at java.sql.Timestamp.<clinit>(java.sql@9-ea/Timestamp.java)
at org.jacoco.ant.TestTarget.main(TestTarget.java:36)
There is also a report in our mailing list - https://groups.google.com/d/msg/jacoco/jHw39ZUjUNY/L-gHeMeBBQAJ
See https://bugs.openjdk.java.net/browse/JDK-8157181 which is associated with this check and which also states:
Methods that do not satisfy condition violate the assumptions of the compilers. Compiling such methods results in different behavior of compiled and interpreted code.
and which discusses removal of dependency on class file version.
Also might be that this check will be backported - see linked tickets, e.g. https://bugs.openjdk.java.net/browse/JDK-8161989
So that we should try to find a way to compile classes (or at least test targets) into bytecode version 53 ( #411 ).
In any case - field must not be final. But unfortunately this will make FieldProbeArrayStrategy unusable for interfaces with methods, because JVMS states that
type: bug :bug: component: coreFields of interfaces must have their ACC_PUBLIC, ACC_STATIC, and ACC_FINAL flags set
An issue was reported to the D8 issue tracker regarding jacoco and monitor instructions: https://issuetracker.google.com/issues/247932119
The problem seems to be come from kotlin code like the following:
val obj = Any()
try {
synchronized(obj) {
Log.d("Test", "Succeeded")
}
} catch (ex: Exception) {
Log.e("Test", "Failed", ex)
}
That is, having an outer try catch around a synchronized block.
The dissassembled code before jacoco is:
public void run();
descriptor: ()V
flags: (0x0001) ACC_PUBLIC
Code:
stack=7, locals=5, args_size=1
...
71: monitorenter
72: getfield #73 // Field com/fyber/inneractive/sdk/config/k.b:Lcom/fyber/inneractive/sdk/config/k$c;
75: dup
76: astore 4
78: iload_1
79: aload 4
81: iload_2
82: aload 4
84: aload_0
85: putfield #78 // Field com/fyber/inneractive/sdk/config/k$c.a:Ljava/lang/String;
88: putfield #81 // Field com/fyber/inneractive/sdk/config/k$c.b:Z
91: putfield #84 // Field com/fyber/inneractive/sdk/config/k$c.c:Z
94: monitorexit
95: goto 104
98: astore_0
99: aload_0
100: aload_3
101: monitorexit
102: athrow
103: pop
104: return
105: astore_0
...
Exception table:
from to target type
0 6 105 Class java/lang/ClassNotFoundException
7 17 105 Class java/lang/ClassNotFoundException
35 38 103 Class android/provider/Settings$SettingNotFoundException
40 45 103 Class android/provider/Settings$SettingNotFoundException
55 62 103 Class android/provider/Settings$SettingNotFoundException
65 68 103 Class android/provider/Settings$SettingNotFoundException
71 72 103 Class android/provider/Settings$SettingNotFoundException
72 75 98 any
78 94 98 any
94 98 103 Class android/provider/Settings$SettingNotFoundException
99 103 103 Class android/provider/Settings$SettingNotFoundException
Note that the any handler on the monitor body is split in two, from 72-75 target 98 and 78-94 target 98. Jacoco will insert an aput-boolean in between here, but assign it the outer-most try-catch handler thereby escaping a catch handler where the monitor exit instruction should be called. As a result all android vms will report a verify-error:
10-31 06:01:51.084 14348 14348 E AndroidRuntime: java.lang.VerifyError: Verifier rejected class com.fyber.inneractive.sdk.config.s: void com.fyber.inneractive.sdk.config.s.run() failed to verify: void com.fyber.inneractive.sdk.config.s.run(): [0x70] expected to be within a catch-all for an instruction where a monitor is held (declaration of 'com.fyber.inneractive.sdk.config.s' appears in /data/app/com.example.monitorjacoco-UHj9aK0fXwUPdts0cNWNAQ==/base.apk)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at com.example.monitorjacoco.MainActivity$1.onClick(MainActivity.java:43)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.view.View.performClick(View.java:7125)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.view.View.performClickInternal(View.java:7102)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.view.View.access$3500(View.java:801)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.view.View$PerformClick.run(View.java:27336)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:883)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:100)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7356)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
10-31 06:01:51.084 14348 14348 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
I've attached a debug test example where the class and method that cause the problem is in class com/fyber/inneractive/sdk/config/s method run.
Not inserting instructions between catch handlers in monitors.
If you just want the class files without going through a reproduction, I've also attached the classes.jar here, from https://mvnrepository.com/artifact/com.fyber/marketplace-sdk. classes.zip
type: bug :bug: reproducer requiredassert statement coverage should be considered complete if the assert statement was visited. There's no need to track multiple branches at the assert statement.
This is in agreement with the previously reported issue #324, which suggested "They should not be treated as code instructions."
I've extended the ignored instructions to include the assert statement check. This will make coverage complete with or without assertions enabled.
coverage of assert statement is considered complete, line in coverage report is green. Code coverage should be considered complete with or without assertions enabled.
assert statement contains two branches and "1 of 2 branches missed", line in coverage report is yellow.
Currently the only way to obtain full coverage of an assert statement is by running the tests twice in the same test suite, once with assertions enabled, and again with assertions disabled, so both branches of the assert statement enabled test are visited.
https://github.com/jacoco/jacoco/issues/324 raised the problem of only 50% branch coverage. The AssertFilter introduced in 0.8.8 reduced the problem from a "2 of 4 branches missed" to a "1 of 2 branches missed". This wasn't exactly the intension of the #324 issue, which suggested "They should not be treated as code instructions."
(In case of exceptions provide FULL STACKTRACE)
type: bug :bug:Follow-up to https://github.com/jacoco/jacoco/pull/1007. The new includeCurrentProject that has yet to be released is listed in the documentation as available since release 0.7.7.
Bumps scala-library from 2.13.4 to 2.13.9.
Sourced from scala-library's releases.
Scala 2.13.9
The following changes are highlights of this release:
Compatibility with Scala 3
- Tasty Reader: Add support for Scala 3.2 (#10068)
- Tasty Reader: Restrict access to experimental definitions (#10020)
- To aid cross-building, accept and ignore
usingin method calls (#10064 by@som-snytt)- To aid cross-building, allow
?as a wildcard even without-Xsource:3(#9990)- Make Scala-3-style implicit resolution explicitly opt-in rather than bundled in
-Xsource:3(#10012 by@povder)- Prefer type of overridden member when inferring (under
-Xsource:3) (#9891 by@som-snytt)JDK version support
- Make
-releasemore useful, deprecate-target, align with Scala 3 (#9982 by@som-snytt)- Support JDK 19 (#10001 by
@Philippus)Warnings and lints
- Add
-Wnonunit-statementto warn about discarded values in statement position (#9893 by@som-snytt)- Make unused-import warnings easier to silence (support filtering by
origin=) (#9939 by@som-snytt)- Add
-Wperformancelints for*Refboxing and nonlocalreturn(#9889 by@som-snytt)Language improvements
- Improve support for Unicode supplementary characters in identifiers and string interpolation (#9805 by
@som-snytt)Compiler options
- Use subcolon args to simplify optimizer options (#9810 by
@som-snytt)- For troubleshooting compiler, add
-Vdebug-type-error(and remove-Yissue-debug) (#9824 by@tribbloid)Security
- Error on source files with Unicode directional formatting characters (#10017)
- Prevent
Function0execution duringLazyListdeserialization (#10118)Bugfixes
- Emit all bridge methods non-final (perhaps affecting serialization compat) (#9976)
- Fix null-pointer regression in
Vector#prependedAllandVector#appendedAll(#9983)- Improve concurrent behavior of Java
ConcurrentMapwrapper (#10027 by@igabaydulin)- Preserve null policy in wrapped Java
Maps (#10129 by@som-snytt)Changes that shipped in Scala 2.12.16 and 2.12.17 are also included in this release.
For the complete 2.13.9 change lists, see all merged PRs and all closed bugs.
Compatibility
... (truncated)
986dcc1 Merge pull request #10129 from som-snytt/followup/12586-preserve-NPEb824b84 Preserve null policy in wrapped Java Mapd578a02 Merge pull request #10128 from SethTisue/revert-10114-10123e5fe919 Revert "Args files are 1 arg per line, fix -Vprint-args -"362c5d1 Revert "Trim and filter empties in arg files"864148d Revert "process.Parser strips escaping backslash"f69fe8b Merge pull request #10127 from scalacenter/tasty/support-3.2.0-final0aa6bd4 remove tasty escape hatch for 3.2.0-RC4af56abc Merge pull request #10123 from som-snytt/dev/814-window-cmd-escapes7e844a5 Merge pull request #10121 from scala-steward/update/slf4j-nop-2.0.0Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase will rebase this PR@dependabot recreate will recreate this PR, overwriting any edits that have been made to it@dependabot merge will merge this PR after your CI passes on it@dependabot squash and merge will squash and merge this PR after your CI passes on it@dependabot cancel merge will cancel a previously requested merge and block automerging@dependabot reopen will reopen this PR if it is closed@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labels will set the current labels as the default for future PRs for this repo and language@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and languageYou can disable automated security fix PRs for this repo from the Security Alerts page.
NullPointerException during filtering (GitHub #1189).formats parameter for Maven report goals to specify the generated report formats. Contributed by troosan. (GitHub #1175).synthetic methods added by the Kotlin compiler version 1.5.0 and above for private suspending functions are filtered out (GitHub #1174).lateinit property is filtered out during generation of report (GitHub #1166).kotlin.String values is filtered out during generation of report (GitHub #1172).kotlin.String values (GitHub #1156).maven-reporting-impl any more (GitHub #1121).toString, hashCode and equals generated by compiler for records are filtered out during generation of report (GitHub #990).URLStreamHandlerRuntime removed (GitHub #471).synthetic constructors that contain values of default arguments in Kotlin should not be ignored (GitHub #888).long or double should be filtered out during generation of report (GitHub #908).synthetic methods that contain bodies of anonymous functions in Scala should not be ignored (GitHub #912).NullPointerException during filtering (GitHub #942, #944).Analyzer and Instrumenter and thus also during report generation and offline instrumentation (GitHub #952).module-info.class should be excluded from analysis to not cause IllegalStateException (GitHub #859).Instrumenter.instrument(org.objectweb.asm.ClassReader) and Analyzer.analyzeClass(org.objectweb.asm.ClassReader) were removed (GitHub #850).runtime or class and whose simple name contains "Generated" (previously equality was required) are filtered out during generation of report (GitHub #822).synthetic methods that contain values of default arguments in Kotlin should not be ignored (GitHub #774).synthetic methods that represent suspend functions in Kotlin should not be ignored (GitHub #804).includes and excludes from dump, merge and restore-instrumented-classes goals of jacoco-maven-plugin, because they have no effect (GitHub #827).switch statements on java.lang.String values is filtered out during generation of report (GitHub #735, #741, #746).lateinit property is filtered out during generation of report. Implementation by Fabian Mastenbroek (GitHub #707).else of when expressions that list all cases of enum or sealed class is filtered out during generation of report (GitHub #721, #729, #749).kotlin.String values is filtered out during generation of report (GitHub #737, #746).runtime or class and whose simple name is Generated are filtered out during generation of report (GitHub #731).switch statement on java.lang.String values with a small number cases is now correctly filtered out during generation of report (GitHub #730).sourcefilename on the class element to allow unambiguously relate classes to source files. The JaCoCo DTD version has been updated to 1.1 (GitHub #702).check goal and Ant check element now also supports percentage values (GitHub #534).Automatic-Module-Name for Java 9 (GitHub #565).runtime and provided dependencies (GitHub #498, #572).During creation of reports various compiler generated artifacts are filtered out, which otherwise require unnecessary and sometimes impossible tricks to not have partial or missed coverage:
valueOf and values of enum types (GitHub #491).@lombok.Generated to better integrate with Lombok >= 1.16.14. Initial analysis and contribution by Rüdiger zu Dohna (@t1) (GitHub #513).@groovy.transform.Generated to better integrate with Groovy >= 2.5.0. Thanks to Andres Almiray (@aalmiray) for adding the annotation to Groovy (GitHub #610).synchronized blocks (GitHub #501).finally blocks (GitHub #604).switch statements on java.lang.String values (GitHub #596).Note: Tools that directly read exec files and embed JaCoCo for this (such as SonarQube or Jenkins) will provide filtering functionality only after they updated to this version of JaCoCo.
dump commands now report error when server unexpectedly closes connection without sending response (GitHub #538).help goal that was missing in version 0.7.9 (GitHub #559).NullPointerException during offline instrumentation of module-info.class (GitHub #600, GitHub #634).InnerClasses attribute caused by bug in ASM library (GitHub #600).NegativeArraySizeException during instrumentation caused by bug in ASM library (GitHub #600).java.lang.ClassFormatError: Short length on BootstrapMethods in class file" caused by bug in ASM library (GitHub #462).java.lang.ClassNotFoundException might be thrown (GitHub #177).ExecutionDataWriter.FORMAT_VERSION is not a compile-time constant (GitHub #474).JaCoCo.ASM_API_VERSION removed (GitHub #474).uses directives, Require-Capability attribute, and export of all internal packages with x-internal:=true directive (GitHub #211).jacocoant.jar that contains all dependencies (GitHub #211).jacoco.dataFile for parameter dataFile of Maven report goal (GitHub #322).RoundingMode#FLOOR instead of RoundingMode#HALF_EVEN for percentages in HTML report, so that "99.5" is displayed as "99%", not as "100%" (GitHub #452).IllegalAccessError will be thrown starting from OpenJDK 9 EA b127 (GitHub #434).IncompatibleClassChangeError starting from OpenJDK 9 EA b122 (GitHub #428).inclnolocationclasses to support execution environments like Android where no source location is provided with classes (GitHub #288).MBeanClient example (GitHub #333).ConcurrentModificationException during shutdown (GitHub #364).ExecutionDataReader.read() now throws a IncompatibleExecDataVersionException.lifecycle-mapping-metadata.xml for M2E (GitHub #203).inclbootstrapclasses to also instrument classes from the bootstrap class loader (GitHub #49).dump Mojo for Maven plug-in (GitHub #107).merge Mojo for Maven plug-in, contributed by Mads Mohr Christensen (GitHub #126).report-integration and prepare-agent-integration goals for integration tests. (GitHub #152, #161).prepare-agent should not lead to incorrect configuration (GitHub #40).check and merge goal failures in jacoco-maven-plugin with Maven 2.2.1 due to incompatible configuration (GitHub #129).org.jacoco.core.tools for shared high-level tools. (GitHub #159).check goal has been reworked to support checks on any element type (GitHub #106).Analyzer and Instrumenter expect resource name as additional parameter for better error messages (GitHub #104).INVOKEDYNAMIC as JaCoCo is now based on ASM 4.0 (GitHub #5).中文README传送门 What is Auto-Unit-Test-Case-Generator Auto-Unit-Test-Case-Generator generates JUnit test suites for Java class just as its name. During te
Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence. It is based on libFuzzer and brings many of its instrumentation-powered mutation features to the JVM.
What is Firing Range? Firing Range is a test bed for web application security scanners, providing synthetic, wide coverage for an array of vulnerabili
cglib Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to g
Vavr is an object-functional language extension to Java 8, which aims to reduce the lines of code and increase code quality. It provides persistent co
Checkstyle is a tool for checking Java source code for adherence to a Code Standard or set of validation rules (best practices). Members chat: Contrib
FRC 2022 Team 5468's 2022 FRC robot code. This code is written in Java and is based off of WPILib's Java control system and utilizes a command based s
CK CK calculates class-level and method-level code metrics in Java projects by means of static analysis (i.e. no need for compiled code). Currently, i
mobsfscan is a static analysis tool that can find insecure code patterns in your Android and iOS source code. Supports Java, Kotlin, Swift, and Objective C Code. mobsfscan uses MobSF static analysis rules and is powered by semgrep and libsast pattern matcher.
Orienteer What is Orienteer Orienteer is Business Application Platform: Easy creation of business applications Extendable to fit your needs Dynamic da
FTC Code Organizer This template created by team 19458 Equilibrium.exe makes it easy to keep your code organized and allows the Autonomous and TeleOp
Spoon Spoon is an open-source library to analyze, rewrite, transform, transpile Java source code. It parses source files to build a well-designed AST
Duck Library is a library for developers who don't want to spend their time to write same library consistently. It has almost every useful feature to
qxml English 一个低侵入，可配置的 Android 库，用于将 layout xml 文件转换为 Java 代码以提高性能。 与X2C的对比 X2C： 使用注解处理器生成View类，使用时需要在类中添加注解，并替换setContentView方法，侵入性较强； 对于布局属性的支持不够完美
Violations Lib This is a Java library for parsing report files like static code analysis. Example of supported reports are available here. A number of
A java serialization library with built-in support for forward-backward compatibility (schema evolution) and validation. efficient, both in speed and
A library for IDEs and Code Editors to compile java projects faster dynamically
About ORM16 ORM16 is a library exploring code generation-based approach to ORM for Java 17 and focusing on records as persistent data model. Example I
FXGraphics2D Version 2.1, 3 October 2020. Overview FXGraphics2D is a free implementation of Java's Graphics2D API that targets the JavaFX Canvas. It m
CodeSheriff is a simple library that helps you in writing JUnit tests that check the quality of your code. For example, CodeSheriff may fail because you have methods in your code that have more than X lines of code, or that have complexity greater than Y.
108 Dec 22, 2022
696 Jan 5, 2023
1.3k Jan 7, 2023
4.5k Jan 8, 2023
5.1k Jan 3, 2023
7.5k Jan 8, 2023
4 Oct 4, 2022
286 Jan 4, 2023
347 Dec 29, 2022
189 Dec 6, 2022
5 Nov 10, 2022
1.4k Dec 29, 2022
5 Jul 28, 2022
74 Oct 6, 2022
127 Nov 23, 2022
1.9k Dec 23, 2022
2 Feb 22, 2022
1 Mar 30, 2022
184 Dec 31, 2022