# SJBCD: A Java Code Clone Detection Method Based on
## 4 Experiment
### Datasets  
BigCloneBench is a dataset constructed by [PERSON] et al. They mined the clone code of specific functions and marked the clone tag of code fragment pairs manually. It is still expanding on Github (Refer to the Data Availability Statement section) and is a benchmark dataset [12]. Recently, most methods based on source code have been evaluated by this  
Figure 5: GRU-based Siamese neural network structure.  
dataset. However, this dataset cannot be compiled, that is, it is impossible to evaluate clone detection methods based on bytecode.  
JCoffee is a Java code repair tool proposed by [PERSON] et al. It tries to convert code fragments into compilable programs and works with any well-typed code fragments (class, function, or even an unenclosed group of statements) while making minimal changes to the input code fragment. JCoffee leverages compiler feedback to convert partial Java programs into their compilable counterparts by simulating the presence of missing surrounding code [32]. Figure 6 shows how using JCoffee fixes the code.  
Figure 6a represents the original code that needs fixing, Figure 6b displays the error message generated by the Java compiler during the initial compilation attempt, and Figure 6c showcases the repaired code. It can be observed that JCoffee primarily performs two tasks for code repair. Firstly, it imports the necessary Java dependency packages to resolve compilation errors. Secondly, it creates the missing classes based on the compiler prompts, ensuring that the original code can be successfully compiled. From Figure 6b, it can be observed that during the initial compilation, the compilation environment indicates that the class \"Foo\" is missing. Therefore, the JCoffee tool adds the \"Foo\" class and performs another compilation. Subsequent compilations may still produce relevant prompts, and thus, by continuously compiling and addressing these prompts, the missing code information can gradually be completed.  
Since the main comparison is made between our model and TBCCD, in order to make the experimental environment as same as possible, we used JCoffee to try to compile the dataset it used. TBCCD extracted part of the data of BigCloneBench for model training and testing, of which 98.23% were Weak Type-3/Type-4 clones, and the rest were other types of clones. The distribution of clone types in this dataset is shown in Table 1[18].  
Figure 6: JCoffee code fix example: (**a**) Snippet of code to be repaired; (**b**) Information about initial compilation; (**c**) Fix the code snippet after completion.  
The clone pairs and non-clone pairs in the dataset consist of 9134 code fragments with a granularity of functions. There is an important parameter \"-n\" in JCoffe, which represents the number of attempts to compile during the repair process. We used JCoffee to write an automated program to perform repairs for three times. The parameters were 10, 20, and 40, respectively, and the code fragments for the three successful repairs were all 3878. To facilitate the experiment, we removed the code containing an anonymous inner class. There were still 3824 codes left. Each piece of data in the dataset consisted of two code fragments and a clone tag. According to these 3824 codes and the data records in the original data set, 423,217 pieces of data were obtained, which was called CompiledBCB. There were 2,416,589 pieces of data used in the original paper of TBCCD. According to Table 1, T1, T2, VST3, ST3 and MT3 accounted for 1.77%, and the total number was about 42,774. Assuming that the 42774 pieces of non-WT3/T4 data were kept in CompiledBCB, then the Weak Type-3/Type-4 clone data in CompiledBCB was 380,443 pieces, accounting for about 89.9%. The actual Weak Type-3/Type-4 clone data accounted for more than 89.9%.