Or try one of the following: 詹姆斯.com, adult swim, Afterdawn, Ajaxian, Andy Budd, Ask a Ninja, AtomEnabled.org, BBC News, BBC Arabic, BBC China, BBC Russia, Brent Simmons, Channel Frederator, CNN, Digg, Diggnation, Flickr, Google News, Google Video, Harvard Law, Hebrew Language, InfoWorld, iTunes, Japanese Language, Korean Language, mir.aculo.us, Movie Trailers, Newspond, Nick Bradbury, OK/Cancel, OS News, Phil Ringnalda, Photoshop Videocast, reddit, Romanian Language, Russian Language, Ryan Parman, Traditional Chinese Language, Technorati, Tim Bray, TUAW, TVgasm, UNEASYsilence, Web 2.0 Show, Windows Vista Blog, XKCD, Yahoo! News, You Tube, Zeldman
Microsoft’s .NET 9 arrives, emphasizing performance, cloud, and AI | InfoWorld
Technology insight for the enterpriseMicrosoft’s .NET 9 arrives, emphasizing performance, cloud, and AI 12 Nov 2024, 11:09 pm
Microsoft has announced the general availability of .NET 9, a major upgrade of its open source software development platform that features scads of performance enhancements and new capabilities for building cloud-native and generative AI-enabled applications.
Released November 12, .NET 9 can be downloaded from dotnet.microsoft.com.
The new .NET release features more than 1,000 performance-related changes across the runtime, workloads, and languages, along with more efficient algorithms to generate better code, Microsoft said. The Server GC has been changed to be adaptive to application memory requirements as opposed to the resources (memory and CPU) available in the environment (machine, VM, or container). Also, the runtime returned to vectorization, adding support for Arm64 SVE and Intel AVX10 silicon and hardware-accelerating the runtime. Dynamic Profile Guided Optimization (PGO), meanwhile, has been updated to optimize more code patterns.
On the AI front, Microsoft has made it easier to integrate AI-infused controls into .NET apps by building out a smart components ecosystem. Also, in collaboration with Semantic Kernel, Microsoft has introduced a set of abstractions to the .NET ecosystem under Microsoft.Extensions.AI and Microsoft.Extensions.VectorData that provide a unified layer of C# abstractions for interacting with AI services, such as small and large language models (SLMs and LLMs), embeddings, vector stores, and middleware. Additionally, improvements have been made to libraries and primitive types to improve AI development.
For the .NET Aspire cloud stack, the release of .NET Aspire 9 brings features such as the ability to start and stop resources from the dashboard, keep containers alive between debug sessions, and access new APIs, including WaitFor
, to better manage resource startup.
Accompanying .NET 9 are new releases of the C# and F# programming languages.
For C# 13, the focus was on features to make it easier, faster, and safer for developers to write code in preferred styles. The use of the params
modifier in method signatures is boosted in C# 13 with the addition of collections expressions. Thus, developers are no longer limited to using array types with params
and can use any supported collection type. C# 13 also unlocks even more high-performance code by introducing new ways to use ref struct
values and makes it easier to work with multi-threaded applications with System.Threading.Lock
.
F# 9 offers language, library, and tool enhancements intended to make programs safer, more resilient, and performant. Nullable reference types bring type safety to interactions with C# libraries, while optimized integral ranges speed up for
loops and other comprehensions. Optimized equality checks avoid boxing and increase performance of many common operations.
The ASP.NET Core web framework in .NET 9 brings improvements to help ensure apps are secure by default. It is now easier to set up a trusted development certificate on Linux to enable HTTPS during development. The framework also features improved monitoring and tracing along with performance improvements, with higher throughput, faster startup time, and less memory usage. For static web assets, like JavaScript and CSS files, ASP.NET Core in .NET 9 now optimizes these files during build and publish for efficient deployment.
Microsoft’s Blazor web framework in .NET 9, meanwhile, features performance improvements across all areas, as well as a new solution template that makes it easier to create .NET MAUI native and Blazor web client apps that share the same UI. Further, Blazor now can detect the component render mode at runtime via the RendererInfo
API and adjust component rendering.
Also in .NET 9, Windows apps will have access to the latest OS features and capabilities while ensuring they are more performant and accessible than before. New built-in support for OpenAPI document generation is offered via the Microsoft.AspNetCore.OpenAPI package. And a new template for .NET MAUI includes 14 Syncfusion controls and other popular libraries, with practices for database access, Model-View-ViewModel, navigation, and other common app patterns.
Red Hat OpenShift AI unveils model registry, data drift detection 12 Nov 2024, 8:47 pm
Red Hat has updated Red Hat OpenShift AI, its cloud-based AI and machine learning platform, with a model registry with model versioning and tracking capabilities, data drift detection and bias detection tools, and LoRA (low-rank adaptation) fine-tuning capabilities. Stronger security also is offered, Red Hat said.
Version 2.15 of Red Hat OpenShift AI will be generally available in mid-November. Features highlighted in the release include:
- A model registry, currently in a technology preview state, that provides a structured way to share, version, deploy, and track models, metadata, and model artifacts.
- Data drift detection, to monitor changes in input data distributions for deployed ML models. This capability allows data scientists to detect when the live data used for model interference significantly deviates from the data upon which the model was trained. Drift detection helps verify model reliability.
- Bias detection tools to help data scientists and AI engineers monitor whether models are fair and unbiased. These predictive tools, from the TrustyAI open source community, also monitor models for fairness during real world deployments.
- Fine-tuning with with LoRA, to enable more efficient fine-tuning of LLMs (large language models) such as Llama 3. Organizations thus can scale AI workloads while reducing costs and resource consumption.
- Support for Nvidia NIM, a set of interface microservices to accelerate the delivery of generative AI applications.
- Support for AMD GPUs and access to an AMD ROCm workbench image for using AMD GPUs for model development.
Red Hat OpenShift AI also adds capabilities for serving generative AI models, including the vLLM serving runtime for KServe, a Kubernetes-based model inference platform. Also added is support for KServe Modelcars, which add Open Container Initiative (OCI) repositories as an option for storing and accessing model versions. Additionally, private/public route selection for endpoints in KServe enables organizations to enhance the security posture of a model by directing it specifically to internal endpoints when needed.
Red Hat OpenShift AI 2.15 also adds predictive and generative AI enhancements to data science pipelines and experiment tracking, so data scientists can more easily manage and analyze pipeline runs grouped in a logical structure. And it adds hyperparameter tuning with Ray Tune, providing advanced optimization algorithms to improve accuracy and train models more efficiently.
Go language rises in Tiobe popularity index 12 Nov 2024, 8:09 pm
The Google-built Go language has reached an all time high position in the Tiobe index of programming language popularity, ranking seventh in the November 2024 edition of the index.
While Go already had cracked Tiobe’s top 10, the language had never ranked higher than eighth. “What makes Go unique in the top 10 is that Go programs are fast and easy to deploy while the language is easy to learn,” said Paul Jansen, CEO of software quality services vendor Tiobe. Although the Python language is similarly easy to learn, it is not fast, and deployment for larger Python programs is fragile due to dependencies on all kinds of versioned libraries in the environment, Jansen said. And if compared to the Rust language, Go is a bit slower, but Go programs are much easier to understand, he added. Rust ranks 14th in this month’s index while Python is first overall.
The next hurdle for Go is to surpass JavaScript, which is currently ranked sixth. While JavaScript will be a tough language to pass, considering its ubiquity in software development, Go could do so in three years if trends continue, Jansen said.
The monthly Tiobe Progamming Community Index rates languages based on the number of skilled engineers worldwide, courses, and third-party vendors pertinent to the language. Ratings are formulated based on examinations of websites such as Google, Bing, Wikipedia, Amazon, and more than 20 others.
The Tiobe index top 10 for November:
- Python, with a rating of 22.85%
- C++, 10.64%
- Java, 9.5%
- C, 9.01%
- C#, 4.98%
- JavaScript, 3.71%
- Go, 2.35%
- Fortran, 1.97%
- Visual Basic, 1.95%
- SQL, 1.94%
The rival Pypl Popularity of Programming Language Index, which also is published monthly, bases its ratings on how often language tutorials are searched on in Google. The Pypl index top 10 for November:
Red Hat Developer Hub adds AI templates 12 Nov 2024, 3:00 pm
Red Hat Developer Hub, an enterprise-grade internal developer portal for platform engineering teams, is adding enhancements for AI, with five templates for building AI-powered applications for common use cases.
Rolled out on November 12, the AI-focused software templates are intended to address resource constraints and skills gaps facing developers working on AI priorities. The templates leverage pre-architected and supported approaches, so developers are able to build and deploy AI-enabled services or components without having to learn all the details of the technology used to implement it, Red Hat said.
The new templates support the following common AI use cases:
- Audio-to-text application: An AI-enabled audio transcription application in which users can upload an audio file to be transcribed
- Chatbot application: A chat application enabled by a large language model (LLM) that creates a bot that replies with AI-generated responses
- Code generation application: An LLM-enabled code generation application for a specialized bot to help with code-related queries
- Object detection application: Enables developers to upload an image to identify and locate objects in the image
- Retrieval-augmented generation (RAG) chatbot application: Enables developers to embed files containing relevant information to allow the model to provide more accurate responses
Red Hat said Developer Hub’s software catalog allows developers and platform engineers to record and share details of their organization’s assets, LLMs, AI servers, and associated APIs.
Snowflake bares its agentic AI plans by showcasing its Intelligence platform 12 Nov 2024, 3:00 pm
As enterprises look to automate more processes with the help of AI-based agents that don’t require human intervention, Snowflake has showcased a new offering at its ongoing developer conference, Build 2024, which it claims is its agentic AI proposition for enterprises.
Named the Snowflake Intelligence platform, the low-code offering, expected to be in private preview soon, is designed to help enterprises unlock insights from their data through the use of data agents, and to take action on these insights.
Snowflake Intelligence will allow enterprise users to create their own data agents using natural language and will address question-and-answer tasks that require structured data to begin with, according to Baris Gultekin, Head of AI at Snowflake.
“It will expand to use cases that also require the use of unstructured data currently siloed in places like Google Workspace, Confluence, Salesforce, and more. Snowflake Intelligence will also support business intelligence tasks, ranging from generating quick answers to creating interactive charts for deeper insights,” Gultekin said, adding that the goal is to start supporting use cases that leverage both structured and unstructured data.
One such example could be a user deriving insights that require using data from multiple sources such as an analytical table, a document from SharePoint, or notes from a Salesforce account.
The platform also supports API calls that can be used by enterprises to allow data agents to take actions such as making modifications to the data, Gultekin said.
Inside Snowflake Intelligence
The Snowflake Intelligence platform is a combination of multiple capabilities that Snowflake released earlier, including Cortex AI, Cortex Search, Cortex Analyst, and the Horizon Catalog.
“Snowflake Intelligence uses Snowflake Cortex AI as the generative AI engine to access industry-leading large language models and retrieval services for responses grounded in enterprise data, which include Cortex Analyst for structured data and Cortex Search for unstructured data,” Gultekin said.
Cortex is a fully managed (serverless) service inside the Data Cloud that is designed to provide enterprises with the building blocks to use LLMs and AI without requiring any expertise in managing complex GPU-based infrastructure.
Separately, Cortex Search and Cortex Analyst, introduced earlier this year, was designed to help enterprises build chatbots that could answer questions about an enterprise’s data using natural language.
Snowpark inside Snowflake handles the custom code execution, such as Python, and the external API calling.
The agents created via the Snowflake Intelligence platform are natively integrated with the Horizon Catalog, which makes the agents compatible with open table formats such as Apache Iceberg and Polaris.
Harnessing the Cortex Chat API capabilities
Snowflake’s Intelligence platform will also harness Cortex Chat API’s capabilities, according to Gultekin.
Cortex Chat API, which is expected to enter public preview soon, is aimed at helping developers connect the chat application front-end with Snowflake and ensure that answers to questions or queries from users are grounded in enterprise data.
The API, according to Gultekin, combines structured and unstructured data into a single REST API call that helps developers make use of retrieval-augmented generation (RAG), which is useful for creating AI-based applications.
Other Cortex updates, such as Cortex Knowledge Extensions, can also be made use of by the platform, the company said.
Cortex Knowledge Extensions, which will be available inside the Snowflake Marketplace and are currently in preview, are designed to provide data teams a way to enrich enterprise AI chatbots with content from third-party providers, such as research or newspaper publications.
The ability of data agents to take actions on behalf of a user makes the Snowflake Intelligence platform similar to several agentic AI offerings introduced by vendors such as Salesforce, Microsoft, Anthropic, IBM, and ServiceNow.
The platform also seems very similar to other offerings, especially in terms of how a low-code or a no-code platform is used to create the agent and later used to manage it.
Snowflake Connector for SharePoint, currently in public preview, can also be used via the Intelligence platform. The connector allows data teams to access data without the need to manually set up any pipelines, Gultekin explained.
A natural evolution
Bradley Shimmin, Omdia’s chief analyst for AI & data analytics, sees the combination of Snowlake Cortex AI and Snowflake ML as “the natural evolution” of the company’s objectives, enabling developers to deploy new agentic processes alongside more mature AI technologies to build more mature and complex applications.
“I think what we’re seeing here is Snowflake attempting to match pace with Salesforce, which rolled out a pretty mature and comprehensive agent platform, Agentforce, a month or two ago,” he said.
Shimmin expects Snowflake to focus on automating functions such as writing back generated information to the datebase, a boon for data teams struggling to keep up with business demands.
And while he he sees Snowflake and its partners creating pre-built agentic workflows for enterprises to adopt at some point in the future, “Early adopters of Snowflake Intelligence will be building out their agentic processes using Cortex AI to set these up on a case-by-case basis,” he said.
Snowflake is yet to announce the general availability of the Intelligence platform.
Why your AI models stumble before the finish line 12 Nov 2024, 10:00 am
In 2023, enterprises across industries invested heavily in generative AI proof of concepts (POCs), eager to explore the technology’s potential. Fast-forward to 2024, companies face a new challenge: moving AI initiatives from prototype to production.
According to Gartner, by 2025, at least 30% of generative AI projects will be abandoned after the POC stage. The reasons? Poor data quality, governance gaps, and the absence of clear business value. Companies are now realizing that the primary challenge isn’t simply building models — it’s ensuring the quality of the data feeding those models. As companies aim to move from prototype to production of models, they’re realizing that the biggest roadblock is curating the right data.
More data isn’t always better
In the early days of AI development, the prevailing belief was that more data leads to better results. However, as AI systems have become more sophisticated, the importance of data quality has surpassed that of quantity. There are several reasons for this shift. Firstly, large data sets are often riddled with errors, inconsistencies, and biases that can unknowingly skew model outcomes. With an excess of data, it becomes difficult to control what the model learns, potentially leading it to fixate on the training set and reducing its effectiveness with new data. Secondly, the “majority concept” within the data set tends to dominate the training process, diluting insights from minority concepts and reducing model generalization. Thirdly, processing massive data sets can slow down iteration cycles, meaning that critical decisions take longer as data quantity increases. Finally, processing large data sets can be costly, especially for smaller organizations or startups.
Organizations must strike a delicate balance between having enough data to train robust models and ensuring that it’s the right data. This means moving beyond data accumulation and focusing on data quality. By investing in practices like cleaning, validation, and enrichment, companies can ensure that their AI models are not only built on a solid foundation of high-quality data but are also well-prepared to scale and perform effectively in real-world production environments.
The price of poor data quality
A study by IBM found that poor data quality costs the United States economy around $3.1 trillion annually. Across industries, this issue is the root cause of AI initiatives stalling after proof of concept, draining resources and blocking companies from achieving full production-scale AI.
Beyond direct financial losses, failed AI projects incur significant indirect costs, including wasted time and computational resources. Most critically, these failures represent missed opportunities for a competitive advantage and can damage both internal and external reputations. Repeated failures can create a culture of risk aversion, stifling the very innovation that AI promises to deliver.
Research indicates that data scientists spend approximately 80% of their time preparing and organizing data before they can conduct any meaningful analysis.
The key characteristics of high-quality data
To overcome the root challenge of poor data quality, high-performance AI data sets must exhibit five key characteristics:
- Accuracy in reflecting real-world scenarios,
- Consistency in format and structure,
- Diversity to enhance adaptability,
- Relevance to specific objectives, and
- Ethical considerations in data collection and labeling.
To illustrate the importance of these characteristics, consider an example from Automotus, a company that automates payments for vehicle unloading and parking. The company faced challenges with poor data quality, including duplicate and corrupt images, which hindered their ability to convert vast amounts of image data into labeled training data sets for their AI models. To address these issues, the company used data quality tools to efficiently curate and reduce their data set by removing the bad examples—achieving a 20% improvement in mean average precision (mAP) for their object detection models. While the data reduction enhanced model accuracy, it further led to a 33% reduction in labeling costs, demonstrating that investing in data quality can yield both performance improvements and economic benefits.
How to achieve high-quality data
To navigate the challenges of AI development, organizations should take the following concrete steps to enhance their data practices:
- Establish clear data governance policies: Organizations should create comprehensive data governance policies that outline roles, responsibilities, and standards for data management. These guidelines ensure uniform data quality throughout the organization, reducing the risk of poor data impacting decision-making.
- Implement rigorous data cleaning techniques: Employ techniques such as outlier detection, imputation for missing values, and normalization to maintain the integrity of data sets. These practices help ensure that the data used for AI models is accurate and reliable.
- Invest in accurate labeling processes: High-quality labels are essential for model precision. Automated data labeling can offer significant advantages over manual labeling by reducing costs and streamlining the process. However, a hybrid approach that combines automated tools with human oversight can enhance accuracy by leveraging the strengths of both methods.
- Source data from diverse and reliable sources: Companies should seek diverse data sources to reduce bias and improve model performance. Examples include public data sets, industry-specific databases, and third-party data providers. Ensuring these sources are credible is crucial for maintaining data quality.
- Leverage advanced data management tools: To ensure ongoing AI performance, leverage advanced data management tools to continuously curate and update training data sets. Data distributions can change over time in production environments, and these tools can help companies adapt data sets accordingly.
Elevate data quality to scale AI
The demand for high-quality data will only grow as AI adoption increases. Gartner predicts that by 2025, enterprises will process 75% of their data outside traditional data centers or the cloud, highlighting the need for new strategies to maintain data quality in distributed environments. To confront these obstacles, key innovations are emerging in the field of data quality, including automated data checks, machine learning for data cleaning, privacy-preserving methods for training models on distributed data, and the generation of synthetic data to enhance real data sets.
These advancements are making it possible — and easy — for every company to create a data-centric culture. By prioritizing data quality, companies aren’t merely avoiding pitfalls, but unlocking AI’s full potential and setting new industry standards. It’s time to rally around the power of quality data — not just for competitive advantage, but to elevate the entire AI ecosystem. As AI continues to mature, the question isn’t “Do we have enough data?” Instead, it’s time to ask, “Do we have the right data to power the AI solutions of tomorrow?”
Ulrik Stig Hansen is co-founder and president of Encord, an AI data development platform built to help companies manage and prepare their data for AI.
—
Generative AI Insights provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss the challenges and opportunities of generative artificial intelligence. The selection is wide-ranging, from technology deep dives to case studies to expert opinion, but also subjective, based on our judgment of which topics and treatments will best serve InfoWorld’s technically sophisticated audience. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Contact doug_dineley@foundryco.com.
Can Wasm replace containers? 11 Nov 2024, 10:00 am
Heralded as the fourth standard of the web, WebAssembly, or Wasm for short, has sparked heated discussion since its origins. Wasm is an assembly-like programming language, a compact binary format, and a compilation target for C, C++, C#, Go, JavaScript, Python, Rust, and others that runs at near-native speeds in a web browser. It is well-established in web development and has been inching closer to mass use outside the browser.
Wasm’s compactness, speed, portability, and security have developers excited about its possibilities on servers as well as clients, and even its potential to supplant Linux containers. But will this technology become a mainstream platform that disrupts today’s established container ecosystem?
People close to the Wasm vs. containers discussion are probably sick of seeing this 2019 tweet from Solomon Hykes, co-founder of Docker and co-founder of Dagger, replastered on every sensationalist Wasm article and presentation slide:
If WASM+WASI existed in 2008, we wouldn’t have needed to have created Docker. That’s how important it is. WebAssembly on the server is the future of computing.
The devil is in the details. What Hykes meant to say was that if Wasm had existed back then, the need for containers like Docker wouldn’t have been as acute. Yet, that did not happen, and we live in a universe where Docker containers reign. Replacing mission-critical Linux-based containers is not a trivial act. As Hykes explains:
That tweet of mine was widely misunderstood. It was interpreted as WebAssembly is going to replace Docker containers. I did not think then that it would happen, and lo and behold, it did not happen, and in my opinion, will never happen. Now that Docker exists and is a standard, WebAssembly and WASI, as cool as they are, are very different. It’s not at all a replacement. It has a very different shape.
Most agree that WebAssembly beats containers in the browser, edge computing use cases, sandboxed plugins, and certain serverless functions. While some are more confident about the transformative potential Wasm will have, outlooks are split on Wasm as a long-term replacement for server-side containers or stateful, long-running server processes. Below, we’ll dive deeper to compare where exactly Wasm beats containers, and where it doesn’t.
Where Wasm beats containers
Some developers see Wasm getting extensive use across applications, especially where containers are too clunky. “Wasm is just as adept in embedded IoT as it is in massive cloud infrastructure,” says Matt Butcher, co-founder and CEO of Fermyon. “Wasm is an excellent technology for serverless functions, IoT, edge computing, and plugin-style extension mechanisms,” he says.
On the edge
One area where Wasm shines is edge computing. Here, Wasm’s lightweight, sandboxed nature makes it especially intriguing. “We need software isolation on the edge, but containers consume too many resources,” says Michael J. Yuan, founder of Second State and the Cloud Native Computing Foundation’s WasmEdge project. “Wasm can be used to isolate and manage software where containers are ‘too heavy.’”
Whereas containers take up megabytes or gigabytes, Wasm modules take mere kilobytes or megabytes. Compared to containers, a .wasm file is smaller and agnostic to the runtime, notes Bailey Hayes, CTO of Cosmonic. “Wasm’s portability allows workloads to run across heterogeneous environments, such as cloud, edge, or even resource-constrained devices.”
This makes Wasm suitable for constrained use cases like small, embedded devices. One particular scenario is manufacturing IoT — for instance, MachineMetrics is deploying wasmCloud on the factory floor to process machine data more securely and efficiently.
Performance-critical workloads
Wasm has a clear role in performance-critical workloads, including serverless functions and certain AI applications. “There are definitive applications where Wasm will be the first choice or be chosen over containers,” says Luke Wagner, distinguished engineer at Fastly, who notes that Wasm brings cost-savings and cold-start improvements to serverless-style workloads. “Wasm will be attractive for enterprises that don’t want to be locked into the current set of proprietary serverless offerings.”
In the AI space, Wasm is ideal for cross-platform inference on heterogeneous devices. Containers are very heavy and not portable across GPUs, says Yuan, making them unfit for applications like LlamaEdge, a Wasm-based local runtime and API server for large language models (LLMs).
Component-based architectures
Some look to the WebAssembly System Interface (WASI), a proposed specification from the ByteCode Alliance, as the foundation for an ecosystem of modular components. “We’ll see new types of architectures evolve that capitalize on the size and speed of Wasm components,” says Cosmonic’s Hayes. She points to Wasm’s small footprint, its runtime agnosticism, and its fast cold starts, which significantly reduce latency compared with containers.
Add to that Wasm’s secure-by-default settings, and it has a big leg up on containers. “Containers are generally not considered the right choice for safe sandboxing and isolation of arbitrary user code,” says Hayes.
“We do expect many workloads to be migrated from containers to Wasm,” says Fastly’s Wagner. This is especially true for greenfield workloads, some of which we are already seeing today. “Based on the current standardization efforts around the WebAssembly Component Model, enterprises will choose Wasm as a way to modularize their services while avoiding the overhead of a traditional microservice architecture,” he says.
If, as some advocate, component-based architecture becomes a dominant development paradigm, containers might play less of a role. “Wasm’s big promise is a new way of building applications by assembly components that are each isolated in their own sandbox,” says Fermyon’s Butcher. “As this technology matures, Wasm may not replace containers feature for feature, but there’s certainly potential for Wasm to supersede containers simply because containers won’t add value to component-based applications.”
Plugins for server-side apps
Plugins for existing systems are another strong Wasm use case, Yuan says. Hykes also sees Wasm as being great for highly sandboxed plugins for server-side applications. In fact, developers of plugin frameworks like Istio WasmPlugins, Shopify Functions, and Envoy extensions have already opted for Wasm. And a handful of frameworks on the market make it easy to generate and run such plugins.
Web apps and services
Of course, browser-based web applications are Wasm’s bread and butter. And it’s an area that containers don’t really touch. Wasm on the browser is well-established and well-supported, meaning the barrier to entry is much lower. As such, Wasm already powers countless high-performance web apps.
For example, Adobe actively integrates Wasm into web-based versions of Photoshop, Express, Lightroom, Acrobat, and other applications. “Wasm is designed around running short-lived programs very quickly, efficiently, and securely,” says Colin Murphy, senior software engineer at Adobe. “As it matures, it will continue to grow its applicability in other areas of computing, such as web services.”
“Wasm on the browser is finally making real headway,” says Hykes. “I think that’ll go mainstream finally.” He notes how Dagger’s back-end engineers are writing front-end code in Go and compiling it to Wasm. “Back-end engineers are disempowered in general since they can’t do front-end development. This is a way to empower them.”
Where containers beat Wasm
All that said, there are places where containers will continue to rule. “Stateful, long-running compute and appliances like databases are unlikely to be replaced with Wasm,” says Cosmonic’s Hayes.
Similar to how containers did not entirely replace virtual machines, the evolution toward Wasm will not be complete. “To jump to the conclusion that WebAssembly will unseat containers is equally as reductive,” says Butcher. This means we’ll likely see Wasm apps running alongside the thousands of apps already running in containers on Kubernetes.
Large-scale server processes
“Wasm is not great for long-running server processes,” Butcher says. “The sweet spot for containers is packaging and executing existing long-running servers (like Postgres or WordPress or your company’s enterprise Java app). I don’t foresee Wasm challenging that space in the next decade.” He credits this to a lack of threads, weak socket support, and the fact that many of the supported languages are not optimized for Wasm.
Wasm can’t easily replace containerized workloads that rely on features of a particular OS or CPU that are not yet supported by Wasm, notes Fastly’s Wagner. The same goes if the workload uses a language that doesn’t have full Wasm support. However, Wagner believes these concerns will dissolve as the Wasm ecosystem matures.
Others aren’t so sure. “Wasm’s security model doesn’t grant access to many of the low-level operating system primitives that server applications access and there’s no reason to expect this to change,” says Butcher. “The vast majority of large code bases can’t simply be compiled to WebAssembly. Code must be rewritten. While some would claim that this is a temporary situation, I don’t think it is.”
Even Cloudflare, a poster child for the next generation of cloud platforms that seemed to replace containers, uses containers at the core of its Workers platform. “If you’ve used AI inference on GPUs with Workers AI, spun up headless browsers with Browser Rendering, or enqueued build jobs with the new Workers Builds, you’ve run containers on our network, without even knowing it,” says the Cloudflare blog.
The takeaway is that containers complement and coexist with other development approaches. And most likely they will continue to do so.
Linux-based cloud-native systems
Linux has proliferated, and containers are intrinsic to this operating system, making them challenging if not impossible to displace. “If you’re talking about replacing containers, you have to talk about replacing Linux,” says Hykes.
“Containers are now a core feature of Linux. Not just the kernel, but the operating system layer, the standard stack around it, and the standard way you run Linux in the data center in the cloud,” Hykes notes. “They will always be there. The only question is, ‘Do you add a layer on top?’”
While containers could certainly host Wasm components, it’s hard to envision Wasm becoming a general-purpose, server-dominating platform the way Linux is today. “At the moment, I don’t see that happening because there’s no obvious reason to switch to this new platform en masse,” says Hykes.
Others agree that a wholesale replacement of today’s current container stack isn’t worthwhile. “I think in most of today’s cloud-native applications, Linux containers are the right tools, and they should not be replaced,” says Second State’s Yuan. “Wasm is for new use cases where isolation is needed, but containers cannot go.”
Other situations where execution time must be minimized make Wasm a nonstarter. “There will also usually be a modest runtime overhead executing Wasm versus native code, and for some workloads, any overhead at all may be unacceptable,” says Fastly’s Wagner. “In those instances, Wasm will not replace containers.”
Wasm and containers
Kubernetes seems inextricably intertwined with the future of cloud infrastructure. While some have predicted that Wasm could replace container-based runtimes by 2030, many disagree. Instead of Wasm replacing the current container paradigm, they see it becoming embedded into this fabric.
Yuan is reluctant to say that Wasm will replace containers — rather, he views them as complementary technologies. To his point, the Bytecode Alliance and CNCF are making strides to ensure that Wasm complements Kubernetes, such as by developing projects that allow containers and Wasm modules to be run side by side in the same cluster.
Others see a future in which Docker runs Linux containers, Windows containers, and Wasm containers side by side. Hykes believes this is a feasible model yet admits demand is low. This is in part because adoption of WebAssembly on the server has not been widespread, says Hykes. It remains a niche use case.
“In order for it to blow up, it’s missing a mainstream use case, a reason everyone must use it on the server, and a way to easily use it,” Hykes says. “It’s really hard to get people to adopt a new platform. You better have a use case.”
Outlooks for Wasm
In the long term, entirely new markets and computing paradigms will likely be made possible with Wasm. “Many of the silos between data center, edge compute, mobile, and IoT will be broken down because of the breakthrough in portability and composability that WASI enables,” says Adobe’s Murphy.
In addition to the applications mentioned above, Wasm spans sectors, too. “We’re seeing wasmCloud being adopted in a wide variety of use cases in banking, manufacturing, telecommunications, digital services, gaming, and more,” says Cosmonic’s Hayes. For instance, TM Forum’s WebAssembly Canvas Catalyst team has demonstrated a proof of concept for replacing Kubernetes using wasmCloud to manage its open APIs.
Refactoring would take work, but it would unlock efficiency gains that the container-era did not require for entry. “Docker and Kubernetes were innovative in so many ways, and if you refactor your applications to take advantage of them, then they are amazing,” says Murphy. “In most cases, however, applications were simply containerized with minimal refactoring.” This typically equates to slow start times and high memory requirements.
So, what will the future bring? Expect smaller and faster Wasm to elbow out containers for an increasing number of greenfield applications. But replacing the existing container ecosystem wholesale? That seems far-fetched. Both Wasm and containers promise to play prominent roles in cloud and enterprise computing for years to come.
Is your software architecture as clean as your code? 11 Nov 2024, 10:00 am
Modern software must function smoothly within a diverse ecosystem, from on-premises monoliths to ever-evolving cloud-based microservices. Architectural choices made during software development, be they explicit or implicit, add complexity and create interdependencies, often leading to an increased risk of outages, incidents, and security issues as well as the accumulation of technical debt that impact the overall performance of the application.
How can you assess whether your software architecture holds up to scrutiny? Modern tools and practices allow organizations to go beyond code quality checks and implement principles that promote the health, stability, and scalability of their software architecture. This article explores why clean architecture is essential for supporting the growth, flexibility, and reliability of your software and provides practical steps for maintaining a healthy system architecture.
The principles of a clean software architecture
All systems are divided into independent modules, each responsible for specific tasks. The way in which these components are defined and how they interact with each other is the key factor in deciding the interdependencies of the system and therefore its complexity. The following principles of clean software architecture serve as the backbone of a well-structured system and promote flexibility while minimizing complexity:
Vertical separation
- Separate business use cases into modules.
- Ensure each module has its own persistence layer to save and retrieve data.
- Minimize cross-module communication.
Vertical separation makes it easier to maintain and update individual modules based on a business case without affecting the whole system.
Horizontal separation
- Communication should travel downwards (i.e., outbound → business logic layer → infrastructure), not upwards or sideways.
- Separate infrastructure from the business logic layer, the brain of the application that contains a complex set of rules, computations, and decision-making processes that define the software’s core functionality.
- Separate core business logic layer modules from outbound modules, interfacing with external users or systems.
Horizontal separation allows the creation of core modules that handle the most critical business logic while keeping them stable, reusable, and independent of external systems. In contrast to core modules, outward-facing modules handle interactions with external users or systems and rely on core services for their functionality but are less stable and more flexible by design.
Qualification
A module should be dedicated to a single purpose but not every purpose warrants a separate module. A well-defined task could potentially require a separate module but it must be qualified as such. Key qualifiers are business role, reuse, and scale.
- Business: The task comprises a clear and distinct business scenario.
- Reuse: The task is used in multiple different scenarios.
- Scale. The task comprises its own unit of scale.
Note that dedication can go too far. Over-dedication leads to an excessive number of modules, increasing complexity on multiple levels (management, development, network, maintenance, etc.).
The principles of vertical separation, horizontal separation, and qualification enable developers to meet current requirements, adapt to future needs, and minimize complexity and technical debt. By ensuring modularity and minimizing dependencies, you ensure that modules can be developed, maintained, and scaled independently, improving system reliability without adding complexity.
The benefits of a clean software architecture
Clean architecture practices ensure that your software remains efficient, resilient, and scalable. Neglecting these principles can lead to mounting architectural technical debt, potentially costing organizations a significant loss in revenue. This financial impact stems from several factors including decreased system resiliency causing more frequent outages, missed market opportunities due to delayed launches and performance issues, customer churn as competitors offer more reliable solutions, and increased infrastructure costs to manage scalability problems.
Clean architecture offers several key benefits that significantly enhance software development and maintenance.
- Improved system quality: Clean architecture results in a more maintainable and scalable system that adapts to changing requirements with minimal disruption.
- Reduced technical debt: Thoughtful architectural decisions minimize debt, making future changes easier and less costly.
- Enhanced developer productivity: A well-structured architecture makes it easier for developers to understand, modify, and extend the system, increasing productivity and reducing onboarding time for new team members.
How organizations can promote clean architecture
While having comprehensive guidelines to define the essential attributes of your architecture is important, relying on architecture quality gates often proves ineffective. Without robust tools and a deep understanding of architectural nuances, gaps in enforcement will leave your system vulnerable to design flaws. Instead of relying on these traditional checkpoints, organizations should adopt proactive strategies that address architectural challenges throughout the development process, ensuring a more resilient and maintainable architecture.
To promote a well-understood architecture, consider the following practices.
Establish processes to measure, prioritize, and remediate technical debt.
- Measure: Leadership should regularly assess technical debt to understand its impact before it becomes critical.
- Prioritize: Application owners should allocate resources to address the most pressing issues, aligning remediation with business needs.
- Remediate: The development team should continuously address technical debt as part of the software development life cycle to ensure long-term architectural health.
Use AI-driven architectural observability and governance tools.
Architectural observability provides real-time insights into whether your architecture supports or obstructs your product strategy. These tools allow organizations to enforce good design principles by detecting issues in the architecture, suggesting improvements, and tracking the impact of changes over time. By detecting issues early, organizations can make data-driven decisions to mitigate risks and improve system resilience.
Provide training and resources for engineering teams.
Offer ongoing education to ensure teams understand and apply architectural principles in their daily work. This empowers them to make informed decisions, promoting continuous improvement.
A clean software architecture is essential for building robust systems that ensure application scalability, resiliency, and engineering velocity. Taking a top-down approach to technical debt remediation and performing regular evaluations in the development process allows organizations to find and fix the root causes of architectural issues, cut down technical debt, and nurture a culture of excellence in architecture. By focusing on proactive measures and continuous improvement, organizations can keep their software architecture in optimal condition—prepared to tackle both current and future challenges.
Ori Saporta is vice president of engineering and co-founder at vFunction.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
Breaking down digital silos 11 Nov 2024, 10:00 am
To absolutely no one’s surprise, a new Gartner survey of more than 3,100 CIOs and technology executives found that 52% of digital initiatives fail. If anything, the surprise is that the number isn’t higher. Way back in 2014, I was writing about how and why big data projects fail. “Most companies simply don’t know what they’re doing when it comes to big data,” I said.
Today, it’s largely the same, though Gartner points to a common characteristic of enterprises that succeed with digital transformation: They don’t treat it as an isolated IT project. For the so-called “digital vanguard” whose initiatives succeed 71% of the time, Gartner VP Raf Gelders argues, “CIOs and CxOs are equally responsible [for digital delivery], accountable and involved in delivering the digital solutions their enterprises need.”
Not just the tech folks, in other words. Business and tech people working together. I’ve seen this principle play out firsthand in my own work.
Shared goals, shared success
I run developer relations for MongoDB. My team is filled with engineers who write code and eschew marketing. Yet my team sits within the marketing org. Different companies do this differently, with some developer relations teams housed within the product or engineering groups (as we used to be at MongoDB). But in my experience, developer relations fits better within marketing precisely because few (if any) within my team would consider themselves marketers. For a company that focuses on serving developers, the last thing we want is traditional marketing. Instead, we want “marketing” to look like deep technical workshops, how-to tutorials, etc.
None of this works without being joined at the hip with more traditional marketing functions. My team knows, for example, that all their work has to support larger business goals. At the same time, these other teams (strategic marketing, field marketing, digital and growth, etc.) also know that they can count on us to support them and help inform the work they do.
This confluence of different functions isn’t a bug, it’s a feature, and it’s something that needs to happen well beyond my developer relations team and marketing. The best companies, whatever their industry, marry technology with business functions. According to Gartner VP Daniel Sanchez-Reina, “To become a digital vanguard, CIOs … need to prioritize four areas: making digital platforms easy for the workforce to build digital solutions, teaching them the interdependencies between technology and business, helping business leaders become innovation leaders at digital, and expanding digital skills beyond the IT department.” Technology, in other words, isn’t meant to sit in a silo. It needs to be central to how all areas of the business operate.
CIOs and CxOs together
As Sanchez-Reina put it, “CIOs need their CxOs to work together and co-lead with them. So their fortunes are intertwined; one cannot succeed without the other.” As an industry, we’ve talked about this for a long time, but it’s easy to say and hard to pull off. In my own experience, the key to making it work is shared goals.
In any organization, people spend their time on the things that get them the most recognition, the highest chance of a positive employee rating (for promotions or bonuses, for example). The way to turn this to the company’s advantage is to align goals between complementary teams. In the case of digital initiatives, such as generative AI and cloud computing, IT and other technical teams must be aligned at the goals level with other teams (marketing, sales, product, etc.) to ensure success. Otherwise, you’re at risk of being one more company confessing to failed digital projects.
The rise of specialized private clouds 11 Nov 2024, 10:00 am
I have always been suspicious of the “private cloud.” I get why the National Institute of Standards and Technology (NIST) included the term in the description of cloud computing almost 17 years ago. However, the term was quickly interpreted as a way to bundle aging on-prem server offerings to be sold as a “cloud.”
The early private clouds were nothing like a cloud. They could not scale on demand or automatically, and self-provisioning was impossible. Clearly, this was “marketecture” and most enterprises avoided it. Of course, there were other private clouds to be had, such as open source OpenStack, which is still around today. OpenStack is much better than when I first experienced it, when it was more like an engineering project than an installation.
New opportunity for private clouds
Private clouds are transforming significantly from general-purpose solutions to specialized implementations, particularly for AI. This evolution is driven by soaring investments in artificial intelligence, prompting organizations to seek dedicated infrastructures that provide a prepackaged AI ecosystem and run in their data center.
Specialized private clouds have evolved far beyond AI-focused implementations, addressing diverse enterprise needs across multiple sectors:
- High-performance computing (HPC) clouds support intensive computational tasks.
- Developer clouds streamline software development with integrated CI/CD tools.
- Database clouds optimize data management workloads.
- Disaster recovery clouds ensure business continuity.
- Edge clouds handle IoT and real-time processing needs.
- Compliance and security clouds address specific regulatory requirements.
Private clouds also focus on specific industries. The financial services sector benefits from clouds designed for high-speed transactions and regulatory compliance, while multimedia clouds optimize content delivery and streaming services. These specialized environments offer unique advantages for their target applications, providing purpose-built infrastructure, optimized performance, and industry-specific features. However, like AI private clouds, they often face similar challenges regarding flexibility, cost, and the risk of technology stagnation, making it crucial for organizations to carefully evaluate their specific needs before committing to any specialized private cloud solution.
Back to AI private clouds. Most enterprises do not know how to knit together their own technology bundle to make an AI or machine learning solution. An AI private cloud offers everything prepacked and preconfigured with the necessary development tools, designed to optimize GPU clusters and equipped with MLOps pipelines that streamline processes. However, instead of consuming this as a set of public cloud services, a bunch of boxes shows up on your loading dock that you install in your data center racks. At first glance, they offer a perfect solution for enterprises eager to dive deep into AI initiatives. However, this promising framework comes with its own set of challenges.
A careful look at the trade-offs
On one hand, these specialized clouds excel in providing purpose-built capabilities for AI and machine learning, enhancing data sovereignty and security. Reduced latency can also be a significant advantage for specific applications, allowing organizations to capitalize on real-time data processing.
Yet, the static nature of these setups presents a considerable drawback. Many private AI clouds limit technological flexibility and may require substantial investments with little room for adaptation as enterprise needs evolve. Organizations could find themselves locked into vendor solutions that might not support newer AI frameworks or tools, stifling innovation and growth.
The cost implications of moving to a private AI cloud represent another critical consideration. Public cloud providers typically operate on a pay-as-you-go model, but private AI clouds necessitate hefty up-front investments that can escalate into the millions. Hardware infrastructure can range from two to ten million dollars, and software licenses often require an annual expenditure of $500,000 to two million. Additionally, there’s operational overhead—staffing, utilities, and maintenance.
In contrast, public cloud providers eliminate the substantial upfront infrastructure investments and provide flexibility in scaling resources according to demand. The quick adaptability of public cloud environments to new technologies and pricing structures represents a significant advantage for many organizations.
This becomes an even more complex decision when you consider that over a five-year horizon, private clouds often offer an operational cost advantage over public clouds. However, you need to consider the all-in costs, including the people who maintain these systems, the cost of power, etc. These are often overlooked when making a TCO comparison between public and private cloud options.
What’s your five-year plan?
Let’s raise an essential question regarding strategic planning. As organizations are drawn to the promise of specialized private clouds, it’s vital to carefully assess performance needs, data governance requirements, and the long-term trajectory of their AI projects. The allure of enhanced control entices many organizations, yet they risk investing in static technologies that may become obsolete in the face of rapid AI advancements.
A hybrid approach is often the most practical solution. Companies may benefit from specialized private clouds for consistent workloads that demand strong data governance while also using public clouds for experimentation and overflow capacity. By the way, that is more challenging than it sounds.
Ultimately, specialized private clouds, especially those focused on AI, are increasingly indispensable in certain contexts. They are better than the private clouds of the past, which were more like scams than legit solutions. However, organizations must weigh the advantages against the drawbacks, particularly the potential limitations and costs associated with static technology infrastructures.
Here’s some general advice. If you plan on changing a lot during the next five years and your existing requirements are not at all settled, public cloud providers are likely the best solution for things like AI development, deployment, and operations. If you’re unlikely to have a lot of change within the next five years, private cloud options, such as for AI, are genuinely cost-effective, assuming that your requirements lead you there. This is another one of those “it depends” situations.
The bottom line is clear: Although specialized AI clouds have a significant role, organizations must be flexible. Starting small in public cloud environments and gradually scaling up only when there is a stable understanding of workload patterns, can mitigate risks. It’s crucial to maintain adaptability since the fast-paced nature of AI means that today’s perfect cloud solution could become inadequate tomorrow. Choose wisely and remember that ongoing change is the only constant in the digital landscape.
Serverless computing’s second act 8 Nov 2024, 10:00 am
Serverless computing has had a tumultuous journey characterized by early excitement, skepticism, and challenges that some—including yours truly—believed might spell its end. However, this technology is now experiencing somewhat of a resurgence, or perhaps it is more of a forced renaissance. In other words, change or die. Perhaps it can accomplish both.
Let’s back up a bit. In the initial stages, serverless computing was embraced for its promise to revolutionize cloud application development. It allowed developers to focus on writing code without the concern of managing or provisioning servers. This streamlined operations and reduced costs.
Rocky road
Despite the enthusiasm, several challenges emerged. Among these were unpredictable pricing models, latency issues referred to as “cold starts,” and limited control over the underlying infrastructure. These challenges led to skepticism about the practicality of serverless in production environments.
Despite these issues, the hype train was at full speed. For example, a large provider took issue with me pointing out some of the shortcomings of this “new” serverless technology. Instead of addressing the problems, they called for my immediate firing due to blasphemous comments. I hit a nerve. Why was that? The cloud providers promoting serverless should have had more confidence in their technology. They knew the challenges. I was right about serverless then, right when I wrote about its decline. However, I’m always willing to reevaluate my position as technology evolves. I believe in redemption.
A technological comeback
Despite its early hurdles, serverless computing has bounced back, driven by a confluence of evolving developer needs and technological advancements. Major cloud providers such as AWS, Microsoft Azure, and Google Cloud have poured substantial resources into serverless technologies to provide enhancements that address earlier criticisms.
For instance, improvements in debugging tools, better handling of cold starts, and new monitoring capabilities are now part of the serverless ecosystem. Additionally, integrating artificial intelligence and machine learning promises to expand the possibilities of serverless applications, making them seem more innovative and responsive.
The serverless market is projected to grow from $7.6 billion in 2020 to $21.1 billion by 2025 at a compound annual growth rate of 22.7% Companies are leveraging its architecture for more efficient and scalable applications. Case in point: Coca-Cola reportedly achieved a 65% reduction in operational costs by migrating to AWS Lambda. Netflix has cited improved scalability and reduced complexity by adopting serverless for back-end processes.
In this renaissance period, serverless computing aligns better with modern application development practices emphasizing rapid iteration and scalability. This alignment may reinforce its adoption across industries, reshaping how developers approach building applications. Some are calling it a “new era for cloud computing.” Maybe.
Too little, too late?
One crucial question remains: Is this resurgence enough to secure the future of serverless computing, or is it simply an attempt by cloud providers to recoup their significant investments? At issue is the number of enterprises that have invested in serverless application development. As you know, this investment goes beyond just paying for the serverless technology. Localizing your applications using this tech and moving to other platforms is costly.
A temporary fix might not suffice in the long run. While the current trends and forecasts are promising, the final verdict will largely depend on how serverless can overcome past weaknesses and adapt to emerging technological landscapes and enterprise needs. A forced renaissance might be a strategic maneuver to reinvigorate serverless, but whether it will lead to enduring success or merely be a fleeting revival remains to be seen.
What should you do?
If you are already leveraging serverless on any public cloud, you’ll find that changing directions now is risky and costly, and I don’t recommend you do it just yet. However, I would not use serverless for any net-new development projects due to the risk I’ve seen.
I do suspect that serverless will get better—it has to if the public cloud providers want to avoid a very public meltdown as enterprises hit that “serverless wall” as I’ve seen so many times. Public cloud providers are good at controlling the narrative around specific technologies. Although they have not been able to intimidate me—yet—they have billions of marketing dollars to tell the market what to think about their technology, including serverless. Pundits like me don’t have access to those kinds of resources.
So, if you’re already running serverless, I suggest you continue and provide alternatives. But for now, and attempting to be fair to the serverless technology providers, it may be best to avoid the new stuff. Let’s see if this gets me canceled.
Java proposals would boost resistance to quantum computing attacks 8 Nov 2024, 10:00 am
Java application security would be enhanced through two proposals aimed at resisting quantum computing attacks, one plan involving digital signatures and the other key encapsulation.
The two proposals reside in the OpenJDK JEP (JDK Enhancement Proposal) index. The Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm proposal calls for enhancing the security of Java applications by providing an implementation of the quantum-resistant module-latticed-based digital signature algorithm (ML-DSA). ML-DSA would secure against future quantum computing attacks by using digital signatures to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA was standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 204.
The Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism proposal calls for enhancing application security by providing an implementation of the quantum-resistant module-lattice-based key encapsulation mechanism (ML-KEM). KEMs are used to secure symmetric keys over insecure communication channels using public key cryptography. ML-KEM is designed to be secure against future quantum computing attacks and was standardized by NIST in FIPS 203.
Both proposals warn of the threat posed to information security by advancements in the field of quantum computing. A future large-scale quantum computer could use Shor’s algorithm to compromise the security of widely deployed public-key-based algorithms. Such algorithms are used by the Java platform for activities such as digitally signing JAR (Java archive) files and establishing secure network connections. An attack could be accomplished by a quantum computer using Shor’s algorithm in hours. Cryptographers have responded to this threat by inventing quantum-resistant algorithms that cannot be defeated by Shor’s algorithm. Switching to quantum-resistant algorithms is urgent, even if large-scale quantum computers do not yet exist.
Each of the two proposals is eyed for the Standard Edition of Java, but neither is targeted for a specific version at this point. Both proposals were created August 26 and updated November 6.
AI accelerating API development, IBM says 7 Nov 2024, 9:33 pm
IBM sees a confluence of generative artificial intelligence and APIs, with AI powering APIs in a way that improves the productivity of API teams.
AI is augmenting skills that API teams may just be starting to learn, said Rashmi Kaushik, director of product management for the integration portfolio at IBM, during a presentation at the API World conference in Santa Clara, California, on November 6. “It’s able to help them complete their API projects faster.” Also, APIs are powering AI, she added. APIs empowering AI and the rise of AI assistance are truly beneficial to API teams, Kaushik said.
Companies such as IBM have released API testing capabilities on traditional AI. But AI is not magic. It has been a technology in the making for many years now and it is here to transform the way business is done, Kaushik said. Regardless of how much AI is leveraged, users want to make sure that it is safe, responsible, and ethical, she said.
IBM offers the API Assistant for IBM API Connect, powered by the watsonx.ai integrated AI platform. It uses generative AI to help API teams accelerate API life-cycle activities for a quicker time to market, the company said. IBM API Assistant automates tasks, enabling teams to focus on higher-value work and innovation, according to IBM. API assistants are able to augment API teams, so they progress faster, Kaushik said.
JDK 24: The new features in Java 24 7 Nov 2024, 10:00 am
In the wake of Java Development Kit (JDK) 23, which arrived September 17, work continues on the planned successor release, JDK 24, which now has reached 17 proposed features. The latest five features include removing the 32-bit x86 port, synchronizing virtual threads without pinning, simple source files and instance main methods, permanently disabling the security manager, and module import declarations.
The previously proposed features include an experimental version of compact headers; primitive types in patterns, instanceof
, and switch
; linking runtime images without JMODs; the generational Shenandoah garbage collector; scoped values; a key derivation function API; removal of the non-generational mode in the Z Garbage Collector; stream gatherers; a vector API; a class-file API; warnings to prepare developers for future restrictions on the use of JNI (Java Native Interface); and a late barrier expansion for the G1 garbage collector.
Due March 18, 2025, JDK 24 has been designated a non-long-term support (LTS) release. Like JDK 23, JDK 24 will receive only six months of Premier-level support from Oracle. Early access builds of JDK 24 can be found at jdk.java.net.
The Windows 32-bit x86 port was deprecated for removal in JDK 21 with the intent to remove it in a future release. Plans call for eventually removing the source code and build support for the Windows 32-bit x86 port. JDK 24 would update the build system to issue an error message when an attempt is made to configure a build for Windows 32-bit x86 (x86-32). The error message will be suppressible through a new configuration option. The port and related port-specific features will be marked as deprecated for removal in the relevant documentation.
Synchronizing virtual threads without pinning involves improving the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform for use by other threads. This would eliminate almost all cases of virtual threads being pinned to platform threads, which severely restricts the number of virtual threads available to handle an application workload.
A fourth preview of simple source files and instance main methods would evolve the Java language so beginners can write their first programs without needing to understand language features designed for large programs. The feature was previously previewed in JDK 21, JDK 22, and JDK 23. New terminology and a revised title would be featured but the feature is otherwise unchanged. It previously was called implicitly declared classes and instance main methods.
Permanently disabling the security manager involves revising the Java platform specification so developers cannot enable the security manager, while other platform classes do not refer to it. The security manager has not been the primary means of securing client-side Java code for many years, has rarely been used to secure server-side code, and has been costly to maintain, the proposal states. The security manager was deprecated for removal in Java 17.
Compact object headers would reduce the size of object headers in the HotSpot VM from between 96 and 128 bits down to 64 bits on 64-bit architectures. The goal of the proposed feature is to reduce heap size, improve deployment density, and increase data locality.
Module import declarations, previously previewed in JDK 23, enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries but does not require the importing of code to be a module itself.
Compact object headers would reduce the size of object headers in the HotSpot VM from between 96 and 128 bits down to 64 bits on 64-bit architectures. The goal of the proposed feature is to reduce heap size, improve deployment density, and increase data locality.
A second preview of primitive types in patterns, instanceof, and switch in JDK 24 would enhance pattern matching by allowing primitive types in all patterns and contexts. The feature also would extend instanceof and switch to work with all primitive types. The feature’s goals include enabling uniform data exploration by allowing type patterns for all types, whether primitive or reference; aligning types with instanceof and aligning instanceof with safe casting; and allowing pattern matching to use primitive types in both nested and top-level pattern contexts. This feature was previously previewed in JDK 23.
Other goals include providing easy-to-use constructs that eliminate the risk of losing information due to unsafe casts, following the enhancements to switch in Java 5 and Java 7, and allowing switch to process values of any primitive type.
With linking runtime images without JMODs, the plan is to reduce the size of the JDK by roughly 25% by enabling the jlink tool to create custom runtime images without JDK JMOD files. This feature must be enabled by default and some JDK vendors may choose not to enable it. Goals include allowing users to link a runtime image from modules regardless of whether those modules are standalone JMOD files, modular JAR files, or part of a runtime image linked previously. Motivating this proposal is the notion that the installed size of the JDK on the file system is important in cloud environments, where container images that include an installed JDK are automatically and frequently copied over the network from container registries. Reducing the size of the JDK would improve the efficiency of these operations.
Generational Shenandoah would enhance the garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resistance, and memory utilization. The main goal is to provide an experimental generational mode, without breaking non-generational Shenandoah. The generational mode is intended to become the default mode in a future release.
Scoped values enable a method to share immutable data both with its callees within a thread and with child threads. Scoped values are easier to reason about than local-thread variables. They also have lower space and time costs, particularly when used together with virtual threads and structured concurrency. The scoped values API was proposed for incubation in JDK 20, proposed for preview in JDK 21, and improved and refined for JDK 22 and JDK 23. Scoped values will be previewed in JDK 24.
With the key derivation function (KDF) API, an API would be introduced for key derivation functions, which are cryptographic algorithms for deriving additional keys from a secret key and other data. A goal of this proposal is allowing security providers to implement KDF algorithms in either Java code or native code. Another goal is enabling applications to use KDF algorithms such as the HMAC (hash message authentication code)-based extract-and-expand key derivation function (RFC 5869) and Argon2 (RFC 9106).
Removing the non-generational mode of the Z Garbage Collector (ZGC) is a proposal aimed at reducing the maintenance cost of supporting two different modes. Maintaining non-generational ZGC slows the development of new features, and generational ZGC should be a better solution for most use cases than non-generational ZGC, the proposal states. The latter eventually should be replaced with the former to reduce long-term maintenance costs. The plan calls for removing the non-generational mode by obsoleting the ZGenerational
option and removing the non-generational ZGC code and its tests. The non-generational mode will expire in a future release, at which point it will not be recognized by the HotSpot JVM, which will refuse to start.
Stream gatherers would enhance the stream API to support custom intermediate operations. Stream gatherers allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations. This feature was proposed as a preview in JDK 22 and JDK 23. The API would be finalized in JDK 24. Goals include making stream pipelines more flexible and expressive and allowing custom intermediate operations to manipulate streams of infinite size.
The vector API is designed to express vector communications that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. The vector API previously was incubated in JDK 16 through JDK 23. It would be re-incubated in JDK 24 with no API changes and no substantial implementations relative to JDK 23. Goals of the proposal include clearly and concisely expressing a wide range of vector computations in an API that is platform-agnostic, that offers reliable runtime compilation and performance on x64 and AArch54 architectures, that degrades gracefully and still functions when a vector computation cannot be expressed at runtime, and that aligns with Project Valhalla, leveraging enhancements to the Java object model.
The class-file API, previously previewed in JDK 22 and JDK 23, would be finalized in JDK 24, with minor changes. This API provides a standard API for parsing, generating, and transforming Java class files. It aims to provide an API for processing class files that tracks the class file format defined by the Java Virtual Machine specification. A second goal is to enable JDK components to migrate to the standard API, and eventually remove the JDK’s internal copy of the third-party ASM library. Changes since the second preview include a renaming of enum values, removal of some fields, the addition of methods and method overloads, methods renamed, and removal of interfaces and methods deemed unnecessary.
Late barrier expansion for the G1 garbage collector is intended to simplify the implementation of G1’s barriers. The G1 garbage collector’s barriers record information about application memory accesses, by shifting their expansion from early in the C2 compilation pipeline to later. Goals include reducing the execution time of C2 compilation when using the G1 collector, making G1 barriers comprehensible to HotSpot developers who lack a deep understanding of C2, and guaranteeing that C2 preserves invariants about the relative ordering of memory accesses, safepoints, and barriers. A fourth feature is preserving the quality of C2-generated JIT (just-in-time)-compiled code, in terms of speed and size.
The first JDK 24-targeted feature, officially called “Prepare to Restrict the Use of JNI,” calls for issuing warnings about uses of JNI and adjusting the foreign function and memory (FFM) API, featured in JDK 22, to issue warnings in a consistent manner. These warnings are intended to prepare for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Goals of the plan include preserving JNI as a standard way to interoperate with native code, preparing the Java ecosystem for future releases that disallow interoperation with native code by default, and aligning the use of JNI and the FFM API so library maintainers can migrate from one to the other without requiring developers to change command-line options.
Additional features targeting JDK 24 will be determined during the next several months. Potential Java 24 features include further previews or final releases of features being previewed in JDK 23. These include structured concurrency, which simplify concurrent programming, and flexible constructor bodies, which give developers greater freedom to express the behavior of constructors.
Ahead-of-time class loading, a feature designed to speed Java startups, and string templates, a feature previewed in JDK 21 and JDK 22 but dropped from JDK 23, could also be targeted to JDK 24.
The most recent LTS release, JDK 21, arrived in September 2023 and is due to get at least five years of Premier support from Oracle. The next LTS version, JDK 25, is due in September 2025. LTS releases have dominated Java adoption, which means adoption of JDK 23 and JDK 24 could be on the low end as users await JDK 25.
GitHub Copilot learns new tricks 7 Nov 2024, 10:00 am
The role of GitHub as part of Microsoft’s developer division is much more than providing Microsoft and its customers with a mix of cloud-hosted and on-premises source code version control. First GitHub branched out into offering a CI/CD platform with a build and test runner in the shape of GitHub Actions. Then it added tools to help reduce the risk of common bugs and to automate patching known security holes by managing dependencies.
These features have all built on its role as the place where we store code, using that as a lever to help developers build all types of projects, from hobbyist hacks to scientific computing. GitHub has billions of lines of code that make up the largest software projects. All that code, much of it with permissive licenses, gives GitHub unprecedented insight into developer trends, which it wraps up in its annual Octoverse report on the programming languages and development tools we’re using.
That massive code base has allowed GitHub to build a set of AI-powered programming assistants, drawing on the collective experience of millions of developers to provide a set of Copilots that plug into familiar developer tools. I think of them as “AI pair programmers,” not so much writing code for you (though you can use them that way if you want) as offering a pool of collective knowledge to hint at alternate ways of doing things, helping solve problems and get around blockages.
GitHub Universe 2024, held last week in San Francisco, saw GitHub expand its roster of Copilots, adding new AI-powered tools and services, as well as new options for its existing platform. These go beyond the semantic space explored by the original GitHub Copilot to provide AI agent-based services to help with migration tasks.
Using GitHub Copilot for code review
One interesting new use for these technologies is GitHub Copilot’s Code Review tool. This takes a similar approach to Microsoft’s Editor in Word, checking the contents of a pull request using Copilot as an additional reviewer. Reviews can be across a section of code or all the changes made since the last push. GitHub notes that the service won’t find all the issues in your code and may make mistakes. For now, you should treat it as an assistive technology and still run tests after using it, or use it alongside human reviewers. There is a feedback loop, where you can comment on the suggestions the service makes, which will drive more training and fine-tuning.
Like a human code reviewer, GitHub’s Copilot will comment on your code and offer quick fixes. The tool is available inside GitHub workspaces or through the Copilot plug-in in Visual Studio Code. The quicker choice of reviewing a selected snippet of code is available for all supported languages, while the deeper review of changes is only available for a subset of more popular languages, such as C#, Java, JavaScript (and TypeScript), and Python.
Most reviews are likely to be manually triggered, but there’s the option to ensure all pull requests are reviewed by the service. Here developer leads and repository owners can set rules for their branches, ensuring that Copilot reviews are run on all new pull requests. This approach will automatically comment code, allowing other members of the team to make or accept changes as part of merging a pull request.
GitHub Spark: AI-powered development for everyone
GitHub also announced GitHub Spark, an AI-powered development tool for small cloud-hosted applications. Perhaps best thought of as a tool that fits in between the development scratchpad of Glitch and the low-code and no-code Power Platform, Spark gives you a framework for quickly building and sharing application ideas with colleagues, using natural language.
GitHub Spark is an interesting experiment, delivering a new development feedback loop where you quickly get to iterate through changes to your application. All the variants of your app are stored in a history view, so you can jump back to an older version to start a new set of iterations. Apps are delivered as progressive web apps (PWAs) and hosted by GitHub, with a managed NoSQL store for your data.
It’s still early days for Spark, with a long to-do list for the development team. But the idea is fascinating, extending what can be done with Copilots into a tool for anyone to build an application.
Using AI to upgrade Java
Microsoft’s own developer tools teams have been working with GitHub to find new uses for GitHub Copilot. One interesting new possibility is using it to provide upgrade help for Java developers. A lot of older Java applications out there could benefit from upgrading to newer releases of Java, frameworks like Spring Boot, or newer versions of APIs and services.
Updating that code requires more than switching to a recent version of the JDK, as applications have many dependencies that will need updating at the same time. This can take a lot of time to follow different update paths and remediate errors and issues. Instead of taking your time, the new GitHub Copilot upgrade assistant for Java uses an agentic workflow, taking advantage of the ability of AI-based applications to construct their own workflows that bring in different tasks as needed. It uses the AI to build an upgrade plan for you.
You start with an existing project and the details of build tools and frameworks, along with a target Java version (for example upgrading from Java 8 to Java 21). The Copilot upgrade assistant analyses your code base and generates a list of the necessary steps to run your upgrade, presenting it as a set of GitHub issues that you can check before running the update.
Once you’re happy with the tasks, the tool takes you to a dashboard where you can watch the update process, including how Copilot rewrites code for you. You can stop and start the process at any time, drilling down into tasks for more information on just how the AI-based code is working. It’s good to have this level of transparency, as you need to be able to trust the AI, especially when it’s working on business-critical software.
As this is an agentic AI process, the service can detect errors and fix them, launching sub-agents that make changes, rebuild, and retest code. Interestingly if a fix doesn’t work, it’ll take another approach, using the shared knowledge of the Java developers whose work has been used to train the Copilot Java model. Like other GitHub Copilots, changes that work are used to fine-tune the model, reducing the risk of errors in future runs. That goes for manual updates and changes too.
The upgrade tool takes advantage of Git, saving changes in a new branch. You can continue supporting the original code without affecting the updated version, which can be tested at the same time. The agent will mark any commits it makes with the details of the action taken, again giving you a guide to how it has handled upgrading your code. It won’t make the final pull request—that’s left for you once you’re satisfied with the upgraded Java application and it’s passed all your tests.
An Azure Copilot in VS Code
Other new GitHub Copilot features are aimed at reducing the number of times developers have to context switch. One, designed to work inside Visual Studio Code, brings Azure infrastructure tools into the GitHub Copilot chat pane, with a new @azure operator.
Besides helping quickly get the syntax for Azure CLI commands, it can help you find features and services you may not have considered. The underlying tool includes a retrieval-augmented generation–based search that uses Azure documentation to deliver always-up-to-date information about the platform and how to use it. Other options help you pick app templates and provide details that help you build and deploy applications, for example, quickly finding an appropriate region where a service you want to use is available.
Other tools help troubleshoot problems by accessing logs and other diagnostic tools to come up with suggested fixes. This is one place where the tools developed for agentic AI have a role to play, providing the APIs and data sources needed to construct a complex diagnostic workflow on the fly. Those same tools can help operate your environment, allowing you to build, troubleshoot, and run a development Azure instance from the same code editor you use to build your application.
Having an assistant in your development tools isn’t about having an AI write code for you. That’s not what generative AI does, at least not yet. Instead, you’re getting a pair programmer that’s made up of the expertise of everyone who’s been working on a similar problem and used GitHub to save their code. It’s about hints, suggested code, and yes, automations that simplify complex tasks. As one of the pioneers of using large language models at scale, GitHub is now looking at what comes next—and it might be very interesting indeed.
.NET vector data abstractions library now available in preview 6 Nov 2024, 10:37 pm
Microsoft has introduced its Microsoft.Extensions.VectorData.Abstractions
library, now in preview. The library provides abstractions to help integrate vector stores into .NET applications and libraries.
The vector data abstractions library, introduced October 29, provides library authors and developers with the ability to perform create-read-update-delete (CRUD) operations and use vector and text search on vector stores.
Vector databases are important for search tasks and grounding AI responses, Microsoft said. These databases are built to store, index, and manage data represented as embedding factors. As a result, the indexing algorithms used by vector databases are optimized to retrieve data that can be used downstream in applications.
Microsoft.Extensions.VectorData
offers a set of core .NET libraries developed in collaboration with the Microsoft Semantic Kernel team and the broader .NET ecosystem. These libraries provide a unified layer of C# abstractions for interacting with vector stores, Microsoft said.
Developers can get started with Microsoft.Extensions.VectorData
abstractions by using Semantic Kernel vector store connectors
‘Package confusion’ attack against NPM used to trick developers into downloading malware 6 Nov 2024, 10:08 pm
Application testing company Checkmarx has warned developers to be on the lookout for malicious NPM packages, after discovering a new attack that employs typosquatting to impersonate two popular packages.
Part of a much larger campaign against NPM, in a new twist, the malicious package eschews traditional command & control (C2) by using the Ethereum blockchain to hold the addresses of its malicious payloads.
The campaign targets two popular NPM (Node Package Manager) packages used as part of the Jest JavaScript testing framework, “fetch-mock-jest” and “Jest-Fetch-Mock”, using a malicious package with a similar-looking name, “jest-fet-mock”.
The attacker’s assumption is that at least some developers will be in too much of a hurry to notice the misspelling, and will download one of the malicious packages.
But in what appears to be a first for attacks against NPM, the malicious package executes a routine that downloads a malware payload after receiving the server address via a smart contract published on the Ethereum blockchain. Using blockchains to obscure C2 is not new, but offers the attackers important advantages.
“By using the blockchain in this way, the attackers gain two key advantages: their infrastructure becomes virtually impossible to take down due to the blockchain’s immutable nature, and the decentralized architecture makes it extremely difficult to block these communications,” noted the Checkmarx researcher, Yehuda Gelb, in his analysis.
In other words, there is no single address, IP, or server to block. That said, there are downsides to the technique that are not mentioned by Checkmarx, including the fact that blockchain communication is slow, as well as public. The blockchains can’t be edited, or blocked easily, but they can be tracked once their use as part of malware C2 has been uncovered.
Despite past predictions that the technique would take off, this is probably why using blockchains for C2 remains the experimental preserve of specialist malware.
Package confusion
Perhaps the more significant part of the story is that the technique is being used to target testing tools distributed via NPM, the largest open source JavaScript registry. Targeting testing tools is another way to get inside the privileged developer testing environments, and any deeper access to the CI/CD pipelines that they reveal.
NPM has become a repeated target for attackers looking to penetrate supply chains, something documented by news sites such as CSO Online, as well as by Checkmarx itself.
On that score, “jest-fet-mock” is only one example from a much larger NPM package confusion campaign documented separately by security companies Phylum and Socket.
According to Phylum, this involved at least 287 malware packages, all deploying the typosquatting technique to target developers downloading a range of libraries including Puppeteer and Bignum.js, as well as cryptocurrencies.
The question is, what can developers do to protect themselves, given that malicious packages can crop up very suddenly and be hard to spot? As Gelb of Checkmarx said, “The cross-platform nature of the malware, coupled with the fact that no security vendors have flagged these files as malicious on VirusTotal at the time of writing, makes this an actively dangerous threat to development environments.”
It gets worse
Beyond typosquatting and package impersonation lie even darker possibilities. In September, a university research study showed how AI LLM coding tools could be used to conduct “package hallucination” attacks against developers.
An LLM might hallucinate a non-existent package, referencing it inside legitimate code. Most of the time, this would fail to compile. But if the attackers were to uncover the name of that imaginary package before this happened, they could bring it into existence, hiding dormant malware inside it.
This would be the perfect supply chain attack, with no easy mitigations even when uncovered. The idea is no theory, either: across 30 different tests, the researchers found that almost 20% of the LLM-generated code samples they looked at contained references to hallucinated packages.
12 Java Enhancement Proposals changing Java 6 Nov 2024, 10:00 am
Java’s internal systems and syntax are constantly evolving, and these changes happen primarily through the Java Community Process (JCP) and Java Enhancement Proposals (JEPs). Together, the JCP and JEPs define the path by which new features can be described, designed, and—hopefully—introduced into the JVM. They keep the Java language and platform dynamic and the community engaged. With JDK 24 so close to its planned release date, now is a good time to take a look at the upcoming JEPs making their way through the process.
Stages of the JEP process
You can check the JEP Index on the OpenJDK homepage for a catalog of all the JEPs, past and present, submitted for Java. The sheer size and scope of the index can be overwhelming at first. It’s not immediately clear what each JEP is about and which ones are more significant. You might expect major projects like virtual threads would be distinguished from proposals of smaller scope, but there is no such distinction. All the JEPs are listed, past and present, showing the complete history of Java’s evolution.
Instead of scope, the JEPs are organized according to their stage of development:
- In-flight JEPs are proposals being worked on right now for inclusion in a future version of Java. This includes everything from proposals that are in preview and available for experimentation to those that have recently been accepted for development. All the proposals in this set have already been vetted along the way and are likely to arrive in a future Java release.
- Submitted JEPs have come through the creation process and are now officially submitted but have not been accepted. Once they are accepted, they will move to the in-flight stage.
- Draft JEPs are proposals that are being worked on to get them into a state where they are ready for official submission. When that happens, they’ll move up to submitted JEP status.
- Delivered feature, infrastructure, and informational JEPs are all the successful JEPs of the past that have become part of the JVM. Some have even been delivered and then modified by further JEPs.
- Withdrawn JEPs are proposals that didn’t work out and were withdrawn.
You’ll also notice Process JEPs at the head of the index. These are procedural JEPs that help you understand and define the process itself.
Sometimes, larger JEPs are broken down into parts or stages. For example, JEP 462: Structured Concurrency (Second Preview) has an individual entry in the delivered features set.
The most notable in-flight JEPs right now
There are numerous interesting JEPs in the pipeline currently. The proposals I’ve highlighted are focused on tuning and refactoring the JVM and expanding and enhancing the language.
JEP 485: Stream Gatherers
As I discussed in my deep dive on the topic, stream gatherers make functional operations more customizable. The Stream Gatherer API exposes a low-level operator interface called a gatherer. Developers can use gatherers for operations on streams that were difficult or impossible before, like working with homogeneous collection types.
The deep dive was based on a preview of the feature. JEP 485 is the proposal to accept this feature as a finalized part of the platform. It’s the culmination of twp previous proposals: JEP 473 and JEP 461.
Stream Gatherers is not the kind of feature you need every day, but when you do need it, it’s awesome to have. It turns a frustrating edge case into a simple solution.
JEP 484: Class-File API
The Class-File API is targeted at library and framework developers who need to decorate the compiled output of Java programs with additional features. This is a long-standing approach in Java. The Java ecosystem has many tools for this type of development, but the faster pace of JDK changes makes having a more standardized approach important.
The Class-File API is a standard mechanism for parsing, manipulating, and outputting a framework or library’s .class
structures. Other tool developers (and the JDK itself) can then build on the provided output.
JEP 478: Key Derivation Function API (Preview)
JEP 478 is a move to improve and expand on Java’s native ability to deal with cryptographic material like keys and hashes. It’s intended to make these operations more robust, including forward-looking capabilities to help future-proof against quantum computing attacks.
Developers involved in cryptography would use the Key Derivation Function API for things like hashing passwords using advanced algorithms like Argon2. JEP 478 upgrades Java’s built-in cryptographic support and better positions it for the coming years.
JEP 478 is a preview proposal currently, meaning it likely has a way to go before it lands as an official feature.
JEP 472: Prepare to Restrict the Use of JNI
Part of Project Panama’s effort to replace the JNI with the Foreign Function Memory API, JEP 472 is an indication that the JVM is moving toward deprecating the Java Native Interface. This proposal is a heads-up for application developers that the time is coming when JNI will be restricted by default. This JEP is concerned with making the JNI and FFM API more consistent and safe. Developers using JNI or FFM will be affected by this change because it requires these features to be explicitly enabled and issues warnings if they are not.
JEP 468: Derived Record Creation (Preview)
Records are immutable objects, added not long ago to Java. JEP 468 introduces a simplified way to create clones of records with specific fields marked as mutated. Records are often copied as a way to modify them. This JEP takes a task that requires boilerplate and adds language-level support for it via the with
keyword.
The proposal’s authors provided an example of scaling an existing Point
instance (nextLoc
) by 2 in a new finalLoc
instance:
Point finalLoc = nextLoc with {
x *= 2;
y *= 2;
z *= 2;
};
A Point
class in this example refers to a three-dimension integer record. This eliminates any need to add chaining methods to the Point
class. Here’s an example of chaining:
Point finalLoc = nextLoc
with { x *= 2; }
with { y *= 2; }
with { z *= 2; };
Overall, the JEP makes a nice addition to the power of records.
JEP 198: Light-Weight JSON API
The feature proposed in JEP 198 is something I’ve wanted for over a decade. Dealing with JSON is a fact of life in modern programming, it crops up everywhere and there are good reasons for it. Using JSON in JavaScript is incredibly easy, whereas in Java it requires a third-party library. At times, these APIs are not easy to use.
Unfortunately, JEP 198 originated in 2014 and hasn’t been updated since 2017. However, there has been some activity on the OpenJDK mailing list. This is an example of a worthwhile JEP that is “in-flight” but also not moving quickly. Here’s hoping for more active development in the future.
JEP 479: Remove the Windows 32-bit x86 Port
JDK 21 deprecated 32-bit windows, and JEP 479 completes the job. Once this proposal becomes part of Java, the Java platform will no longer support 32-bit windows. The JEP describes how removing these code paths will streamline the JVM.
JEP 218: Generics over Primitive Types
Part of project Valhalla, JEP 218 is the ability to use primitive types in generics. This is a major improvement to the basic Java syntax and implies a significant amount of internal planning and refactoring. Unifying generics and primitives means we are getting away from primitive wrappers and (auto)boxing. This clears the way for a thoroughgoing unification of primitives and objects and the introduction of value types.
This will be the biggest change to the way we write Java in a long time. It is still being actively worked on but no hard date is set.
JEP 483: Ahead-of-Time Class Loading & Linking
JEP 483 is a great example of the JVM team at work on improving the underlying behavior of Java. The end result is a better platform; in this case, one that starts and reloads faster.
The general idea is that the JVM is adding the means to quickly load classes with other areas of dynamism preserved, resulting in faster startup and warmup times. Application developers won’t have to do anything special to take advantage of this feature; we get it for free in coming versions of the HotSpot JVM.
JEP 475: Late Barrier Expansion for G1
Like JEP 483, JEP 475 is a refactoring that won’t be directly used by application developers. Instead, it improves the performance and accessibility of the HotSpot JVM for platform developers implementing garbage collection routines.
JEP 475 is especially focused on reducing memory and time in the garbage collector, which is critical for making Java a stronger platform for the cloud. These kinds of improvements—technologically demanding operations that happen behind the scenes—are important for keeping the Java platform relevant.
JEP 450: Compact Object Headers (Experimental)
Another internal performance improvement, JEP 450 is designed to reduce the in-memory size of Java objects. Real-world testing has shown that much of the heap space occupied by objects is object header data. That means that, as the JEP says, “Cutting down the header of each object from 96 to 64 bits means improving overall heap usage by more than 10 percent, since the header is a fixed cost for every object. A smaller average object size leads to improvement in memory usage, GC pressure, and data locality.”
This is another welcome internal refactor that we can look forward to silently improving the way our programs run.
JEP 111: Additional Unicode Constructs for Regular Expressions
JEP 111 looks to expand the character types that regular expressions can handle, covering more of the Unicode tech standard. Specifically, it is adding the following types of chars that can be handled in strings:
- Unicode Name Properties:
\N \{...\}
- Extended Grapheme Clusters:
\X
- Fix the broken canonical equivalent support
- Unicode line-break sequence, as suggested at TR#18 Line Boundaries:
\R
- Perl style construct for named capturing group and capturing group:
\g \{...\}
- More complete Unicode properties, as in
\p \{IsXXXX\}
- Horizontal/vertical whitespace:
\h \H \v \V
Conclusion
Although I’ve covered many of the in-flight JEPs, there are several others, not to mention the wealth of draft-stage proposals. Looking at the index is a great way to get a sense of the immense amount of work going into Java. In this article, I focused on proposals for tuning and refactoring the JVM and expanding and enhancing the language.
Dataframes explained: The modern in-memory data science format 6 Nov 2024, 10:00 am
Most people are familiar with data in the form of a spreadsheet, with labeled columns of different data types such as name, address, age, and so on. Databases work the same way, with each table laid out according to a strict schema.
Dataframes are structures used in data science that work like spreadsheet pages or database tables. Many common data science libraries use dataframes in some form—Spark, Pandas, Polars, and many more. But dataframes are far more efficient and powerful than working with databases through an SQL query or reading an Excel spreadsheet via a libary. In fact, you can create dataframes from any of those data sources and more. Then you can use the imported data with far greater speed, thanks to the way dataframes work.
The basics of dataframes
Dataframes are two-dimensional data structures, with rows of data elements organized into named columns that hold specific data types. In that sense they’re closer to the way databases work, as spreadsheets are more intentionally freeform. But dataframes have many of the same conveniences of both—for instance, you can access a column by its name rather than a mere index position.
Each dataframe typically has a schema: a description of the name and perhaps also the data type for each column. The data types supported by dataframes ought to be familiar to most programmers—integers, floating-point numbers, strings, and so on. You can also store empty or null values in a dataframe, in the same way a spreadsheet can hold an empty cell or a database can have a NULL
value.
Some dataframes allow you to specify types for a column to keep data consistent. You can’t put string data in a column for integers, for instance, but you can leave a column untyped if you must—again, as a convenience.
Dataframes can be created by importing data from an existing source, or through a programmatic interface. For instance, in Python, the Pandas library lets you use Python data structures as the basis for creating dataframes:
import pandas as pd
data = {
"Title": ["Blade Runner", "2001: a space odyssey", "Alien"],
"Year": [1982, 1968, 1979],
"MPA Rating": ["R","G","R"]
}
df = pd.DataFrame(data)
Applications that use dataframes
As I previously mentioned, most every data science library or framework supports a dataframe-like structure of some kind. The R language is generally credited with popularizing the dataframe concept (although it existed in other forms before then). Spark, one of the first broadly popular platforms for processing data at scale, has its own dataframe system. The Pandas data library for Python, and its speed-optimized cousin Polars, both offer dataframes. And the analytics database DuckDB combines the conveniences of dataframes with the power of a full-blown database system.
It’s worth noting the application in question may support dataframe data formats specific to that application. For instance, Pandas provides data types for sparse data structures in a dataframe. By contrast, Spark does not have an explicit sparse data type, so any sparse-format data needs an additional conversion step to be used in a Spark dataframe.
To that end, while some libraries with dataframes are more popular, there’s no one definitive version of a dataframe. They’re a concept implemented by many different applications. Each implementation of a dataframe is free to do things differently under the hood, and some dataframe implementations vary in the end-user details, too.
For instance, Spark dataframes (or DataFrames, as they’re called in Spark) do not support strongly typed columns. Every column is considered a Java object. Another Spark data type, the Dataset, adds typing guarantees for columns as a way to enable optimized processing.
Another under-the-hood example: While dataframes can in theory use any kind of under-the-hood data layout, many of them use columnar storage. Data is laid out in a column-wise format, instead of row-wise. This speeds up processing the data, at the cost of making it slower to insert rows (assuming that’s even allowed). If you’re curious about under-the-hood implementation details, this talk at PyData Seattle 2015 describes how Pandas implements dataframes.
Advantages of dataframes
The features commonly expected of dataframes make them appealing for many reasons:
- High-performance operations: Dataframes provide convenience methods for selecting, sorting, and transforming data at scale. Most dataframe implementations come with methods for filtering, transposing, or performing pivot-table-like operations. What’s most crucial is these methods don’t require the developer to iterate through the dataframe, so they can be applied as fast, atomic operations.
- In-memory processing: Dataframes tend to reside in-memory by default for speed. Some dataframe applications like Daft or Dask support dataframes larger than system memory. However, the vast majority of work in dataframes happens in-memory instead of on-disk. Likewise, with DuckDB, data can be kept on disk for persistence, but processed in-memory as per other data science libraries.
- A convenient and consistent metaphor: Working with a dataframe is less abstract or cumbersome than working with a simple homogenous data array (such as a NumPy array). Again, it’s more akin to working with a spreadsheet or a database. Once you’ve worked with a dataframe in one place, the behavior and concepts port easily to other incarnations of dataframes.
The consistent metaphor provided by dataframes is the most crucial item on this list. As frameworks and libraries for data science proliferate, there’s a growing need for consistency and familiar footing. Dataframes bring conceptual consistency to working with data. The dataframes concept is bigger than any library that uses them. Dataframes will also likely outlast most libraries that implement them.
Why scrum is dumb 6 Nov 2024, 10:00 am
You would be hard-pressed to find a software manager who didn’t want to be “agile.” But I’m guessing that a vanishingly small percentage of them have actually read the Agile Manifesto. And I’m guessing even fewer have given any real thought to what agile means and how it might be applied in the real world.
Sure, the Agile Manifesto is revered by software developers. Most of us feel like there is something there — some deep-seated truth that we all know. But the problem arises when we try to figure out the answer to the question, “Okay, now what do we do?”
The norm seems to be, “We need to be agile, so let’s hire a scrum consultant and implement scrum. Then we’ll be agile!” The market forces to provide scrum services are strong. And there is certainly no shortage of eager consultants who are ever-ready to offer their services.
Why this is true is a mystery to me. I fail utterly to see how scrum is a manifestation of the Agile Principles. In my view, scrum is in direct opposition to them, and in the end, doesn’t even remotely fulfill their purpose.
Cramming it with scrum
Everything about scrum tries to squeeze a large peg into a small hole. Scrum creates a fixed-sized hole of a given chunk of time, takes a large wooden block of effort, and tries to make a series of small, properly sized blocks fit into that hole.
Never mind that the size of the hole may or may not fit the blocks that you have. You are supposed to whittle them down so they fit, even if what you end up with isn’t really what you want or need. You are not allowed to change the size of the hole that the blocks are supposed to fit into. That block must fit into that hole, and that hole ain’t getting any bigger.
I have no clue why this is a good idea, and I certainly don’t see how it prioritizes “individuals and interactions over processes and tools.”
So, we whittle down the pegs into these unnatural shapes that will allegedly fit the rigid holes we’re given. Only they don’t. The peg rarely if ever ends up fitting in the hole. As the sprint nears its conclusion, the work is either already done (what to do with three extra days?) or it will never be done in time (“Can we extend the sprint a week?” “No!”), in which case we “fail” the sprint.
Sprint, sprint, and sprint again
And who wants to continuously sprint anyway? Who wants to always and forever be approaching a deadline? Constantly pushing for “finishing” something leads to shallow solutions that are rushed. Requirements and constraints in software development change all the time as unknown unknowns are discovered. Doing something properly and thoroughly often takes time. But the process of scrum says that if you want to change course, you must wait until the sprint is over. How is that “Responding to change over following a plan?”
A sprint is a very narrowly focused chunk of work. If you constantly focus on narrow things, you can easily lose sight of the bigger picture.
And all too often, scrum becomes a large ceremony. Does anyone look forward to the daily standup where you have to drop everything, go to a meeting room (or a Zoom meeting), and tell everybody what you did and will do? Be honest — aren’t you relieved whenever the scrum master says, “Email scrum today!”?
What’s more, retrospectives are frequently forced and held even if there isn’t any feedback to be had. There ends up being much too much going through the motions — the very antithesis of agility and adaptability.
And that isn’t even talking about the never-ending sprint planning and backlog grooming meetings that inevitably become part of the process that you are supposed to put in the back seat behind individuals and interactions.
A better scrum process
In the end, scrum becomes an endless series of short software projects that end like most software projects. They take longer than you expect, don’t accomplish what they set out to do, and involve many hours of meetings that most folks would rather not be in.
How about doing something like this instead?
- Break the work up into natural chunks that match the needs of the project. Some will be small chunks, and some will be big chunks.
- Do each chunk in the order that makes sense, with each chunk taking a given amount of time. Perhaps a chunk needs more than one developer — not a problem.
- Recognize that the time for each chunk will vary from what you expect at the beginning. Track each trunk separately, and don’t force every chunk to finish at a fixed, inflexible time.
- If you are in the middle of something, and what you are doing no longer makes sense because of changing circumstances and shifting winds, change to a new, better course immediately.
- When the time is right — not when the calendar dictates — review what you’ve done, ask for feedback from customers and stakeholders, and adjust accordingly.
- If the list of chunks needs to change, let the list change.
- Lather, rinse, repeat, until all the chunks you need are complete, then ship the software.
- Maybe even ship each chunk as it completes.
In other words — be flexible, nimble, and… agile.
Page processed in 1.02 seconds.
Powered by SimplePie 1.3.1, Build 20121030095402. Run the SimplePie Compatibility Test. SimplePie is © 2004–2024, Ryan Parman and Geoffrey Sneddon, and licensed under the BSD License.