👍 For cleaning-up package visibility!

A remark regarding method isKotlinClass():

• The new location introduces a cyclic dependency between Filters and the Kotlin filter implementations (which we also have at other places)
• The following filters miss this check: KotlinLateinitFilter, KotlinWhenFilter, KotlinWhenStringFilter, KotlinNotNullOperatorFilter

Both could be addressed by creating a separate Group for the Kotlin filters. It also eliminates the repeated isKotlinClass() checks in every filter implementation:

private static IFilter allKotlinFilters() {
	return new Filters( //
			new KotlinGeneratedFilter(), //
			new KotlinEnumFilter(), //
			new KotlinLateinitFilter(), //
			new KotlinWhenFilter(), //
			new KotlinWhenStringFilter(), //
			new KotlinUnsafeCastOperatorFilter(), //
			new KotlinNotNullOperatorFilter(), //
			new KotlinInlineClassFilter(), //
			new KotlinDefaultArgumentsFilter(), //
			new KotlinInlineFilter(), new KotlinCoroutineFilter(), //
			new KotlinDefaultMethodsFilter(), //
			new KotlinComposeFilter()) {
		@Override
		public void filter(final MethodNode methodNode,
				final IFilterContext context, final IFilterOutput output) {
			if (isKotlinClass(context)) {
				super.filter(methodNode, context, output);
			}
		}
	};
}

A remark regarding method isKotlinClass():
The following filters miss this check: KotlinLateinitFilter, KotlinWhenFilter, KotlinWhenStringFilter, KotlinNotNullOperatorFilter

• KotlinWhenStringFilter - recognizes pattern where switch by hashCode of String is followed by String comparisons, which is IMO unlikely can be written by a human, and even if it will filter non-Kotlin classes, then this most likely will mean that non-Kotlin compiler implemented the same strategy to implement switch by String and it should be filtered anyway - we already have filters that are applicable for different languages and compilers - just a few examples among others are StringSwitchFilter and FinallyFilter

• KotlinLateinitFilter - unlikely that INVOKESTATIC kotlin/jvm/internal/Intrinsics.throwUninitializedPropertyAccessException appears outside Kotlin classes

• KotlinNotNullOperatorFilter unlikely that INVOKESTATIC kotlin/jvm/internal/Intrinsics.throwNpe appears outside Kotlin classes

• KotlinWhenFilter - unlikely that INVOKESPECIAL kotlin/NoWhenBranchMatchedException.<init> and GETSTATIC for a field with a name starting with $EnumSwitchMapping$ from class with a name ending $WhenMappings appear outside Kotlin classes

So IMO the absence of this check in them is not a problem. We can add it, but IMO such a change should not be made within this PR.

The new location introduces a cyclic dependency between Filters and the Kotlin filter implementations

I agree that factoring out repeated isKotlinClass is indeed a good thing to do, even on its own, and actually I have been planning to do so for some time already.

But unfortunately this will not remove all cycles - it is also used in SyntheticFilter
It seems that SyntheticFilter should be split into two or more to remove all cycles - for Kotlin and for the rest. IMO such change should not be made within this PR.

There are also filters which are likely not applicable for Kotlin - for example TryWithResourcesJavac11Filter. IMO such classification should not be made within this PR and instead made carefully with the addition of more tests to not regress which I already started to add - see #1703 and #1684

@marchof All in all, I think that the scope of this PR should not be extended above its current title - change of visibility of classes (see "Clear scope" in org.jacoco.doc/docroot/doc/conventions.html), and I think that it should not be blocked and should not wait for all the above, ie IMO factorization of isKotlinClass and removal of cycles can be done later. Also it seems that to avoid cycles isKotlinClass can be moved to KotlinSMAP - I just updated this PR to do so. WDYT about this?

@Godin Ok, let's focus on the class visibility in this PR and discuss isKotlinClass() in a separate PR, ok?

@marchof ok and so where this PR should place isKotlinClass? 😅 😉

1. in KotlinSMAP class as it is currently proposed in this PR - I like this variant because they are related since the use of KotlinSMAP must be guarded by isKotlinClass as it can't be used for non-Kotlin classes, and seems that this avoids cycles
2. in Filters class as was initially proposed in this PR - this variant introduced cycles
3. in KotlinGeneratedFilter as was initially - in this case KotlinGeneratedFilter will remain public and we'll need to add a comment to its constructor to get rid of the warning
4. and one more idea just came to my mind - as non-static in interface IFilterContext implemented by ClassAnalyzer, but IMO this is overkill and again IMO requires separate PR

@Godin Ah I see, due to visibility issues we need to move it 😅

So let's go with your initial proposal and keep it in Filters for now.

@Godin Thanks! Let me propose a follow-up for the filter code organization.