Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More easily detect overridden methods & calls to super #1040

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 8 commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
/*
* Copyright 2014-2022 TNG Technology Consulting GmbH
* Copyright 2014-2023 TNG Technology Consulting GmbH
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should isolate this "Happy new year, code base!" change into a separate commit (that also fixes all java files, which happens automatically when building the project).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah for some reason my IntelliJ or some other plugin automatically made this change for all the classes with this documentation, I forgot to undo the changes on this file itself but did them for all other classes. 😅

*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
Expand All @@ -15,20 +15,20 @@
*/
package com.tngtech.archunit.core.domain;

import java.lang.reflect.Method;
import java.util.List;
import java.util.Optional;
import java.util.Set;
import java.util.function.Function;
import java.util.function.Supplier;

import com.tngtech.archunit.PublicAPI;
import com.tngtech.archunit.base.ArchUnitException.InconsistentClassPathException;
import com.tngtech.archunit.base.MayResolveTypesViaReflection;
import com.tngtech.archunit.base.ResolvesTypesViaReflection;
import com.tngtech.archunit.base.Suppliers;
import com.tngtech.archunit.core.importer.DomainBuilders;

import java.lang.reflect.Method;
import java.util.List;
import java.util.Optional;
import java.util.Set;
import java.util.function.Function;
import java.util.function.Supplier;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we please adhere to the import order specified in CONTRIBUTING.md, i.e. keep the java.* imports at the top?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, I'll do so in JavaMethodTest as well

import static com.google.common.collect.Sets.union;
import static com.tngtech.archunit.PublicAPI.Usage.ACCESS;
import static com.tngtech.archunit.core.domain.Formatters.formatMethod;
Expand Down Expand Up @@ -125,6 +125,14 @@ public String getDescription() {
return "Method <" + getFullName() + ">";
}

@PublicAPI(usage = ACCESS)
public boolean isOverridden() {
return getOwner().getAllRawSuperclasses().stream()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to conisder overridden methods from interfaces as well, we can replace this stream with

Streams.concat(getOwner().getAllRawSuperclasses().stream(), getOwner().getAllRawInterfaces().stream())

.map(JavaClass::getAllMethods)
.flatMap(Set<JavaMethod>::stream)
.anyMatch(superMethod -> superMethod.getName().equals(getName()) && superMethod.getParameterTypes().equals(getParameterTypes()));
}

@ResolvesTypesViaReflection
@MayResolveTypesViaReflection(reason = "Just part of a bigger resolution process")
private class ReflectMethodSupplier implements Supplier<Method> {
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
package com.tngtech.archunit.core.domain;


import com.tngtech.archunit.core.importer.ClassFileImporter;
import org.junit.Test;

import static com.tngtech.archunit.testutil.Assertions.assertThat;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotEquals;

public class JavaMethodTest {
@Test
public void isOverriddenTest() {
class Base {
void method1() {
}

void method1(int x) {
}
}
class Child extends Base {
void method1() {
}

void method2() {
}
}
class GrandChild extends Child {
void method1() {

}

void method1(int x) {

}

void method2() {

}

void method3() {

}

}
ClassFileImporter importer = new ClassFileImporter();
JavaClass baseClass = importer.importClass(Base.class);
JavaClass childClass = importer.importClass(Child.class);
JavaClass grandChildClass = importer.importClass(GrandChild.class);
assertThat(baseClass.getMethod("method1").isOverridden()).isFalse();
assertThat(baseClass.getMethod("method1", int.class).isOverridden()).isFalse();
assertThat(childClass.getMethod("method1").isOverridden()).isTrue();
assertThat(childClass.getMethod("method2").isOverridden()).isFalse();
assertThat(grandChildClass.getMethod("method1").isOverridden()).isTrue();
assertThat(grandChildClass.getMethod("method1", int.class).isOverridden()).isTrue();
assertThat(grandChildClass.getMethod("method2").isOverridden()).isTrue();
assertThat(grandChildClass.getMethod("method3").isOverridden()).isFalse();
//TODO add testing for methods with generic parameters
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that we indeed don't recognize all overriden generic methods:

    @Test
    public void overridden_generic_methods_are_supported() {
        class Parent<T extends Number> {
            void method(T t) { }
        }
        class Child extends Parent<Integer> {
            @Override
            void method(Integer t) { }
        }
        JavaClass childClass = new ClassFileImporter().importClass(Child.class);
        JavaMethod method = childClass.getMethod("method", Integer.class);
        assertThat(method.isOverridden()).isTrue();  // Expecting value to be true but was false 
    }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, this might complicate the code now.
I'll see what I can do.

}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also have a test for the use case of #1047 .

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that is already in place, currently we check if the parameters and name of the method are equal, and that implies compatibility of return type.
If that is not the case, then the user code will not compile in the first place

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that we should document that this works (which it curently does, but we also want to avoid any future regression):

    @Test
    public void more_specific_return_type_is_supported() {
        class Parent {
            CharSequence method() { return "base"; }
        }
        class Child extends Parent {
            @Override
            String method() { return "overridden"; }
        }
        JavaClass childClass = new ClassFileImporter().importClass(Child.class);
        JavaMethod method = childClass.getMethod("method");
        assertThat(method.isOverridden()).isTrue();
    }