Month: December 2024

Article originally posted on InfoQ. Visit InfoQ

This week’s Java roundup for December 23rd, 2024 features news highlighting: the fifth milestone release of Spring AI 1.0; the first milestone release of Grails 7.0; the first alpha release of LangChain4j 1.0; and the release of JHipster 8.8.

JDK 24

Build 29 remains the current build in the JDK 24 early-access builds. Further details on this release may be found in the release notes.

JDK 25

Similarly, Build 3 remains the current build in the JDK 25 early-access builds. More details on this release may be found in the release notes.

For JDK 24 and JDK 25, developers are encouraged to report bugs via the Java Bug Database.

Spring Framework

Ten days after introducing the experimental Spring AI MCP, a Java SDK implementation of the Model Context Protocol (MCP), to the Java community, the Spring AI team has released a version 0.2.0 milestone. This initial release features: a simplified McpClient interface such that listing operations no longer require a cursor parameter; and a new SseServerTransport class, a server-side implementation of the MCP HTTP with the SSE transport specification. Breaking changes include a rename of some modules for improved consistency. Further details on this release may be found in the release notes.

The fifth milestone release of Spring AI 1.0 delivers: incubating support for the Model Context Protocol; support for models such as Zhipuai Embedding-3 and Pixtral; and support for vector stores such as MariaDB and Azure Cosmos DB. There were also breaking changes that include moving the MilvusVectorStore class from the org.springframework.ai.vectorstore package to the org.springframework.ai.vectorstore.milvus package. The Spring AI team plans a sixth milestone release in January 2025 followed by one release candidate before the final GA release.

TornadoVM

The release of TornadoVM 1.0.9 ships with bug fixes and improvements such as: support for the RISC-V 64 CPU port to run OpenCL with vector instructions for the RVV 1.0 board; support for int, double, long and short three-dimensional arrays by creating new matrix classes; and the addition of a helper menu for the tornado launcher script when no arguments are passed. More details on this release may be found in the release notes.

Micronaut

The Micronaut Foundation has released version 4.7.3 of the Micronaut Framework featuring Micronaut Core 4.7.10, bug fixes and patch updates to modules: Micronaut Logging, Micronaut Flyway, Micronaut Liquibase Micronaut Oracle Cloud and Micronaut Pulsar. Further details on this release may be found in the release notes.

Grails

The first milestone release of Grails 7.0.0 delivers bug fixes, dependency upgrades and notable changes such as: a minimal version of JDK 17, Spring Framework 6.0, Spring Boot 3.0 and Groovy 4.0; and an update to the PublishGuide class to use the Gradle AntBuilder class instead of the deprecated Groovy AntBuilder class. More details on this release may be found in the release notes.

LangChain4j

After more than 18 months of development, the first alpha release of LangChain4j 1.0.0 features: updated ChatLanguageModel and StreamingChatLanguageModel interfaces to support additional use cases and new features; and an initial implementation of the Model Context Protocol. The team plans a GA release in Q12025. Further details on this release may be found in the release notes.

Apache Software Foundation

The Apache Camel team has announced that the version 3.0 release train has reached end-of-life. The recently released Apache Camel 3.22.3, will be the final one. Developers are encouraged to upgrade to the 4.0 release train via this migration guide.

JHipster

The release of JHipster 8.8.0 features: upgrades to Spring Boot 3.4, Angular 19 and Gradle 8.12; experimental support for esbuild in Angular; and improved CSRF token handling for single page applications. More details on this release may be found in the release notes.

Similarly, the release of JHipster Lite 1.24.0 ships with an upgrade to Spring Boot 3.4.1 and new features/enhancements such as: a new module for configuring a Liquibase linter; and the addition of metadata to the preprocessor to resolve a ESLint cache error. Further details on this release may be found in the release notes.

Article originally posted on InfoQ. Visit InfoQ

The Cloud Native Computing Foundation (CNCF) released Kubernetes 1.32, named Penelope a few weeks ago. The new release introduced support for the Graceful Shutdown of Windows Nodes, new status endpoints for core components, and asynchronous preemptions in the Kubernetes scheduler.

A key feature in Kubernetes 1.32 is the various enhancements to Dynamic Resource Allocation (DRA), a cluster-level API for requesting and sharing resources between pods and containers. These enhancements improve the ability to effectively manage resource allocation for AI/ML workloads that rely heavily on specialized hardware such as GPUs.

Some alpha features in version 1.32 include two new HTTP status endpoints /statusz and /flagz for core components such as the kube-scheduler and kube-controller-manager. This makes gathering details about a cluster’s health and configuration easier to identify and troubleshoot issues.

Another feature entering alpha in this release is asynchronous preemption in the scheduler. This mechanism allows high-priority pods to get the resources needed by evicting low-priority pods in parallel, minimizing delays in scheduling other pods in the cluster.

In addition, an enhancement to Gracefully Shut down Windows Nodes has been added to the Kublet to ensure proper lifecycle events are followed for pods. This allows pods running on Windows nodes to be gracefully terminated and workloads rescheduled without disruption. Before this enhancement, this functionality was limited only to Linux nodes.

The automatic removal of PersistantVolumeClaims(PVCs)created by StatefulSets is a stable feature in version 1.32. This streamlines storage management, especially for stateful workloads, and reduces the risk of unused resources.

This release also includes a generally available improvement to the Kubelet to generate and export OpenTelemetry trace data. This aims to make monitoring, detecting, and resolving issues related to the Kubelet easier.

Allowing anonymous authorization for configured endpoints moved to beta in this release. This enhancement is enabled by default in version 1.32 allowing cluster administrators to specify which endpoints can be accessed anonymously.

Additionally, recovery from volume expansion failure is a beta feature in the new release. This improvement allows recovery from a volume expansion failure by retrying with a smaller size, reducing the risk of data loss or corruption throughout the process.

The flowcontrol.apiserver.k8s.io/v1beta3 API related to FlowSchema and PriorityLevelConfiguration was removed in the new release. It’s part of the Kubernetes API functionality to deal with an overload of incoming requests. Users are encouraged to migrate to flowcontrol.apiserver.k8s.io/v1 which has been available since version 1.29.

According to the release notes, Kubernetes version 1.32 has 44 enhancements, including 19 entering alpha, 12 graduating to beta, and 13 becoming generally available or stable.

For more information on the Kubernetes 1.32 release, users can refer to the official release notes and documentation for a detailed overview of the enhancements and deprecations in this version or watch the upcoming CNCF webinar by the release team scheduled for Thursday, January 9th, 2025 at 5 PM UTC. The next release version 1.33 is expected in April 2025.

Article originally posted on InfoQ. Visit InfoQ

Evan You, creator of the Vue.JS web framework and Vite build tool, recently announced the creation of VoidZero Inc., a company dedicated to building a unified development toolchain for the JavaScript ecosystem. You posits that VoidZero may succeed where Rome, a previous project with similar goals, failed as it would inherit the large user base from the popular Vite toolchain. While VoidZero would release open-source software, the company itself is VC-funded.

