# javaone Published articles for javaone. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Principles of Memory Management in Java DevFeed: [Principles of Memory Management in Java]() Original publisher: [Read original article]() Author: Ron Pressler Published: 2026-09-04T00:00:00Z Content type: article Language: en Sources: [Inside Java]() Topics: [Java](), [cpu]() Tags: [2026](), [cpu](), [garbage-collectors](), [java](), [javaone](), [jdk](), [memory](), [performance](), [talk]() ### AI overview This talk explains the design choices behind the JDK's garbage collectors and how Java memory management affects application performance. It also examines the relationship between RAM and CPU and questions whether Java's memory use is inherently wasteful. ### Source excerpt In this talk, we'll explore why the JDK's garbage collectors work the way they do and how Java memory management affects application performance. We'll look at the sometimes non-obvious relationship between RAM and CPU, and why they must always be considered together. ## Code generating beans - mutable and immutable DevFeed: [Code generating beans - mutable and immutable]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2016-09-26T01:36:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Code generation](), [Java](), [Data structures](), [Code](), [ide](), [Open Source]() Tags: [abstract-class](), [code](), [code-generation](), [compilation](), [constructor](), [data-structure](), [hashcode](), [interface](), [java](), [javaone](), [jodabeans](), [properties](), [tostring]() ### AI overview This article discusses Java bean code generation, arguing that immutable beans and data structures are preferable to mutable beans. It compares IDE generation with annotation processors such as AutoValue, Immutables, and VALJOGen, which generate implementations during compilation. ### Source excerpt Java has long suffered from the pain of beans. To declare a simple data class takes far too much code. At JavaOne 2016, I talked about code generation options - see the slides. Code generation of mutable and immutable beans The Java ecosystem is massive. So many libraries releasd as open source and beyond, which naturally leads to the question as to how those libraries communicate. And it is the basic concept of beans that is the essential glue, despite the ancient specification. How do ORMs (Hibernate etc.), Serialization (Jackson etc.) and Bean Mappers (Dozer etc.) communicate? Via getters and setters. The essential features of beans have moved beyond the JavaBeans spec, and are sometimes referred to as POJOs. The features are: Mutable No-args constructor Getters and Setters equals() / hashCode() / toString() But writing these manually is slow, tedious and error-prone. Code generation should be able to help us here. But should we be using mutable beans in 2016? No, no, no! It is time to be writing immutable data structure (immutable beans). But the only practical way to do so is code generation, especially if you want to have builders. In my talk at JavaOne 2016, I considered various code generation approaches: IDE code generation This is fine as far as it goes, but while the code is likely to be correct immediately after generation, there is still no guarantee that the generated code will stay correct as the class is maintained over time. AutoValue, Immutables and VALJOGen These three projects - AutoValue, Immutables, VALJOGen - use annotation processors to generate code during compilation. The idea is simple - the developer writes an abstract class or interface, and the tool code generates the implementation at compile time. However, these tool all focus on immutable beans, not mutable (Immutables can generate a modifiable bean, but it doesn't match the JavaBeans spec, so many tools will reject it). On the up side, there is no chance to mess up the equals / hash ## Why we no longer Attend JavaOne DevFeed: [Why we no longer Attend JavaOne]() Original publisher: [Read original article]() Author: Shai Almog Published: 2016-09-20T00:00:00Z Content type: opinion Language: en Sources: [CodeName One]() Topics: [Java](), [Mobile](), [Internet]() Tags: [conference](), [internet](), [javaone](), [mobile](), [revenue]() ### AI overview The author explains why Codename One stopped attending JavaOne. Despite meetings, talks, and a booth, the event produced little revenue or traction, while the conference audience was often not responsible for mobile development. The author says Internet promotion currently provides better returns and that the lack of Android content reduces JavaOne's relevance to mobile developers. ### Source excerpt I love going to JavaOne, I used to do it every year and it's loads of fun. I've been speaking on a regular basis at JavaOne since 2008 and got a rockstar award a while back. Two years ago we purchased a booth to promote Codename One as well. Last year we skipped the show and it has been so great we decided to skip it again. While JavaOne is loads of fun it does nothing to the bottom line even if you have a booth in place. We had many meetings, talks & introductions. These resulted in very little in terms of revenue or traction shift.