Resolving the Java Representation Exposure Problem with an AST-Based Deep Copy and Flexible Alias Ownership System

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The paper presents an extension to the Java programming language to solve the representation exposure problem by following an AST approach inspired by other programming languages (such as Rust) and previous studies.

The paper is easy to read, and prepares the reader for what to expect in the following sections of the paper. The paper also has the potential to attract developers in the industry who especially work with Java language.

I have a few comments for the authors. Please see my comments below:

1) For the introduction section, it might be useful to explicitly mention the contributions of their work, possibly showing them with bullet points.

2) In Section 3.1, did the authors consider supporting multiple/shared ownership? I am curious how the SlimeOwned works with inheritance, such as protected members in a superclass annotated as @SlimeOwned. Wouldn't these be shared ownerships with subclasses? Would this violate the idea of the SlimeOwened? What will happen if modification attempts happen at a superclass and a subclass level?

3) The part that I wasn't able to understand in Section 3.1 for the deepCopy() example is whether the developer explicitly has to write deepCopy() or whether it will be automatic. Will it provide an error if deepCopy() is not used? If it is required there should be an error defined for this case.

4) Can the annotations work with Interfaces, Abstract classes, Inner classes, and Enum as well? All the examples seem to be on concrete classes, and there is nothing mentioned about the others.

5) Starting from Section 3, while giving the code examples with "Errors," I think it is important to mention when these errors are given. Runtime or compile time (Syntax Analysis phase, maybe?)? 

5) In Section 3.2., the idea of @SlimeBorrow reminds me a lot of the smart pointers feature that is supported by C++11, under the "memory" library. I think the authors should make room for smart pointers and should look into how "unique" and "shared" smart pointers work. They are intentionally developed for semi-automatic garbage collection using reference counting, but the idea seems very similar.

6) In section 3.5, the authors mention about Kotlin having null safety features and Java not having. However, the authors should definitely look into "Checker Framework". It is widely used in academia, and industry, and actively maintained, which also uses an annotation-based approach like the authors have proposed in this work. 

Papi, Matthew M., Mahmood Ali, Telmo Luis Correa Jr, Jeff H. Perkins, and Michael D. Ernst. "Practical pluggable types for Java." In Proceedings of the 2008 international symposium on Software testing and analysis, pp. 201-212. 2008.

 The Checker Framework

typetools/checker-framework: Pluggable type-checking for Java (github.com)

7) In Figure 3.2, the black background color and the blue text do not go along together. It is very difficult to read the blue text. Maybe you could consider using a lighter (white) background.

8) The flowchart in figure 3.3., needs revision. There are control blocks (diamonds) without yes/no labels. But most importantly there are control block that has one outgoing arrow, so what is the meaning of describing them as control blocks? What happens if the control block condition is not satisfied? Would it just stay there? Some arrows don't have arrows (see "Check if the symbol table matches the syntax" block). Also, based on the flowchart it seems like the code is multi-threaded in some way. "Traverse each node" block has 4 outgoing edges, which I think is not right, there could be conflicting scenarios based on this (typical race conditions). You can have both error messages and finish at the same time. This figure needs serious adjustments and attention. You could possibly consider writing a pseudocode algorithm.

9) This is probably a minor comment, but the notation that is used for the code and method, such as Tweet::saveToMemento(), is not Java notation, but more like C++ notation, where "::" is used for namespace. Typical Java static analysis output notation uses <packageName>.className.methodName(...). Authors have used JavaParser; they must have seen it from JavaParser.

10) For Table 4.3, Java is used for comparison, but I think it is critical to mention which Java version they compared it with. Lately, Java versions have changed very frequently and continue to change very fast. Same, goes for Rust as well. Years later, if Java updates and adds features like SlimeJava, people would like to know from which version it is supported and in which it is not.