VoidZero aims at creating an open-source, high-performance, and unified development toolchain for the JavaScript ecosystem that covers parsing, formatting, linting, bundling, minification, testing, and other common tasks that are part of the web development life cycle. While unified, the toolchain would be made of components that cover a specific task of the development cycle and can be used independently.

High performance would result from using the system development language Rust. Rust’s compile-to-native nature removes layers of abstraction and is credited to run at close-to-native speed. Rust’s memory safety features additionally facilitate concurrently running tasks and better utilization of multicore architectures. Additional performance gains come from better design (e.g., parsing once and using the same AST for all tasks in the development cycle).

The release note also mentions seeking to provide the same developer experience across all JavaScript runtimes. JavaScript is now being run in many different environments, including at the edge. New runtimes have appeared in recent years to reflect those new execution contexts (e.g., Deno, Bun, Cloudflare Workers, Amazon’s LLRT).

You justified its vision on Twitter:

The biggest challenge of a unified toolchain is the zero-to-one problem: it needs to gain critical mass for exponential adoption to justify continued development, but it is hard to cross the chasm before it actually fulfills the vision.

VoidZero does not have this problem, because Vite is already the fastest growing toolchain in the JavaScript ecosystem. And even by pure implementation progress, we’ve already built more than Rome did (before it transitioned into Biome) at this point. I think the premise that JS would benefit from a unified toolchain stands without questions – it’s the execution that matters.

Some developers on Reddit have raised concerns regarding VoidZero’s venture capital backing. The release note mentions that potential revenue incomes would come on top of the released open-source components in the shape of end-to-end solutions targeting the Enterprise segment, which has specific requirements in terms of scale and security. As adoption in the Enterprise is tied to adoption outside of the Enterprise (where developers are sourced from), VoidZero has an incentive to maintain free access to its core offering, beyond the usual benefits of open-source development. Trevor I. Lasn, in an article in which he elaborates on the pros and cons of VC funding, wonders:

[Premium features or enterprise solutions] aren’t necessarily a bad thing. Sustainable open source is good for everyone. But it does raise questions about long-term accessibility and potential lock-in.

The full release note is available online and includes many more technical details together with answers to a list of frequently asked questions.

Article originally posted on InfoQ. Visit InfoQ

In order to maximize the benefits brought by Kotlin in terms of productivity and safety, Meta engineers have been hard at work to translate their 10 million line Android codebase from Java into Kotlin. One year into this process, they have ported approximately half of their codebase and developed a specific tool, Kotlinator, to automate the process as much as possible.

Instead of translating only actively developed code, which could sound the most convenient approach, Meta engineers decided to go for a full migration to avoid the risk that any remaining Java code could be the source of nullability issues but also to remove the drawbacks of using two different toolchains in parallel and the performance hit of having to compile a mixed codebase.

From the beginning, it was clear to Meta engineers that the support provided by IntelliJ’s J2K translation tool was not enough for such a large codebase and that they needed to automate the conversion process as much as possible. However, J2K provided the foundations for their conversion solution, Kotlinator.

The first step was transforming J2K into a headless tool that could be run on a remote machine. The headless J2K was implemented as an IntelliJ plugin extending the ApplicationStarter class and calling directly into JavaToKotlinConverter, as the IntelliJ conversion button does.

Before running the headless J2K, Kotlinator uses a pre- and post-conversion steps to make sure that converted code can build. These steps deal with nullability, apply some known J2K workarounds, and make the generated code more idiomatic.

Both phases contain dozens of steps that take in the file being translated, analyze it (and sometimes its dependencies and dependents, too), and perform a Java->Java or Kotlin->Kotlin transformation if needed.

Meta open sourced some of those conversions so that they could be directly used and also to provide examples of Kotlin AST manipulation through the Kotlin compiler API.

Most of the conversion steps are built using a metaprogramming tool leveraging JetBrains’ Program Structure Interface (PSI) libraries, which can parse files and create syntactic and semantic code models without resorting to the compiler. This is important, say Meta engineers, because in many cases post-processed code would not compile at all, so an alternative method to transform it was required and PSI provided just that.

Any build errors resulting from these steps are handled by interpreting the compiler’s error messages just as a human would do, explain Meta engineers, but in an automated way specified using some metaprogramming.

Instead of simply reducing developers’ effort, these automated steps were also used to minimize the possibility of human error when converting code manually. In the process, Meta engineers collaborated with JetBrains to extend J2K to enable it to run hooks injected by client libraries directly in the IDE.

As Meta engineers explain, a large part of their effort to make Java code translatable to Kotlin is aimed at making it null-safe. This can be achieved simply using a static analyzer, such as Nullsafe or NullAway, to detect all suspect cases, but it is still not enough to eliminate the risk of null-pointer exceptions (NPEs).

NPEs, for example, can arise when some non null-safe dependency passes a null value into a formally non-nullable parameter to a function. One approach taken by Kotlinator to reduce this risk is “erring on the side of more nullable”, which means defaulting to considering parameters and return types as nullable when the code does not suggest they actually are non-nullable. Additionally, they built a Java compiler plugin that collects nullability data at runtime to identify parameters and return types that could be null in spite of not being declared as nullable.

As it is evident from Meta report, translating a large Java codebase into Kotlin is no trivial effort and requires some very advanced engineering. Meta’s journey to make their codebase 100% Kotlin has not come to an end yet but it surely provides the opportunity for some deep understanding of the differences between the two languages and how to transform Kotlin code in a programmatic way. There is much more to this than can be covered here, so do not miss the original article if you are interested in the full details.

Article originally posted on InfoQ. Visit InfoQ

Google Cloud has officially announced the general availability (GA) of its sixth-generation Tensor Processing Unit (TPU), known as Trillium. According to the company, the AI accelerator is designed to meet the growing demands of large-scale artificial intelligence workloads, offering more performance, energy efficiency, and scalability.

Trillium was announced in May and is a key component of Google Cloud’s AI Hypercomputer, a supercomputer architecture that utilizes a cohesive system of performance-optimized hardware, open-source software, leading machine learning frameworks, and adaptable consumption models.

With the GA of Trillium TPUs, Google enhanced the AI Hypercomputer’s software layer, optimizing the XLA compiler and popular frameworks like JAX, PyTorch, and TensorFlow for better price performance in AI training and serving. Features like host-offloading with large host DRAM complement High Bandwidth Memory (HBM) for improved efficiency.

The company states that Trillium delivers training performance over four times and up to three times the inference throughput compared to the previous generation. With a 67% improvement in energy efficiency, Trillium is faster and greener, aligning with the increasing emphasis on sustainable technology. Its peak compute performance per chip is 4.7 times higher than its predecessor, making it suitable for computationally intensive tasks.

Trillium TPUs were also used to train Google’s Gemini 2.0 AI model, with a correspondent on a Hacker News thread commenting:

Google silicon TPUs have been used for training for at least 5 years, probably more (I think it’s 10 years). They do not depend on Nvidia GPUs for the majority of their projects. It took TPUs a while to catch up on some details, like sparsity.

