Allow writing a single test case which will scan the current classpath for all @Immutable classes

[Grundlefleck]

Currently, if you want to start using Mutability Detector on your project, and you already have a lot of classes marked as @Immutable, you can either:

• use the FindBugs plugin to automatically detect them, in which case, you can't configure the assertion to suppress false positives
• add a unit test for every class, in which case, you have to spend a lot of tedious time writing new test methods.

I would like to find a solution which offers the best of both worlds: to be able to quickly check all your immutable classes, but which still allows flexible configuration for suppressing false positives.

Currently I think we could do something where:

• a user configures one assertion in a unit test
• the test scans the classpath for @Immutable classes and analyses them, reporting errors from all classes
• ... excluding classes which are being tested in another method, with custom suppressions.

This could possibly use a library like http://scannotation.sourceforge.net/ or something similar, to do the scanning. I don't know yet how this method could exclude classes which are being tested elsewhere. Perhaps we would need to get creative.

[Grundlefleck]

Assigned to Daniel, see here: https://groups.google.com/d/msg/mutability-detector/M_qWYxGKkWo/_Me0UkRGuwMJ

[MaximumTrainer]

Well its been a while as I've been settling into my new job and teaching basic TDD. I now have a need for this and will start looking into a solution

[neomatrix369]

Sounds like a good plan! Looking forward to your participation.

On Mon, Jul 7, 2014 at 9:01 PM, sandeater notifications@github.com wrote:

Well its been a while as I've been settling into my new job and teaching
basic TDD. I now have a need for this and will start looking into a solution

[lasombra]

That is a very interesting issue. I know nothing about class scanning but I'm interested in giving this a try. Is that OK?

[Grundlefleck]

@lasombra absolutely!

I know nothing about classpath scanning either, so hopefully we can learn together 😄

This entire issue may be a bit big as it's currently described. So I think a good contribution to get started would be a change to Mutability Detector where a method was available, which, when invoked, scanned the classpath and lists all the classes it finds annotated with @Immutable. Once we have that we can then start to talk about actually asserting on them, customising the assertions, etc. If you want to start even smaller, and just find something really tiny, like fixing a typo in the documentation, just to get into the swing of forking the project and issuing pull requests, that's cool too.

I see you're on the LJC's Slack. Feel free to ping me there for any questions you have in getting the project checked out, built. I don't know your level of familiarity with Java/Maven/Git etc, but no question is too basic!

[sband]

Is this issue resolved yet ? if there is any work remaining around this and no one can pick up, please let me know. I could look into it

[Grundlefleck]

This feature isn't available yet, no. Still work to be done. IIRC the first steps have been taken to lookup classes (using reflection which isn't how I'd like it but that's another topic, it'll do for now). Then there's work to create the API for setting it up then executing all the tests. Plenty to do would be great if you're interested!

…

On Sat, 23 Mar 2019, 09:05 Sanket Band, ***@***.***> wrote: Is this issue resolved yet ? if there is any work remaining around this and no one can pick up, please let me know. I could look into it — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcLq9gl5pEYWJXVJgS6vkM9D2mvAEViks5vZe5hgaJpZM4A8N1G> .

[sband]

ok, cool. For scanning the classes should we look at this open source project https://github.com/classgraph/classgraph ? it is compatible with Java 9 as well.

[Grundlefleck]

My ideal solution would:

• not require classes to be loaded. Anything using reflection (e.g. java.lang.Class et al) requires classes to be loaded. I'd prefer to just analyse .class files and their bytecode, without worrying about having to load the class. This is mostly to avoid excess memory usage (in PermGen/Metaspace) that I've found difficult to manage in code.
• be fast. I'd like to not have to do something like persist an index across runs, because of the extra effort and complexity to manage the state across different JVM lifetimes. But I'm not ruling it out if that's what it takes to be fast.
• not have false negatives. It needs to find 100% of classes annotated with @Immutable, even weirder cases like inner classes, because these are perhaps the most likely to also be mutable. Any scanning, whether custom written, or using a library, should be able to find these classes by default.

@sband with that as a rough guidance, I'll let you investigate and make a judgement call on whether classgraph is suitable or not. How does that sound?

[sband]

Awesome ! Most of the requirements you mentioned are addressed in classgraph. Here is the link for reference - https://github.com/classgraph/classgraph/wiki/How-fast-is-ClassGraph%3F
Now what remains is the problem about false negatives which i think can be sorted out through testing. I think classgraph is a suitable solution for scanning part of the problem.

I think i am asking too much, but would it be possible for you to explain the other part of this problem in more detail, i.e. creation of API so that i could proceed accordingly. An example would be more useful.

[ShreyasKudari]

Is this issue still open? If yes I'd like to start looking into this! Please let me know.

[Grundlefleck]

@ShreyasKudari yes, still open. We don't have this functionality yet and I still believe it would be a fantastic feature.

Let me know how I can help you get started. Feel free to issue small pull requests / fixes to get into the flow of committing. You don't have to have everything finished and perfect before contributing. I'd actually encourage the opposite, small, iterative improvements if you can. Thank you for your interest and don't hesitate to reach out.

[ShreyasKudari]

Got it. I will study this over the weekend and update you if I need something clarified.

[erikhofer]

What do you think about integrating with ArchUnit? I think it would be way more flexible and you don't have to worry about classpath scanning.

[Grundlefleck]

ArchUnit looks great! I wonder if Mutability Detector should wrap it, or just make sure we can be used with it... Are you affiliated to ArchUnit in any way, can you say more about how we could integrate with it?

…

On Wed, 24 Feb 2021, 22:45 Erik Hofer, ***@***.***> wrote: What do you think about integrating with ArchUnit? I think it would be way more flexible and you don't have to worry about classpath scanning. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADQXK2PZFQ4ZBOKITZUG23TAV6Q5ANCNFSM4AHQ3VDA> .

[erikhofer]

@Grundlefleck I'm neither affiliated nor an expert. I think you should not wrap it but provide an ArchRule so that users of ArchUnit can simply include it. Take a look here: https://github.com/TNG/ArchUnit/blob/main/archunit/src/main/java/com/tngtech/archunit/library/GeneralCodingRules.java

Probably would look something like

classes.that().areAnnotatedWith(Immutable.class).should(BE_IMMUTABLE)

where BE_IMMUTABLE is a custom ArchCondition that wraps MutabilityDetector. ArchUnit exposes a low-level API for implementing custom rules. See https://www.archunit.org/userguide/html/000_Index.html#_creating_custom_rules