[KotlinConf2025] LangChain4j with Quarkus
In a collaboration between Red Hat and Twilio, Max Rydahl Andersen and Konstantin Pavlov presented an illuminating session on the powerful combination of LangChain4j and Quarkus for building AI-driven applications with Kotlin. The talk addressed the burgeoning demand for integrating artificial intelligence into modern software and the common difficulties developers encounter, such as complex setups and performance bottlenecks. By merging Kotlin’s expressive power, Quarkus’s rapid runtime, and LangChain4j’s AI capabilities, the presenters demonstrated a streamlined and effective solution for creating cutting-edge applications.
A Synergistic Approach to AI Integration
The core of the session focused on the seamless synergy between the three technologies. Andersen and Pavlov detailed how Kotlin’s idiomatic features simplify the development of AI workflows. They presented a compelling case for using LangChain4j, a versatile framework for building language model-based applications, within the Quarkus ecosystem. Quarkus, with its fast startup times and low memory footprint, proved to be an ideal runtime for these resource-intensive applications. The presenters walked through practical code samples, illustrating how to set up the environment, manage dependencies, and orchestrate AI tools efficiently. They emphasized that this integrated approach significantly reduces the friction typically associated with AI development, allowing engineers to focus on business logic rather than infrastructural challenges.
Enhancing Performance and Productivity
The talk also addressed the critical aspect of performance. The presenters demonstrated how the combination of LangChain4j and Quarkus enables the creation of high-performing, AI-powered applications. They discussed the importance of leveraging Quarkus’s native compilation capabilities, which can lead to dramatic improvements in startup time and resource utilization. Additionally, they touched on the ongoing work to optimize the Kotlin compiler’s interaction with the Quarkus build system. Andersen noted that while the current process is efficient, there are continuous efforts to further reduce build times and enhance developer productivity. This commitment to performance underscores the value of this tech stack for developers who need to build scalable and responsive AI solutions.
The Path Forward
Looking ahead, Andersen and Pavlov outlined the future roadmap for LangChain4j and its integration with Quarkus. They highlighted upcoming features, such as the native asynchronous API, which will provide enhanced support for Kotlin coroutines. While acknowledging the importance of coroutines for certain use cases, they also reminded the audience that traditional blocking and virtual threads remain perfectly viable and often preferred for a majority of applications. They also extended an open invitation to the community to contribute to the project, emphasizing that the development of these tools is a collaborative effort. The session concluded with a powerful message: this technology stack is not just about building applications; it’s about empowering developers to confidently tackle the next generation of AI-driven projects.
Links:
[DotAI2024] DotAI 2024: Daniel Phiri – Bridging the Multimodal Divide: From Monoliths to Mosaic Mastery
Daniel Phiri, Developer Advocate at Weaviate—an open-source vector vault pioneering AI-native navigation—and a scribe of scripts with a penchant for open-source odysseys, bridged breaches at DotAI 2024. His clarion countered consternation: AI’s archipelago awash in apparatuses, scant in sustainable structures—fear’s fetter, fractured faculties. Phiri prescribed pluralism: modalities as medley, not monad—systems symphonizing senses, from spectral scans to syntactic streams, piping predictions to prowess.
Dismantling the Monolithic Myth: Modalities as Multifaceted Melange
Phiri’s parable pulsed: truffle’s trio—pasta’s plinth, Parmesan’s piquancy, fungus’ finesse—mirroring modalities’ mosaic, where singular silos starve synergy. Models’ mirage: magic boxes masking machinations, inputs imploding into ineffable infinities.
Multimodality’s mantle: processing’s palette—images’ illuminations, videos’ vigor, depths’ delineations, code’s calculus—beyond binaries, beckoning breadth. Phiri posited pipelines: predictive pulses—confidence’s calculus—channeling to tool-calling’s trove or retrieval’s reservoir.
Embeddings’ empire: encoders etching essences, vectors vaulted in versatile voids—similarity’s summons spanning spectra. Near-image nexuses: base64’s bastion, querying quanta for cinematic kin—posters procured through proximity’s prism.
Piping Pluralities: Advanced Assemblies for Augmented Actions
Phiri forged the flux: intent’s inception—microchip’s mystery, snapshot’s summons—”what’s this?”—cascading through cognoscenti: vision’s verdict, textual translation, tool’s tether. Assumptions assailed: monolithic mandates misguided—modest modules, manifold models, melded through metrics.
Retrieval’s renaissance: multimodal matrices, embeddings’ expanse enabling eclectic echoes—text’s tendrils twining visuals’ veins. Code’s cadence: Weaviate’s weave, near-image invocations instantiating inquiries, pipelines pulsing predictions to praxis.
Phiri’s provocation: ponder peripheries—tasteless trifles transcended, users uplifted through unum’s unraveling. Cross chasms with choruses: smaller sentinels, synergistic streams—building’s beckon, beyond’s bridge.
Links:
[DevoxxFR2025] Alert, Everything’s Burning! Mastering Technical Incidents
In the fast-paced world of technology, technical incidents are an unavoidable reality. When systems fail, the ability to quickly detect, diagnose, and resolve issues is paramount to minimizing impact on users and the business. Alexis Chotard, Laurent Leca, and Luc Chmielowski from PayFit shared their invaluable experience and strategies for mastering technical incidents, even as a rapidly scaling “unicorn” company. Their presentation went beyond just technical troubleshooting, delving into the crucial aspects of defining and evaluating incidents, effective communication, product-focused response, building organizational resilience, managing on-call duties, and transforming crises into learning opportunities through structured post-mortems.
Defining and Responding to Incidents
The first step in mastering incidents is having a clear understanding of what constitutes an incident and its severity. Alexis, Laurent, and Luc discussed how PayFit defines and categorizes technical incidents based on their impact on users and business operations. This often involves established severity levels and clear criteria for escalation. Their approach emphasized a rapid and coordinated response involving not only technical teams but also product and communication stakeholders to ensure a holistic approach. They highlighted the importance of clear internal and external communication during an incident, keeping relevant parties informed about the status, impact, and expected resolution time. This transparency helps manage expectations and build trust during challenging situations.
Technical Resolution and Product Focus
While quick technical mitigation to restore service is the immediate priority during an incident, the PayFit team stressed the importance of a product-focused approach. This involves understanding the user impact of the incident and prioritizing resolution steps that minimize disruption for customers. They discussed strategies for effective troubleshooting, leveraging monitoring and logging tools to quickly identify the root cause. Beyond immediate fixes, they highlighted the need to address the underlying issues to prevent recurrence. This often involves implementing technical debt reduction measures or improving system resilience as a direct outcome of incident analysis. Their experience showed that a strong collaboration between engineering and product teams is essential for navigating incidents effectively and ensuring that the user experience remains a central focus.
Organizational Resilience and Learning
Mastering incidents at scale requires building both technical and organizational resilience. The presenters discussed how PayFit has evolved its on-call rotation models to ensure adequate coverage while maintaining a healthy work-life balance for engineers. They touched upon the importance of automation in detecting and mitigating incidents faster. A core tenet of their approach was the implementation of structured post-mortems (or retrospectives) after every significant incident. These post-mortems are blameless, focusing on identifying the technical and process-related factors that contributed to the incident and defining actionable steps for improvement. By transforming crises into learning opportunities, PayFit continuously strengthens its systems and processes, reducing the frequency and impact of future incidents. Their journey over 18 months demonstrated that investing in these practices is crucial for any growing organization aiming to build robust and reliable systems.
Links:
- Alexis Chotard: https://www.linkedin.com/in/alexis-chotard/
- Laurent Leca: https://www.linkedin.com/in/laurent-leca/
- Luc Chmielowski: https://www.linkedin.com/in/luc-chmielowski/
- PayFit: https://payfit.com/
- Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
- Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
- Devoxx France Website: https://www.devoxx.fr/
[KotlinConf2024] Kotlin Multiplatform Powers Google Workspace
At KotlinConf2024, Jason Parachoniak, a Google Workspace engineer, detailed Google’s shift from a Java-based multiplatform system to Kotlin Multiplatform (KMP), starting with Google Docs. For over a decade, Workspace has relied on shared code for consistency across platforms, like Gmail’s synchronization layer. Jason shared how KMP enhances this approach, leveraging Kotlin’s ecosystem for better performance and native interop. The talk highlighted lessons from the migration, focusing on build efficiency, runtime latency, and memory challenges, offering insights for large-scale KMP adoption.
Why Kotlin Multiplatform for Workspace
Google Workspace has long used multiplatform code to ensure consistency, such as identical email drafts across devices in Gmail or uniform document models in Docs. Jason explained that their Java-based system, using transpilers like J2ObjC, was effective but complex. KMP offers a modern alternative, allowing developers to write Kotlin code that compiles to native platforms, improving runtime performance and ecosystem integration. By targeting business logic—everything beyond the UI—Workspace ensures native-feel apps while sharing critical functionality, aligning with user expectations for productivity tools.
Google Docs: The Migration Testbed
The migration began with Google Docs, chosen for its heavily annotated codebase, which tracks build performance, latency, and memory usage. Jason described how Docs is rolling out on KMP, providing metrics to refine the Kotlin compiler and runtime. This controlled environment allowed Google to compare KMP against their legacy system, ensuring parity before expanding to other apps. Collaboration with JetBrains and the Android team has been key, with iterative improvements driven by real-world data, setting a foundation for broader Workspace adoption.
Tackling Build Performance
Build performance posed challenges, as Google’s Bazel-like system resembles clean builds, unlike Gradle’s incremental approach. Jason recounted a 10-minute build time increase after a Kotlin Native update optimized LLVM bitcode generation. While this improved binary size and speed, it slowed builds. Profiling revealed a slow LLVM pass, already fixed in a newer version. Google patched LLVM temporarily, reducing build times from 30 to 8 minutes, and is working with JetBrains to update Kotlin Native’s LLVM, prioritizing stability alongside the K2 compiler rollout.
Optimizing Runtime Latency
Runtime latency, critical for Workspace apps, required Kotlin Native garbage collection (GC) tweaks. Jason noted that JetBrains proactively adjusted GC before receiving Google’s metrics, but further heuristics were needed as latency issues emerged. String handling in the interop layer also caused bottlenecks, addressed with temporary workarounds. Google is designing long-term fixes with JetBrains, ensuring smooth performance across platforms. These efforts highlight KMP’s potential for high-performance apps, provided runtime challenges are systematically resolved through collaboration.
Addressing Memory Usage
Memory usage spikes were a surprise, particularly between iOS 15 and 16. Jason explained that iOS 16’s security-driven constant pool remapping marked Kotlin Native’s vtables as dirty, consuming megabytes of RAM. Google developed a heap dump tool generating HPROF files, compatible with IntelliJ’s Java heap analysis, to diagnose issues. This tool is being upstreamed to Kotlin Native’s runtime, enhancing debugging capabilities. These insights are guiding Google’s memory optimization strategy, ensuring KMP meets Workspace’s stringent performance requirements as the migration expands.
Links:
[DevoxxGR2025] Unmasking Benchmarking Fallacies
Georgios Andrianakis, a Quarkus engineer at Red Hat, presented a 46-minute talk at Devoxx Greece 2025, dissecting benchmarking fallacies, based on a talk by performance expert Francisco Negro.
The Benchmarketing Problem
Andrianakis introduced “benchmarketing,” where benchmarks are manipulated for marketing. Inspired by Negro’s frustration with a claim that Helidon outperformed Quarkus in a TechEmpower benchmark, he explored how data can be misrepresented. Benchmarks should be relevant, representative, equitable, repeatable, cost-effective, scalable, and transparent. A misleading article claimed Helidon’s superiority, but Negro’s investigation revealed unfair comparisons, sparking this talk to expose such fallacies.
Dissecting a Flawed Claim
Focusing on equity, Negro analyzed the TechEmpower benchmark, which tests web frameworks on tasks like JSON serialization and database queries. The claim hinged on a test where Helidon used a raw database driver (Vert.x for PostgreSQL), while Quarkus used a full object-relational mapper (ORM) like Hibernate, incurring performance penalties. Filtering for full ORM tests, Quarkus topped the charts, with Helidon absent. Comparing both without ORMs, Quarkus still outperformed. This exposed the claim’s inequity, as it wasn’t apples-to-apples, misleading readers.
Critical Thinking in Benchmarks
Andrianakis emphasized skepticism, citing Hitchens’ Razor: claims without evidence can be dismissed. Using Brendan Gregg’s USE method, Negro identified CPU saturation, not database I/O, as the bottleneck, debunking assumptions. He urged active benchmarking—monitoring errors and resources—and measuring one level deeper to understand performance. Awareness of biases, like confirmation bias, and avoiding assumptions of malice over incompetence, ensures fair evaluation of benchmark claims.
Links
[DevoxxBE2025] Finally, Final Means Final: A Deep Dive into Field Immutability in Java
Lecturer
Per Minborg is a Java Core Library Developer at Oracle, specializing in language features and performance improvements. He has contributed to projects enhancing Java’s concurrency and immutability models, drawing from his background in database acceleration tools like Speedment.
Abstract
This investigation explores Java’s ‘final’ keyword as a mechanism for immutability, examining its semantic guarantees from compilation to runtime execution. It contextualizes the balance between mutable flexibility and immutable predictability, delving into JVM trust dynamics and recent proposals like strict finals. Through code demonstrations and JVM internals, the narrative assesses approaches for stronger immutability, including lazy constants, and their effects on threading, optimization, and application speed. Forward implications for Java’s roadmap are considered, emphasizing enhanced reliability and efficiency.
Balancing Mutability and Immutability in Java
Java’s design philosophy accommodates both mutability for dynamic state changes and immutability for stability, yet tensions arise in performance and safety. Immutability, praised in resources like Effective Java, ensures objects maintain a single state, enabling safe concurrent access without locks. Immutable instances can be cached or reused, functioning reliably as keys in collections—unlike mutables that may cause hash inconsistencies after alterations.
Mutability, however, provides adaptability for evolving data, crucial in interactive systems. The ‘final’ keyword aims to enforce constancy, but runtime behaviors complicate this. Declaring ‘final int value = 42;’ implies permanence, yet advanced techniques like reflection with Unsafe can modify it, breaching expectations.
This duality impacts optimizations: trusted finals allow constant propagation, minimizing memory accesses. Yet, Java permits post-constructor updates for deserialization, eroding trust. Demonstrations show reflection altering finals, highlighting vulnerabilities where JVMs must hedge against changes, forgoing inlining.
Historically, Java prioritized flexibility, allowing such mutations for practicality, but contemporary demands favor integrity. Initiatives like “final truly final” seek to ban post-construction changes, bolstering trust for aggressive enhancements.
JVM Trust Mechanisms and Final Field Handling
JVM trust refers to assuming ‘final’ fields remain unchanged post-initialization, enabling efficiencies like constant folding. Current semantics, however, permit reflective or deserialization modifications, limiting optimizations.
Examples illustrate:
class Coordinate {
final int coord;
Coordinate(int coord) { this.coord = coord; }
}
Post-constructor, ‘coord’ is trusted, supporting optimizations. Reflection via Field.setAccessible(true) overrides this, as Unsafe manipulations demonstrate. Performance tests reveal trusted finals outperform volatiles in accesses, but untrusted ones underperform.
Java’s model historically allowed mutations for deserialization, but stricter enforcement proposals aim to restrict this. Implications include safer multi-threading, as finals ensure visibility without volatiles.
Advancements in Strict Finals and Leak Prevention
Strict finals strengthen guarantees by prohibiting constructor leaks—publishing ‘this’ before all finals are set. This prevents partial states in concurrent environments, where threads might observe defaults like zero before assignments.
Problematic code:
class LeakyClass {
final int val = 42;
LeakyClass() { Registry.register(this); } // Leak
}
Leaks risk threads seeing val=0. Strict finals reject this at compile time, enforcing safe initialization.
Methodologically, this requires refactoring to avoid early publications, but yields threading reliability and optimization opportunities. Benchmarks quantify benefits: trusted paths execute quicker, with fewer barriers.
Lazy Constants for Deferred Initialization
Previewed in Java 25, lazy constants merge mutable deferral with final optimizations. Declared ‘lazy final int val;’, they compute once on access via suppliers:
lazy final int heavy = () -> heavyComputation();
JVM views them as constants after initialization, supporting folding. Use cases include infrequent or expensive values, avoiding startup costs.
Unlike volatiles, lazy constants ensure at-most-once execution, with threads blocking on contention. This fits singletons or caches, surpassing synchronized options in efficiency.
Roadmap and Performance Consequences
Strict finals and lazy constants fortify Java’s immutability, complementing concurrent trends. Consequences include accelerated, secure code, with JVMs exploiting trust for vector operations.
Developers balance: finals for absolutes, lazies for postponements. Roadmaps indicate stabilization in Java 26, expanding usage.
In overview, these evolutions make ‘final’ definitively final, boosting Java’s sturdiness and proficiency.
Links:
- Lecture video: https://www.youtube.com/watch?v=J754RsoUd00
- Per Minborg on Twitter/X: https://twitter.com/PMinborg
- Oracle website: https://www.oracle.com/
[NDCOslo2024] Building a Robot Arm with .NET 8, Raspberry Pi, Blazor and SignalR – Peter Gallagher
Amid the mesmerizing merger of microcontrollers and modern markup, Peter Gallagher, a prolific .NET pioneer and podcast personality, prototypes a pivotal plaything: a prehensile prosthesis powered by Pi, .NET 8, Blazor’s bounty, and SignalR’s synergy. As the mind behind “The .NET Core Podcast” and a maestro of minimal viable marvels, Peter parades the panoply—from GPIO gymnastics to VR vistas—proving platform potency in playful pursuits. His hands-on homage, humming with hardware harmony, heralds hobbyists to harness high-level harmony for haptic happenings.
Peter polls the populace: Raspberry aficionados abound, yet arm artisans are scarce—his spur to share schematics, sans soldering sermons. .NET 8’s native nod to ARM architectures animates accessibility, eclipsing esoteric embeds.
Wiring the Wonder: GPIO and Servo Symphonies
Genesis germinates in GPIO groundwork: Pi’s pins, PWM-proficient, pulse servos to swivel shoulders, elbows, wrists. Peter parades the paraphernalia: SG90 servos, jumper joys, breadboard bastions—budget below 50 quid.
Code commandeers: Iot.Device.Bindings beckon, Servo class summoning sweeps—angle aspirations from 0 to 180. Peter’s prototype: console commands calibrating claws, clutching candies in cinematic clips.
Blazor’s Bridge: Browser-Borne Brawn
Blazor bridges the breach: WebAssembly wielding webcams, SignalR streaming signals—real-time relays routing remote reaches. Peter’s portal: Razor renders ranges, sliders summoning servo shifts; hubs herald hubbub, harmonizing host and handler.
He highlights hitches: CORS courtesies, container conundrums—Pi’s paucity of ports prompting proxies. Yet, yields yield yawns: yawns of yawp, where web wielders wrench wrenches wirelessly.
VR’s Vanguard: Questing for Quarters
Quest 3 quests quaternary: Unity unleashes OpenXR, hand-tracking hailing haptics—gestures grasping grippers. Peter’s phantasm: VR viewport voyaging Pi’s panorama, passthrough peering at prehensile prowess.
Integration ignites: SignalR surges selections, servos saluting salutes—synthetic senses simulating seizures. Peter’s plea: print, procure, partake—his GitHub grotto granting guides.
Horizons of Hardware: Harmonizing Hopes
Peter’s panegyric: .NET’s ubiquity unlocks universes—embedded epics, VR ventures—vitalizing visions. His valediction: venture ventures, validate validations—birthday bonuses beckon bold builders.
Links:
[GoogleIO2025] Adaptive Android development makes your app shine across devices
Keynote Speakers
Alex Vanyo works as a Developer Relations Engineer at Google, concentrating on adaptive applications for the Android platform. His expertise encompasses user interface design and responsive layouts, contributing to tools that facilitate cross-device compatibility.
Emilie Roberts serves as a Developer Relations Engineer at Google, specializing in Android integration with Chrome OS. She advocates for optimized experiences on large-screen devices, drawing from her background in software engineering to guide developers in multi-form factor adaptations.
Abstract
This analysis explores the principles of adaptive development for Android applications, emphasizing strategies to ensure seamless performance across diverse hardware ecosystems including smartphones, tablets, foldables, automotive interfaces, and extended reality setups. It examines emerging platform modifications in Android 16, updates to Jetpack libraries, and innovative tooling in Android Studio, elucidating their conceptual underpinnings, implementation approaches, and potential effects on user retention and developer workflows. By evaluating practical demonstrations and case studies, the discussion reveals how these elements promote versatile, future-proof software engineering in a fragmented device landscape.
Rationale for Adaptive Strategies in Expanding Ecosystems
Alex Vanyo and Emilie Roberts commence by articulating the imperative for adaptive methodologies in Android development, tracing the evolution from monolithic computing to ubiquitous mobile paradigms. They posit that contemporary applications must transcend single-form-factor constraints to embrace an array of interfaces, from wrist-worn gadgets to vehicular displays and immersive headsets. This perspective is rooted in the observation that users anticipate fluid functionality across all touchpoints, transforming software from mere utilities into integral components of daily interactions.
Contextually, this arises from Android’s proliferation beyond traditional handhelds. Roberts highlights the integration of adaptive apps into automotive environments via Android Automotive OS and Android Auto, where permitted categories can now operate in parked modes without necessitating bespoke versions. This leverages existing mobile codebases, extending reach to in-vehicle screens that serve as de facto tablets.
Furthermore, Android 16 introduces desktop windowing enhancements, enabling phones, foldables, and tablets to morph into free-form computing spaces upon connection to external monitors. With over 500 million active large-screen units, this shift democratizes desktop-like productivity, allowing arbitrary resizing and multitasking. Vanyo notes the foundational AOSP support for connected displays, poised for developer previews, which underscores a methodological pivot toward hardware-agnostic design.
The advent of Android XR further diversifies the landscape, positioning headsets as spatial computing hubs where apps inhabit immersive realms. Home space mode permits 2D window placement in three dimensions, akin to boundless desktops, while full space grants exclusive environmental control for volumetric content. Roberts emphasizes that Play Store-distributed mobile apps inherently support XR, with adaptive investments yielding immediate benefits in this nascent arena.
Implications manifest in heightened user engagement; multi-device owners exhibit tripled usage in streaming services compared to single-device counterparts. Methodologically, this encourages a unified codebase strategy, averting fragmentation while maximizing monetization. However, it demands foresight in engineering to accommodate unforeseen hardware, fostering resilience against ecosystem volatility.
Core Principles and Mindset of Adaptive Design
Delving into the ethos, Vanyo defines adaptivity as a comprehensive tactic that anticipates the Android spectrum’s variability, encompassing screen dimensions, input modalities, and novel inventions. This mindset advocates for a singular application adaptable to phones, tablets, foldables, Chromebooks, connected displays, XR, and automotive contexts, eschewing siloed variants.
Roberts illustrates via personal anecdote: transitioning from phone-based music practice to tablet or monitor-enhanced sessions necessitates consistent features like progress tracking and interface familiarity. Disparities risk user attrition, as alternatives offering cross-device coherence gain preference. This user-centric lens complements business incentives, where adaptive implementations correlate with doubled retention rates, as evidenced by games like Asphalt Legends Unite.
Practically, demonstrations of the Socialite app—available on GitHub—exemplify this through a list-detail paradigm via Compose Adaptive. Running identical code across six devices, it dynamically adjusts: XR home space resizes panes fluidly, automotive interfaces optimize for parked interactions, and desktop modes support free-form windows. Such versatility stems from libraries detecting postures like tabletop on foldables, enabling tailored views without codebase bifurcation.
Analytically, this approach mitigates development overhead by centralizing logic, yet requires vigilant testing against configuration shifts to preserve state and avoid visual artifacts. Implications extend to inclusivity, accommodating diverse user scenarios while positioning developers to capitalize on emerging markets like XR, projected to burgeon.
Innovations in Tooling and Libraries for Responsiveness
Roberts and Vanyo spotlight Compose Adaptive 1.1, a Jetpack library facilitating responsive UIs via canonical patterns. It categorizes windows into compact, medium, and expanded classes, guiding layout decisions—e.g., bottom navigation for narrow views versus side rails for wider ones. The library’s supporting pane abstraction manages list-detail flows, automatically transitioning based on space availability.
Code exemplar:
val supportingPaneScaffoldState = rememberSupportingPaneScaffoldState(
initialValue = SupportingPaneScaffoldValue.Hidden
)
SupportingPaneScaffold(
state = supportingPaneScaffoldState,
mainPane = { ListContent() },
supportingPane = { DetailContent() }
)
This snippet illustrates dynamic pane revelation, adapting to resizes without explicit orientation handling. Navigation 3 complements this, decoupling navigation graphs from UI elements for reusable, posture-aware routing.
Android Studio’s enhancements, like the adaptive UI template wizard, streamline initiation by generating responsive scaffolds. Visual linting detects truncation or overflow in varying configurations, while emulators simulate XR and automotive scenarios for holistic validation.
Methodologically, these tools embed adaptivity into workflows, leveraging Compose’s declarative paradigm for runtime adjustments. Contextually, they address historical assumptions about fixed orientations, preparing for Android 16’s disregard of such restrictions on large displays. Implications include reduced iteration cycles and elevated quality, though necessitate upskilling in reactive design principles.
Platform Shifts and Preparation for Android 16
A pivotal revelation concerns Android 16’s cessation of honoring orientation, resizability, and aspect ratio constraints on displays exceeding 600dp. Targeting SDK 36, activities must accommodate arbitrary shapes, ignoring portrait/landscape mandates to align with user preferences. This standardization echoes OEM overrides, enforcing free-form adaptability.
Common pitfalls include clipped elements, distorted previews, or state loss during rotations—issues users encounter via overrides today. Vanyo advises comprehensive testing, layout revisions, and state preservation. Transitional aids encompass opt-out flags until SDK 37, user toggles, and game exemptions via manifest or Play categories.
For games, Unity 6 integrates configuration APIs, enabling seamless handling of size and density alterations. Samples guide optimizations, while titles like Dungeon Hunter 5 demonstrate foldable integrations yielding retention boosts.
Case studies reinforce: Luminar Neo’s Compose-built editor excels offline via Tensor SDK; Cubasis 3 offers robust audio workstations on Chromebooks; Algoriddim’s djay explores XR scratching. These exemplify methodological fusion of libraries and testing, implying market advantages through device ubiquity.
Strategic Implications and Forward Outlook
Adaptivity emerges as a strategic imperative amid Android’s diversification, where single codebases span ecosystems, enhancing loyalty and revenue. Platform evolutions like desktop windowing and XR demand foresight, with tools mitigating complexities.
Future trajectories involve deeper integrations, potentially with AI-driven layouts, ensuring longevity. Developers are urged to iterate compatibly, avoiding presumptions to future-proof against innovations, ultimately enriching user experiences across the Android continuum.
Links:
[OxidizeConf2024] Moving Electrons with Rust
From Novice to Custom PCB
Embarking on a journey from minimal electronics knowledge to designing a custom printed circuit board (PCB) is a daunting yet rewarding endeavor. At OxidizeConf2024, Josh Junon from GitButler shared his nine-month odyssey of building a PCB with an STM32 microcontroller, powered by async Rust firmware. Josh’s candid narrative detailed his trials, errors, and eventual success in creating a component for kernel CI/CD testing pipelines, offering valuable lessons for software developers venturing into hardware.
With a strong software background but little electronics experience, Josh tackled the complexities of PCB design, from selecting components to soldering hair-thin parts. Using Rust’s async capabilities, he developed firmware that leveraged interrupts for efficient communication, integrating the PCB into a larger project. His story underscores Rust’s versatility in bridging software and hardware, enabling developers to create reliable, high-performance embedded systems without extensive hardware expertise.
Practical Lessons in Hardware Development
Josh’s presentation was a treasure trove of practical advice. He emphasized the importance of verifying component sizes early, as datasheets often understate their minuteness. For instance, selecting appropriately sized parts saved costs and prevented assembly errors. He also advised against prioritizing aesthetics, such as costly black solder masks, in favor of affordable green ones. These lessons, born from trial and error, highlight the importance of aligning hardware choices with project constraints, particularly for budget-conscious developers.
Rust’s async ecosystem, including libraries like embassy, facilitated Josh’s firmware development. The STM32F4 (or possibly F7) microcontroller, though potentially overpowered, provided a robust platform for his needs. By sharing his GitHub repository, Josh invites community feedback, fostering collaboration to refine his approach. His experience demonstrates how Rust’s safety guarantees and modern tooling can empower software developers to tackle hardware challenges effectively.
Balancing Cost and Learning
Cost management was a recurring theme in Josh’s journey. He cautioned against over-purchasing components and investing in expensive equipment early on, noting that basic tools suffice for initial projects. Custom stencil sizes, while tempting, added unnecessary costs, and Josh recommended reusing standard boards for versatility. Despite these challenges, the learning outcomes were profound, equipping Josh with skills in microcontrollers, interrupts, and embedded programming that enhanced his broader project.
Josh’s success highlights Rust’s role in democratizing hardware development. By leveraging Rust’s ecosystem and community resources, he transformed a side quest into a valuable contribution to kernel testing. His call to “just do it” inspires developers to explore hardware with Rust, proving that persistence and community support can yield remarkable results in unfamiliar domains.
Links:
[KotlinConf2025] Closing Panel
The concluding panel of KotlinConf2025 offered a vibrant and candid discussion, serving as the capstone to the conference. The diverse group of experts from JetBrains, Netflix, and Google engaged in a wide-ranging dialogue, reflecting on the state of Kotlin, its evolution, and the path forward. They provided a unique blend of perspectives, from language design and backend development to mobile application architecture and developer experience. The conversation was an unfiltered look into the challenges and opportunities facing the Kotlin community, touching on everything from compiler performance to the future of multiplatform development.
The Language and its Future
A central theme of the discussion was the ongoing development of the Kotlin language itself. The panel members, including Simon from the K2 compiler team and Michael from language design, shared insights into the rigorous process of evolving Kotlin. They addressed questions about new language features and the careful balance between adding functionality and maintaining simplicity. A notable point of contention and discussion was the topic of coroutines and the broader asynchronous programming landscape. The experts debated the best practices for managing concurrency and how Kotlin’s native features are designed to simplify these complex tasks. There was a consensus that while new features are exciting, the primary focus remains on stability, performance, and enhancing the developer experience.
The State of Multiplatform Development
The conversation naturally shifted to Kotlin Multiplatform (KMP), which has become a cornerstone of the Kotlin ecosystem. The panelists explored the challenges and successes of building applications that run seamlessly across different platforms. Representatives from companies like Netflix and AWS, who are using KMP for large-scale projects, shared their experiences. They discussed the complexities of managing shared codebases, ensuring consistent performance, and maintaining a robust build system. The experts emphasized that while KMP offers immense benefits in terms of code reuse, it also requires a thoughtful approach to architecture and toolchain management. The panel concluded that KMP is a powerful tool, but its success depends on careful planning and a deep understanding of the underlying platforms.
Community and Ecosystem
Beyond the technical discussions, the panel also reflected on the health and vibrancy of the Kotlin community. A developer advocate, SA, and others spoke about the importance of fostering an inclusive environment and the role of the community in shaping the language. They highlighted the value of feedback from developers and the critical role it plays in guiding the direction of the language and its tooling. The discussion also touched upon the broader ecosystem, including the various libraries and frameworks that have emerged to support Kotlin development. The panel’s enthusiasm for the community was palpable, and they expressed optimism about Kotlin’s continued growth and adoption in the years to come.