This is followed by a comment that notes that TPUs have been used for training deep prediction models in ads since at least 2018, with TPU capacity now likely surpassing the combined capacity of CPUs and GPUs.

Currently, Nvidia holds between 70% and 95 % of the AI data center chip market, while the remaining percentage comprises different versions like Google’s TPUs. Google does not sell the chips directly but offers access through its cloud computing platform.

In a Reddit thread, a correspondent commented regarding not selling the chips:

That’s right, but I think Google is more future-focused, and efficient AI will ultimately be much more valuable than chips.

In my country, we often say that we should make wood products rather than export wood because making furniture creates more value. I think this is similar: TPUs and AI create more value than the two things alone.

More details on pricing and availability are available on the pricing page.

Article originally posted on InfoQ. Visit InfoQ

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Article originally posted on InfoQ. Visit InfoQ

As customers take on a more active role in national language adaptation, the process should be simple, using tools they are familiar with, Daniela Engert stated in her talk at NDC TechTown. They decided to use GetText in C++ where they provide tools and procedures for their customers to provide translations.

Engert mentioned that they want their customers to be a bigger part of the whole development process. With the opportunity of their – at least optional – ultimate decision about the “language” (national or regional language, jargon, terms, script) the application communicates with them, they are increasingly less passive consumers:

We need to be aware of the needs of our customers to take part in this process, and learn to abandon some control over what we thought to be our private playground, bound only by our company culture and upbringing in our wider environment.

If we expect customers to work with us on a product that satisfies their needs and meets their expectations, we should make the whole process as simple as possible to people outside of our inner circle, Engert said. What we may perceive as “simple” and “easy” might just reflect a very particular world view, she explained:

For example, we might see an XML file with all the necessary information for the language translation process as “perfect”, albeit wordy. But customers and all the people involved at their site like end users, professional translators, or the like, will most likely perceive this as gobbledygook with arcane and obscure rules, possibly outright frightening.

There is no “blessed way” of doing it, there are rightfully no related functions in the C++ standard library, and there is no “standard” library that fulfills the needs. Instead, we have the choice of multiple libraries from both C++ and C, Engert said, so we then need to figure out which one suits us best.

There are solutions available that come with a rich enough ecosystem of tools and information sources that can guide us. Some of them are pretty specific to a subset of programming languages or communities. These are great because their gravitational pull helps defend their selection, Engert said.

Some tools are more geared to a wider audience, Engert mentioned. This is part of the landscape where you might find a solution that fits possibly all applications (and their dependencies) that you might intend to adapt to more languages than just one:

Such solutions tend to be more open to inputs from communities outside the programmers’ guild. They often have a richer tooling ecosystem and more sources for information at different levels of understanding the problems. That’s good for our customers, too.

They chose to use the GetText tools in their company, Engert said, to develop a feature in e.g. C++ with little to no translation in mind, in a language they preferred. Tools that come with GetText then extract all those strings that require translation and put them into a container text file with all the already existing translations.

Engert mentioned that they let their customers come up with translations of their own taste, using their preferred procedures and tools. Or they do it themselves if the customer chooses so. Tools build the artifacts that they incorporate into the application and deploy to the machines at the customer site (they are a company that builds machines). People can then select one more UI language when working with the machine, Engert said.

The GetText facilities became standardised this year, after a decades-long history and widespread use in the industry, Engert mentioned. They take advantage of other standards like Unicode and the information available there about how to handle languages and their peculiarities like language forms dependent on quantities, she concluded.

InfoQ interviewed Daniela Engert about doing natural language adaptation.

InfoQ: How can we involve customers in national language adaptation?

Daniela Engert: Timely involvement and short development cycles are more likely with the least possible entry barriers for people that are much less affine to the world of IT than we implicitly are. Rather choose something as simple as a text file with the least possible amount of rules to follow.

Ideally, a customer can modify such a file with any text editor at hand, with a small chance of introducing errors. And if they do, like using e.g. MS Word as their preferred tool, we can quickly undo it without loss of information. Ideally, we can give them tools that feel like all the other tools they are already familiar with.

InfoQ: What will the future bring when it comes to national language adaptation in C++?

Engert: I can see no appetite in the committee to incorporate something like that into the C++ standard library. Besides alluding to language translation in some proposals, I am not aware of any substantial efforts or even proposals to widen the target area of C++.

Many of the committee members – like myself – are volunteers with little to no support from their employers. Our resources and our energy are limited. That’s the reality of most ISO languages with no company backing. C++ was always meant to be a tool for implementing libraries, tailored to certain applications and particular needs. Let’s keep it this way. The language itself is expressive enough, powerful enough, and dynamic enough to fulfill current and future requirements.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Luu: My name is Christopher Luu. I do work at Netflix. I work on the growth engineering team. What that means is that we work on the customer lifecycle, anything that happens for Netflix before the user is a member, while the user is a member, if they subsequently cancel and become a non-member, and everything in between. This talk is about how we decided to approach server-driven UI, not just for mobile, but for all of our platforms. The problems that we were encountering that caused us to even go down this path. A little bit about what are the problems that we encountered, what are the challenges that we faced? All that kind of stuff, typical stuff.

What is Server-Driven UI (SDUI)?

What is server-driven UI, SDUI? It is a UI driven by the server. We’re going to talk about the spectrum of SDUI. What exactly does it mean to be on the spectrum here of server-driven UI? All the way on one side, we got something that’s really not very server-driven, like a completely offline app might be. You could think like a calculator app or something like that. It doesn’t ever need to talk to the server unless it’s stealing your data, which they probably are. All the way to the other side, you can have something that is extremely server-driven like a WebView. Something that is driven entirely by a server, where it’s sending HTML and JavaScript and CSS, and it renders it. That’s the other side of it.

Then everything in between in the spectrum. You’ve got the RESTful API. You’ve got GraphQL APIs. You even got SOAP APIs, for some reason. I think pretty much all of us probably do some form of server-driven UI. That’s the point. Even at Netflix, before we embarked on this journey, we were doing server-driven UI. We had all sorts of different protocols. You may have heard of Moneyball, or Falcor, or some of our GraphQL experimentation. All of these are server-driven UI, because the server is telling each of the clients to drive the UI to do something, to show something. For this particular case, we wanted to get a little bit closer to all the way on the other side of that, which is right there. Maybe not right there, I just put it there. We wanted to be server-driven for this particular problem.

Pros and Cons of Server-Driven

What are some of the pros of being more server-driven UI, in my opinion? One of the big pros here is this first bullet, the updating of the UI without a client update, because the server itself is what is driving the UI. What is so key about that, especially for our mobile applications, is that we can update the UI without needing to submit it to Apple or to Google, or for our TV, they can just refresh and get the latest version. That’s pretty cool for us, especially as we’re trying to do a lot of experimentation. We’re also able to share a little bit more code and logic across all the different platforms that we’re dealing with. Netflix is on a lot of different devices. With all of these different platforms, we’re really interested in being able to share some of that logic so not every single client has to reimplement the same networking code and the same parsing logic and all that stuff.