11) In Section 4.3., while measuring the performance, from what I understand the authors tested their approach on one single test code, which I also assume is a very small code. But this is not a good way to test in terms of scalability. The authors should select a set of popular open-source projects, run them, and evaluate their performance. Otherwise, the experiment in the study is biased.

12) Please fix reference [7] for the Gang of Four. Only one of the author's names (Gamma) is given, and other authors' names should be given as well. This is important because Google Scholar sometimes does not capture these references, which affects their citation count.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

 

 

This paper highlights the significance of encapsulation in object-oriented programming languages and design patterns, emphasizing its critical role. However, certain programming languages like Java may encounter a challenge known as representation exposure. This issue arises due to inadequate mechanisms for ownership and immutability, resulting in compromised encapsulation. External references can unexpectedly modify fields or members of objects, leading to broken encapsulation. To address this problem, we introduce SlimeJava, an extension of Java. SlimeJava incorporates an ownership system that operates based on abstract syntax trees and utilizes annotations for performing source-to-source transformations. The primary objective of this system is to assist programmers in preventing representation exposure.

Furthermore, this paper delves into the utilization of annotations and how they enable the realization of ownership. We also explore why this approach proves to be effective in mitigating representation exposure issues.

In conclusion, this paper presents SlimeJava as a solution to the problem of representation exposure in Java programs. By employing an ownership system and leveraging annotations, programmers can effectively safeguard encapsulation and prevent unexpected modifications to object fields and members.

Several improvements are required to enhance the quality of the manuscript:

1- The abstract needs to be revised to focus solely on the key findings of this paper.

2- The English should be further polished, and typos should be avoided.

3- Authors must add more details about subsection 3.4 Summary of the Proposal.

4- To demonstrate the efficacy of the proposed shortcomings in Java related to ownership and immutability a comparative analysis can be presented, contrasting it with existing in literature.

5- The literature survey needs to be improved.

 

 

   

Comments on the Quality of English Language

This paper highlights the significance of encapsulation in object-oriented programming languages and design patterns, emphasizing its critical role. However, certain programming languages like Java may encounter a challenge known as representation exposure. This issue arises due to inadequate mechanisms for ownership and immutability, resulting in compromised encapsulation. External references can unexpectedly modify fields or members of objects, leading to broken encapsulation. To address this problem, we introduce SlimeJava, an extension of Java. SlimeJava incorporates an ownership system that operates based on abstract syntax trees and utilizes annotations for performing source-to-source transformations. The primary objective of this system is to assist programmers in preventing representation exposure.

Furthermore, this paper delves into the utilization of annotations and how they enable the realization of ownership. We also explore why this approach proves to be effective in mitigating representation exposure issues.

In conclusion, this paper presents SlimeJava as a solution to the problem of representation exposure in Java programs. By employing an ownership system and leveraging annotations, programmers can effectively safeguard encapsulation and prevent unexpected modifications to object fields and members.

Several improvements are required to enhance the quality of the manuscript:

1- The abstract needs to be revised to focus solely on the key findings of this paper.

2- The English should be further polished, and typos should be avoided.

3- Authors must add more details about subsection 3.4 Summary of the Proposal.

4- To demonstrate the efficacy of the proposed shortcomings in Java related to ownership and immutability a comparative analysis can be presented, contrasting it with existing in literature.

5- The literature survey needs to be improved.

 

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

This article explores the necessity of encapsulation in object-oriented programming and design patterns, highlighting the requirement for mechanisms such as ownership and immutability to protect encapsulation. The authors discuss the challenge of representation exposure in the context of Java, which refers to the problem where the internal representation of an object is accessed directly outside the container, resulting in less predictable software applications.

The authors' main example demonstrates how to utilize the Memento pattern to save the state of sent tweets using a referenced tweet mechanism. The state includes the content, timestamp, and comments. The author's example aims to bring attention to information on how aliases might impair encapsulation, resulting in representation exposure in Java program development and other programming languages such as Rust.

 

Based on the information gathered from the authors' research and their conducted experiments, I recommend the following changes:

