{'fraction_non_alphanumeric': 0.02810077519379845, 'fraction_numerical': 0.003875968992248062, 'mean_word_length': 5.22289156626506, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Deadlock-Detection in Java-Library Using Static-Analysis

Well-written Java programs that conform to the Language and the J2SE-API Specifications can surprisingly deadlock their hosting JVM. Some of these deadlocks result from the specific manner in which the library implementations (incorrectly) lock their shared objects. Properly fixing them can require corrections in the J2SE-source. We use static-analysis to fetch a list of such potential deadlock scenarios stemming from the library, and use it to drive focused investigation into its source. This can help improve the reliability of the Library-design and implementation. A related reliability-metric can also be designed for objective comparison of update-releases to avoid regression (in maintenance-releases) of large Java libraries. The focus of this investigation is to identify, and thereby, help remove deadlock-possibilities in the Java-Library. An initial prototype implementation of our approach has already helped detect a deadlock in the JDK1.5 Annotation API.