Netflix is a very A/B heavy company, and so being able to iterate fast on different A/B tests is a great benefit for us. That’s one of the big pros that we’re looking for here. This other point is interesting to us, where developers can work on other platforms as well. What that means is that even if I have no idea what mobile development is like, I’ve never touched Xcode or Android Studio or anything like that, I may actually still be able to create a UI from the server and have it render with native UI elements. That’s a pretty cool prospect for us, especially as we’re trying to juggle all of the different developers that we have and try to figure out which projects they could be assigned to.

Of course, there are cons. What are some of these cons that we have to consider here? We’ve got the higher upfront cost to architect. We’re dealing with not just a simple RESTful API anymore, but we have a little bit more to deal with in order to, upfront, be able to architect exactly what we’re going to be able to drive from the server. There’s this complicated backwards compatibility concern. We’ve got an app that’s out in the App Store, maybe the user doesn’t update it for a while. How do we deal with that? There’s this non-native UI development.

What that means is that all of us engineers, we pick the particular platform that we’re developing for, probably because it’s delightful to us. We like SwiftUI development. We like Jetpack Compose. We like Angular and React. We like these particular ones. If we’re changing it so that now we’re having to do the development of a UI from the server, that’s not necessarily the best thing. It’s also harder to support offline apps. If, by necessity, the UI of an application needs to be driven by the server, if it can’t connect to the server, then what are we going to do? These are problems that we have to deal with. It’s also harder to debug. You’ve got more layers of abstraction in between the client, all the way up to where the UI is being driven.

What Were We Trying to Solve?

What were we as Netflix on the growth team trying to solve here? I’m going to tell you a little bit of a story. It’s a story that got us to this point. We’re going to be talking about UMA. Of course, at Netflix, and I’m sure at a lot of other companies, we have a lot of different acronyms. UMA is the Universal Messaging Alert. This is a generic UI that we were trying to drive across all of our platforms in order to notify the user of something. They may have a payment failure, and we want to be able to rectify that so that they can go on streaming our lovely service. There may be a promotional aspect where we want to drive the user to certain parts of the app. Maybe there’s a new feature that we want to exploit for them, something like that. There are all these different kinds of alerts.

Our messaging partners have created this lovely template of different kinds of alerts that we can display to the user. Here, just as a very simple alert, it’s got a title, a body, some CTAs. You might imagine a JSON payload driving that being something on the left there, with the title, body, the CTAs, and it tells it to do something. It’s really cute and cuddly. It’s not that complicated. All of our platforms can implement it pretty easily. I might call that UMA-kun. It’s nothing to be concerned about. Let’s pretend we were actually trying to iterate on this a bit. If we were trying to actually create an API for this, you might have a title, it’s a string, easy enough. We’ve got a body. It’s a formatted string because we know copywriters, they want to put some bold, or they might want to link to a privacy policy or something like that, so we got to make it formatted. Big deal. We got the CTAs.

We do need to have the ability to block the user in case it’s something really legal specific. They need to accept some new terms of use, or something like that. We need the ability to say whether they can close it without using one of the CTAs. The design team came and say, “Actually, we want to try something like this. This is going to be really awesome”. That means, now there’s some eyebrow text. That’s the text that goes above the title. Sure, we can add that. Now it looks like you center aligned the content instead of what it was before, which is left aligned, so now we got to add some text alignment. Background color, it’s not the same color as before. There’s a header image now, this banner image.

Sometimes they might want an icon instead of an image. Maybe like a warning sign or something like that. Then there might be a footer, if it’s really legal. They need to add some copy beneath the CTAs. Maybe there needs to be another background image in case they don’t just want to use a color, they got to use some gradients or something beautiful in the background. Maybe there needs to be text color that changes, depending on the brand and what is displayed in the background, could even need some secondary CTAs. You all get the picture.

UMA-kun rapidly turned into UMA-sama. This got to the point where we were trying to deal with all of these different requirements, and not only were there different requirements where this particular once simple API shifted and became more complicated. We also have different platforms that we have to deal with. The four main innovation platforms currently on Netflix are TV, web, iOS, and Android. TV, we do have a special platform that means that we don’t have to do a very specific UI for every single TV brand out there. We have our own platform that allows us to evolve those relatively quickly. For iOS and Android, specifically, we have this long tail version issue.

This means that, because of how quickly we release app versions, there are likely going to be a good number of users who don’t necessarily always update to the latest version. Not only that, iOS might drop support for a certain device, like the latest iPad, or iPads four years ago may not run necessarily the latest version of iOS. Someone gets an iPad from their parents or something like that, and all of a sudden it just stops working with Netflix. That wouldn’t be great. We can’t drop support for those. We have to consider all of these different things.

Let’s say, if we’re going back to UMA-sama, and we’re like, now iOS happened to introduce the footer field in version XYZ, but TV didn’t implement it until this certain date. Web is ok. Web’s generally ephemeral. You refresh the page, you get the latest version. Maybe that’s not as big of a deal. Android, they’re slackers. They haven’t implemented it yet, whatever. The point is, the backend now has to figure out, can I even send this message that has this particular field in it? How does it deal with that? This is one of the key problems that we were trying to solve as we just explored server-driven UI. It’s worth mentioning that this also does exist on the TV side as well, like our older TVs, something that was sold many years ago may not be able to support the latest version of our platform, so we also had to deal with this problem there as well.

Not only that, many of our interstitials and things are multi-step. We’ve got this first message that appears, maybe it’s bugging the user to enter their phone number, but then we also have to verify their phone number and then show them some toast that lets them know that they were able to enter it properly. We deal with a lot of microservices at Netflix, which means that likely the first screen might be driven by one server, and then the client has to do completely other integration with some very other service in order to populate the next couple screens and be able to submit them.

Possible Solutions

What are some possible solutions? We could do a WebView. That was all the way on one side of this server-driven spectrum. If you remember, the design of UMA-kun was an interstitial, it’s something that pops up. I personally have never seen a WebView that looks very good, especially in the context of presenting an interstitial. We might have to take over the user screen or something like that. That’s just not great. What if we just evolved the template? Now that we know all of the properties that UMA-sama has, can we just learn from that? That is our new API, and then just set it from day one, and then now we’ll never evolve it again. Yes, no one believes that.

We, of course, looked at server-driven UI, and we looked at something that we call CLCS, we call it CLCS for short. It does not stand for Christopher Luu’s Component System. It stands for the Customer Lifecycle Component System. It’s designed to be able to drive all of these different kinds of interstitials relevant to dealing with everything from the customer lifecycle.

CLCS (Customer Lifecycle Component System)

CLCS in general, is a wrapper around our design system. This is really important for us, because I am a lazy engineer, I do not want to have to go and implement all of the UI components necessary to build a server-driven UI. I, as a lazy engineer, am going to be able to utilize all of the lovely work being done on all of our platforms to adopt our new design system. This allowed us to move much more rapidly, because we already had all these kinds of buttons and components and things that we could use. It supports multi-step interstitials because it completely abstracts away all of the backend logic away from the client.

