📰 English IT Daily · 2026-06-20

After many years of work, Project Valhalla is finally moving closer to Java developers. Oracle engineer Lois Foltan confirmed that JEP 401, called Value Classes and Objects, is being integrated into the main OpenJDK repository and is targeting JDK 28. This is an important step because some people in the industry had started to doubt that Valhalla would ever arrive. However, experts also warned that this is only the first part of the project.

Valhalla has long used a simple idea: code like a class, work like an int. In today’s Java, most data types are reference types. That means a variable often stores a pointer to an object on the heap, not the object itself. This design is flexible, but it can hurt performance. Each object needs memory for metadata in an object header, and the JVM must allocate and later garbage collect those objects. When many small objects are spread across memory, programs may also lose cache efficiency.

Value classes aim to reduce that cost for some kinds of data. The goal is to let developers write clear, object-oriented code while giving the JVM a chance to store and handle the data more efficiently, more like primitives such as int. This could be especially useful for simple data-heavy structures like points, money values, or coordinates. In plain terms, Valhalla tries to cut the extra memory and pointer jumping that come with ordinary objects.

Still, the JDK 28 feature is expected to be a preview and disabled by default, so teams should not treat it as a finished change yet. The integration is also very large, showing how deep the change is inside the platform. For developers, the news matters because it may eventually affect API design, library performance, and the way Java models data. For now, Valhalla is best understood as a major foundation step rather than the final destination.

A new project called Prylint suggests a familiar idea in software tools: rebuilding an older utility in Rust. The topic has attracted attention because the project name points to Pylint, a well-known Python linter. A linter is a program that checks source code for possible mistakes, style problems, and patterns that may cause bugs. Developers use these tools to improve code quality before software moves to testing or production.

The available source page gives only limited information, so many technical details are still unclear. However, the basic idea is easy to understand. Rust is a programming language known for speed and memory safety, which means it tries to prevent some common programming errors. Because of these strengths, some teams choose Rust when they want to build developer tools that can run quickly and handle large codebases more efficiently.

If a Python code checker is converted to Rust, one possible goal is better performance. In practice, this could mean faster scans, lower resource use, or a smoother experience in editors and continuous integration systems. Still, a rewrite is never simple. Developers must preserve useful rules, maintain compatibility with existing workflows, and make sure the new version produces reliable results. For users, trust is important: a fast tool is helpful only if it stays accurate.

This kind of project also reflects a wider trend in programming. Companies and open-source communities are reviewing old tools and asking whether newer languages can offer practical benefits. At the same time, teams must balance innovation with maintenance costs, learning curves, and migration risk. Even with limited public detail, the Prylint example shows why engineers keep watching the toolchain closely: small changes in development tools can affect productivity across many projects.

vocabulary

The European Union Cyber Resilience Act, or CRA, is a new law for products with digital elements. That means many connected devices and software products sold in the EU. The rules will fully apply in late 2027, and many companies are already preparing. Some people have warned that the law could be very hard for software makers, especially open-source communities. However, supporters say the goal is simpler: make digital products safer and more trustworthy for users and businesses.

A key idea behind the CRA is that suppliers should understand what is inside their products. In practice, this means they may need to provide an overview of components and dependencies. Components are the parts used to build software or devices, and dependencies are outside libraries or tools that the product relies on. This kind of visibility helps customers, auditors, and business partners check whether a product has hidden security risks or weak points in its supply chain.

The CRA is part of a wider European effort to regulate technology, alongside laws such as GDPR, DORA, and NIS2. The general purpose is to protect safety, business continuity, and civil rights as technology becomes more important in daily life. For companies, the law may increase documentation work and require better engineering discipline. For example, teams may need clearer records of what they ship, how they handle vulnerabilities, and how they prove compliance before selling products in regulated markets.

For developers, the message is not only legal but practical. If a company wants to win contracts and keep market access, it may need to show that its products meet recognized standards, such as CE marking where required. This does not automatically mean the end of open source. Instead, it may push the industry toward better maintenance, clearer responsibility, and more transparent development. In that sense, the CRA could become a business and engineering challenge, but also a chance to improve software quality across the ecosystem.

Data compression is the process of reducing the number of bits needed to store or transmit information. A 2012 educational book by Matt Mahoney explains that compression can be lossless or lossy. In lossless compression, data can be restored exactly to its original form. In lossy compression, some detail is removed to save more space. This is often used for images, audio, and video, where small changes may not be noticed by people.

