Use at your own risk: the Java unsafe API in the wild

Abstract

Java is a safe language. Its runtime environment provides strong safety guarantees that any Java application can rely on. Or so we think. We show that the runtime actually does not provide these guarantees-for a large fraction of today's Java code. Unbeknownst to many application developers, the Java runtime includes a "backdoor" that allows expert library and framework developers to circumvent Java's safety guarantees. This backdoor is there by design, and is well known to experts, as it enables them to write high-performance "systems-level" code in Java. For much the same reasons that safe languages are preferred over unsafe languages, these powerful-but unsafecapabilities in Java should be restricted. They should be made safe by changing the language, the runtime system, or the libraries. At the very least, their use should be restricted. This paper is a step in that direction. We analyzed 74 GB of compiled Java code, spread over 86, 479 Java archives, to determine how Java's unsafe capabilities are used in real-world libraries and applications. We found that 25% of Java bytecode archives depend on unsafe third-party Java code, and thus Java's safety guarantees cannot be trusted. We identify 14 different usage patterns of Java's unsafe capabilities, and we provide supporting evidence for why real-world code needs these capabilities. Our long-term goal is to provide a foundation for the design of new language features to regain safety in Java.

Why and how Java developers break APIs

“…The rationale is that clients of these elements were previously warned that they are no longer supported, and, therefore, subjected to changes or even to removal. Finally, APIDIFF warns if a BCC is performed in an experimental or internal API [11], [12]. For this purpose, the tool checks if the qualified name of the changed API element As presented in Table I, APIDIFF does not use the term refactoring to name BCCs.…”

“…We organized the reasons mentioned by these developers on two major themes: internal APIs and testing branches/new releases. Regarding the first theme, APIDIFF gives a warning about APIs that are likely to be internal; specifically, the ones implemented in packages containing the string internal, as recommended in the related literature [11], [12]. Nonetheless, 21 developers mentioned that the BCCs occurred at internal (or low-level) APIs that do not include internal in their names, as in the following answers:…”

Leveraging InfiniBand for Highly Concurrent Messaging in Java Applications

“…Data structures are mapped and accessed as C-structs in the native space. In Java, we access the native Cstructs using a helper class which utilizes the Unsafe library [29] as this is the fastest method in both spaces.…”

NG2C: pretenuring garbage collection with dynamic generations for HotSpot big data applications

“…There are some solutions based on off-heap memory [41,44,46] (i.e., allocating memory for the application outside the GCmanaged heap). While this is an effective approach to allocate and keep data out of the range of the GC (and therefore, reducing object copying), it has several important drawbacks: i) off-heap data needs to be serialized to be saved in off-heap memory, and de-serialized before being used by the application (this obviously has performance overheads); ii) off-heap memory must be explicitly collected by the application developer (which is error prone [11,14] and completely ignores the advantages of running inside Figure 1: Allocation of Objects in Different Generations a memory managed environment); iii) the application must always have objects identifying the data stored in off-heap (these so called header objects are stored in the managed heap therefore stressing the GC).…”