Now the client deals with one little middleware layer that then reaches out to all of the other microservices and figures out, I’ve got a message. Here’s the message. It’s displayed in some template, something like that. I’m going to turn it into this server-driven UI payload, give it to the client. The client sees, great, I’m going to render it. I’m going to collect some user input. Maybe it’s a form, or like that collecting phone number interstitial I showed you before. Collect all that data, send it back to the server. Server says, this means that you want to render the next screen. Here’s the next screen, and on it goes.

That design system at Netflix is called Hawkins. Basically, Hawkins consumer design system is how we try to establish a branding guideline across all of our applications, across all of our platforms, into a set of typography tokens, components like the button, or checkbox, or inputs, any of the various kinds of components that you might want to build, UIs. Also, colors, like surface colors, foreground colors, borders, all that stuff. Because this Hawkins design system was very much in progress when we started the server-driven UI, we were able to leverage all of that and essentially just wrap it up in a nice little server-driven UI bundle and deliver that to the client. Then the client could basically utilize all of these 100% native components built in what other UI frameworks are native to that platform.

On iOS, that might be SwiftUI. On Android that might be Jetpack Compose, or it could be the legacy XML, it could be Flutter, it could be React native. We don’t really care. All we care about is that now all of these design system components are being implemented on each platform, and we’re able to utilize these. Not only that, they already established the certain levers, because one of the key pieces about going down this route that we wanted to do was to not reinvent a browser. We did not want to just reinvent HTML because otherwise why not just send the WebView? It was very important to us to pick specific things about each of the components that we wanted to be able to drive from the server.

On the left side, you might see all the different kinds of buttons there. Those are the exact levers that we provide through the server-driven UI to customize the way that a button looks. We don’t let you specify a height or an arbitrary width or anything like that. We utilize the particular levers that the Hawkins design system was able to provide for us. Similarly, we don’t allow you to just change the foreground color, because that’s where it starts to eke into being more like a browser, which we just did not want to do.

CLCS at a whole is basically components, fields, and effects. The components are all of those building blocks, buttons, inputs, checkboxes, all that stuff. Then, we basically glue all those things together with stacks, essentially vertical stacks, horizontal stacks, or because of web, more responsive stacks. Stacks that might want to be horizontal if I’ve got enough room there, or might want to be vertical if I don’t have enough room. We’ve got fields, this is how we actually collect user input. This is maybe a string, a Boolean number, depending on the kind of data that we want to collect for a user. Then the effects.

These are what actually happens when the user interacts with the particular component, so when the user taps on a button, it might dismiss the interstitial, or submit for the next screen, or log something, something like that. This is what it actually can look like. Here I was trying to fit every single possible UI platform that Netflix supports, which is the web, TV, iOS, and Android on one screen. It honestly didn’t fit. I had to try to jam it as much as possible. You see, there’s an iPhone, there’s an Android phone, there’s an Android tablet, there’s an iPad, there’s a web screen jammed in the corner there. There’s a TV emulator on the bottom right. They’re all displaying the exact same payload here, which is a complicated one. It’s got three cards here.

Each one has a banner image and the title and body. For smaller screens, they get laid out vertically. For larger screens, they get laid out in a nice little horizontal stack. This is all being driven by a single payload across all the four major platforms.

Let’s take a little bit of a closer look at a CLCS screen. Here we’ve got one of the more typical UMA-kuns. We’ve got an image at the top. It’s an icon in this particular case. We got some title. We got a body. We got some CTAs. We’ve got the footer. Essentially, we were able to break that down as essentially one modal that contains a vertical stack. You can see that, it’s pretty vertically oriented there. The first element of that vertical stack might be a horizontal stack that includes a single child that is center aligned. The next one is just the title text. The next one is just the body text. Those are text elements that have specific typography tokens that tell them to render with a specific font and weight. Then we’ve got the CTAs. The CTAs is actually going to be in one of those responsive stacks that I mentioned, which means that on a larger screen, those might want to be displayed next to each other, whereas on a smaller screen, vertically.

Finally, the footer text at the bottom. What could that actually look like in the CLCS code that we generate? It could look like this. It does look like this. Basically, because a lot of our engineers at Netflix, and especially on the growth team, are web engineers or TV engineers, they’re very familiar with React programming. We utilize JSX and TSX to essentially allow us to author the UI like this from the server. You can see, it’s all of those elements that I mentioned before. It’s got that modal. It’s got that vertical stack, the horizontal stack with the content justification as center. Because of this, we’re able to actually generate this UI. It turns it into the payload that each of the clients expect, and then those clients take it off to the races, and they’re actually able to render it as you saw on the other screen before.

Backwards Compatibility

Mr. Netflix man, you were talking about backwards compatibility. This is a key problem that we have to deal with. Because there’s all those folks that might not have updated to the latest version. What if you create some new components that cannot be rendered in the old version that someone might be running, what do we do there? Or, how do you make sure that you’re not sending something that would just completely make the app crash, or something like that. We actually rely a lot on GraphQL. This is part of our transition to GraphQL at Netflix. We do a lot with the built-in safety features of GraphQL that allows us to ensure that there are no breaking schema changes. It allows us to also fall back on components using what we call request introspection.

Then we can also basically know that they are a set of baseline components that are implemented on all the different platforms, at a minimum, if they support the CLCS spec. What do I mean by GraphQL features? The way that GraphQL works is that it’s essentially when you are trying to query for something, you might create a fragment. Here’s an example of a fragment on a button component. Here, with GraphQL, you have to specify every single property that you want to get, and maybe expand on that with another fragment, something like that. Here we might be getting the accessibility identifier, the label, the button size, type, icon, onPress. Because of the way that GraphQL works, if we were to remove the label property altogether, all of our deployment scripts, our CI/CD, everything, would yell at us and say, “You can’t do that. That’s a breaking schema change”.

We also have a lot of observability so that we can see exactly how often this particular property is being utilized. Maybe in the future, if we do decide to deprecate something, we could take a look at that and safely remove it. It makes it very hard. You have to force it to actually remove something like that. That’s one of the nice things. We don’t have to worry about it accidentally removing something that hundreds of clients are still being used.

The component fallback thing is an interesting one, though. Let’s pretend we have this overarching fragment called ComponentFragment, it spreads over the entire interface for CLCS component. Every component that exists belongs in this one huge switch statement. Eventually, I don’t show it here, but you might assume that there’s the button fragment referenced here, or the text fragment, or the checkbox fragment, all that stuff. Let’s pretend there’s this fancy new label that we want to introduce for some reason.

The FancyLabel is now added to this ComponentFragment, and there’s a fragment for it. That’s all well and good. When we actually define how this particular component is rendered or is put together, we define a component in our CLCS backend that essentially is able to take in a fallback. What that fallback does is it essentially takes all the properties that belong to that FancyLabel. Let’s pretend it’s these key, label, color, typography, all that stuff, and it’s able to then say, what are you going to do if this particular component just does not exist? If the user did not request it. The user’s not spreading on it. It has no reference to this, because of the way that GraphQL works, and every request has to basically reference all of the things that a particular client supports, that is our tell. It says, “They didn’t request the FancyLabel component, so I need to fall back in this case”.