1.       Missing ORCID number for all authors. Please, add this information.

2.       The abstract does not contain information about the method of realization of the experiments and there is no mention of information related to the Memento Pattern anywhere. I ask the authors to read the instructions for authors once more.

3.       The paper lacks information related to the definition of the research method. Please add a section and define the research method. There is a lack of information on the research contributions made during this research.

4.       In order to make the work easier to read, I suggest changing subsection 2.1. Memento Pattern Example to the Memento Pattern Example section

5.       All figures based on code should be modified to use the Code Listing, and the source information should be included. Also, the formatting of the code must be consistent throughout the work; I recommend that the authors present the code on a white background. If it is the author's contribution, it must be stated as follows: Source: contribution of the authors. In order to avoid difficulties with copyright.

6.       On line 158, you should add the code listing and make the appropriate call (Latex \ref{}) to the displayed code. This also applies to all other parts that have the same problem.

7.       It is necessary to specify in Table 2.1. Expected saved tweet states - information about the source that also applies to other tables.

8.       Section 3. Proposal and Implementation - should be moved within the Results section

9.       Within section 3.5. Implementation Detail - it is necessary to add information about the used laboratory environment, which hardware, and operating system is used?

10.   Figures 3.2. The AST structure of the code snippet of Tweet class in YAML file format – this should be displayed differently with a better specification of content information. I suggest adding a table with information about the variables and their data types, as well as information about the level at which they are displayed.

11.   In Figure 3.3. SlimeJava flowchart - the part written for "Yes" in the part of the loop called "Does the annotation already exist?" is not visible well enough. Please correct so that the specified text is visible in its entirety.

12.   For the research to be clearer, I suggest to the authors that within the research method, add information that is currently found within section 4.3. Quantitative Performance Evaluation.

13.   Within section 5. Related Work - information is missing on how the selection of literature within the text was made, as well as the time frame that was used.

14.   A section that covers the discussion part is missing within the paper. Please add a section called discussion and write inside it what are the currently remaining open questions that you have come up with during your research.

15.   The conclusion section contains references. It is not recommended to add references within the conclusion unless they refer to specific data sources. The current conclusion must be better written and corrected so that it contains certain information about the verification and review of the obtained results.

16.   Within the section Data Availability Statement: Source code of SlimeJava: https://github.com/ncu-psl/slime-java - information about the type of license being applied should be provided.

17.   Regarding the literature, the work contains a larger number of older sources of literature without an explanation of the reasons for their use. The oldest source is from 1998. It should be more clearly explained within the research method why the mentioned older sources were used.

The primary advantage of this research can be found in the section dealing with storing the state of objects and representation in various programming languages. The main disadvantage can be seen in the lack of a research approach, which makes research incomplete. 

The research work itself has a good potential for future publication but requires better organization and presentation of the results.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

I would like to thank the authors for kindly addressing my questions and comments. The paper definitely looks better. My only feedback is that, for future paper submissions, please consider highlighting the edited/added text (maybe using red font color). It was really difficult to locate the changes, and I had to review it side-by-side with the previous submission to find the changes.

It would also be nice to have a second README.md file for the GitHub page, which is in English. This could possibly increase the audience who would like to utilize the approach.

Thank you for your hard work!

Reviewer 2 Report

Comments and Suggestions for Authors

After reviewing the revision made and the response to the reviewers' comments by authors.  The authors have addressed the concerns raised by the reviewers and have provided satisfactory explanations and improvements to the manuscript. The revised version of the paper demonstrates a comprehensive understanding of the topic and incorporates valuable contributions to the field. I believe this paper is now suitable for publication.

 

Reviewer 3 Report

Comments and Suggestions for Authors

The authors implemented the suggested improvements, considerably improving the paper's overall quality given that the paper now has a method of investigation and discussion.

I'm pleased with the modifications that were made, and the paper can now be accepted for publication.