When using tai-e to analyse the class, the permission modifier of the inner class is always public.

[zpc0801]

📝 Overall Description

When using tai-e to analyse the class, the permission modifier of the inner class is always public. As shown in the following example, the permission modifiers of inner class B and C are private and protected respectively. However, the result of calling Tai-e's interface is that both classes B and C are public, i.e., assertTrue(B.isPublic()); assertTrue(C.isPublic());

package com.example;
public class A{
    private class B{
    }
    protected class C{
    }
}

🎯 Expected Behavior

the permission modifier of the inner class B is private, and the permission modifier of the inner class C is protected.

🐛 Current Behavior

the permission modifiers of the inner class B and C are public.

🔄 Reproducible Example

No response

⚙️ Tai-e Arguments

🔍 Click here to see Tai-e Options

{{The content of 'output/options.yml' file}}

🔍 Click here to see Tai-e Analysis Plan

{{The content of 'output/tai-e-plan.yml' file}}

📜 Tai-e Log

🔍 Click here to see Tai-e Log

{{The content of 'output/tai-e.log' file}}

ℹ️ Additional Information

No response

[ayanamists]

This is a frontend issue, and since we are currently using Soot as the frontend, we are temporarily unable to address it.

At the moment, I have the following observations:

1. Due to the nature of inner classes, javac has to use a hacky way to compile modifiers of inner classes, which is the root cause of the problem.
2. We can restore the "source code" modifiers , as the JVM's reflection API can also retrieve the "source code" modifiers.
3. As an analyzer, Tai-e needs to decide whether to align with the source code or directly use the flags field from the classfile. This requires further discussion.

We will soon release a new bytecode frontend, and this issue should be properly resolved in the new frontend.