In this case, we could fall back to a less fancy label, just give them a text, great, whatever. They’re using an old version, maybe they don’t need to see the latest stuff. We could also potentially do other things. We could send them a button that says, “Sorry, you got to update to the latest version. Here’s a way to get to the app store”, something like that. It’s completely arbitrary, made up, but there are options here. This is a way that we can actually fall back, which is key, because we do want to continue to evolve CLCS. We don’t want to just stay at the set of baseline components.

How does UI development actually look like in CLCS? We’re going to explore something that I call templating and demoing. Essentially, you might assume that we have this function that says, MyLovelyScreen template. It takes in these options, let’s say a title and a date, and it’s able to render it. This is a very pared down version of what this payload might look like. You might assume it’s got this modal with a stack of these two text elements, or something like that. This is our template function. When I actually want to render this, let’s say there’s a backend that I want to integrate with, you might have the MyLovelyScreen function, which promises to return a screen. In that case, it reaches out to the backend, it fetches the data, it’s able to get that.

Then it calls that MyLovelyScreen template, so that it can actually render it in the way that it’s supposed to. At the same time, we can also create a completely mocked version of this, like a demo. In this case, it’s passing in a title and a date that’s completely arbitrary. It’s made up. It’s basically utilizing the exact same rendering path. It’s going to be rendering that same screen here. Because it’s utilizing the exact same thing, we can use this for a lot of things, actually, these demos. We can use this for our automated testing strategy. These demos, because they render in the exact same way that the more server, actual backend driven version looks like, that means that we’re able to run all sorts of different kinds of screenshot tests against them. The client is now essentially forced into basically just being a rendering engine and a user input collection engine.

Now, if we were wanting to set up these tests where the client is getting this demo payload. For all intents and purposes, it looks exactly like the real payload. We’re able to take screenshot tests there and ensure that there are no regressions introduced if something changes in the client renderer, or something changes in the backend, or something like that. That’s pretty cool, because in the past, we have been pretty reliant on end-to-end tests at Netflix, which means that we have to set up a user. We have to create this fake user. We have to set it up in this particular state to get this particular message, get to this particular screen to actually render this particular screen. It was a pain. It’s faulty. There are so many points of failure.

Now, because we’re able to go and get just this demo and say, “Backend, give me a demo of this particular screen”. We’re able to bypass all that, and just get the logic that we want and show the particular payload. Not only that, it’s super helpful for localization quality control. We support a lot of different languages in our app, and in order to support our localization teams, we take screenshots of everything and say, does this screen look ok in your language?

In the past, with those end-to-end tests, they were a massive pain to try and get the user in all these different states and ensure that they work, whereas now all it has to do is make a single call, get a demo, come back and render it with that particular language. We’re able to do these client integration tests, so we had build up that much more confidence about how CLCS is implemented. These are tests that maybe challenge how the effects are implemented. Or, they’re hyper-focused on each particular effect, so that we can ensure that when we ask it to do something, it’s doing the right thing. We’re also, from the backend side, able to take a lot of snapshot tests with our templates.

I mentioned the template before with the MyLovelyScreen, we’re now able to take actual snapshots of the output, and when that changes, then we know, “We know that you updated this template to add some new field or something like that”. Since we have a snapshot, it says, this change, is that right? Is that what we’re expecting? Allowing us to have much more granular confidence in the actual templates that we’ve created. What about this end-to-end test? Those are still important for us to ensure that, at the end of the day, it’s great that the client does what it’s expecting to do, but what if something in the backend does actually happen?

For this, we actually created a pretty cool system that allows us to create a completely headless version, a completely headless client that implements CLCS. What that means is that it can take a CLCS payload and then interpret it, be able to traverse its DOM to determine if elements are existing when they’re supposed to be, and even click on buttons for us. The really nice thing about this is that we have one centralized place for all of our platforms. In the past, we had every single platform, Android, iOS, TV, web, they had to create their own end-to-end tests, set up all of this stuff to get to the right state to do it. Now it’s all happening just in one place, in the backend. If something happens downstream from us, we can point at the right place, and they’ll hopefully fix it for us.

What’s Next for CLCS?

We’re getting to the point now where we can talk about what’s actually next for CLCS. We’re going to continue to migrate our old messages. There’s a lot of those old UMA-kuns that are out there that we’re looking to transition to the new interstitial system. We’re going to experiment usage across other multi-step forms that are particularly pertinent in the customer life cycle stuff that I mentioned before. We’re going to try to replace some of our old WebView-based flows. Not only are WebViews more less elegant for our users to use, but they’re complicated for us to maintain. That means a whole nother canvas that web engineers have to go and test on.

If we’re able to eliminate those and just replace it with CLCS flows, that’d be pretty cool. We’re going to take over the entire app. No, that’s not our purpose. There’s a lot of other parts of our app that will not necessarily work well with CLCS. We’ve got our huge screen where you’re scrolling through all your different movies and TV shows and things like that that you want. There’s no way we’re going to want to render that in CLCS. That doesn’t necessarily make sense. The goal is to be hyper-specific about this particular flavor of server-driven UI. What is it really good at? Use that. Don’t try to leak it into everywhere because server-driven UI is cool.

If I Could Turn Back Time

If I were able to turn back time and go back to where we were when CLCS was first created, I’d probably try to do a few of these things. This might be helpful for you, if you’re trying to implement your own server-driven UI. I’d probably try to establish that baseline a lot earlier. It’s hard. It’s kind of a chicken and the egg, because once you start building the experiences, that’s when you realize, we actually need this other component. That’s going to push back the baseline further as you continue to explore these. If we could really sit down and try to establish what those things really are, I think that would help us a lot more in the long run, and give us a lot more runway to run with.

Also, try to formalize that testing strategy earlier. We’re at a pretty good place with our testing strategy, but it took us a while to get there. I’d probably try to work with some of our testing partners and try to figure out, how can we actually speed up this formalization so that we just build up that much more confidence in this brand-new system. Also, try to have better alignment with our design system partners. When this started, we were parallel tracked with the design system. We were basically just trying to exploit all of the wonderful work that they were doing. Now that we are much more aligned, that means that we can have much closer roadmaps together and try to evolve together, rather than each independently working separately.

We also would have been more helpful to align all of the platforms on the templates earlier. I showed you that big screen that showed all of the different platforms displaying the same UI with the same payload. It took us a while to get to that point. Before, we had a lot of if statements. We had an, “If I’m on TV, then do this one thing. If I’m on mobile, do this other thing. If I’m on a tablet, do this other thing”. Being able to align the platforms and the templates, means that we’re able to evolve those templates much more quickly and much more confidently.

Should I Adopt SDUI?

Should I adopt UI? Should any of you adopt SDUI? SDUI is super personal. It’s super specific to what you’re trying to solve. On that big spectrum of SDUI, there might be certain elements that you want to garner from it. You might not need all of the flexibility that we have on the Netflix side, so maybe you’ll go closer to the other side. You probably are using some form of SDUI, so maybe the answer is yes.

