Menu ▾ ▴

#15 Wrong default visibility marker for classes

open
Joerg Spieler
Causes compile error (4)
5
2018-07-17
2009-01-27
Anonymous
No

with version 0.12.0, and the following 3 java files, ucdetector detect that the Field class could be set to default. But if i switch it to default, there is a compilation error in Main.foo :

// ===
package tests;

import tests.sub.Container;

public class Main {
void foo() {
Container container = new Container();
String s = container.field.getBar();
}
}

// ===
package tests.sub;

public class Container {
public Field field;
}

// ===
package tests.sub;

public class Field {

public String getBar() {
    return "Bar";
}

}

Discussion

  • Joerg Spieler

    Joerg Spieler - 2009-01-27

    This is a bug!
    Solution: A class can only have default visibility, when all it members and methods can be default!

     

  • Chris West (Faux)

    Chris West (Faux) - 2009-02-27

    That solution won't work in the following situation:

    // two/Consumer.java, main class:
    package two;

    import one.Foo;

    public class Consumer { // NO_UCD -- main method

    public static void main(String[] args) {
    // With the UCDetector suggestions, the following error is issued: The type Bar is not visible.
    new Foo().getBar().getClass();
}

    }

    // one/Foo.java
    package one;

    public class Foo {
    public Bar getBar() {
    return new Bar();
    }
    }

    // one/Bar.java
    package one;

    // UC detector warning: Change visibility of "Bar" to default
    public class Bar {
    // Does nothing at all
    }

     

  • Joerg Spieler

    Joerg Spieler - 2009-03-29

    Hi fauxfaux,

    you are right! That means: UCDetector can't suggest to make a class default, without compile errors.

    I think I will realize my first idea, which resolves the initial problem:
    "A class can only have default visibility, when all it members and methods can be default!"
    and add a warning: "May cause compile errors"

    What do you think?

    Joerg

     

  • Joerg Spieler

    Joerg Spieler - 2009-03-30

    Added a warning: "May cause compile errors"
    I think the only solution is to run no visbitility detection for classes!

     

  • Joerg Spieler

    Joerg Spieler - 2009-06-12

    I didnt find a solution for this bug. Changed resolution to Wont Fix.

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2009-08-26

    The only solution is to parse all local variable/field/parameter references and see if they can "see" their own type if the type is private/protected or public.

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2009-08-27

    If you parse the AST, you will get some kind of MemberAccess for the ".field" in the Main class, in method foo().

    Since you can't access the "tests.sub.Field" class from the "tests.Main.foo()" method, it means the class cannot be default or protected (not same package and no inheritance).

     

  • Joerg Spieler

    Joerg Spieler - 2009-09-24

    Can you make a code example for the AST stuff? Maybe a eclipse class, which does something similar.

    I don't understand your posting. It would be great, if your posting can fix this bug!

     

  • Anonymous

    Anonymous - 2018-07-17

    If this rule cannot be fixed, it should be disabled or removed, it just creates noise in the results which seriously devalue this tools usefulness.

     

Anonymous
Anonymous

Add attachments
Cancel