The book says that every compression method has at least two main parts: a model and a coder. The model tries to predict which symbols are more likely to appear. For example, in English text, some letters are much more common than others. The coder then gives shorter codes to likely symbols and longer codes to rare ones. Morse code is a simple historical example of this idea, because common letters such as E and T have short codes.

Mahoney also explains an important limit: coding has efficient and even optimal solutions, but modeling is much harder. In fact, perfect modeling is not computable in a general sense. This means there is no universal method that can compress all kinds of data equally well. Different data types need different strategies. Text, executable files, pictures, and sound each have patterns, so successful compression depends on understanding those patterns.

The book covers many techniques, including Huffman coding, arithmetic coding, LZ77, LZW, and context mixing, as well as transforms such as run-length encoding and Burrows-Wheeler Transform. It also introduces lossy methods used in JPEG, MP3, and MPEG. The larger message is that compression is not only about saving storage or bandwidth. It is also closely related to prediction, information theory, and artificial intelligence, because a system must guess what data is likely to come next.

A recent blog post by engineer Marc Brooker explains a simple but surprising idea about waiting time. He introduces “Alice,” a user who says a web service feels slow, even though the service team reports that the average request finishes very quickly. In another example, “Alex” says outages feel very long, while the team says the average time to recover is short. The point is that both sides can be correct at the same time.

The difference comes from how time is measured. Engineers often measure in requests or in outage events. Users measure in seconds and minutes. If one request takes much longer than others, a user spends more real time inside that slow request. In the same way, if one outage lasts much longer than others, people experience that event for a longer period. Because of this, users do not feel the simple average in the same way that service metrics report it.

Brooker connects this idea to the inspection paradox, a statistical effect in which longer events are more likely to be experienced. In plain language, people are more likely to notice and remember the long waits because those waits occupy more of their time. The article also points to the importance of the tail of a distribution. The tail means the small number of unusually slow requests or very long recovery times. Even if they are rare, they can strongly shape user experience.

To show this, the blog describes a small simulation using median and p99 values to estimate a latency or recovery-time distribution. The result is that customer experience can look much worse than the average reported by the service. The post argues that teams should pay close attention to tail latency and long recovery times, not only to mean values. It also warns that trimmed measurements can hide important information, because they remove the extreme cases that users may feel most strongly.

Many companies rushed to adopt artificial intelligence after the recent boom in generative AI. They tested tools for writing, coding, customer support, and data analysis. But after the first wave of excitement, some businesses are now trying to control how much they use these systems. The main reason is cost. Running advanced AI models can be expensive, especially when many employees use them often or when companies build AI into daily business processes.

Business leaders still believe AI can improve productivity, but they are under pressure to show clear value. In many cases, AI projects started as experiments, and the spending was easier to approve. Now finance teams want stronger evidence that the tools save time, reduce labor, or increase revenue. Companies are also learning that not every task needs a large model. Smaller systems, limited rollouts, and more careful usage rules can sometimes deliver similar results at a lower cost.

Another issue is infrastructure. AI workloads often require powerful chips, large amounts of computing capacity, and reliable data systems. These needs can push up cloud bills and make budgets harder to predict. Some companies are therefore setting limits on employee access, choosing cheaper models for simple tasks, or asking teams to justify each new AI application. This does not mean they are giving up on AI. Instead, they are moving from broad experimentation to more disciplined deployment.

The shift reflects a more mature stage of AI adoption. Rather than treating AI as a tool for every problem, companies are focusing on practical use cases where the return is easier to measure. For technology teams, this means balancing innovation with cost control, governance, and performance. As AI becomes a normal part of business, success may depend less on using the most powerful model and more on using the right model in the right way.

A major discovery in neuroscience has changed how scientists understand memory. In 2026, neuroscientist Oswald Steward received the Kavli Prize in Neuroscience for work that helped explain how the brain learns and stores memories. He shared the prize with Christine Holt, Kelsey Martin and Erin Schuman. Their research showed that neurons can make proteins near synapses, the small connection points where brain cells send signals to each other.

For many years, scientists believed that most proteins in a neuron were produced mainly in the cell body, the central part of the cell, and then moved to distant areas. This idea seemed reasonable because neurons can be very long cells with many branches. Proteins are important because they help maintain synapses and allow them to become stronger or weaker over time. These changes are closely linked to learning, memory and brain plasticity, which means the brain can reorganize itself after new experiences.