Questions and Answers

Participant 1: You have design components for SDUI. You have a separate set of design components for your native drawing, for the other non-SDUI driven, or do you reuse the same design components?

Luu: Do we use a different set of design components for SDUI versus just the regular native development?

No, we utilize the exact same components across both. The whole point of the design system was to ensure that all of our UIs, they’re adopting the Netflix branding guidelines. The whole point, it would be pretty weird if you all of a sudden got this popup and it had a completely different design element with different typography, different colors, different components altogether. We utilize the exact same components that they have.

Participant 2: From the app perspective, the CLCS makes the app more complicated in one sense, because there’s two different rendering mechanisms. There’s the native stuff, and then there’s the CLCS stuff on top. From the apps’ perspective, is it worth it? Because dealing with these popups and the flows was a pain, so they rather render stuff than trying to do five different screens in a row and all the different permutations in native code, or do the apps don’t really have a say in that, because you say, you use CLCS, and that’s it.

Luu: Is it a pain? No. We have found that it actually worked quite well for us, because a lot of the kinds of flows that we’re driving through the CLCS flows, are some of the more annoying kinds of UIs you want to develop. All of the developers that were traditionally developing those in the past were more than happy to hand that over to this new system. It’s completely outside of their interest. They want to do something that has really fun animations, that shows this thing over here and all that stuff. The developers that develop the CLCS frameworks, for them, it’s interesting because they’re building this whole new system inside of the app code base. That piece is interesting. I think everyone’s pretty happy, actually.

Participant 2: The applications that were built or finished, or the versions of the application that were finished before CLCS were implemented, they still do the old alarms. It’s only the new versions that get to use CLCS. You have to support both, the old native alarms plus CLCS on top for the new versions.

Luu: That is 100% true. We still have a lot of versions of the applications for all of our platforms, except for web, that have no semblance of any idea of what CLCS is. We still have to support those in some fashion or another. In this particular case we showed you UMA. UMA does still exist. That is a kind of payload that is still being sent by our backends as needed. It’s not being used for new messages. We have other fallbacks. There are other ways to send more simpler alerts. Not necessarily something that looks as nice as an UMA, but it’s still just a functional maybe like a JavaScript alert, or UI alert dialog, or something like that in iOS. We still have the ability to fall back on those older versions if we need to. The true story is that there’s still going to be that subset that’s always going to be a problem that we have to deal with until we can somehow completely deprecate those old versions.

Participant 3: How do you manage the navigation stack with these kinds of systems, because if I want to go back or forward or navigate through the application, how do you do that?

Luu: How do you deal with navigation stacks with this system?

We cheated because we already have a system in place for growth that is essentially a very big state machine for a user. Our UI development in the past has depended on this essential service that tells us the state of a user. If I’m in this particular state, show this kind of screen. We’re utilizing that already. Essentially, if I’m on screen five, and then the user hits back, we say, state machine, what state do I go to the user? Because the user asked to go back, and that tells you to go to state three or something like that. That, at its core, is how we deal with it. We also do have a semblance of a navigation stack in the CLCS backend itself, so we’re able to store the state of a particular user and know where they are in a particular flow. Even if that state machine wasn’t part of the process, we’re still able to figure out some semblance of where they should go. It is complicated.

Participant 3: How do you handle offline requirements?

Luu: How do you handle offline? We’re lucky in that most of these particular screens are happening in a world where the user has to be online. We’re basically asking our messaging service, do you have a message to display to this user? In this particular case, the user has to be online to get that message. If not, it’s not the end of the world. They can continue to operate offline. However, there are use cases that we’re exploring where we’re trying to figure that out, like, is there a way that we can deal with an offline connectivity state?

The true answer is that, yes, absolutely, because at the end of the day, the payload that we’re getting back to render as CLCS as a screen is just a GraphQL output, which happens to be a JSON payload. There’s no reason that we couldn’t necessarily bundle that JSON payload with the application in order to render in the fallback case where the user doesn’t have connectivity. It’s not the best case, because we’re not able to update that payload, but it still allows the user to be unblocked if it’s a particularly critical flow.

Participant 4: How do you do caching?

Luu: How do we do caching? We actually rely mostly on the different frameworks that we’re using. On our mobile clients, we’re heavily invested in using Apollo clients. The Apollo mechanism has caching part of it. A lot of our network engineers on the client side have already built our own caching mechanisms on top of them, so we’re able to utilize that caching. There are all sorts of other caches too. There’s a cache at the DGS level, or at the backend level, which is able to not necessarily always have to go back to messaging if the message was requested X amount of time ago. In general, we basically utilize most of the existing caches that we already have implemented because we already had networking implementations on all of the different platforms.

Participant 5: Have you ever encountered the issue, for example, some interfaces being so complicated, which you cannot have it. For example, you can have it in web, and you can’t have it on TV, and probably you’re going for the fallback, but there is another fallback required because some other version in some, for example, Android, doesn’t have. That you want a message to tell the user that, you need to update so you have multiple fallbacks, or how did you deal with this situation?

Luu: How do you deal with recursive fallbacks?

In general, the fallback logic that we have in place is already able to do that. If you fall back to another component that’s not necessarily baseline, it’s already going to be able to fall back on its fallback and continue recursively. That’s not particularly a problem. I do want to touch on one piece that you mentioned, though, which is, what do you do about some component that is actually more difficult to render in general, for a particular platform. There’s an interesting strategy that we’ve started to adopt now where our components don’t necessarily need to be specific Lego blocks that are Hawkins components in our design system.

They can actually be larger components that could encapsulate more interesting behavior. Something that adopts animations, or maybe is a much more complicated responsive thing that we need to render specifically for web. We wholeheartedly support those with the caveat that we know that the further that we get away from these building blocks, it means the more complicated it’s going to make maintaining those particular components that we’ve introduced or adopting them across all the different platforms.

Participant 6: Can you describe, like I’m telling a 5-year-old, how does the client ask the server for the building blocks that he wants to display? For example, does it send a request to the server saying, this is the platform name, for example, iPhone 15 Pro Max, and this is the dialog I want to display. Then the server will return what will be displayed.

Luu: How do we start this whole process, and what kind of data are we able to pass back to the server so that it knows exactly what to tell it to render?

We cheated. We utilize all of the existing stuff that was already in place for our networking backend. That includes a bunch of headers that we send for every single request that informs a lot of like, which particular device I’m on, or not necessarily which device, but which client I’m running on in my iOS or Android, what version of that I’m running, like my screen size, something like that. We already have a lot of these headers that it’s able to inform what we do on the backend side.

Because these are GraphQL endpoints, they’re just queries and mutations that we’re utilizing, we’re also able to add additional properties at any point. If there’s something specific to one particular entry point that we want to drive, some specific thing about what the user is doing at that time, maybe if they have a lower connection because they’re on cellular or something like that, we’re able to add that data as well anytime we want, for any particular entry point. We’re just able to leverage a lot of the flexibility that being GraphQL allows us.

