Accessibility Excessiveness Analysis for Java Programs
This case study delves into the analysis of accessibility excessiveness in Java programs, highlighting research problems related to access modifiers in Java classes, controlling field/method access, and common issues caused by inexperienced developers. The study emphasizes the importance of proper access modifier usage to avoid bugs and challenges. It introduces the concept of Accessibility Excessiveness (AE) as a discrepancy between declared and actual usage, offering insights and examples of how overexposure can lead to unwanted access and affect software development processes.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
CASE STUDIES OF ACCESSIBILITY EXCESSIVENESS ANALYSIS FOR JAVA PROGRAMS Dotri Quoc Inoue Laboratory
RESEARCH PROBLEM(1) ACCESS MODIFIER IN JAVA CLASS1 field declaration public int[] A ; protected int c ; .. public void sort() { } (default) int binarySearch(int value) { } private void process(){ } Access Modifier method declaration
RESEARCH PROBLEM(2) Access Modifier of fields/methods in Java : control the access of other classes to that field/method. Access Modifier Public Protected Default Private Same Class OK OK OK OK Package Subclass Any Class OK OK OK - OK OK - - OK - - - 3
RESEARCH PROBLEM(3) In Java, inexperienced/careless developers often set all of the access modifier public or default(no declaration) The fields/methods which should be hidden are not hidden Bugs in latter development/maintenance phase 4
EXAMPLEOFBADACCESSMODIFIER DECLARATION Class X Public method B Public method A Current program O K Invoke Initialization Main job Other objects Future modification Directly invoke B 5
AE : ACCESSIBILITY EXCESSIVENESS(1/2) AE : Discrepancy between declared access modifier and actual usage An AE could cause unwilling access to method/field AE could be used as an indicator of immaturity of developer Declaration Access Modifier Public Protected Default Private Same Class OK OK OK OK Package Subclass Any Class OK OK OK - OK OK - - OK - - - AE 6 Actual use
AE : ACCESSIBILITY EXCESSIVENESS(2/2) Acquirement of AE for each field/method AE causes bug in latter development and maintenance phase AE analysis tool : ModiChecker 7
APPROACHTO AE ANALYSIS(1) AE MAP AE Id Unused AE Id of Excessive fields/methods Actual Usage Syntax Error Public Protected Default Private Unused Declaration Public ok- pub0 pub1 pub2 pub3 pub4 Protected ok-pro0 pro1 pro2 - pro3 ok-def0 - Default Private - - - - def1 ok-pri0 def2 pri1 No Discrepancy 8
APPROACHTO AE ANALYSIS(2) STATIC SOURCE CODE ANALYSIS Requirement Information of each field/method s access modifier declaration Actual Usage of each field/method Static source code Analysis is required Employing MASU MASU : Platform for Metrics measurement but is useful as a Java program analysis framework 9 MASU - http://sourceforge.net/projects/masu/
ARCHITECTUREOF MODICHECKER ModiChecker Input MASU Source Code Required Library(.jar files) Source Code Analyzer AST Database Extraction of method/field usage Extraction of access modifier declaration Detection of declaration excessiveness 10 Report of AE Id for each method/field
OVERVIEWOF EXPERIMENT(1/2) Objectives of experiment Validation of our approach Quantitative analysis of AE Id in some software systems Reasons for excessive/unused fields/methods (found by interviewing developers) Reason 1 : Set for future use Reason 2 : Created by other program(automatic code generators or refactoring tools ) or accessed by other programs(Java bean) Reason 3 : Carelessness and immaturity Target Software Industrial Software(341 Java files/ 64455 LOC) 1. 2. 3. 11
EXPERIMENT RESULT - FIELDS Actual Usage Public Protected Default Private Unused Declaration Public 0 207 59 936 33 Protected 0 - 9 18 0 4 - Default Private - - - - 5 2 5 1123 12
EXPERIMENT RESULT - METHODS Actual Usage Public Protected Default Private Unused Declaration Public 14 816 23 190 1005 Protected 13 - 36 48 9 0 - Default Private - - - - 3 0 4 488 13
EXPERIMENT RESULT Excessive fields : 1027 Excessive methods : 512 Unused methods : 1018 Unused fields: 40 5 fields named serialVersionUID Intentionally set for future use : 8 Actually unused : 28 (5 fields contain potential bug) 14
DISCUSSION Validation of ModiChecker output Changed all of the excessive access modifier and deleted some unused fields/methods Modified programs were compiled and executed without any error Developer should look for the detailed result and make decision to change/delete the unused/excessive fields/methods 15
CONCLUSION AND FUTURE WORK Conclusion Analysis method named AE for each field/method ModiChecker : report AE of each field/method Experiment on some software systems Future work ModiChecker for other Java systems and other programming language system(C# , C++ ) 16