Steward did not begin his research with the goal of challenging the accepted view. He was studying how the brain forms new connections after injury. Using radioactive amino acids, which are the building blocks of proteins, he and his colleagues tracked where protein production happened inside neurons. Instead of finding the main signals in the cell body, they noticed activity in other places. To investigate further, Steward used electron microscopy, a method that creates very detailed images by using beams of electrons.

Under the microscope, Steward saw clusters of polyribosomes near spine synapses. Polyribosomes are groups of ribosomes, the tiny structures that build proteins inside cells. This finding suggested that neurons could produce proteins locally, close to the exact synapses that needed to change. Scientists now see local protein synthesis as a fundamental process in memory and learning. The discovery has reshaped neuroscience and may eventually support new treatments for neurological disorders, while also showing how one unexpected result can transform an entire field.

Let’s Encrypt, a major provider of free digital certificates, reported degraded performance in its production API on June 18. A digital certificate helps websites use HTTPS, which protects data sent between users and servers. During the incident, some clients received 400 and 500 error responses when they tried to use the API. However, the status page said that most clients were still succeeding.

According to the status update, the problem began after an upstream network event disrupted traffic between two datacenters. In simple terms, a network problem outside Let’s Encrypt’s own systems affected communication between its facilities. To reduce the impact, the team re-routed traffic. After that change, success rates returned to normal, although the company later said it was still operating with reduced redundancy.

Reduced redundancy means the service was running normally, but with less backup capacity than usual. Redundancy is important because it gives systems extra paths or resources during failures. Let’s Encrypt said it continued to work with its upstream ISP to identify and resolve the issue. The production API and the portal were listed as operational, while staging services and other public systems also appeared operational on the status page.

The event is a useful reminder that even widely trusted internet services can experience short periods of instability. For developers and operations teams, certificate services are a critical part of security and automation. If certificate requests fail, new deployments or renewals may be delayed. This incident seems to have been limited in time, but it highlights the value of monitoring, retry logic, and clear status communication during service disruptions.

Norway is imposing a near ban on the use of artificial intelligence in elementary schools, according to Reuters. The move shows growing concern about how AI tools affect young children in the classroom. Officials want schools to be careful with technology that can produce text, images, or answers automatically. At the elementary level, the main goal is to protect basic learning, social development, and critical thinking.

The policy does not mean that all digital tools will disappear from schools. Instead, it targets AI systems that can do thinking or writing tasks for students. In simple terms, AI is software that can create content or make decisions based on large amounts of data. Supporters of the restriction say young students need to build reading, writing, and problem-solving skills without depending too much on automated systems.

Another issue is data privacy and safety. Many AI services collect user information to improve their models, and schools must be careful when children are involved. Teachers and parents are also worried that AI-generated content may be incorrect, biased, or too hard for children to question. If students trust every answer from a machine, they may learn less deeply and become less confident in their own judgment.

Norway’s decision adds to a wider global debate about AI in education. Some people believe AI can support teachers by saving time and personalizing lessons, while others think strict limits are necessary for younger learners. The discussion is likely to continue as schools try to balance innovation with responsibility. For technology teams, the case is a reminder that adoption decisions should consider age, risk, transparency, and long-term impact, not only technical ability.

A developer recently shared lessons from a conference talk about moving legacy applications to modern frameworks. The main message was simple: waiting too long makes migration harder. In software, a legacy system usually means an older application that still works but is built with outdated tools, patterns, or libraries. Many companies keep such systems for years because changing them looks risky, expensive, and slow.

However, teams often decide to migrate for practical reasons, not because they want to follow trends. One major reason is security. When a library becomes obsolete, active maintenance may stop, which means fewer or no security patches. As a result, known weaknesses can remain in the product for a long time. Another reason is performance and tooling. Newer build tools and frameworks can make development faster and applications more responsive for users.

The speaker's experience included several kinds of frontend migration, such as moving from older Angular versions to modern Angular, from ASP.NET MVC 5 to Vue, and from React class components to newer React patterns. These examples show that migration is not one single task. It can mean updating a framework, changing the architecture, or improving code step by step. For stakeholders, the key point is that migration supports the long-term survival of a product.

The article also noted that large language models, or LLMs, have not completely changed migration strategies. AI tools may speed up some parts of the work, but they do not remove the need for planning, testing, and careful decisions. Teams still need to choose whether to rewrite a system fully or refactor it in smaller parts. The central warning remains clear: the longer a company postpones migration, the more complex and costly the process usually becomes.