Participant 7: If the device is in portrait and landscape, does the server send back and say the dialog box should be wider then narrower, or does the device automatically know that, and does that layout work?

Luu: Our goal was to not have to go back to the server for that, because that’s a whole nother round trip. As part of our payload, we added that responsive stack. Basically, it has children, and it does something with those children based on the amount of space available to it. In that particular case, the responsive stack might say, because I’m in landscape mode, I’m going to be able to lay this out in all sorts of manners. It’s actually a very complicated component, but that’s how we leverage it, and we’re able to use that for web as well. Because on web, if you’re resizing the window, it’s going to really suck if you’re going to have to do another request every single time that the breakpoint changes. That’s how we decided to leverage it on our end.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Android XR is Google’s new operating system aimed at powering devices like headsets and glasses and making possible new experiences, a.k.a. apps, running on them. Android XR will integrate Gemini, Google’s AI assistant, to enable understanding user intent, defining a plan, guiding through tasks, and more.

Android XR is build on top of the Android OS, leveraging key components like ARCore, Android Studio, Jetpack Compose, Unity, and OpenXR to provide solid foundations for the new platform. Android XR apps will make it possible for a virtual environment to coexist with the real world. For example, says Google, they are working to allows users to watch YouTube videos on a virtual big screen, display photos in 3D, and so on.

We’ll soon begin real-world testing of prototype glasses running Android XR with a small group of users. This will help us create helpful products and ensure we’re building in a way that respects privacy for you and those around you.

Android XR apps will exist inside virtual spaces and include 3D elements, spatial panels, and spatial audio to create a sense of depth, scale, and realism. They will also leverage multimodal interaction capabilities using hands and eyes.

To make it easier for developers to create Android XR apps, Google has also announced the Android XR SDK.

You’ll have endless opportunities to create and develop experiences that blend digital and physical worlds, using familiar Android APIs, tools and open standards created for XR.

A key component of the Android XR SDK is Jetpack XR, which includes new XR-specific libraries, such as Jetpack Compose for XR, Material Design for XR, Jetpack SceneCore, and ARCore for Jetpack XR.

Besides Jetpack Compose XR, the Android XR SDK also supports creating apps based on Unity or WebXR.

You can use the Android XR SDK with Android Studio Meerkat, which also includes the new Android XR Emulator. This will make it possible to use a virtualized XR device to deploy and test apps built with the Jetpack XR SDK. The emulator will rely on keyboard and mouse to enable navigation in the virtual 3D space using a palette of tools to rotate the scene, zoom in and out, and so on.

Android XR will have its own Play Store, where you will find apps created specifically for Android XR as well as compatible Android apps, which will be automatically spatialized with no developer effort.

First and foremost, Android XR’s preview aims at providing device makers and creators the opportunity to start creating a whole new ecosystem of devices and apps. According to Google, the first Android XR device will be released by Samsung in 2025.

Android XR and the Android XR SDK are currently available in preview only. If you are interested in getting access to the new platform, you can apply here.

Posted on mongodb google news. Visit mongodb google news

A powerful rally in the U.S. stock market in 2024 has set the stage for even greater momentum in 2025. The S&P 500 index reached a record-breaking closing value of 6,090.27 in December, and experts anticipate more gains as a new rate cut cycle takes effect.

Drawing insights from historical data, Charles Schwab highlights that 86% of the time, the S&P 500 posted positive returns within a year after the commencement of rate cuts since 1929. While downturns occurred in 2001 and 2007 due to recessions, the present environment seems different. The Federal Reserve’s rate reduction in September 2024 provides optimism for continued growth. Analysts from UBS predict the S&P 500 will climb to 6,400, while John Stoltzfus from Oppenheimer Asset Management forecasts a rise to 7,100 in 2025.

Amidst these promising projections, certain stocks stand out for their potential to ride the upward trend, particularly Oracle and MongoDB.

Oracle has carved a niche in cloud services and AI infrastructure. Despite narrowly missing analysts’ estimates in the recent fiscal quarter, Oracle’s dominance in AI data centers, partnering with giants like Nvidia and OpenAI, sets it apart. Its innovative cloud infrastructure design, widespread geographical presence, and cost-efficient scalability are catalysts for its growth.

On the other hand, MongoDB is gaining traction with its flexible database solutions. Although shares dipped following leadership changes, MongoDB’s impressive expansion, with over 52,600 customers, underscores its resilient performance. The company’s focus on AI-powered applications and modernization of legacy systems positions it for sustained success.

These attributes make Oracle and MongoDB potential winners as investors seek to capitalize on the stock market’s anticipated 2025 upswing.

Stocks to Watch: Oracle and MongoDB Poised for Growth in 2025

In the landscape of financial market predictions for 2025, Oracle and MongoDB surface as noteworthy contenders, driven by their strategic innovations and market adaptability. As the S&P 500 continues its upward momentum, bolstered by historical trends and recent rate cuts, these companies are well-positioned to benefit from the evolving market dynamics.

Oracle’s Strategic Expansion in AI and Cloud

Oracle’s strategic investments in cloud services and artificial intelligence (AI) infrastructure have fortified its position in the tech industry. Despite minor setbacks with analyst expectations, Oracle’s partnerships with industry giants such as Nvidia and OpenAI highlight its robust presence in AI data centers. The company’s innovative cloud infrastructure, coupled with its extensive geographical reach and scalable cost efficiencies, are significant growth accelerators. As businesses increasingly shift towards AI-driven solutions, Oracle’s offerings provide a compelling proposition for sustained expansion.

MongoDB’s Resilient Growth in Database Solutions

MongoDB continues to make its mark with flexible database solutions that cater to modern enterprise needs. Despite recent leadership changes, the company’s expansion to over 52,600 customers signals strong market performance and resilience. MongoDB’s focus on AI-powered applications and its initiatives to modernize legacy systems underscore its commitment to staying at the forefront of technological advancements. These factors contribute significantly to MongoDB’s potential success in an upward-trending stock market.

Market Predictions and Trends for 2025

Financial experts suggest a promising trajectory for the stock market, with predictions of the S&P 500 reaching values as high as 7,100 by 2025. This optimism is largely fueled by the Federal Reserve’s recent rate cuts and historical patterns that favor market upturns following such financial measures. With the S&P 500 anticipated to maintain its growth, stocks like Oracle and MongoDB are likely to attract investors aiming to leverage market opportunities.

Potential Challenges and Considerations

While the outlook appears bright, potential challenges should not be overlooked. Both companies must navigate the fast-paced technological landscape, addressing competitive pressures and the ever-evolving consumer demands. Additionally, macroeconomic factors and geopolitical uncertainties could pose risks to their growth trajectories.

For investors looking to capitalize on these trends, keeping a close watch on Oracle’s and MongoDB’s strategic implementations and market movements will be essential. As the financial environment continues to evolve, these tech giants are well-poised to be front-runners in the anticipated 2025 market upswing.

For further insights on market trends and investment strategies, visit the main domain sites of Oracle and MongoDB.

Article originally posted on mongodb google news. Visit mongodb google news