Your SDKs are more brittle than you think. We treat forward compatibility as an API versioning problem. But what happens when an API evolves faster than consumers can update their SDKs? The client breaks. At Speakeasy, we maintain that SDKs aren't just thin clients. They're products that deserve the same engineering rigor as the APIs they wrap. I've been working with Java SDKs, so I'll speak to the two common failure points in them, which are evolving enums and polymorphic responses (unions). A new enum value from the server shouldn't crash a client that hasn't updated yet. I wrote about the patterns we use: 1. Open Enums in Java: A class-based pattern for handling unknown enum values gracefully. 2. Java Unions with Jackson: Techniques for deserializing evolving union types without breaking. Links in the comment below. #Java #SDK #APIDesign #DeveloperExperience
Java SDKs: Brittle and Breaking
More Relevant Posts
-
A simple doubt triggered today’s deep dive. I was revisiting Java’s “Write Once, Run Anywhere” concept when a question hit me: If I can copy C/C++ source code to another OS and run it after compiling, then how is Java different? Why is Java called platform independent? That confusion forced me to experiment instead of just accepting definitions. I: – Compiled individual .java files manually – Observed when .class files were actually created – Deleted them and tested execution behavior – Compared it mentally with how C/C++ produce OS-specific binaries The breakthrough: Java’s portability isn’t at the source level — it’s at the bytecode level. C/C++ require recompilation per platform because they produce machine-specific binaries. Java separates compilation (javac) and execution (JVM), and that architectural split is what enables true portability. The real lesson wasn’t about Java. It was about pushing a doubt until the mental model becomes clear. Sometimes one persistent “why?” is all it takes to understand a system deeply. #LearningInPublic #Java #SystemsThinking #CSJourney
To view or add a comment, sign in
-
🚀 Day 9 of My 90 Days Java Full Stack Challenge Today, I focused on strengthening my understanding of String manipulation, Stack implementation, and Exception Handling in Java. 🧩 Problems Practiced ✔ String Compression Input: "aaabbc" Output: "a3b2c1" Learned how to implement run-length encoding logic using StringBuilder efficiently in O(n) time. ✔ Valid Parentheses Input: "({[]})" Used Stack (including manual stack implementation) to validate proper nesting of brackets. Improved understanding of LIFO and stack-based problem solving. ⚙ Java Concept Practiced ✔ Exception Handling try–catch blocks finally block usage Checked vs Unchecked exceptions Why exceptions shouldn’t be used for normal control flow 🧠 Key Takeaways Importance of handling edge cases Writing optimized code instead of brute force Understanding internal working of Stack Writing cleaner and more structured Java logic Consistency matters more than intensity 💪 #90DaysJavaFullStack #Java #StringManipulation #Stack #ExceptionHandling #LearningInPublic #DeveloperJourney
To view or add a comment, sign in
-
Java isn’t “old.” It’s battle-tested. While new languages trend every year, Java quietly powers: • High-throughput banking systems • Distributed microservices architectures • Enterprise workflow platforms • Large-scale cloud-native applications What keeps it relevant? Not nostalgia. But evolution. From Java 8 lambdas To Java 17 LTS To Java 21 virtual threads The language keeps adapting to modern engineering needs. Today, writing Java isn’t just about syntax. It’s about: • Concurrency management • JVM tuning • Garbage collection behavior • Thread pools vs virtual threads • Observability and monitoring • Designing resilient microservices The real power of Java shows up in production. Under load. Under scale. Under pressure. Frameworks come and go. But a well-designed Java system can run for years. Curious, what’s one Java feature you think changed the game? #Java #SpringBoot #BackendDevelopment #Microservices #CloudNative #SoftwareEngineering
To view or add a comment, sign in
-
-
Many people write Java code without really understanding 𝘄𝗵𝗲𝗿𝗲 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗯𝗲𝗴𝗶𝗻𝘀. They know the line. They don’t know the reason. The 𝚖𝚊𝚒𝚗 method isn’t special because of magic. It’s special because the 𝗝𝗩𝗠 𝗻𝗲𝗲𝗱𝘀 𝗮 𝗰𝗹𝗲𝗮𝗿 𝗲𝗻𝘁𝗿𝘆 𝗽𝗼𝗶𝗻𝘁. When a Java program starts, the JVM looks for: • A class • A method with an exact signature • A predictable way to pass arguments That strictness isn’t accidental. It allows Java programs to: • Start consistently on any machine • Accept external inputs cleanly • Be managed by tools, frameworks, and servers The 𝚂𝚝𝚛𝚒𝚗𝚐[] 𝚊𝚛𝚐𝚜 part is often ignored, but it represents something important : your program doesn’t live in isolation. It can receive data from outside — commands, environments, systems. Understanding this changes how you see programs not as scripts, but as 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀 𝗶𝗻 𝗮 𝗹𝗮𝗿𝗴𝗲𝗿 𝘀𝘆𝘀𝘁𝗲𝗺. Today was about: • How the JVM locates the entry point • Why the 𝚖𝚊𝚒𝚗 method signature must be exact • How arguments connect your program to the outside world Once you know how a program starts, you write code with more intention. #Java #JVM #ProgrammingConcepts #SoftwareEngineering #DeveloperJourney #LearningInPublic
To view or add a comment, sign in
-
-
Latest edition of Java newsletter is out ! Here is what we are covering : - How Netflix handles 270k RPS with Java concurrency - Spring Boot rest client builder explained - Spring AI prompt caching - Power of data frames in Java - Pragmatic aether: Let Java be Java - How to customize JaCoCo report - ML based spam detection using ONNX - Open Telemetry & Distributed tracing - Optimizing Java Class Metadata in Project Valhalla And more… Read the newsletter: https://lnkd.in/gfrAtUFp Subscribe & Join 5k Java & Spring Boot subscribers: https://lnkd.in/gwiRqWBV #java #spring #springboot
To view or add a comment, sign in
-
-
90% of Java modernization projects under‑deliver within 6 months — not because of language features, but because teams skip pragmatic platform hygiene. Use this scannable 31-step checklist to migrate to Java 21+ and Spring Boot with minimal rework. Full 10–15 line explainers for Core Java, HTML, CSS, JavaScript, React, Spring Boot, SQL, REST, and JDBC plus 100+ PrepInsta-style problems live in the appendix repo: https://lnkd.in/gtu3S999 1 Inventory services & deps 2 Define target JDK & test matrix 3 Lock modules & package visibility 4 Replace legacy date APIs 5 Introduce records for DTOs 6 Use sealed interfaces for closed hierarchies 7 Audit native bindings 8 Choose GC per workload
To view or add a comment, sign in
-
I recently went through all the Stream API changes from Java 8 to Java 21. Quite a lot when You see it all in one place. Here's the timeline: - Java 8 — Streams arrive. filter, map, reduce, collect. A paradigm shift. - Java 9 — takeWhile, dropWhile, ofNullable. Streams get practical for real-world edge cases. - Java 10 — Unmodifiable collectors. Immutability becomes a one-liner. - Java 12 — Collectors.teeing(). Two reductions in a single pass. - Java 16 — Stream.toList() and mapMulti(). Less boilerplate, more flexibility. - Java 21 — Sequenced Collections bring ordered access (getFirst, getLast, reversed) that pairs naturally with Stream pipelines. Virtual Threads make parallel stream alternatives viable at scale. What I've noticed over the years: each release didn't add complexity — it cut the boilerplate. The API got simpler to use, not harder. If You learned Streams in Java 8 and haven't revisited since, You're writing more code than You need to. A quick refresh across these versions will clean up a lot of patterns. I completely missed Collectors.teeing() when it came out in Java 12 and haven't used it yet. Curious what surprised You on this list? #Java #Java21 #StreamAPI #JavaEvolution #SoftwareDevelopment #CleanCode #Developer
To view or add a comment, sign in
-
-
Most Java backend systems don’t break because of performance. They break because of tight coupling. When controllers depend on concrete services, and services depend on concrete implementations, change becomes risky. That’s exactly why interfaces exist. An interface is not boilerplate. It’s a boundary. High-level code should depend on behavior, not details. Low-level code should implement those behaviors. This flips the dependency direction. That’s dependency inversion. I explained this in my latest article with real Java examples see it here: 👉 https://lnkd.in/dAwihfPm Good design isn’t about adding patterns everywhere. It’s about protecting your core logic from change. #Java #BackendDevelopment #SystemDesign #OOP #CleanCode #SoftwareArchitecture
To view or add a comment, sign in
-
🔁 Process vs Thread in Java – What’s the real difference? Many devs use process and thread interchangeably — but internally they are very different beasts. Here’s a practical breakdown 👇 Feature Process Thread Definition Independent program in execution Lightweight unit inside a process Memory Own heap, stack, code Shares heap, has own stack Communication IPC (slow, OS-level) Shared memory (fast) Creation Cost Heavy Very lightweight Failure Impact Crash isolated Can crash entire process Context Switch Slow Fast Java Example Running another JVM new Thread() / Virtual Thread ⸻ 🧠 Visual Model PROCESS ├── Heap ├── Code ├── Thread-1 (Stack) ├── Thread-2 (Stack) └── Thread-3 (Stack) All threads share the same heap, but each has its own stack. ⸻ ☕ Java Example Creating Threads Runnable task = () -> System.out.println(Thread.currentThread().getName()); Thread t1 = new Thread(task); Thread t2 = new Thread(task); t1.start(); t2.start(); Creating a Process (New JVM) ProcessBuilder pb = new ProcessBuilder("java", "-version"); Process p = pb.start(); ⸻ ⚡ When to use what? Use Threads when: • You need concurrency • You want fast in-memory communication • You are building high throughput APIs Use Processes when: • You need strong isolation • You want fault boundaries • You run different services/microservices ⸻ 🚀 Modern Java (21+) With Virtual Threads, Java can now: • Handle millions of threads • Without heavy OS cost • Making thread-based concurrency scalable again ⸻ 📌 One-liner A process is a container, threads are workers inside it. ⸻ #Java #Multithreading #Concurrency #VirtualThreads #JVM #BackendEngineering #SystemDesign
To view or add a comment, sign in
-
Explore related topics
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development
- https://www.speakeasy.com/blog/java-open-enums - https://www.speakeasy.com/blog/java-unions-jackson