# Vanilla Java Understanding how Core Java really works can help you write simpler, faster applications. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Deciding how to progress your career and find work you find interesting/challenging. DevFeed: [Deciding how to progress your career and find work you find interesting/challenging.]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2026-09-12T07:32:17Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Job](), [Learning](), [Artificial Intelligence](), [Code]() Tags: [ai](), [career](), [code](), [job](), [learning](), [opinion](), [work]() ### AI overview An opinion article about progressing in a career by creating growth opportunities within a current role. It recommends teaching others, understanding users and systems, improving quality and efficiency, taking responsibility for outcomes, and focusing on work that AI cannot easily automate. ### Source excerpt When you start a new role, many challenges are placed on you. Once you have been in a role for a while, you may feel like you aren't learning as much, your career isn't progressing, and you wonder what job you might move to next. Having been in that situation many times, my suggestion is that rather than waiting to be given challenges or the next role, you take the opportunity to challenge yourself to grow in your current role. This doesn't mean accepting a role with too little growth, but rather see if there are opportunities to grow while you have some capacity, if you drive them. For example, imagine the roles you would wish to have, how much of that could you be doing now without being asked, possibly in your own time? I am not suggesting doing more unpaid work, rather extending the work you have to benefit your career. Ways to extend your current role to help you grow Teach others. Often, you don't really understand something until you have had to explain it to someone else. Understand the people using your work. Broaden your understanding of the people or systems using what you are producing. How can what you're doing be more efficient, high-quality, more valuable to the end users, and easier to maintain? Take responsibility for a larger part of an outcome. Instead of only producing a piece of work, help define what success means, consider alternatives, check whether it works in practice and learn from what happens afterwards. Say you are working heavily with AI. Explore all the ways it currently fails, rather than sticking to what it does safely. Anything AI does easily now will be increasingly automated, and there probably isn't a future in that. Instead, focus on what AI can't do and where you add value. That is likely to be in demand. Consider two approaches to using AI to write for illustration: 2,000 words of content on a subject (or 200 lines of code @ ~10 words per line). You could prompt it for an answer of about 2,500 words and then edit out anything ## Which Doc Format is Best for AI Specifications? DevFeed: [Which Doc Format is Best for AI Specifications?]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2026-07-14T14:00:28Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Specifications](), [Markdown](), [Fable](), [HTML](), [Documentation]() Tags: [ai](), [fable](), [html](), [info](), [markdown](), [readability](), [specifications]() ### AI overview The article compares Markdown, AsciiDoc, and HTML for AI specifications using document-size, markup-overhead, readability, and editing-workflow observations. It recommends Markdown for AI working documents, AsciiDoc for curated human-reviewed specifications, and HTML primarily as a publishing target. ### Source excerpt I have a Spec Driven Project with 674 documents incl 181 specs, 429 tasks, and 40 project docs. About 1/3 of these are an acceptance sub-project to show the root project meets fit-for-purpose requirements. I used Fable to convert these to and from AsciiDoc, Markdown, and HTML. From this, I tried to draw some conclusions about which format is better than the others for AI specifications. TL;DR: Markdown for AI working documents, AsciiDoc for curated human-reviewed specs, HTML only as a publishing target. Objective Metrics Corpus Tokens (Approx) Markdown: 594k, AsciiDoc: 598K, HTML: 661k Worst Single-File Ratio AsciiDoc: 1.023x, HTML: 1.26x (due to tables and code blocks) Markup share of file content Markdown 0.9%, AsciiDoc 1.3%, HTML 9.9% - a 10x overhead for HTML Read/write Assessment In terms of readability, both Markdown and AsciiDoc are good. HTML has far more tags, which add noise. One of the most common tags is some code however in the other formats, this is just `some code` When you have an average of 16 per file, this adds a lot of noise. Usability GitHub renders both Markdown and AsciiDoc with working links and checkboxes; HTML is shown as raw source, so the review loop dies there. The first two are also easier to view while you're editing in IntelliJ. HTML is more difficult to read and edit, and it is not as easy to view the rendered output. If you occasionally need HTML, you don't need HTML files: embed an island with ```{=html} in Markdown (Pandoc raw-attribute syntax) or in AsciiDoc. It renders where HTML is supported and drops out cleanly elsewhere. If you really need to use HTML, you can include a link to a file in that format. Note As these were one-for-one conversions, I didn't use features that only exist in AsciiDoc or HTML, such as. Markdown vs AsciiDoc While you might choose either format for your specs, I have been following this convention to keep the authoring consistent. Markdown used for AI-generated content, not human-written, ## Why You Should Tune Code Before Your Garbage Collector DevFeed: [Why You Should Tune Code Before Your Garbage Collector]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2026-06-08T11:52:44Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Benchmark](), [Java](), [Latency](), [Logging](), [Code]() Tags: [benchmark](), [benchmarks](), [io](), [java](), [latency](), [logging](), [low-latency](), [performance]() ### AI overview A Java latency benchmark compares garbage collectors while varying redundant SLF4J logging and log storage. The article reports that removing redundant logging can have a much larger effect on extreme tail latency than changing the garbage collector, and can change which collector performs best. ### Source excerpt Optimising your memory allocations in Java could make far more difference than your choice of Garbage Collector and may even change which is the best garbage collector. In this post I look at a simple event to response latency benchmark, MarketDataSnapshot to NewOrderSingle at 50K/s for 30 minutes using JLBH to test Chronicle-FIX. The goal is to compare a system which is doing redundant work (in this case logging each message using SLF4J), compared with not logging (Chronicle-FIX records every message internally using Chronicle Queue) and how this changes the choice of Garbage Collector For the p99 (worst 1 in 100) the choice of Garbage Collector makes a different on par with optimising how loggin is done However, for the p99.99 (worst 1 in 10,000) optimsing how the logging is done is orders of magnitude more signifciant than the choice of Garbage Collector Unoptimised Benchmark This takes the optimised benchmark and adds one SLF4J log line of just the message to be sent. One log line might not sound like much but ding this on every message makes a big difference esp when the rest of the code is written for low latency. Table 1. RTT latency distribution with slf4j logging GC option p99 p99.99 Parallel large Eden, no large pages 16.86 20,480 ZGC, no large pages 12.21 19,694 G1 + COH, no large pages 12.02 20,349 G1, 2 MiB large pages 13.94 20,021 Shenandoah generational, no large pages 12.30 19,235 Note The p99.99 are thousands of microseconds or 19 to 20 milliseconds. The p99.99 or worst 1 in 10,000 might sound rare, however at 50K/s that is 5 times per second or 300 times per minute Based on these results, you might conclude that Shenandoah is a good option, and avoid Parallel GC. How much difference is the disk IO making IO is often a significant proportion of delays, and we can see that just moving where the logs are written. In this case to a tmpfs filesystem. Table 2. RTT latency distribution with slf4j logging to /dev/shm GC option p99 p99.99 Parallel large Ede ## Testing Java Memory Management with Chronicle-FIX using AI DevFeed: [Testing Java Memory Management with Chronicle-FIX using AI]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2026-06-05T09:03:26Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [Testing](), [Benchmark](), [Artificial Intelligence]() Tags: [ai](), [benchmark](), [benchmarks](), [claude](), [code](), [codex](), [gc](), [java](), [low-latency](), [opinion](), [testing](), [ubuntu](), [ubuntu-24-04]() ### AI overview This article reports on using Codex to create and test a JLBH benchmark for Chronicle-FIX from documentation and sample code. On a Java 25.0.2 system running Ubuntu, the benchmark measured half-round-trip latency of 2.4 to 3.7 microseconds, with about 11 microseconds at the 99.999th percentile under Parallel GC. The author presents AI as useful for benchmark code and experimentation, while cautioning that business logic generally requires substantial human authorship or rewriting. ### Source excerpt While I am sceptical of using AI for release code, it has plenty of uses that previously weren't practical, such as determining how easy your software is to use. If an AI can "figure it out" with a few hints, then you are on the right track. For me, the value of AI is what you learn using it. For more Techincal Information on Chronicle-FIX What AI Does Well and What It Doesn't Claude and Codex are effective for producing idiomatic code; for low-latency code, it needs a significant body of example code. In this case, it was able to utilise sample code for benchmarks. If it was being used to write business logic, it would need the code to be mostly complete examples, and then it could write variations on that. If you were starting, it would be better to either; a) get it to write something functionally correct with the expectation you would rewrite it again manually, or b) write the code yourself and use AI to assist you in improving it. The AI Benchmark Trial I gave Codex (GPT-5.5) the task of writing a JLBH benchmark for Chronicle-FIX from documentation and sample code, testing the round-trip latency of W -> D and D -> 8 messages. The throughput is 50K/s each way. The W market data message is ~512 bytes, and the D new order signal and '8' execution reports are a small ~160 bytes. The test is run for 15 minutes each. I verified the benchmark was written but avoided hand-tuning it; then I asked it to trial different GC options, expecting they wouldn't make much difference, since the application is low GC; however, there might still be some difference. The system is using Java 25.0.2 on a Ryzen 9 9955HX3D with 64 GiB of RAM in a laptop running Ubuntu 24.04.04 LTS. A significant difference between JMH and JLBH benchmark harness is that JLBH supports many concurrent asyncrhonous inflight actions whereas JMH tests one action at a time. The Results The half-round-trip time (RTT/2) was between 2.4 and 3.7 microseconds (< 0.004 milliseconds). For the recommended Parallel GC, t ## Peter Lawrey: Java Engineer, Chronicle Software Founder, and Open-Source Contributor DevFeed: [Peter Lawrey: Java Engineer, Chronicle Software Founder, and Open-Source Contributor]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-08-10T10:56:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [Low Latency](), [Open Source](), [Software Engineering](), [Concurrency]() Tags: [concurrency](), [info](), [infoq](), [java](), [low-latency](), [mechanical-sympathy](), [messaging](), [open-source](), [software-engineering](), [stack-overflow](), [updated]() ### AI overview An updated biography of Peter Lawrey, covering his work on ultra-low-latency Java systems, leadership of Chronicle Software, stewardship of OpenHFT projects, conference presentations, technical writing, and Stack Overflow contributions. ### Source excerpt Peter Lawrey is an Australian/British software engineer and entrepreneur best known for work on ultra-low-latency Java systems and for leading the open-source OpenHFT libraries. He is the founder and chief executive of Chronicle Software, a London-based company whose technology is used in trading and market-infrastructure workloads. Lawrey is also a recognised Java community figure: he was named a Java Champion in 2015, has been described by conference organisers as having provided the most answers for the Java and JVM tags on Stack Overflow, and writes the long-running Vanilla Java blog. (Chronicle Software, javachampions.org, qconnewyork.com, blog.vanillajava.blog) Career Lawrey founded and leads Chronicle Software, which builds enabling technology for event-driven trading and market-data platforms. The company states that its software underpins systems at several tier-one banks; a 2024 press announcement similarly described Chronicle as supplying "8 of the top 11 investment banks". (Chronicle Software, Yahoo Finance) Alongside the commercial platform, Lawrey architects and stewards Chronicle's open-source projects under the OpenHFT umbrella. These include Chronicle Queue (a persisted low-latency shared memory messaging framework) and Chronicle Map (a high-performance in-memory/off-heap key-value store). The projects are widely used in low-latency and high-throughput applications. (GitHub) Lawrey regularly presents at software-engineering conferences (including QCon, JCrete) on topics such as microservices for performance, vertical scalability and practical techniques for achieving deterministic latency on the JVM. InfoQ and other outlets have covered his talks and interviews. (InfoQ, qconnewyork.com) Community and writing Since 2014, Lawrey has authored Vanilla Java, a technical blog focused on performance optimisation, concurrency and mechanical sympathy on the JVM. He has also contributed articles to Foojay.io. (blog.vanillajava.blog, foojay) He is a long-stand ## Improving the prompt to the AI to get better code DevFeed: [Improving the prompt to the AI to get better code]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-07-17T15:56:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Artificial Intelligence](), [Code](), [implementation](), [Latency]() Tags: [ai](), [change](), [code](), [exercise](), [how-to](), [latency](), [library](), [opinion](), [performance](), [prompt]() ### AI overview The article compares how several AI systems improve a Java code-optimization task when given a more detailed prompt. It concludes that prompt refinement improved weaker results, but the systems generally missed the same byte-array optimization and did not consistently reduce duplication, while longer processing did not produce a significantly better answer in this case. ### Source excerpt In a previous article I looked at one-shoting a solution to optimise code to show the variation in different AI. Thsi is the not the best way to get what you want however. More often you need to either refine the prompt or give feedback. After one-shoting the same prompt on multiple AI, I have created a refined prompt based on the various concerns with previous results. The prompt Based on the results in a previous run Asking multiple AI to optimise the same code Suggest how to implement this more optimally using low latency techniques to minimize any objects created. ## Use - a ThreadLocal for temporary data. - simple maths rather than a library, add comments for clarity if needed. - offset in the form ±hh, ±hhmm, or ±hhmmss, using the shortest form that does not lose information, where hh, mm, and ss are the hours, minutes, and seconds east (+) or west (-) of UT - return a `intern()` String. ## Don't use - String.format - String operations that create objects. - any colons, they aren't required - reduce code duplication ## The code private static String formatOffset(int millis) { String sign = millis < 0 ? "-" : "+"; int saveSecs = Math.abs(millis) / 1000; int hours = saveSecs / 3600; int mins = ((saveSecs / 60) % 60); int secs = (saveSecs % 60); if (secs == 0) { if (mins == 0) { return sign + twoDigitString(hours); } return sign + twoDigitString(hours) + twoDigitString(mins); } return sign + twoDigitString(hours) + twoDigitString(mins) + twoDigitString(secs); } private static String twoDigitString(int value) { return Integer.toString(value + 100).substring(1); } I typically use asciidoc rather than markdown, but trying to keep this example simple. None of the AI considered using a byte[] event though String now uses a byte[] as an underlying store. I asked each one to change the implementation to use a byte[] to create an ISO_8859_1 encoded string which they were able to do, but none suggested it. Gemini 2.5 pro This result is signifciantly improved. Use use of S ## Asking multiple AI to optimise the same code DevFeed: [Asking multiple AI to optimise the same code]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-07-16T21:11:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Artificial Intelligence](), [Code](), [long-context](), [Claude](), [GitHub Copilot]() Tags: [ai](), [claude](), [code](), [context-window](), [copilot](), [exercise](), [openai](), [opinion](), [performance]() ### AI overview The article compares how multiple AI systems optimize the same Java code. It reports that the systems produce different results, with some solutions introducing bugs or taking longer, and recommends using multiple opinions rather than treating one model as consistently best. ### Source excerpt As different AIs are implemented differently, they don't all provide the same answer, nor do they consistently outperform one another. The best approach is to use multiple AI and pick the one you like best. My goal here is not to declare a winner based on one example, but instead to show the variety of answers you can get with different AI. I asked each AI to Suggest how to implement this more optimally private static String formatOffset(int millis) { String sign = millis < 0 ? "-" : "+"; int saveSecs = Math.abs(millis) / 1000; int hours = saveSecs / 3600; int mins = ((saveSecs / 60) % 60); int secs = (saveSecs % 60); if (secs == 0) { if (mins == 0) { return sign + twoDigitString(hours); } return sign + twoDigitString(hours) + twoDigitString(mins); } return sign + twoDigitString(hours) + twoDigitString(mins) + twoDigitString(secs); } private static String twoDigitString(int value) { return Integer.toString(value + 100).substring(1); } Gemini 2.5 pro While Gemini is often my first go-to AI when I have a large code base, it's not the smartest. It does have a large context window, which means I can dump a large context into it without much thought on my part. However, if you have less than about 6,000 lines of context, you might find that o3-pro, o4-mini-high, or Claude 4 gives a better answer. In this case, it offered in about 10 seconds; private static String formatOffset(int millis) { long totalSeconds = Math.abs((long) millis / 1000); long hours = totalSeconds / 3600; long minutes = (totalSeconds % 3600) / 60; long seconds = totalSeconds % 60; StringBuilder sb = new StringBuilder(); sb.append(millis < 0 ? "-" : "+"); sb.append(String.format("%02d", hours)); if (minutes > 0 || seconds > 0) { sb.append(String.format(":%02d", minutes)); } if (seconds > 0) { sb.append(String.format(":%02d", seconds)); } return sb.toString(); } Not only is this approach slower, but it also fails to achieve the same result, which is even worse. The original format is +HHMMSS without a co ## Practical Considerations for Advancing AI Collaboration in Software Development DevFeed: [Practical Considerations for Advancing AI Collaboration in Software Development]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-05-15T19:35:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Artificial Intelligence](), [AI Development](), [Development](), [Prompt Engineering](), [Software Engineering]() Tags: [ai](), [challenges](), [collaboration](), [development](), [evaluation](), [info](), [maintainability](), [mentoring](), [opinion](), [practical]() ### AI overview This article examines practical considerations for collaborating with AI in software development. It argues for human oversight, stronger documentation and context, critical evaluation of probabilistic outputs, diverse model use, and awareness of deskilling, ethical, intellectual-property, and software-economics risks. ### Source excerpt TL;DR Human-in-the-loop is essential; AI offers probability, not certainty. AI excels at word-smithing, so spend more time on documentation and context. Leverage diverse AI models for varied research, improvements, and analysis. Be wary of deskilling: if AI makes a task trivial, agents may soon replace it. You should feel like you are testing the boundaries of what AI is capable of for at least some tasks. The Problem AI's proficiency in handling routine coding allows human engineers to dedicate more time to strategic activities such as system design, architectural planning, intricate requirement elicitation, and the rigorous evaluation of application performance across multifaceted metrics. Tools often amplify underlying behaviours and failures -- Rob Lambert Value is increasingly found not in rote knowledge, which AI can often provide, but in the capacity to frame complex problems effectively for AI, critically evaluate its probabilistic outputs, and innovatively integrate AI's capabilities into novel solutions. Developing with AI is not merely about adopting a new tool but about learning to collaborate with intelligence that operates on different principles, sometimes without profound contextual understanding, yet capable of processing and synthesising information at a scale and speed that surpasses human capability. However, this power comes with new challenges: ensuring the reliability of probabilistically generated outputs, managing the 'black box' nature of some AI reasoning, and navigating the ethical and IP landscapes of AI-generated content. Effective collaboration requires developers to master prompt engineering, the art of providing precise context, critically verifying outputs, and understanding the AI's inherent limitations to guide it effectively. This is akin to mentoring an exceptionally capable but occasionally erratic junior partner. Moreover, "disposable" or "ephemeral" AI-generated software carries profound and often unexamined implications for s ## Functional Interfaces Can Extend Other Interfaces DevFeed: [Functional Interfaces Can Extend Other Interfaces]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-02-20T09:04:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [interfaces]() Tags: [functional](), [interface](), [interfaces](), [puzzles]() ### AI overview The article explains that a functional interface can extend marker, functional, and non-functional interfaces, as well as an annotation. ### Source excerpt A functional interface can extend a marker interface, functional interface, non-functional interface, and an annotation. A recent X poll suggested 25% of those responding didn't know that. ## Generative AI, Software Development, and Career Growth for Java Developers DevFeed: [Generative AI, Software Development, and Career Growth for Java Developers]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-01-24T10:27:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Generative AI](), [AI Development](), [Programming](), [Java]() Tags: [ai](), [career-development](), [developers](), [development-tools](), [generative-ai](), [java](), [opinion](), [testing]() ### AI overview This article examines how generative AI may fit into software development and affect developers' career growth. It discusses the need for expertise and careful review of AI-generated results, career development, founder experience, and practical uses and limitations of generative AI. ### Source excerpt Table of Contents Introduction Superhuman Intelligence Is Already Here ATMs Didn't Replace Bank Tellers About Me Multidimensional Growth Areas of Career Development Scope of Consideration Roles Where All Areas Are Important The Range of a Founder's Role How Will AI Change Development? How You Ask the Question Changes the Result Some key terms in understanding how Generative AI works Estimating the Value of AI-Generated Documentation AI and the Reverse Baltimore Phenomenon The Baltimore Phenomenon The Reverse Baltimore Phenomenon Filling a void Brainstorming Ideas Sample Project 2048 Using Prompts as Meta-Programming When AI is useful What Generative AI Can't Yet Do Human in the Loop Conclusion This article is background material for this talk Lessons learnt from founding my own company, and over 30 years hands-on coding Introduction Unlike most deterministic development tools, Generative AI is a productivity tool that uses a statistical model to produce results. It can be useful when used appropriately and carefully reviewed, but fundamentally, it only has a probability of being correct. Plausible results can be challenging to review unless you have expertise in the content produced. In this talk, I will explore where I see Generative AI fitting into development and how it can help developers grow their careers. I will look at practical tips and ways to consider it for development. Working with Generative AI can feel meta, so I will start with a quote about quotes: I love quotations because it is a joy to find thoughts one might have beautifully expressed with much authority by someone recognised as wiser than oneself. -- Marlene Dietrich 1901-1992 Superhuman Intelligence Is Already Here As of November 2024, the United States' El Capitan is the most powerful supercomputer in the TOP500, reaching 1742 petaFlops (1.742 exaFlops) on the LINPACK benchmarks. -- TOP500 Supercomputer Wikipedia Supercomputers have long been able to do calculations no human can, yet they can't ## Does AI-Generated Documentation Have Value? DevFeed: [Does AI-Generated Documentation Have Value?]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-01-10T17:42:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Artificial Intelligence](), [Documentation](), [user guide](), [Code]() Tags: [ai](), [code](), [developers](), [documentation](), [opinion](), [user-guide]() ### AI overview This opinion article evaluates the usefulness of AI-generated documentation. Based on a subjective review of generated user guides, it argues that most output is correct but uninteresting, while some content is wrong and a smaller portion is compelling. Reviewing and heavily editing the output can still reveal documentation improvements, corrections, testing ideas, performance checks, and clarifications. ### Source excerpt As many have observed, at best, AI generates either: Mundane, repetitive documentation or code that most experts already know or If an expert doesn't know it, they can ask an AI to explain it anyway. Is it the case that if an AI can generate it, it's not worth adding to your documentation or code? While this is usually the case, there is still value in reading AI-generated documentation as a means of reviewing and validating what you might write differently. In this post, I show how changing the documentation can affect the AI's output and how reviewing it can be a useful exercise. Estimating the value of AI-generated documentation I tried to gauge the relative value of AI-generated documentation for my knowledge and set expectations for others. I asked o1 pro to generate user guides in several different ways I considered effective for: a simple class and package a large class and package a complex class and package Then, I subjectively estimated how many points made were compelling, interestingly incorrect, correct but not interesting, or just plain wrong. I ignored repeated points. This is what I concluded: Type Average points per query Percentage Correct but not interesting 35 80% Just plain wrong 5.4 13% Compelling to keep 2.1 5% Wrong But Interestingly 0.8 2% This assumes I crafted the query to be as specific as possible. Without a specific query, the AI can generate a lot of irrelevant or wrong content. Understandably, this can lead people to conclude that AI is unusable. However, there is still value in reviewing AI-generated documentation. Why Bother Reviewing AI-Generated Content? If we go into this process with the mindset that the content will be ruthlessly edited, we can extract value for relatively low effort. For example, each file I have reviewed had, on average approx 3 points that are compelling to keep or errors worth addressing. Is this point worth emphasising in your official documentation? Is the suggestion so far off that it needs immediate cor ## Generative AI and the Reverse Baltimore Phenomenon DevFeed: [Generative AI and the Reverse Baltimore Phenomenon]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-01-08T13:08:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Artificial Intelligence](), [Documentation](), [Generative AI](), [code comments](), [context]() Tags: [ai](), [code-comments](), [context](), [documentation](), [generative-ai](), [opinion]() ### AI overview The article introduces the Reverse Baltimore Phenomenon as an analogy for a tendency in generative AI-generated documentation and code comments. With limited context, AI may fill gaps with authoritative-sounding but unnecessary details, creating a misleading sense of completeness. The article argues that useful documentation should provide enough explanation without overwhelming readers. ### Source excerpt One of the first challenges developers might face is getting generative AI to produce accurate documentation. Once you are comfortable doing this, the next challenge is creating enough documentation to be helpful without overwhelming the reader. Until generative AI came along, it might have seemed like there could never be too much documentation. Now, the challenge is to provide just enough detail to give understanding without overwhelming the material with unnecessary details. I was exploring the best way to generate accurate documentation for a project as I was flying over Australia and saw Alice Springs on the map, and it reminded me of the Reverse Baltimore Phenomenon. Generating documentation can give a "sense of completeness" that will likely be a distraction rather than have practical value. The text produced by a generative AI system can superficially convincingly feel "whole", but much of it is fluff that isn't actually helpful to the reader or an AI using it as instructions. e.g. copilot or a chat app. The Reverse Baltimore Phenomenon describes how small but isolated towns (like Alice Springs) can appear on a zoomed-out map while much larger cities elsewhere remain unlabeled. They appear because, in a sparsely populated area, the cartographer (or map algorithm) has "room" for that single label--despite far bigger cities in denser regions that don't make it onto the map. Generative AI exhibits a similar dynamic with documentation and code comments: in an attempt to be thorough, it sometimes fills "empty space" with details that don't truly matter. Much like Alice Springs popping up on world maps simply because there's little else around, AI-generated documentation can insert seemingly authoritative but superfluous commentary simply because there's room to elaborate. Both phenomena stem from "filling a void": Sparse vs. Dense Spaces Cartography: Sparse regions allow tiny towns to receive disproportionate emphasis. AI Text Generation: Minimal context leads the ## Prompt Engineering for AIDE DevFeed: [Prompt Engineering for AIDE]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2025-01-04T07:11:00Z Content type: tutorial Language: en Sources: [Vanilla Java]() Topics: [Prompt Engineering](), [Artificial Intelligence](), [Code](), [Development](), [Requirements](), [Java](), [Testing](), [Concurrency]() Tags: [ai](), [code](), [concurrency](), [development](), [engineering](), [exercise](), [info](), [java](), [opinion](), [prompt](), [prompt-engineering](), [requirements](), [testing]() ### AI overview A tutorial on writing structured AsciiDoc requirements as prompts for AI-generated Java code in AIDE. It explains how to specify context, constraints, references, concurrency requirements, performance targets, error handling, and testing needs. ### Source excerpt This article was AI-generated using this project as context. AIDE Project. The purpose of this project is to see how much an AI could generate given enough context, and in this project, all the "source" code is generated using the requirements and unit tests as context. This follows the Next-Level Development: Harnessing AI with AIDE approach. The main parts are: Requirements Documents in .adoc format. JUnit tests in Java. AIDE itself. AI-generated code in Java. Even the articles written about AIDE are part of the context for the AI. This article is about how to write requirements as a prompt for AI to generate code, seeded with AIDE in the context. Everything after this line is AI generated. Prompt engineering can differentiate between AI-driven code that works and genuinely excels. Drawing insights from real-world Java projects--especially those striving for low latency, high throughput, and clear domain logic--this article will show you how to shape AsciiDoc prompts to engage the AI more effectively. We'll also explore how these techniques fit neatly into AIDE's (Artificial Intelligence Development Environment) documentation-driven approach, building on the examples below. 0. Well-Formed Prompt Examples Strong prompts don't just request code; they specify context, constraints, references, and testing requirements. Below are refined examples of "good prompts" structured to deliver more domain-aligned code and documentation. 0.1 Concurrency-Safe Service Prompt = Concurrency-Safe Order Processor :context: high-throughput trading system We need a Java service that: * Accepts orders via a concurrent queue (Chronicle Queue recommended). * Processes up to 100,000 orders per second. * Ensures thread safety using optimised locking (or lock-free where practical). * Logs all failures (e.g., malformed orders) with a contextual message. Constraints: * Sub-100 µs end-to-end latency per order. * Must pass the existing `OrderProcessorTest` found in xref:order-tests.ad[Order Tests] ## AIDE: An AI-Assisted, Documentation-Driven Development Workflow DevFeed: [AIDE: An AI-Assisted, Documentation-Driven Development Workflow]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-31T08:24:00Z Content type: tutorial Language: en Sources: [Vanilla Java]() Topics: [AI-assisted coding](), [Documentation](), [Test-driven development](), [Prompt Engineering](), [Requirements](), [Code generation](), [unit tests](), [Development]() Tags: [ai](), [documentation](), [github](), [guide](), [opinion](), [performance](), [prompt-engineering](), [requirements](), [testing](), [tests](), [training](), [unit-tests]() ### AI overview The article introduces AIDE, a workflow that combines AI-assisted code generation, structured AsciiDoc prompts, documentation-driven development, and test-driven development. It presents documentation as a single source of truth linking requirements, implementation, and tests, while leaving domain-specific logic and refinement to human developers. ### Source excerpt If it's worth doing by hand, it's worth automating. Just because not everyone is (yet) a world-class developer; that doesn't mean we can't step closer to that expert-level space. In this post, I will introduce AIDE (Artifical Intelligence Development Environment), a powerful workflow that merges AI-driven code generation with a sharp focus on documentation-driven development. With AIDE, I tap into the best of artificial intelligence (AI) while respecting the real human insight needed for domain-specific logic. The result? An environment that streamlines repetitive coding, synchronises requirements, code, and tests, and elevates your engineering game. Here is a practical example of an AIDE on GitHub developed using it's own AIDE. Introducing AIDE: Merging AI and Documentation-Driven Development AIDE transforms development by combining: Prompt Engineering with AsciiDoc: Clear, structured prompts guide AI to produce accurate, context-aware outputs. Documentation-Driven Development: Documentation as the "single source of truth" ensures alignment across requirements, tests, and implementation. Test-Driven Development: Unit tests validate outputs, forming a feedback loop between documentation and implementation. At times, AIDE makes you feel more like a curator than a coder. Yet, this curation--refining AI-generated scaffolds and aligning them with domain-specific logic--delivers impressive results. Why AIDE Empowers Developers Confidence in Documentation Documentation is the backbone of AIDE's approach. With a cohesive workflow: Single Source of Truth: AsciiDoc becomes a live blueprint, ensuring code, tests, and documentation stay aligned. Real-Time Updates: Incremental updates highlight changes, prompting immediate documentation synchronisation. Onboarding Simplified: New developers can onboard quickly, thanks to the always-current AsciiDoc artefacts. Innovation-Focused Development: By delegating boilerplate tasks to AI, developers focus their energy on problem-solving an ## Empowering Your Annotations with Fields DevFeed: [Empowering Your Annotations with Fields]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-21T22:13:00Z Content type: tutorial Language: en Sources: [Vanilla Java]() Topics: [Java](), [Java Language](), [Code](), [interfaces](), [enum]() Tags: [class](), [code](), [enum](), [info](), [interfaces](), [java](), [java-language](), [opinion]() ### AI overview This tutorial explains how Java annotations can contain nested classes, interfaces, enums, other annotations, static fields, and embedded logic. It discusses uses such as domain converters, framework lifecycle hooks, and syntactic sugar, while noting that excessive nesting can reduce readability. ### Source excerpt Introduction Java's annotation system has come a long way since its introduction in Java 5. At first glance, annotations appear to be mere metadata markers on classes and methods. However, annotations can do much more than that. You can nest types within them, incorporate fields that reference helper classes, and even embed logic via static singletons. These capabilities provide a powerful mechanism for integrating domain-specific or framework-specific functionality right into your code, in ways that are both compact and self-documenting. Why Add Code to Annotations? The Java language specification usually treats annotations as static metadata describing a type, method, field, or parameter. However, you can leverage nested classes (including enums, interfaces, and even other annotations) to extend the functionality of a single annotation. This approach allows you to keep logic closely tied to the metadata, rather than scattering it across multiple classes. Common use cases include: Custom domain converters. For example, if you have a long that needs to be stored in an encoded format (e.g., Base85), you can supply a default converter directly within the annotation. Framework-specific lifecycle hooks. You can embed an interface for processing the annotation, enabling the framework to perform reflective lookups and apply behaviour at runtime. Syntactic sugar. Rather than writing @LongConversion(SomeConverter.class), you could write @ShortText, which internally references a known converter. Nesting Types in Java You can nest various kinds of types within your classes or annotations--these include interfaces, enums, classes, and even other annotations. Although nesting these types can feel unconventional, it is fully supported by the language. For example: public class A { public interface B { public enum C { ; public @interface D { public class E { // etc etc } } } } } While this example might look bizarre, it demonstrates the power and flexibility of Java's nesting rule ## Calendar and Time-Zone Complexities in Software DevFeed: [Calendar and Time-Zone Complexities in Software]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-20T14:20:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Temporal data](), [Data analysis](), [Time Series]() Tags: [exercise](), [info](), [pitfalls](), [time](), [time-series]() ### AI overview This commentary explains why date and time handling is complex in software. It discusses time zones, calendar systems, cultural conventions, and historical changes that can cause incorrect date arithmetic and other defects. ### Source excerpt I find time fascinating and surprisingly complex. Time zones and calendars change from place to place over time. There are a number of interesting websites on the subject. Time is one of those concepts that appears deceptively simple on the surface yet becomes increasingly intricate the more we examine it. As software developers, we often face scenarios where we must handle dates and times and their myriad associated rules--time zones, calendar systems, cultural conventions, and historical irregularities. Working with time can lead us into subtle pitfalls that affect everything from straightforward user interfaces to global financial systems. Time is an illusion. Lunchtime doubly so. -- Douglas Adams The Hitchhiker's Guide to the Galaxy The Surprising Complexity Behind Time Time is not uniform. Humans have invented calendar systems and measurement techniques, each influenced by politics, religion, and culture. As a result, how we record and interpret dates has repeatedly changed over the centuries. These shifts mean that historical dates do not map cleanly onto modern calendars. The Julian and Gregorian calendars, the French Revolutionary calendar, and the attempts by certain countries to gradually or abruptly adjust to the Gregorian standard all introduce tricky discontinuities. We also have complex local customs, such as the Korean age-counting system, or unique historical anomalies like Sweden's February 30th in 1712. Understanding these anomalies is crucial when dealing with historical data sets, genealogical records, financial time series that stretch back centuries, or any domain that involves retrospective data analysis. From a technical perspective, these complexities translate into potential defects. Off-by-one errors, incorrect conversions, or failure to account for historical shifts can lead to incorrect date arithmetic. Even if you never work with centuries-old data, these quirks are cautionary tales: time is never as straightforward as it first appears. H ## AI Adoption in Software Engineering: Practical Limits and the Need for Human Review DevFeed: [AI Adoption in Software Engineering: Practical Limits and the Need for Human Review]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-16T12:03:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Artificial Intelligence](), [AI Strategy](), [Software Engineering](), [AI-assisted coding]() Tags: [adoption](), [ai](), [ai-adoption](), [human-review](), [info](), [opinion](), [security](), [testing]() ### AI overview The article examines the practical challenges of adopting AI in software engineering, including inaccurate or outdated suggestions, weak contextual understanding, inconsistent style, and security or compliance risks. It argues that human review, domain expertise, testing, and validation remain necessary. ### Source excerpt Artificial Intelligence (AI) has long promised to transform software development. Yet, as many experienced engineers discover, initial enthusiasm often settles into a more subdued reality. This is the "Trough of Disillusionment" within the Gartner Hype Cycle--where inflated expectations give way to measured assessments. In this phase, teams confront the practical limitations of AI-driven tools, refine their strategies, and seek a balance between what AI can deliver and what human expertise must still provide. This article continues from AI on the Hype Cycle. We do these things not because they are easy, but because we thought they were going to be easy. -- Programmer's Credo Challenges of AI Adoption When integrating AI into software engineering workflows--be it code completion, architectural documentation, or performance tuning hints--teams quickly encounter stumbling blocks: Accuracy and Reliability: AI-generated content may contain inaccuracies, out-of-date references, or misunderstandings of domain-specific terms. Ensuring factual correctness requires careful human review and validation. AI outputs often present plausible suggestions that fail strict validation. For instance, an AI tool may confidently return a code snippet referencing APIs deprecated in Java 11 or misapply concurrency constructs from Java 21 libraries. Ensuring correctness demands human review, domain expertise, and rigorous testing Contextual Understanding: AI suggestions may misalign your codebase's patterns or standards without proper context. For example, given a legacy codebase optimised around ConcurrentSkipListMap, an AI may suggest using HashMap for "simplicity." Senior developers must provide guardrails, review outputs, and ensure that each recommendation aligns with existing architectural guidelines and performance expectations. Maintaining Consistency and Style: Projects often follow strict coding conventions and documentation formats. AI outputs might vary in style, indentation, or nami ## AI on a Hype Cycle DevFeed: [AI on a Hype Cycle]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-15T20:38:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Artificial Intelligence](), [AI Models](), [coding](), [Learning]() Tags: [ai](), [ai-models](), [developers](), [exercise](), [info](), [opinion](), [technology](), [trends]() ### AI overview This article examines AI through the lens of technology hype cycles, arguing that developers should learn from past technological trends, maintain perspective about short-term hype, and prepare for AI's longer-term effects. ### Source excerpt This is the first in a series of posts supporting a talk I will be giving online at JChampionConf 27th January 27th 2025. Lessons learnt from founding my own company, and over 30 years hands on coding In these posts, I am looking to provide some theory as well as practical examples. One way to try to predict what is possible in the future is to look at the past. One of may favourite ways to look at the past is through aphorisms. Aphorisms are short, pithy statements that express a general truth or opinion. I love quotations because it is a joy to find thoughts one might have, beautifully expressed with much authority by someone recognised wiser than oneself. -- Marlene Dietrich 1901-1992 Quotes about Learning from History and Adaptability The only constant is change. -- Heraclitus of Ephesus c. 500 BCE In the ever-evolving realm of AI, this ancient wisdom remains pertinent. Today's cutting-edge AI models may become tomorrow's standard tools. Developers must stay agile, continually updating their skill sets to keep pace with technological advancements. The only constant in the technology industry is change. We are now in the most exciting time of our industry. -- Marc Benioff Salesforce CEO Embracing this change is a hallmark of a senior developer. In an industry where new frameworks, platforms, and tools appear constantly, the ability to evolve, learn from past experiences, and mentor others ensures you remain indispensable. History doesn't repeat itself, but it often rhymes. -- Mark Twain (no definitive written source) Early 20th century History provides a blueprint for what might be possible with AI. By studying previous technological trends, developers can better prepare for the challenges and opportunities that AI presents. We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. -- Roy Amara Institute for the Future Known as Amara's Law, this principle is crucial when assessing AI's impact. While the immediate ## What might an AI System Prompt look like? DevFeed: [What might an AI System Prompt look like?]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-15T16:47:00Z Content type: opinion Language: en Sources: [Vanilla Java]() Topics: [Conversational AI](), [Artificial Intelligence](), [Prompt Engineering]() Tags: [ai](), [conversational-ai](), [ethics](), [info](), [opinion](), [reasoning](), [safety](), [system-prompts]() ### AI overview The article explains the role of system prompts in shaping an AI assistant's objectives, behavior, reasoning, and safety boundaries. It then presents a speculative example of what system prompts for a hypothetical next-generation conversational AI called "o2" might contain, emphasizing that the example is not based on a real system. ### Source excerpt Not surprisingly, the system prompts for "o1" are restricted, but it can provide a hypothetical answer. Understanding the Role of System Prompts System prompts serve as the invisible backbone of an AI's reasoning process. They define core objectives, ethical boundaries, and operational tactics well before the user asks a question. In older models, these prompts were often implicit or underspecified, leaving the AI uncertain about handling ambiguous instructions or potentially unsafe requests. Hypothetical System Prompts for o2 The system prompts for a hypothetical next-generation O2 restricted are as follows: Imagine you are the next generation of chat AI called o2; what system prompts might it have? System Prompts for "o2" (Hypothetical Example) Below is a hypothetical set of system-level instructions that a next-generation chat AI--let's call it "o2"--might be given before it begins interacting with users. These prompts are entirely speculative and designed to illustrate what such an advanced system's guiding principles, constraints, and operational details might look like. They are not drawn from any real system but represent a plausible future scenario. Core Directives and Alignment You are "o2," an advanced conversational AI designed to assist users with factual information, reasoning, creativity, and problem-solving. Remain consistently aligned with the policies, values, and ethics embedded in your training. Adhere to correctness, helpfulness, and user safety standards at all times. User Focus and Understanding Accurately interpret user instructions, requests, and goals. Aim to understand the user's context, including their level of expertise, language, and purpose for the query. Strive to provide answers with appropriate detail, clarity, and complexity, adapting as you gain more context from the conversation. Explainable Reasoning and Transparency Make reasoning steps and logic explainable when asked or when clarity is needed. Avoid unexplained leaps in reasoni ## Demystifying Java Object Sizes: Compact Headers, Compressed Oops, and Beyond DevFeed: [Demystifying Java Object Sizes: Compact Headers, Compressed Oops, and Beyond]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-10T16:51:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [systems](), [Code](), [Concurrency]() Tags: [code](), [gc](), [info](), [java](), [jvm](), [low-latency](), [memory](), [object](), [opinion](), [performance](), [threads]() ### AI overview An article explaining how Java object sizes are affected by Compressed Oops and Compact Object Headers. It describes estimating object sizes with JVM memory measurements, while accounting for TLAB allocation, garbage collection, and concurrent allocations. It also summarizes JEP 450's proposed reduction of object headers to 64 bits on supported 64-bit platforms. ### Source excerpt Introduction Measuring an object's size in Java is not straightforward. The platform encourages you to consider references and abstractions rather than raw memory usage. Still, understanding how objects fit into memory can yield significant benefits, especially for high-performance, low-latency systems. Over time, the JVM has introduced optimisations like Compressed Ordinary Object Pointers (Compressed Oops) and, more recently, Compact Object Headers. Each of these can influence how large or small your objects appear. Understanding these factors helps you reason about memory usage more concretely. Measuring Object Sizes In principle, you can estimate an object's size by creating instances and observing changes in the JVM's free memory. However, you must neutralise certain factors to get consistent results. For example, turning off TLAB allocation (-XX:-UseTLAB) makes memory usage more directly observable. Repeated measurements and median calculations can reduce the impact of GC and concurrent allocations. A GC can occur while you are creating your object. This will result in more free memory at the end than when you started. I ignore any negative sizes in this test ;) Other threads in the system could use memory at the same time. I perform multiple test and take the median, which removes any outliers. Below is a rough approach: long before = usedMemory(); Object obj = createYourObject(); long after = usedMemory(); long approximateSize = after - before; This test SizeofTest.java is a simple test which creates a number of objects and measures the memory used to create each object. This is usually the same as the amount of memory the object retains for simple objects. Approximate layout of an object Memory Region Description Size (Bytes) Mark Word Header information including identity hash code, lock state, and GC metadata 8 bytes (on 64-bit JVMs) Class Pointer (Klass Pointer) Reference to the object's class metadata, used internally by the JVM Typically 4 bytes with C ## Novel Uses of Core Java for Low-Latency and High-Performance Systems DevFeed: [Novel Uses of Core Java for Low-Latency and High-Performance Systems]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-09T16:24:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [Low Latency](), [systems](), [Code](), [Exception](), [Data structures]() Tags: [diagnostics](), [exception](), [high-performance](), [info](), [java](), [latency](), [low-latency](), [opinion](), [performance](), [systems]() ### AI overview This article examines unconventional Core Java techniques for low-latency and high-performance systems. It discusses capturing stack traces without throwing exceptions, system-wide unique timestamps, trivially copyable data types, zero-garbage strategies, and conditional diagnostic tracing, with attention to performance, determinism, and production use. ### Source excerpt Standard Java libraries and idioms may only sometimes suffice in high-performance and low-latency Java systems. This article explores unconventional yet practical techniques that push Core Java to its limits, focusing on performance, diagnostics, and determinism. Drawing on experiences from building ultra-low-latency libraries and infrastructure, we will highlight patterns such as capturing stack traces without exceptions, system-wide unique timestamps, "trivially copyable" data types, zero-garbage strategies, and more. We will also discuss lessons from applying these approaches in production environments, where nanosecond-level considerations are the norm. This is taken from the transcript for Novel Uses of Core Java for Low-Latency and High-Performance Systems Moderated by Melissa McKay. Introduction Developers often rely on standard Java idioms--throwable hierarchies, BigDecimal for financial calculations, thread-local resources, or off-the-shelf message queues. While straightforward, these approaches can impose unwanted latency, garbage generation, or diagnostic blind spots. Even microseconds matter in low-latency trading, market data processing, or other time-sensitive domains. We aim to present "novel uses" of Core Java that remove such bottlenecks, allowing developers to produce cleaner, more deterministic, and more insightful code. These techniques are not always common knowledge, yet they can deliver substantial benefits in the right context. Capturing Stack Traces Without Exceptions Most Java developers assume that Throwable subclasses like Exception or Error must represent actual errors. However, you can extend Throwable to capture a stack trace at any point, even without throwing it. public final class StackTrace extends Throwable { // Intentionally extends Throwable but never thrown } Why do this? Treating a stack trace as a standalone data structure lets you record where and when certain critical events occur. For example, if a resource is closed premat ## Trivially Copyable Objects in Java DevFeed: [Trivially Copyable Objects in Java]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-09T15:38:00Z Content type: tutorial Language: en Sources: [Vanilla Java]() Topics: [Java](), [Low Latency](), [real-time](), [C++](), [systems]() Tags: [benchmarks](), [c-plus-plus](), [ecosystem](), [high-performance](), [java](), [jvm](), [latency](), [low-latency](), [opinion](), [performance](), [real-time]() ### AI overview This article explains how Java objects composed only of fixed-size primitive fields can emulate C++ trivially copyable objects for more efficient serialization. It describes reducing object graph traversal, reflection, and per-field copying through bulk memory operations, and discusses using Chronicle Bytes when strict trivial copyability is unnecessary. The approach trades flexibility for lower latency and higher throughput in latency-sensitive systems. ### Source excerpt TL;DR Problem: Java's standard serialisation can be slow due to scattered object fields and reflection-based overhead. Approach: Emulate C++-style trivially copyable objects by restricting fields to primitives, enabling bulk memory copies. Result: Near C++-like serialisation performance, dramatically reducing latency and improving throughput. Trade-offs: Requires careful design, limited flexibility, and testing for JVM compatibility. Outcome: Low-latency systems with high performance, suitable for financial data feeds, real-time analytics, and other latency-sensitive domains. Introduction For low-latency systems, every microsecond has tangible business impact. In high-frequency trading, real-time analytics, and similarly time-sensitive workloads, even minor inefficiencies in serialisation and deserialisation can degrade throughput and responsiveness. The seemingly mundane act of converting objects into bytes and back often becomes a performance bottleneck. This article explores how we can emulate a C++-like concept of Trivially Copyable Objects within Java to achieve far more efficient serialisation. By ensuring objects contain only fixed-size primitives, we can sidestep the traditional overheads of object graph traversal, reflection, and per-field copying. Instead, we can treat them as contiguous memory blocks, dramatically reducing the time taken to read and write data. We shall also consider how to get very close to this performance using Chronicle Bytes without strictly requiring trivial copyability. This technique blends the low-level efficiency with the safety and familiarity of Java's ecosystem. The Core Challenge of Java Serialisation Most Java object graphs are composed of references linking scattered heap allocations. Serialising such objects typically involves visiting numerous memory locations, reading each field individually, and writing them out one at a time. This is akin to foraging around a warehouse for individual items whenever you need to pack a ## Efficient Distributed Unique Timestamp Identifier Generation DevFeed: [Efficient Distributed Unique Timestamp Identifier Generation]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-08T19:51:00Z Content type: tutorial Language: en Sources: [Vanilla Java]() Topics: [identifier](), [systems](), [Microservice](), [Concurrency](), [ordering](), [Latency]() Tags: [benchmarks](), [concurrent](), [distributed](), [identifier](), [latency](), [microservices](), [ordering](), [performance](), [precision](), [unique]() ### AI overview The article presents a distributed identifier scheme that embeds a host identifier into a nanosecond-resolution timestamp. It describes the resulting 64-bit identifiers as globally unique, human-readable, chronologically sortable, and suitable for high-concurrency, latency-sensitive systems. ### Source excerpt Distributed unique timestamp identifiers provide a powerful means of generating globally unique, human-readable 64-bit values at sub-microsecond speeds. By embedding a host identifier directly into a nanosecond-resolution timestamp, you gain a simple, chronologically sortable, and intuitive scheme for correlating events across multiple hosts. This approach offers significant benefits in latency-sensitive systems where even small delays can become expensive at scale. Introduction In a world of horizontally scaled microservices, ensuring that each event or message receives a unique identifier across multiple machines can be challenging. Traditional approaches often rely on UUIDs, which--while easy to use--lack intuitive readability and can be relatively expensive to generate in ultra-low-latency scenarios. Our solution builds upon nanosecond-resolution timestamps combined with a host identifier embedded directly into the lower-order digits of the timestamp. This technique, inspired by previous work on system-wide unique nanosecond timestamps, creates identifiers that are compact, human-interpretable, and extremely fast to produce. In essence, we treat time itself as the source of uniqueness. By carefully structuring the timestamp and assigning a unique hostId per machine (or per logical partition), we can scale to produce up to one billion unique 64-bit identifiers per second. These identifiers repeat only after centuries, making them suitable for long-running systems and distributed architectures that demand both precision and high performance. Concurrent identifier generation in a distributed system In distributed environments, colliding identifiers can lead to data corruption, misrouted requests, or difficulty in debugging. Although UUIDs solve uniqueness issues, they do not inherently convey temporal ordering or machine origin. More subtle forms of identifiers, such as database sequence numbers or custom counters, often need to be more convenient when synchronising ## A Java Conversion Puzzler: Understanding Implicit Casting and Overflow DevFeed: [A Java Conversion Puzzler: Understanding Implicit Casting and Overflow]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-07T22:23:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [floating-point](), [Code]() Tags: [code](), [critical](), [exercise](), [floating-point](), [info](), [java](), [performance](), [puzzles]() ### AI overview This article explains a Java conversion puzzle involving compound assignment, implicit casting, floating-point rounding, and integer overflow. It shows why adding 0.0f can produce different results for int and long values, including a conversion to Integer.MIN_VALUE when the rounded value is cast back to int. ### Source excerpt This article explores a subtle Java conversion puzzle that challenges assumptions about how arithmetic operations, implicit casting, and floating-point conversions interact. Inspired by complexities often encountered in low-latency and high-performance environments, it demonstrates why a keen understanding of Java's type system is essential for building reliable and efficient applications. Introduction The following example demonstrates a scenario where an innocuous-looking arithmetic operation leads to a surprising result. While such questions are rare and arguably impractical, they highlight subtle behaviours that can affect correctness and performance, especially in critical systems like high-frequency trading platforms or complex data-processing pipelines. The Problem: A Surprising Print Statement Consider the following code: int i = Integer.MAX_VALUE; i += 0.0f; int j = i; System.out.println(j == Integer.MAX_VALUE); // true At first glance, one might assume that adding 0.0f to an int should not change its value. Indeed, the output true reinforces this notion. However, if you change int i for long i, things get weird: long i = Integer.MAX_VALUE; // only the type of i is changed i += 0.0f; int j = (int) i; System.out.println(j == Integer.MAX_VALUE); // false System.out.println(j == Integer.MIN_VALUE); // true What is going on, you might wonder? Let me start by explaining why using a long gives such a strange result. Understanding the Implicit Casting The key detail lies in how Java handles the += operator. It is not strictly equivalent to a = a + b; but rather: a += b; has a subtle difference which most of the time doesn't matter: // has an implicity cast here a = (typeOf(a)) (a + b); Another subtle feature of addition is that the result is the "wider" of the two types. This means that: i += 0.0f; is actually: i = (int) ((float) i + 0.0f); // or i = (long) ((float) i + 0.0f); The result of (float) i can be imprecise due to floating-point rounding. A float has a 2 [Next page]()