How writing a book made me open a few of my favorite Smalltalk books

It’s hard to imagine what my career would have been like without the great fortune of having learned and programmed professionally in the Smalltalk programming language. This amazing programming language continues to inspire and teach me important lessons, decades after I used it professionally.

In the first book I have written, “Eclipse Collections Categorically: Level up your programming game�, Appendix C is dedicated to Smalltalk. You can find some simple Smalltalk code examples in the appendix and elsewhere in the book. I also include three Smalltalk books as sources in the references section that helped me learn valuable lessons in the formative years of my career in the late 1990s. These books have been invaluable in helping me solve problems for the past thirty years.

The three Smalltalk books referenced in the book are underlined in red below, and are in the image above.

I know that Smalltalk is not done teaching me lessons. I just have to go back to the “Deep Thought� language and books and ask the right questions. I learned one lesson tonight, from “Smalltalk-80: The Language.� The answer to the ultimate question of the organization of chapters 3–10 in my new book is described on page 42. I found the answer tonight as I was writing this post. The question is, of course, “What is on page 42?� I had to write the entire book and publish it to find out the question I didn’t realize I should have been looking for in the book, that I had cited for another purpose. 🤦�♂�

Hopefully you’re more curious than confused. If you get the HGTTG reference above, hopefully you chuckled, and didn’t spit out your coffee or tea. The section on page 42 is titled “Message Categories.� That’s all I will say. If you’ve programmed in Smalltalk, you’ll know what these are. If you haven’t, then I explain an equivalent idea for Java in my book. I also talk about them in several other blogs I have written over the last six months (if you’re looking for free). I don’t refer to the idea as “Message Categories� in the book or blogs, as message is a real thing in Smalltalk, that is not available in Java (at least in the same way). In my book and the blogs, I refer to the concept as “Method Categories.� The difference between Message and Method is another thing worth researching and learning from Smalltalk.

Anyway, there are some other great books and articles that have influenced me in my programming career and in the writing of my book and many of my blogs. You can see some of these books referenced above. Even if you aren’t interested in reading my book, I would highly recommend checking out some of the amazing books and authors above. If you’re programming in any language with a unit testing framework influenced by or named JUnit, and you haven’t read Kent Beck’s article in “Guide to Better Smalltalk: A Sorted Collection� starting on p. 277, then you’re possibly one level removed from the original source of inspiration and influence for JUnit.

I love learning new things about computers and our somewhat short history. There are some great books and authors out there. I love buying classic computer books when I discover them.

Thank you for reading! Keep on reading, especially books written by human authors!

• A link for anyone still confused by the HGTTG reference

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am also the author of the book, Eclipse Collections Categorically: Level up your programming game.

We’re excited to share a new video from EclipseSource! In this session, you’ll learn about the future of (building and using) AI-powered tools and how you can take full control of your development …

The post Theia AI: Discover How to Build AI-Native Tools with Full Control! appeared first on EclipseSource.

Theia AI and the AI-powered Theia IDE support OpenAI’s brand new GPT-4.1 family of models out of the box! This includes support for: gpt-4.1 gpt-4.1-nano gpt-4.1-mini These models can be added, …

The post Theia AI and the AI-powered Theia IDE support GPT-4.1 (and friends) out of the box! appeared first on EclipseSource.

Milestones happen. Occasionally they’re worth celebrating. Thank you!

I usually like to pay more attention to yearly trends than individual monthly stats, but passing one million downloads in one month from Maven Central for the open source Eclipse Collections Java library hits a little different. It’s a nice milestone for the (almost) tenth year of Eclipse Collections at the Eclipse Foundation.

I’ll share one more image to keep this blog short and sweet. Eclipse Collections passed 2,500 stars on GitHub recently as well. GitHub stars are a vanity metric, but it’s a nice feeling when a few folks drop by to say hello with a star. A few years ago, Eclipse Collections finally caught up to and passed GS Collections with GitHub stars. GS Collections was the predecessor to Eclipse Collections.

Thank you to all the users, contributors, committers, and star providers!

Thanks for reading!

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am also the author of the book, Eclipse Collections Categorically: Level up your programming game.

We are happy to announce the Eclipse Theia 1.60 release! The release contains in total 100 merged pull requests. In this article, we will highlight some selected improvements and provide an overview …

The post Eclipse Theia 1.60 Release: News and Noteworthy appeared first on EclipseSource.

In late March 2025, a security researcher in our community reported a security concern about a publicly accessible API endpoint containing user information on accounts.eclipse.org. After reviewing the issue, we determined this API endpoint was unnecessary and have since disabled it.

We looked through our access logs for the past few months and confirmed that the only requests were from the security researcher and the Eclipse Foundation staff who verified the report.

Background

The incident was introduced by the Drupal core JSON:API module being enabled in production without recommended field access restrictions. This module exposes data such as user entities and fields based on Drupal’s default permissions. While email addresses were not visible, other custom fields were publicly accessible for some users and staff:

• City
• Province/State
• Country
• Matrix ID

We did not intend for this information to be publicly accessible by this module. While we do ask our committers to provide their full postal address, that additional information is not stored in Drupal and was not exposed.

Timeline of Events

• January 19, 2025: Endpoint became accessible after going live with our Drupal 10 migration of accounts.eclipse.org
• March 26, 2025 (08:16 AM EDT): Received initial security report from ethical security researcher in the security@eclipse.org inbox.
• April 3, 2025 (11:08 AM EDT): Security Team confirmed the issue, and notified the WebDev team.
• April 3, 2025 (12:39 PM EDT): Endpoint was disabled.

Resolution and Next Steps

To resolve the issue and prevent similar incidents in the future, we have:

• Disabled Drupal’s JSON:API module from accounts.eclipse.org
• Installed and configured the Field Permissions module to enforce field-level access control.
• Initiated a full audit of all our Drupal-based sites to ensure the JSON:API module is disabled and the Field Permissions module is enabled and properly configured.

We remain committed to continuously strengthening our security practices and protecting user data. We would like to thank security researcher Gaurang Maheta for promptly reporting this issue. If you have any questions or concerns, please contact us at privacy@eclipse.org or security@eclipse.org.

Vibe coding—the concept of letting AI generate entire codebases from natural language prompts—offers a glimpse into what’s possible with today’s large language models. But as we’ve discussed, it often …

The post Delegating Code Tasks to AI: From Challenge to Breakthrough appeared first on EclipseSource.

Breaking large feature-rich interfaces into smaller, easy to learn categories

Open the door to Java 24

When I wrote the book, Eclipse Collections Categorically: Level up your programming game, I used Java 21 to compile and run the code examples in the book. Now that Java 24 is released, and the Gatherer feature is no longer a preview feature, I thought I would add it to a Venn Diagram above that compares JDK Set type with Eclipse Collections MutableSet type. If you buy the book, you will find the the the Venn Diagrams for List and MutableList , Stream and LazyIterable, in the Appendix A: Method Categories and Counts. The first Venn Diagram that compares Iterable and RichIterable is at the beginning of Chapter 2. The paperback version of the book is available on Amazon here:

Eclipse Collections Categorically: Level up your programming game

As we can see from the Venn Diagram above, Gatherers adds five new methods that have no overlap with the method names in any of the other types. The new methods in Gatherers are fold(), mapConcurrent(), scan(), windowFixed(), windowSliding(). Eclipse Collections types have access to all of these methods when using Java 24. You don’t have to choose whether you use Eclipse Collections or Stream with Gatherers — you can use both!

Note, the method fold() is similar to the method injectInto() in Eclipse Collections, and the method windowFixed() is similar to the method chunk(). Examples of injectInto() and chunk() are included in the book. The biggest difference between these methods can be seen in the following example.

import java.util.List;
import java.util.stream.Gatherers;

import org.eclipse.collections.api.RichIterable;
import org.eclipse.collections.api.factory.Lists;
import org.eclipse.collections.api.factory.Sets;
import org.eclipse.collections.api.list.MutableList;
import org.eclipse.collections.api.set.MutableSet;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

public class GatherersTest
{
    // Fold and injectInto are categorized as Aggregating Methods
    @Test
    public void foldVsInjectInto()
    {
        ImmutableSet<Integer> set = Sets.immutable.with(1, 2, 3, 4, 5);

        String gathered = set.stream()
                .gather(Gatherers.fold(() -> "", (s, i) -> s + i))
                .findFirst()
                .orElse("");

        String injected = set.injectInto("", (s, i) -> s + i);

        Assertions.assertEquals("12345", gathered);
        Assertions.assertEquals(gathered, injected);
    }

    // WindowFixed and chunk are categorized as Grouping Methods
    @Test
    public void windowFixedVsChunk()
    {
        ImmutableList<Integer> list = Lists.immutable.with(1, 2, 3, 4, 5);

        List<List<Integer>> gathered = list.stream()
                .gather(Gatherers.windowFixed(2))
                .toList();

        RichIterable<RichIterable<Integer>> chunked = list.chunk(2);

        var expected = List.of(List.of(1, 2), List.of(3, 4), List.of(5));
        Assertions.assertEquals(expected, gathered);
        Assertions.assertEquals(gathered, chunked);
    }
}

As we can see, it is less verbose, to use injectInto() and chunk() directly on Eclipse Collections types. The Gathers can run in parallel, so there might be some benefit for some use cases, and you can always use Stream with gather(Gatherer) with Eclipse Collections types. There are no direct equivalents of scan and windowSliding in Eclipse Collections today. The great thing with Eclipse Collections is that you have options, and can use what works best for your use cases. :-)

Note, I did not include Venn Diagrams or method category bar charts for Set and MutableSet, Map and MutableMap, or Bag and MutableBag in the book. There is a lot of overlap for the methods between these types and RichIterable. I also did not include Venn Diagrams for the Immutable equivalents of these types. I will include the Venn Diagrams and bar charts for MutableSet and ImmutableSet below in this blog.

MutableSet Categorically

Here’s the Venn Diagram for java.util.Set and MutableSet:

Categorizing the methods in MutableSet is pretty straightforward and fun. I did not categorize the methods for MutableSet in the book, Eclipse Collections Categorically. Since I wrote the book, I have written some code that categorizes collection types with feature-rich APIs. This is handy for quickly drawing diagrams and charts. Chapter 10 in the book covers a method category called Set Operations which is a category that is unique to Set types in Eclipse Collections. Chapter 10 covers examples of methods that one would expect to exist on a Set type like union(), intersect(), difference(), symmetricDifference(), and cartesianProduct(). These methods do no exist on java.util.Set. I explain how to implement these methods in the book using java.util.Set.

Here are all of 173 methods on MutableSet, grouped categorically.

The other methods included in Set Operations are powerSet(), unionInto(), intersectInto(), differenceInto(), and symmetricDifferenceInto(). The methods with the suffix Into place the results into a target Set that is passed as a second parameter.

The Converting category is large because there are symmetric converters to both Mutable and Immutable types. All of the converter methods are explained in the book.

ImmutableSet Categorically

Here’s the Venn Diagram for java.util.Set and ImmutableSet:

There is a subtle difference between MutableSet and ImmutableSet Venn Diagrams. The Set interface is not wholly contained in ImmutableSet bubble, as it was with MutableSet. Why is this? MutableSet extends java.util.Set. ImmutableSet does not extend java.util.Set. This difference in relationships between these interfaces leads to an interesting difference between the method categories for MutableSet and ImmutableSet.

Which category would you guess should be missing from ImmutableSet, that is included with MutableSet?

Here are all of 158 methods on ImmutableSet, grouped categorically.

If you guessed that the category Mutating is missing, you are correct. ImmutableSet has no mutating methods like add() and remove(). All Immutable collection interfaces in Eclipse Collections are contractually immutable, which means they contain no mutating methods in their API. There is a new category named Casting in this chart. The book explains the methods that are included in this category in detail. I will give a little spoiler and tell you the method names are castToSet() and castToCollection(). What type do you think these methods return, and why?

If you guessed java.util.Set and java.util.Collection, you are correct.

Final Thoughts

Categorizing methods in large feature-rich interfaces is a useful activity for helping developers learn the API. This is one of the primary lessons of the Eclipse Collections Categorically book. If you’re wondering why I don’t just categorize the methods in all of the types in Eclipse Collections source code, like I did the RichIterable interface, simply put, it is a lot of work! The picture below, which I included in the book in Chapter 2, shows the result for RichIterable in IntelliJ. I’ve zoomed into the graphic to make it very easy to see the detail. The left and middle examples show how RichIterable can be browsed in IntelliJ Structure View today with Eclipse Collections 11.1.0. I have categorized the methods using Custom Code Folding Regions in Eclipse Collections 12.x and the right example shows the resulting simplification of an expandable tree view of method categories.

I would prefer to wait for Javadoc to include a method category tag so the tooling will take care of things automagically. Today, I would have to use Custom Code Folding Regions in the source code so that IntelliJ can group methods in Structure view. Then I would have to write the Javadoc summary for all of the methods grouped by method category by hand. This is the most painful part to write. The Custom Code Folding regions is the most painful for a committer to have to review as it will be hard in the diff to tell if I accidentally deleted or changed anything.

It is easy enough for me to produce diagrams and charts today, by running some code and creating the diagrams in a presentation tool. Hopefully you can imagine what the method category tags in Javadoc should be able to produce for us in the future. I really think method categories will be a wonderful addition to the Javadoc toolkit.

If you’re interested in learning more about Eclipse Collections and how to organize a feature-rich library using method categories so it is easier to learn, then I would recommend checking out my new book — Eclipse Collections Categorically: Level up your programming game.

Thanks for reading!

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am also the author of the book, Eclipse Collections Categorically: Level up your programming game.

The rise of AI in software development has sparked discussions, excitement and criticism about vibe coding — the idea that developers let AI generate entire codebases based on natural language and …

The post Dibe Coding: The Developer-First Approach to AI-native Development appeared first on EclipseSource.

Eclipse Collections Categorically: Level up your programming game.

JavaOne and done!

Eclipse Collections Categorically is now available in paperback (color) as of March 16th, 2025. This is the day I arrived in San Francisco for JavaOne 2025. The book was released just in time to be available for purchase during JavaOne which takes place from March 18–20. Thank you in advance if you buy a copy! �

TL;DR — Book link

I will be giving a talk on Thursday March 20 with Vladimir Zakharov on Data Frames in Java. There are a lot of great talks to choose from this week, but I would be honored if you would join our talk. If you order the book and the book gets delivered in time and you bring it to our talk, I will be happy to sign it for you outside the room.

You can spot me walking around at JavaOne wearing one of these t-shirts that has a picture that is very similar to the cover of the book. I will also be in the JavaOne Community Keynote on Thursday morning.

This is my first book , and I’ve been focused on writing this book for the past year plus. It only took me twenty-one years to write this book. This is the book that I never knew I wanted to write, after I created and open sourced a collections framework in Java and then proceeded to work on for two decades. Life is funny, and usually happens when you are busy making other plans.

The paperback book is only available in color. The reaction so far to the over 200 code examples with color syntax highlighting in print has been very positive. A color hardback version of the book and an eBook version will be released eventually.

The nice thing about Eclipse Collections Categorically, like Eclipse Collections itself, is that the book has a long potential shelf life. Eclipse Collections is now twenty-one years old, and Eclipse Collections Categorically should continue to be relevant and useful to developers for a very long time, whether or not they regularly use Eclipse Collections.

Programming is a marvelous craft. I hope this book brings the joy of programming to those who read it. It has renewed the joy of programming I felt when I was eleven years old. This book is meant to be as fun to read on the inside as it is to look at on the outside.

Eclipse Collections is over one million lines of code. Eclipse Collections Categorically slices this feature-rich Java library up into several easy to remember categories of methods. If you can’t remember all the categories, they’re all available on the cover. In this sense, you can judge the contents of this book by its cover, and also by its t-shirt.

A quick guide to categories on the t-shirt and cover can be found here:

🟧 Counting
🟧 Testing
🟧 Finding
🟧 Filtering
🟧 Transforming
🟧 Grouping
🟧 Aggregating
🟧 Converting
🟧 Iterating
🟧 Mutating

Here’s a link to the current paperback version available on Amazon if you are interested in exploring the reading sample and perhaps purchasing. If you buy a copy and can find me at a conference or Java user group meetup, I would be happy to sign it for you.

Eclipse Collections Categorically: Level up your programming game

Thanks, and I hope you enjoy Eclipse Collections Categorically!

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.

In search of the simplification of our software building blocks

These are not the droids you are looking for

I spent the past year writing the most improbable of books. The book is a story about how to learn and effectively leverage a twenty-one year old collections library, built in Java, for Java developers. The book contains knowledge learned in the last century, in the days when developers wielded Smalltalk like a light saber. The book lowers the cost of learning a feature-rich, million plus LOC Java collections library named Eclipse Collections to help developers write more concise and readable code. It does this by leveraging information chunking techniques to group hundreds of methods in its rich API into several method categories explained with color syntax highlighted code examples in eight chapters. The book is a reminder that programming is fun, not just a tedious necessity.

Book: Eclipse Collections Categorically

The book contains some revelations, and effective strategies for many developers to leverage in the building of their own better building blocks. It is a reminder that the code we build our applications with is important. It is also a reminder that every developer who invests in themselves and others for the long term is going to be more valuable than every LLM that they may decide to leverage to augment their own development speed.

We’re not there yet

I believe using LLMs to generate code based on the building blocks we have today is going to be a costly decision. I think it would be much better to focus significant energy and resources on building better building blocks to help us simplify how we build applications. If AI can be used to help build those better building blocks, then great! One of the biggest problems that we face with technology today is the sheer complexity of the building blocks we need to deal with when building applications. 3d printing our applications with AI code generators trained on code we and others have written previously will not improve the complexity we need to deal with. It will just generate a huge morass of code, that someone down the road will still need to understand and maintain. This is not a problem caused by the LLMs, it is a problem we caused for ourselves.

Today, when we build applications we use the equivalent of Lego, Erector Set, Lincoln Logs, Etch-a-sketch, Play-doh, and copious amounts of Super Glue. We have to be experts in all of them.

I see the gradual improvements being made to languages like Java (and other JVM languages), Python, C++, C#, JavaScript, Rust, Go, Swift, and can’t help wonder what will happen when we use fast concrete to quickly build apps based on soon to be outdated versions of all these languages. Multiply all of these by the huge number of libraries build in each of these ecosystems. Tools like OpenRewrite will likely see significant use in trying to keep applications up to date and current, but I think we will quickly forget how to keep our developers up to date on all of the components and versions.

Where do we go from here

I would like to see much more investment into the underlying infrastructure (programming languages, libraries, etc.) that we use to build our applications. Let’s simplify things, before we drown ourselves in the fast concrete homes that AI salespeople promise us that LLMs will build for us.

In 1997, I built Distributed Smalltalk applications with DB2 as a relational back-end. Everything from the UI, to the RPC, to the data access and integration logic (e.g. direct manipulation of Excel files) was built in a single language — Smalltalk. The client app was built in Smalltalk. The server apps were built in Smalltalk. The remote monitoring and administration app was built in Smalltalk. One person could understand and maintain the application in its entirety, even though it was a multi-tier distributed app. The days of this kind of uniform simplicity are long gone, and I never quite understood why we headed down the road of complexity we now find ourselves in.

The web got us strangely dazed and confused in the late 1990s and early 2000s. We started building apps with multiple teams doing front-end and back-end development. We went quickly through numerous generations of UI frameworks, RPC solutions, backend mapping layers, and database storage platforms. The first to deliver solutions were often rewarded, even though the underlying infra was often slapped together. Those that could evolve to scale continued to survive.

The problem with generating our applications based on where we are, is that we will wind up exactly where we are, just with too much code for too few well trained, and experienced developers to maintain. We have some very smart people working on developing programming languages and libraries. I hope we continue to invest sufficiently in them so we can help simplify our building blocks.

I encourage you to keep investing in yourselves and other developers in your communities. We will need to help each other to keep ourselves from drowning in the complexity of our own making. I wrote my book to pass on so many of the lessons I have learned in the past 35 years of my own career. I hope the knowledge I share serves you well, and that we all wind up in a better software development future, not just stuck firmly where we already are. I hope others will continue sharing their stories in blogs and books. Not to feed the LLMs more text, but to feed each other new ideas so we can survive and thrive.

I can’t predict the future, but my hope for the future is for billions of happy and healthy humans exploring and expanding upon their creativity, aided by better tools that we can all hope to understand. Thanks for reading.

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am also the author of the book, Eclipse Collections Categorically: Level up your programming game.

JavaOne 2025, celebrating the 30th birthday of the Java programming language, was held at the Oracle Conference Center in Redwood Shores, California. This three-day event consisted of 80 sessions and hand-on labs, and two keynotes. Day Two, scheduled on March 19th, 2025, included presentations from various conference tracks.

Many Eclipse developers (mis)use logging for debug messages. As the result, the Error Log view in Eclipse, which is supposed to show important errors or warnings, is quickly filled up with debug infos, hiding relevant warnings or errors:

But there is advanced tracing capability built in into Eclipse that provides exactly the required functionality (reporting low level, debug related information) and doesn't spam the Error Log view by default.

Here is the "classic" introduction into tracing that explains briefly the idea of debug tracing. Note, that tracing is switched off by default but can be switched on via command line or by a user via General -> Tracing preferences, so tracing functionality is available not only during debug session.

It is pretty straightforward to enable tracing for a plug-in.

Steps:

1. Remove the current code to read any debug options flag from your plug-in (all what you did after reading article above :-))
2. Your plug-in's activator must implement org.eclipse.osgi.service.debug.DebugOptionsListener
3. In the plug-in's activator start(BundleContext context) method register debug options listener with the OSGI framework
4. Create boolean fields to cache the debug flags state
5. Update the flag state in the optionsChanged(DebugOptions options) method of the DebugOptionsListener interface (added in step 2)

Here is a simple code that does that:

To make your options show up in the preferences dialog:

• Contribute to the org.eclipse.ui.trace.traceComponents extension point in the plugin.xml and add your bundle entry there:

• Create a new .options file in the plugin directory with following content:
  
  

  your_bundle_symbolic_name_as_in_the_manifest/debug=false

  your_bundle_symbolic_name_as_in_the_manifest/debug/traceExtraData=false

  
  
• and add it to the build.properties (so it is shipped with the bundle):
  
  bin.includes = .options,\

Twenty-one years is just a page turn in the general scheme of things

Maybe I should write a book

After five years of blogging publicly, friends and colleagues began telling me that I should write a book. It would be easy they said. I could just wire together some of my (at the time) hundred and fifty plus blogs they said. I wish writing a book was that simple. But then again, if it was, it probably wouldn’t be as good.

I thought about it for a while, and figured after the twentieth anniversary of Eclipse Collections in 2024, I should either write a book about it, or stop working on it. I decided to write the book. This is the story of how I transitioned from a general idea to a specific story about Eclipse Collections. There will be an announcement coming soon when the book is available for purchase.

Announcement (March 19, 2025):

The book has been released on Amazon. I blogged about it below. There is a link to the book on Amazon in the blog.

Book: Eclipse Collections Categorically

What should I write about?

I spent a year trying to figure out how to approach writing a book about Eclipse Collections. Writing a book about an open source data structures and algorithms library was challenging. The problem wasn’t generating content. I had written hundreds of blogs of content over the years. I had worked on Eclipse Collections for twenty years, so there are hundreds of blogs of content still locked up in my brain waiting to be typed in. I have enough content to write five or six books on Eclipse Collections.

The problem is that I wanted to write a book that I would want to read. Of course, I’d like others to want to read it as well.

Folks who discussed my struggles finding a storyline with me suggested I should try and draft a table of contents. So I tried that… several times. I hated every single TOC I drafted. As quickly as I wrote them down, I threw them out.

I spoke to lots of friends and my family in 2023 about my desire to write a book about Eclipse Collections. I continued blogging, and even tried writing different kinds of blogs about Eclipse Collections. Those blogs confirmed for me what I already instinctively knew. It is very easy to write a reference guide for a library like Eclipse Collections. The challenge is to write a compelling story.

Taking a long walk into the story

I decided to take a break from work in 2024 and focus on writing the book. It helps to have time availability and time pressure sometimes if you want to complete something. I started out by taking a seventeen day road trip with my wife down and up the east coast of the U.S. I didn’t really think much at all about writing. I just enjoyed seeing sites and finding places to stay as we drove all the way down the the Florida Keys. This was the best idea I’ve had in a long long time. I always wanted to drive the bridges in the Florida Keys, and now I’ve done it twice, in one year.

I wrote a couple of interesting blogs before leaving on the road trip. Together these blogs have over 25K views so far. I didn’t realize it at the time but these blogs were a hint to me about what might work for a story about Eclipse Collections in a book.

• What if null was an Object in Java?
• What if Java had no if?
• What if Java had no for?

When I returned from the road trip, I stared at my computer screen for days on end, trying to write something. I deleted a lot of random stuff I started writing. Getting started is hard.

I pondered about what made the three blogs I had written over ten days in the beginning of January interesting to readers. I thought maybe the blogs made Java developers think about things they might not have thought about before. At least not in the same way that I explored the questions. I found myself comparing my experience as a former Smalltalk developer and adapting it to what might be possible in Java if folks found it interesting.

Most Java developers have never experienced programming in Smalltalk. This has been my experience over the years anyway. Smalltalk has helped provide myself and other Smalltalk developers a different perspective on what software development can be like.

It wasn’t clear to me at that moment how my experience in Smalltalk was going to help me write a book I would want to read. After six months of writing, it would suddenly become very clear that a feature of Smalltalk I had not thought much about would drive the organization of my book.

Just write it

It took me at least a month, maybe two, to write the first chapter. Chapter one in the early stages felt like writing a history of two programming languages. There was a lot of useful content, but it failed miserably to be compelling in the context of a book. I finally just said “stuff it” after writing almost thirty pages and moved on to chapter two. I knew that I would wage battle with chapter one many times before I would be done.

Chapter two contained a lot of Eclipse Collections fundamentals. I wrote the content in chapter two in about month. The content was dry and somewhat disjointed at first, but most of it was good and necessary. I wasn’t very happy with the setup for the story in chapter one or two. The content felt like two useful blogs, but not something someone would want to sit down and read. I got some great advice from my friend Chandra Guntur who suggested I just start writing chapter three. Once I finished chapter three, I found a steady pace and got drafts written through chapter ten by mid summer, just in time to go to JCrete.

I would go back and spend a month or two rewriting and editing chapters one and two. They were the hardest chapters to write, and to get right. After much constructive review feedback from some great technical reviewers, I rewrote chapter one maybe nine or ten times before feeling like I had the beginning of the story I wanted. Chapter one would prove a great producer of content that was ultimately moved to the appendices. There was also some content that just got deleted. The content was not bad. It was just incomplete thoughts and possibly some great ideas for other books in the future. The content just didn’t fit well in the story of this book.

What if Java had Method Categories?

I wrote last year a few times about my re-discovery of method categories and the potential impact of this lesser known Smalltalk feature on Java and other programming languages with feature rich APIs. This feature is so simple (and good) it was staring me in the face for thirty years, and I just didn’t recognize its potential for Java.

Grouping Java methods using custom code folding regions with IntelliJ

This blog will show you the insights I discovered about method categories while writing the book. It will also explain how I was able to simulate method categories in Eclipse Collections today, in both the IDE and Javadoc.

My book answers the question “What if Java had Method Categories?”, specifically in the context of Eclipse Collections. I found the way I could write the story about Eclipse Collections that I can enjoy reading. I have read the story several times, and it surprises me every time. It has renewed the joy of programming for me. I hope it will renew the joy of programming for others as well.

I can only guarantee one thing for you. This will be the best and worst book about Eclipse Collections you will read this year.

I wrote it and the book will be out soon

I received my first proof copies of my book yesterday. It was very exciting. My plan (fingers crossed) is to have the book published and available for purchase before JavaOne (March 18–20). I will blog again here once the publishing date is set in stone. I will share an image of the cover once I receive my author copies. The proof copies had a “Not for Resale” banner across them so not quite as nice for sharing.

It is a strange and exhilarating feeling to hold a book with over 400 pages that weighs two pounds with your name on the cover. It’s also strange to be holding a book written about something you created twenty one years earlier. Did I really do that? This journey has taken a very long time. I hope my journey will inform and inspire others to take their own journeys.

I wrote this book for myself and for my family. I have given my first printed manuscript and a proof copy to my parents, who are enjoying reading a story their son wrote, even though Java programming is a foreign language to both of them. The foreword and preface was fun for them to read because they never really understood what I have been working on for the past twenty one years. Explaining that you created and work on an open source collections library written in Java to your parents, means absolutely nothing to them. At least now they can page through over 200 code examples in a book and try and piece together a little bit of what my twenty one years of working on Eclipse Collections has been like.

Since you read this far… the title of the book is “Eclipse Collections Categorically.”

Thanks for reading!

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.

We are excited to introduce a powerful feature available in the AI-powered Theia IDE and the underlying Theia AI framework: SCANOSS integration. SCANOSS scans AI-generated (and of course any other) …

The post Introducing SCANOSS Integration in Theia: Transparent License Compliance for AI-Generated Code appeared first on EclipseSource.

We are happy to announce the ninth Eclipse Theia community release “2025-02”, version 1.58.x! New to Eclipse Theia? It is the next-generation platform for building IDEs and tools for the web or …

The post The Eclipse Theia Community Release 2025-02 appeared first on EclipseSource.

We are excited to announce the public release of Theia AI, an open framework that empowers tool vendors to seamlessly integrate cutting-edge AI capabilities into their custom tools and IDEs. As part …

The post Introducing Theia AI: The Open Framework for Building AI-native Custom Tools and IDEs appeared first on EclipseSource.

We’re happy to announce the alpha release of the AI-powered Theia IDE, the open source development environment that puts the power of AI in your hands—with full transparency and control. Unlike …

The post Introducing the AI-powered Theia IDE: AI-driven coding with full Control appeared first on EclipseSource.

More news

GitHub has recently introduced GitHub Models, a free service that allows developers to experiment with selected AI models via an API. While this service is not suitable for production use due to rate …

The post Testing the AI-Powered Theia IDE and Theia AI Applications for Free Using GitHub Models appeared first on EclipseSource.

When discussing AI integration in development environments, the conversation often centers around chat interfaces. While chat-based interactions with AI are powerful, they represent just one dimension …

The post Beyond AI Chat Agents with Theia AI appeared first on EclipseSource.

In modern development environments, AI assistants have become indispensable for enhancing developer productivity. However, a persistent challenge has been presenting complex AI-suggested changes to …

The post Theia AI Change Sets: Managing Complex AI Change Suggestions appeared first on EclipseSource.

I am delighted to announce the release of Eclipse CDT 12 and CDT LSP 3, which will be generally available this Wednesday as part of the Eclipse IDE 2025-03 release.

The preferred way to get CDT is to install Eclipse CDT as part of the Eclipse IDE for C/C++ Developers using the installer. Further release information on how to get CDT will be published on Wednesday on the GitHub CDT 12 release page.

The two themes for the CDT 12 release are highlighting the new C/C++ editing experience based on the CDT LSP project by leveraging clangd and improved CMake integration, especially for CDT extenders. But there are many other new and noteworthy items, along with over 200 issues and PRs closed across CDT and CDT LSP repos.

Here is a video highlight of the new C/C++ Editing Experience based on the Language Server Protocol (LSP) using clangd and showing the improved CMake integration.

We are happy to announce the Eclipse Theia 1.59 release! The release contains in total 95 merged pull requests. In this article, we will highlight some selected improvements and provide an overview of …

The post Eclipse Theia 1.59 Release: News and Noteworthy appeared first on EclipseSource.

Meet Theia Coder, an open, flexible, and transparent AI coding assistant designed to seamlessly integrate into your development workflow. It can generate and apply code and arbitrary file changes …

The post Introducing Theia Coder - the open AI coding agent with full control appeared first on EclipseSource.

Imagine a world where your AI-powered IDE can manage your development workflows, e.g. the entire Git process—branching, committing, viewing diffs, and more—at your command. With the AI-powered Theia …

The post Let AI commit (to) your work - With Theia AI, Git and MCP appeared first on EclipseSource.

In today’s AI-powered tools, giving users the ability to scope their requests with relevant context is essential. Whether it’s a file, a symbol, a hardware component, or any other domain-specific …

The post Enhancing Your Tools with Chat Context in Theia AI appeared first on EclipseSource.

We are pleased to announce that the Eclipse Foundation has been selected by the Sovereign Tech Agency for a new service agreement. Through this collaboration, the Sovereign Tech Fund—a program of the Sovereign Tech Agency—will invest in the development, improvement, and maintenance of open digital base technologies worldwide, driving significant security enhancements across Eclipse Foundation projects.

Why This Matters

Open source software is the backbone of countless industries and technologies. At the Eclipse Foundation, we host a diverse range of critical projects, including:

• Eclipse IDE — Powers approximately 10% of developers worldwide and widely used in embedded systems and hardware development.
• Jakarta EE — Provides enterprise-grade Java APIs for leading application servers, including Payara, WildFly, Apache TomEE, and more.
• Eclipse Jetty — A high-performance web server essential for scalable and secure web applications, referenced by over 3,700 artifacts in the Maven Central repository.
• Eclipse Temurin — Delivers secure, high-quality Java distributions, with over 20 million downloads each month.
• Eclipse GlassFish — Offers cloud-native Jakarta EE implementations.
• Eclipse Software Defined Vehicle (SDV) — Collaborates with major European automotive manufacturers to shape the future of software-defined vehicles.

For more than two decades, Java has remained one of the top five programming languages, underpinning critical systems in finance, healthcare, aerospace, and power grid management. Ensuring robust security and reliability for these foundational tools is paramount. Our engagement with the Sovereign Tech Agency will further strengthen the security and long-term sustainability of these essential open source technologies.

What Is Being Commissioned?

The Sovereign Tech Fund is funding two key initiatives to enhance security, transparency, and vulnerability management across the Eclipse Foundation ecosystem:

1. Software Bill of Materials (SBOM) Generation

• Integration into Build Pipelines – SBOM generation will be embedded directly into the build processes of Eclipse Foundation projects.
• Central SBOM Registry – A unified repository will provide clear insights into components and dependencies across our portfolio.
• SBOM Tools Evaluation – We will assess and select the most effective tools for various project categories, ensuring compatibility with diverse technology stacks.
• Eclipse IDE Support – SBOM generation capabilities will be developed for Eclipse IDE products, enabling developers to effortlessly produce SBOMs for custom IDEs and products developed on top of the Eclipse Platform.

2. Vulnerability Management Enhancement

• Continuous Vulnerability Monitoring – We will implement ongoing monitoring solutions to rapidly detect newly discovered vulnerabilities in project dependencies, even post-release.
• Developer Education and Best Practices – Training and resources will empower maintainers and contributors to triage and remediate security issues swiftly, strengthening our overall ecosystem.
• New Tooling and Automation – Investments in advanced scanners and management platforms will streamline vulnerability detection, reporting, and resolution.

These initiatives will reinforce our supply chain security, enhance transparency, and ensure that Eclipse Foundation’s open source projects remain reliable and resilient for the millions of developers who depend on them.

Looking Ahead

Our partnership with the Sovereign Tech Agency underscores our commitment to open source security and quality. This service agreement further solidifies the Eclipse Foundation’s leadership in delivering critical software technologies worldwide. Ultimately, this collaboration will benefit organisations of all sizes—from large enterprises to individual contributors—who rely on open source software to power their infrastructure, operations, and innovation.

Stay tuned for updates as we make progress on these initiatives. We look forward to sharing new features, best practices, and milestones that will help secure the future of open source technology for everyone.

For additional details about this collaboration, visit the Sovereign Tech Fund’s technology page in English and German.

For more information about the work of the Sovereign Tech Fund—an initiative of the Sovereign Tech Agency—please visit their official website.

Great news for fans of cutting-edge AI: Theia AI and the AI-powered Theia IDE support the latest GPT-4.5-preview model right out of the box! Wondering what’s new or haven’t heard of Theia AI yet? Be …

The post Theia AI and the AI-powered Theia IDE support GPT-4.5-preview by default! appeared first on EclipseSource.

The landscape of large language models (LLMs) is rapidly evolving, with numerous models available and new ones released every day. These models can be accessed through cloud-based services, on-premise …

The post Why Theia supports any LLM! appeared first on EclipseSource.

Building tools or Integrated Development Environments (IDEs) is a complex process, and without a clear strategy, it’s easy to get lost in technical details too soon. At EclipseSource, our blog …

The post How to Build a Custom IDE or Tool appeared first on EclipseSource.

Eclipse Ditto team is excited to announce the availability of a new minor release, including new features: Ditto 3.7.0.

The focus of this release was to ease the migration of Things “definitions” (following WoT Things Models) and to provide a new Policy decision API to check permissions for a logged-in user.
On the operating side, it is now possible to configure extra fields to be proactively added to Things in order to optimize cluster roundtrips and to throttle the amount of updates to the search index after a re-used policy was updated.

Adoption

Companies are willing to show their adoption of Eclipse Ditto publicly: https://iot.eclipse.org/adopters/?#iot.ditto

When you use Eclipse Ditto it would be great to support the project by putting your logo there.

Changelog

The main improvements and additions of Ditto 3.7.0 are:

• Introduce new Policy decision API to check with a single request what a logged-in user is allowed to do with a specific resource
• Include current entity revision of a resource (thing and policy) in the response of requests (commands) and in all emitted events
• Support updating referenced WoT ThingModel based thing definition for a Thing by defining a migration payload and when to apply it

The following non-functional work is also included:

• Add option to configure pre-defined extra fields (enrichments) to be proactively added internally in Ditto in order to save cluster roundtrips
• Include throttling configuration option for updating the search index as a result of a policy update targeting many things
• Add namespace to Ditto Helm chart managed Kubernetes resources

The following notable fixes are included:

• Fix flattening of JSON objects in arrays when an exists() RQL condition was used e.g. as a Ditto evaluated condition

Please have a look at the 3.7.0 release notes for a more detailed information on the release.

Artifacts

The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central.

The Ditto JavaScript client release was published on npmjs.com:

• @eclipse-ditto/ditto-javascript-client-dom
• @eclipse-ditto/ditto-javascript-client-node

The Docker images have been pushed to Docker Hub:

• eclipse/ditto-policies
• eclipse/ditto-things
• eclipse/ditto-things-search
• eclipse/ditto-gateway
• eclipse/ditto-connectivity

The Ditto Helm chart has been published to Docker Hub:

• eclipse/ditto

–
The Eclipse Ditto team

Exciting news for developers and tool builders: Yesterday, the new Anthropic model Claude 3.7 Sonnet has been released and Theia AI and the AI-powered Theia IDE now support the new model right out of …

The post Theia AI and the AI-powered Theia IDE support Claude 3.7 Sonnet out-of-the-box appeared first on EclipseSource.

Recent reports indicate that cybercriminals are exploiting the Windows DLL side-loading technique using the legitimate jarsigner.exe executable to propagate malware. This binary is commonly included in Java distributions such as Eclipse Temurin, which is also bundled with the Eclipse Integrated Development Environment (IDE). This has understandably raised concerns about the role of our software and whether the Eclipse Foundation or its projects bear any responsibility.

As the Head of Security at the Eclipse Foundation, I want to clarify the situation, explain DLL side-loading, and reaffirm our commitment to security and collaboration with the community. My goal is to provide a clear understanding of both the technical aspects of this misuse and our approach to maintaining a secure ecosystem.

Understanding the Situation

Dynamically Loaded Libraries (DLL) side-loading, or DLL hijacking, is a well-documented Windows vulnerability. It occurs when an application like jarsigner.exe starts up and Windows loads required DLLs. It is important to note that this attack can exploit any other legitimate, signed binary that loads DLLs, as seen in multiple past security exploits. If an attacker places a malicious DLL in a directory prioritized by Windows’ search order, the system may load the rogue library instead of (or alongside) the legitimate one.

The sequence of events leading to malware infection unfolds as follows:

1. The victim downloads a ZIP file from a rogue website or a malicious email, often with an enticing name such as Employee Performance Report and Termination List.zip, as initially reported by AhnLab.
2. The victim opens or extracts the contents of the ZIP file.
3. Executing the (renamed) .exe file triggers the infection. In the initial report, the executable attempted to masquerade as a regular document, though its name—Documents2012.exe—was already suspicious.

In this case, the Eclipse Temurin distribution of jarsigner.exe remains unmodified and legitimate. It is merely renamed and packed within the ZIP file distributed by malicious actors. The attack relies on an attacker-supplied DLL placed alongside the trustworthy executable, not on any flaw within jarsigner.exe itself.

Why This Does Not Implicate Eclipse Temurin or the Eclipse Foundation

The misuse of jarsigner.exe stems from Windows’ DLL loading behavior, not a vulnerability in Eclipse Temurin. The technique affects countless Windows applications and does not reflect a security flaw in Eclipse Foundation software.

There is no evidence of compromise within the Eclipse Foundation’s infrastructure, Temurin build systems, or projects—not that an attacker would need any. Attackers are simply leveraging a legitimate, signed binary post-distribution by bundling it with malicious files.

Our Response

Although this is not an Eclipse Foundation software vulnerability, security remains our top priority. We actively engage with project teams, security researchers, and downstream distributors to share information and mitigate risks. Even when an issue originates outside our control, we take steps to help users protect themselves and their organisations.

We continuously monitor security advisories and threat intelligence to detect potential misuse. When relevant, we update our documentation with best practices to help users secure their environments. If packaging or configuration adjustments can reduce DLL hijacking risks, we collaborate with downstream maintainers to implement them.

We strongly encourage Windows users and organisations to adopt proven defenses against DLL side-loading, including:

• Application whitelisting to restrict execution of unauthorised binaries.
• Code integrity policies to enforce signed DLL execution.
• Strict application control policies using tools like Windows AppLocker.
• File integrity monitoring to detect unexpected DLLs near trusted executables.
• Principle of least privilege restricting write access to application directories to prevent attackers from placing malicious DLLs.

Looking Ahead

The Eclipse Foundation remains committed to open collaboration and secure software development. While DLL side-loading is a Windows OS issue—not a flaw in Eclipse Temurin, the Eclipse IDE or jarsigner.exe—we take a responsible, transparent approach to securing the software supply chain. Specifically, we provide guidance to all Eclipse Foundation projects as needed, including best practices for hardening executables against malicious actors

We appreciate the security researchers and organisations who brought attention to this issue. By clarifying the technique and its risks, we aim to help organisations enhance their defenses against such threats.

Attackers will continue to misuse legitimate software. While Eclipse Temurin’s jarsigner.exe has been targeted in this case, the real issue lies in Windows’ DLL search order, not a vulnerability in our software.

As always, we remain committed to supporting our users, collaborating with security professionals, and taking proactive measures to safeguard the integrity of the Eclipse ecosystem.

For security concerns or questions, contact our Security Team.

References & Further Reading

• The Hacker News: Cybercriminals Use Eclipse JARsigner to Evade Detection
• AhnLab ASEC Blog: Cybercriminals Abusing Eclipse JARsigner
• MITRE ATT&CK: T1574.002 - DLL Search Order Hijacking
• Eclipse Temurin / Adoptium Project
• Eclipse Foundation Security Policies

The code quality metric that gives Java syntax a metal boost

Many of us muse about the readability of code, and pontificate on the idea of code quality. We complain about the verbosity, pedestrian syntax, and cryptic nature of some programming languages.

But how many of us have tried to sing our code?

I’ve shared the video above with my family and friends. I head bang and laugh hysterically every time the Java syntax is sung aloud! Exclamation point.

If you’ve lost your love of programming, are feeling overwhelmed by learning a programming language, are contemplating changing your career, or are worried about being rendered unemployed by AI, then I recommend you watch this video. It is a great reminder that the creativity of humans remains unmatched, and that even the cryptic syntax of a programming language can be fun. Period. This video by NANOWAR OF STEEL has become an instant classic in the Java community.

Now, if someone tells me this song was actually created by a LLM, I will say it was the best use of a LLM to date. Period.

Enjoy! Exclamation point.

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.

In today’s AI-powered development environments (IDEs) and tools, chat interactions are no longer just about answering questions. They have evolved into dynamic dialogues where the AI can ask users for …

The post Introducing Interactive AI Flows in Theia AI appeared first on EclipseSource.

The Theia Cloud project is an open-source framework designed to host Theia-based applications in the cloud, allowing users to access their development environments without the need for local …

The post Theia Cloud Progress, Contributions, and the Road to 1.0 appeared first on EclipseSource.

The past week has witnessed a surge of excitement surrounding DeepSeek, a Chinese AI startup that has made significant waves in the AI landscape. We were of course eager to explore the DeepSeek models …

The post Integrating DeepSeek into the Theia IDE and Theia AI appeared first on EclipseSource.

We are happy to announce the Eclipse Theia 1.58 release! The release contains in total 95 merged pull requests. In this article, we will highlight some selected improvements and provide an overview of …

The post Eclipse Theia 1.58 Release: News and Noteworthy appeared first on EclipseSource.

Over the last decade, the landscape of development tools and Integrated Development Environments (IDEs) has undergone a significant transformation, thanks to the switch to web technologies and the …

The post Modern (web-based) Tool and IDEs: Definitions, Concepts and Architecture appeared first on EclipseSource.

Exciting news for developers and tool builders: Theia AI and the AI-powered Theia IDE now support the new o3-mini and o1 models right out of the box. These models can be used seamlessly without any …

The post Theia AI and Theia IDE support o3-mini and o1 appeared first on EclipseSource.

An example of the convenience of inheritance in Java gone wrong

Statue extends Bird

Please file this in the “Statue extends Bird” category of inheritance lessons in Java. Consider this a cautionary tale of leveraging an inheritance relationship between utility classes purely for a convenience. It’s hard to remove Bird once it has been extended as Statue.

When we think of inheritance in Java, we usually think of classes that override instance methods from a parent class. The parent class may define some common attributes and behaviors, and the child class can add additional attributes and behaviors in addition to being able to use the parents attributes with a suitable scope defined and specialize the behaviors that were defined in the parent, also with a suitable scope defined.

We don’t usually think of inheriting static methods defined in utility classes. In this blog, I will share an example of a static utility class that extends another static utility class.

The Futility of Utility

Don’t create a static utility class that extends another static utility class. Even if the convenience feels overwhelmingly amazing, resist the temptation. If you are a library developer creating a static utility class, you can help prevent others from the potential pain by making the class final.

I have written and spoken about what I call the futility of utility before, but this is a new kind of futility of a utility class. When you build Statue and extend Bird, you potentially accumulate $hi+ that you don’t define, but that you and your clients become increasingly dependent on. The Bird doesn’t know about the Statue. Over many years, it may unknowingly add new methods on the Statue. Those methods harden over time so the Statue may look like is an extension of the Bird. The Statue is not the Bird, but the Statue was designed to be Bird.

The methods defined on the Bird will probably be great, appropriate, and extremely useful. The Statue extending the Bird is not the decision of the Bird, even if the Bird allows itself to be extended. It is the decision of the designers of the Statue. They have designed a BirdButStatue utility class.

As a developer who has designed Java utility classes over the year, I try and prevent others from making the same mistakes I have made or allowed, by making utility classes I add final. This makes it clear that the utility class is to only be used, as the final keyword makes it impossible to extend. If you find a utility class in Eclipse Collections that is not final, please report it as a potential bug via the GitHub issue tracker. Java library designers may have good reasons to not make a utility class final, and hopefully document those reasons and leave guidance to future developers who depend on the utility classes.

AssertButVerify

There is a module in Eclipse Collections that is published as a separate .jar with a utility class with only static methods named Verify. Verify extends Assert, which also only has static methods that are public. Verify can do everything that Assert can do. You can call public static methods on Verify, which are actually defined on Assert, and may or may not be “hiding” as specifically defined methods on Verify.

This is the current class definition for the Verify utility class in Eclipse Collections. Thankfully, no class can further extend Verify. Verify has been designed this way for over a decade, and has had absolutely no issues.

public final class Verify extends Assert

Why does Verify extend Assert?

Verify was a utility class created a long time ago to make it easy to assert specific things about Collection and Iterable types. The assertions on Verify have intention revealing names about what is being asserted about various collection types. A complete list of the methods on Verify can be seen in a table below. The methods on this class are used extensively for testing collections in Eclipse Collections. A convenience decision was made to have Verify extend the Assert class, so that we didn’t have to switch between using Verify and Assert for common assertions in test cases (e.g. assertEquals, assertNull). Verify is Assert, but also Verify. This was convenient for use in Eclipse Collections, because we didn’t have to remember which assertion methods were on Assert and which were on Verify, and could just import one class — Verify. When we open sourced Eclipse Collections and made the class public in the eclipse-collections-testutils.jar, our hands became unknowingly and unfortunately tied with this old inheritance dependency decision. Users of the library may have been potentially using the static methods defined on Assert that are available via Verify. This has not caused any issues for Eclipse Collections users or library developers, until now. I will explain what the issue is in the next section.

The following table shows the list of distinct and shared methods between Verify and Assert. Assert has no distinct methods in this table, because Verify extends Assert. If I drew a Venn Diagram to show the relationship, Assert would be completely contained within Verify.

As can be seen by the table above, Verify has a large number of distinct assert methods (165) for developers to use. These methods are extremely useful if you write a lot of collection tests. Bolting an additional 56 methods was purely convenience so we didn’t need to remember whether a method was on Verify or if it was on Assert. We got all the methods in one place. One less import! Yay!

This turns out to be a convenience gone wrong. Thankfully, we will be fixing this unfortunate design decision in the Eclipse Collections 12.0 release, when we are also upgrading to JUnit 5.

All Your Assertions R Belong to Us

We are looking to upgrade from JUnit 4 to JUnit 5 in Eclipse Collections, and this is now causing some short-term pain for the developers working on the library. We have no quick and easy way out of this decades old decision, but there is a path to correcting this convenience design decision, and it is being worked on now.

Eclipse Collections is in the process of upgrading to JUnit 5. As seen above, Verify has a public API that currently extends the public API of Assert. The type junit.org.Assert is a utility class in JUnit 4. There is a new utility class in JUnit 5 that should be used instead of Assert named Assertions, which we have been migrating all of our tests to. What should we do with Verify? Should it be changed to extend Assertions in JUnit 5?

Old Statue seeking new BiggerBird to supply convenience

No, No, No. Although the Assertions class does not prevent Verify from extending it, there is very helpful guidance in the JavaDoc of Assertions from the JUnit team.

We decided even before reading this guidance, that we would break the inheritance dependency between Assert and Verify, and not repeat the same convenience mistake with Assertions. If Verify were changed to extend Assertions, we would have replaced a pigeon-sized bird with an ostrich-sized bird. The Assertions class would add an additional 265 methods to the Verify class if we extended it. This is in addition to the 26 methods we would need to add by hand that Assertions doesn’t have in common with the Assert class. Imagine if we did this what it might be like to eventually upgrade Verify to JUnit 6. Ouch!

We don’t like making breaking changes in Eclipse Collections. We are still deciding whether we will make a source breaking change with Verify once we correct the decision to extend Assert . My current thinking is to add all of the Assert methods as deprecated for removal and throw UnsupportedOperationException in all of them with a JavaDoc example and a link to the equivalent method in Assertions to use. When we release the next major release of Eclipse Collections we can then “safely” remove all of the deprecated methods. Phew!

Convenience has a shelf life. Changing inheritance design decisions can be painful and take a long time to correct.

In case you didn’t know

I spoke to a long time Java developer this week who was not aware that static methods can be “inherited” by subclasses. This is an oddity many developers hopefully won’t encounter in their daily development! If you add a static method with the same signature in a subclass, it is referred to as “hiding” not “overriding” the same method in the parent class. If you call static methods on instances of a subclass, the static method that is called will depend on the type of the variable which holds onto the instance. Even if a subclass hides a static method, if the type of an instance of a subtype is set to the superclass type, the static method that is called will be the one defined on the superclass.

If you haven’t heard of or encountered this feature before, the following link might be useful. There are also some blogs out there you can search for to find out how method “hiding” works with static methods on classes.

Overriding and Hiding Methods

Thankfully, this static method inheritance feature is not available for static methods on interfaces. This is a very good thing, IMO. It would have made it potentially very messy to add the of() factory methods to List, Set, and Map. The SortedSet interface extends Set, and the SortedMap interface extends Map, but neither interface defines their own of() methods. Imagine if the SortedSet and SortedMap interfaces inherited the of() method from Set and Map. That would be very odd.

Final thoughts

My recommendation is to make your static utility classes final. If you’re going to define a utility class with only static methods, make sure you have a very good reason to not make the class final. My recommendation for users of libraries, don’t extend static utility classes if you are building your own utility classes. You don’t want to turn a Bird into a Statue. Add only the behaviors you need and keep your Statue independent and clean. Just use static utility methods as intended, do not extend them.

Thanks for reading!

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.

The Eclipse Foundation is excited to announce the formation of the Eclipse Cloud Interest Group, aimed at empowering cloud providers, users, and industry vendors to independently build, manage, and operate cloud services, promoting freedom from vendor lock-in, interoperability, and resilience across diverse cloud environments.

Why This Matters

In today’s digital landscape, the need for flexible, scalable and interoperable cloud solutions has never been greater. Vendor lock-in can stifle innovation, limit choices, and create unnecessary barriers for cloud users. The Eclipse Cloud Interest Group believes that cloud autonomy and interoperability are the keys to unlocking the full potential of cloud technologies. Imagine being able to switch between cloud providers seamlessly, adopt services that best meet your needs, and ensure your operations remain resilient no matter the platform. That’s the vision we’re working to achieve.

How We’re Making a Difference

This initiative doesn’t prescribe specific technologies or methods for building cloud infrastructure and service. Rather, it focuses on creating a framework for interoperability and portability. Key components like virtualisation, containerisation, orchestration, observability, billing, and identity management should be accessible, switchable, and manageable across different platforms. The goal? To make multi-cloud environments not just possible but practical and efficient.

To support this goal, the group will focus on several key areas, including the emergence of critical cloud components necessary for the development of autonomous cloud infrastructures, cloud service portability, and multi-cloud managed services interoperability. The group will also investigate ways to ensure that cloud  services not only meet interoperability requirements but also adhere to expected quality, performance, and service level standards.

Our work is rooted in open source technologies, which already power much of today’s cloud infrastructure. By leveraging existing projects like Eclipse Xpanse (portable managed services), Biscuit (decentralised authentication), the Eclipse Conformity Assessment Policy and Credential Profile (standards compliance), and XCP-ng (high-performance enterprise virtualisation), we’re building a strong foundation to empower developers and organisations alike. 

Aligned with EU Values

The Eclipse Cloud Interest Group aligns closely with the European Union’s Data Act, which emphasises switchability between cloud providers. By supporting these regulatory goals, we’re helping to advance digital sovereignty and strategic autonomy, ensuring Europe remains at the forefront of innovation while protecting user choice and independence.

What’s Next?

We’re just getting started, but the Eclipse Cloud Interest Group already has strong support from organisations like Clever Cloud, Gaia-X, Vates, and Overnet. Together, we’re laying the groundwork for the future of cloud services, with plans to evolve this Interest Group into an Eclipse Working Group to drive specifications and development activities.

Join Us!

Whether you’re a cloud provider, user, vendor, or part of the broader open source community, we invite you to join us in shaping the future of the cloud. Together, we can create a more autonomous, flexible, and interoperable cloud ecosystem.

The Eclipse Cloud members will be this week at FOSDEM with a BoF session planned in Track C, Saturday February 1st 15:00. A number of workshops to present the Interest Group are also planned in Barcelona on March 3rd (collocated with the Mobile World Congress) and in London on March 31st (collocated with Kubecon). Don’t miss the opportunity to learn more firsthand!

Stay tuned for updates, opportunities to contribute, and ways to get involved. Subscribe to our mailing list and become part of this exciting journey toward a better cloud future!

We are excited to announce the release of Theia Cloud 1.0, a major milestone for running Theia-based tools and IDEs in cloud environments. This open-source framework streamlines deploying and managing …

The post Theia Cloud 1.0: Simplifying Deployment and Management of Theia-Based Tools in Kubernetes appeared first on EclipseSource.

The Theia ecosystem is at the forefront of innovation in AI-powered tools and IDEs. With Theia AI—a flexible framework for tool builders—and the AI capabilities in the Theia IDE, the platform empowers …

The post Pioneering AI in Tools and IDEs: Insights from TheiaCon 2024 appeared first on EclipseSource.

Eclipse Theia is an open-source platform for building tools and IDEs. Designed with flexibility in mind, it enables developers to create tailored and domain-specific tools and IDEs that run seamlessly …

The post Exploring Real-World Applications of Theia: Insights from TheiaCon 2024 appeared first on EclipseSource.

A long-term commitment to myself.

I’m sitting here on January 19th, 2025 wondering what to write. I’m almost finished writing my first book. I wrote 48 blogs in 2024. Writing has again become a permanent part of my life. I can’t imagine a world where I wasn’t writing something. If you’ve been reading my blogs for the past seven plus years, thank you! I hope my writing has brought something positive and useful into your life.

Writing is therapy for me. It’s where I get to sort out my thoughts. I tend to meander when I speak, and it’s the same when I write. The difference between speaking and writing is the ability to edit. It’s wonderful to meander in writing sometimes. I go back and read what I wrote, and move stuff around or just hit the delete key. Sometimes I write a whole blog, read it, and then delete it. I don’t feel the need to persist every thought I have. Sometimes I am the only audience, and I don’t feel the need to keep a memory for myself.

So why did I say writing is “again” a permanent part of my life. I was a writer in high school and college. I wrote poetry and prose and submitted many literary works for consideration to my high school and college literary magazines. A few of the many things I submitted got published, and I’ve shared some of my old published poetry in blogs on Medium.

I used to write with pen and paper, because when I was in high school, we didn’t have online blogging platforms. I captured my poetry in a text file on an old Franklin Ace 1000 and printed a few copies on my Epson MX-80 for myself and some high school friends. Once I finished university in the early 1990s, I stopped writing for myself. I wrote lots of stuff for work, and that was all.

Then, in August, 2017, I started blogging here. Blogging is a trippy experience. The possibility that something I write here might have some random impact on a reader anywhere in the world is wild. I hope the experiences are mostly positive. Most of the time, I have no idea who has read something I wrote. Sometimes when I chat with someone, they tell me they enjoy reading my blogs. This makes me feel good in the moment. It’s always nice to hear positive things.

It took me a while to get comfortable writing about personal experiences publicly. I started doing that as a result of the pandemic. I have since gotten more comfortable alternating between tech writing and personal stories.

Sometimes my stories weave together tech, personal, and career stuff. My favorite blog in that category is “The Joy of Programming.” In the poetry department, “Playing in the Sand” will likely always be my favorite. My favorite tech blog is “Java Streams are great but it’s time for better Java Collections.” It’s almost been five years since I wrote this one. My favorite personal blog is also almost five years old. Credit the pandemic for helping me find my personal blogging voice. The blog title is “What I learned about COVID-19 from Acute Myeloid Leukemia.” My favorite tech blog series is “The missing Java data structures no one ever told you about.” You can’t say no one told you about them now.

I have favored regularity of writing over notability. Why? Not everything I write is going to be amazing and world changing, and I’m ok with that. I aim for stuff I write to be well written, and maybe a few blogs a year will be notable. The practice of writing helps me to write better. If I only tried to write notable stuff, I probably would never write anything. I write when I am motivated to write. I don’t worry about how notable it will be. I don’t see any reason to change this for my blogs. If something doesn’t meet my own gauge for good enough, then I delete it.

When it came to writing my first book, which is about Eclipse Collections, I wanted to avoid the blogs I had previously written about Eclipse Collections. It would have been straightforward and take much less time to just wire together a couple hundred blogs. I wanted to write something new and notable that I would find fun to read, and that developers who read it could walk away with some useful lessons about designing and using a feature-rich library in Java or any programming language. I have at least met my goal of writing something I find fun to read. I hope once it is published others will enjoy it as well.

If you read this far, congratulations! I decided if I was going to share some background about the book, I would also share an excerpt of something interesting from chapter one.

Here is a table comparing lambda-enabled methods available in Eclipse Collections types and equivalent types in the JDK.

Since you don’t have the book in your hands to help you with context, a lambda-enabled method is a method that accepts a Functional Interface as a parameter. A Functional Interface in Java is an interface with a single abstract method. A Functional Interface is a type that can be represented in a method call using a lambda expression. Thus, the term lambda-enabled is any method that can have an inlined lambda expression passed as a parameter. Some examples of lambda-enabled methods in Java are forEach, sort, removeIf, filter, map, reduce.

Here’s a quick example of a lambda used with the forEach method:

List.of("One", "Two", "Three").forEach(each -> System.out.println(each));

The lambda in this code snippet is each -> System.out.println(each) and is the implementation of a Functional Interface named Consumer.

I hope you enjoyed the book excerpt. If you’re wondering how I can count methods that can take lambdas as parameters, it’s simple enough to do in code. This is the code I used to create the table in the book.

private static final MutableList<String> FUNCTION_TYPES =
        Lists.mutable.with(
                "Function", "Predicate", "Consumer", "Procedure", 
                "Supplier", "Comparator", "Operator");

record ClassInfo(String className, int eagerMethods, int lazyMethods, int lambdaMethods)
{
    public ClassInfo plus(ClassInfo other)
    {
        return new ClassInfo(
                this.className,
                this.eagerMethods + other.eagerMethods,
                this.lazyMethods + other.lazyMethods,
                this.lambdaMethods + other.lambdaMethods);
    }
}

public static void viewJDKandECLambdaMethodCounts()
{
    MutableList<Twin<Class<?>>> typePairs = Lists.mutable.with(
            Tuples.twin(RichIterable.class, Iterable.class),
            Tuples.twin(MutableCollection.class, Collection.class),
            Tuples.twin(MutableList.class, List.class),
            Tuples.twin(MutableSet.class, Set.class),
            Tuples.twin(MutableStack.class, Stack.class),
            Tuples.twin(MutableBag.class, Map.class),
            Tuples.twin(MutableMap.class, Map.class),
            Tuples.twin(MutableMultimap.class, Map.class),
            Tuples.twin(MutableBiMap.class, Map.class),
            Tuples.twin(LazyIterable.class, Stream.class),
            Tuples.twin(LazyIntIterable.class, IntStream.class),
            Tuples.twin(LazyLongIterable.class, LongStream.class),
            Tuples.twin(LazyDoubleIterable.class, DoubleStream.class),
            Tuples.twin(Collectors2.class, Collectors.class));

    viewAsciiDocCombinedLambdaMethodCounts("Eclipse Collections", "JDK", typePairs);
}

public static void viewAsciiDocCombinedLambdaMethodCounts(
        String left,
        String right,
        MutableList<Twin<Class<?>>> classes)
{
    System.out.println(".Unlocking productivity gains with lambda-enabled methods");
    System.out.println("[%autowidth.stretch]");
    System.out.println("|===");
    System.out.println("|" + left + " Type |Lambda Method Count |" + right + " Type |Lambda Method Count");
    System.out.println();

    ClassInfo totalJDK = new ClassInfo("*Total " + left + "*", 0, 0, 0);
    ClassInfo totalEC = new ClassInfo("*Total " + right + "*", 0, 0, 0);

    Twin<ClassInfo> totals = classes.injectInto(
            Tuples.twin(totalJDK, totalEC),
            ClassComparerAsciiDoc::outputCombinedLambdaMethodCountsForClasses);

    outputLambdaClassInfos(totals.getOne(), totals.getTwo());

    System.out.println("|===");
}

private static Twin<ClassInfo> outputCombinedLambdaMethodCountsForClasses(
        Twin<ClassInfo> total,
        Twin<Class<?>> clazz)
{
    ClassInfo jdkClassInfo = getClassInfo(clazz.getOne());
    ClassInfo ecClassInfo = getClassInfo(clazz.getTwo());

    outputLambdaClassInfos(jdkClassInfo, ecClassInfo);
    return Tuples.twin(total.getOne().plus(jdkClassInfo), total.getTwo().plus(ecClassInfo));
}

private static ClassInfo getClassInfo(Class<?> clazz)
{
    ClassComparer returnComparer = new ClassComparer(true, true, false);
    MutableSortedSet<String> methodNamesWithReturns = 
        returnComparer.getMethodNames(clazz);
    MutableList<String> distinctMethods = 
        methodNamesWithReturns.toList().distinctBy(each -> each.split(":")[0]);

    int eagerReturnMethods =
            distinctMethods.count(
                each -> LAZY_RETURN_TYPES.noneSatisfy(each.split(":")[1]::contains));
    int lazyReturnMethods =
            distinctMethods.count(
                each -> LAZY_RETURN_TYPES.anySatisfy(each.split(":")[1]::contains));
    int lambdaMethods = distinctMethods.count(
                each -> FUNCTION_TYPES.anySatisfy(each.split(":")[0]::contains));

    return new ClassInfo(clazz.getSimpleName(), eagerReturnMethods, lazyReturnMethods, lambdaMethods);
}

private static void outputLambdaClassInfos(ClassInfo jdkClassInfo, ClassInfo ecClassInfo)
{
    System.out.println("|`" + jdkClassInfo.className() + "`");
    System.out.println("|`" + jdkClassInfo.lambdaMethods() + "`");
    System.out.println("|`" + ecClassInfo.className() + "`");
    System.out.println("|`" + ecClassInfo.lambdaMethods() + "`");
    System.out.println();
}

The work for getting info about a class is done by ClassComparer, which is part of the Eclipse Collections eclipse-collections-testutils.jar. I mentioned the ClassComparer utility a while ago in this blog.

Anyway, that’s enough writing for today. Thanks for reading!

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.

StarCoder is an advanced open-source language model designed specifically for code generation and auto-completion tasks. Developed by BigCode, StarCoder is trained on a large, transparent dataset of …

The post Using StarCoder for AI-Powered Auto Completion in the Theia IDE appeared first on EclipseSource.

Are you eager to integrate Artificial Intelligence (AI) into your custom, domain-specific tools but unsure where to begin? AI has the potential to revolutionize tools and IDEs, turning them into …

The post Kickstarting AI Integration for Custom Tools and IDEs: Watch the Recording appeared first on EclipseSource.

On behalf of the Eclipse JKube team and everyone who has contributed, I'm happy to announce that Eclipse JKube 1.18.0 has been released and is now available from Maven Central ğŸ�‰.

Thanks to all of you who have contributed with issue reports, pull requests, feedback, and spreading the word with blogs, videos, comments, and so on. We really appreciate your help, keep it up!

What's new?

Without further ado, let's have a look at the most significant updates:

• New Helm Test Maven goals and Gradle tasks
• Updated base images
• Better support for Spring Boot
• Better support for Micronaut
• ğŸ�› Many other bug-fixes and minor improvements

New Helm Test Maven goals and Gradle tasks

This release includes a new Helm Test feature that allows you to run tests on your Helm charts. We've added new Helm capabilities to both the Maven and Gradle plugins:

• Maven k8s:helm-test: Allows you to run tests on your Eclipse JKube generated Helm charts via Maven.
• Gradle k8sHelmTest: Allows you to run tests on your Eclipse JKube generated Helm charts via Gradle.

Using this release

If your project is based on Maven, you just need to add the Kubernetes Maven plugin or the OpenShift Maven plugin to your plugin dependencies:

<plugin>
  <groupId>org.eclipse.jkube</groupId>
  <artifactId>kubernetes-maven-plugin</artifactId>
  <version>1.18.0</version>
</plugin>

If your project is based on Gradle, you just need to add the Kubernetes Gradle plugin or the OpenShift Gradle plugin to your plugin dependencies:

plugins {
  id 'org.eclipse.jkube.kubernetes' version '1.18.0'
}

How can you help?

If you're interested in helping out and are a first-time contributor, check out the "first-timers-only" tag in the issue repository. We've tagged extremely easy issues so that you can get started contributing to Open Source and the Eclipse organization.

If you are a more experienced developer or have already contributed to JKube, check the "help wanted" tag.

We're also excited to read articles and posts mentioning our project and sharing the user experience. Feedback is the only way to improve.

Project Page | GitHub | Issues | Gitter | Mailing list | Stack Overflow

The integration of Artificial Intelligence (AI) into tools and Integrated Development Environments (IDEs) is no longer just an innovative idea—it’s a game-changer reshaping how tools are built and …

The post Enhancing Custom IDEs and tools with AI: Strategies, Use Cases, and Pitfalls appeared first on EclipseSource.

The automotive industry within the Eclipse community is driving the development of cutting-edge tools, toolchains, and methodologies. But the true potential of these innovations lies in their seamless …

The post Getting Started with Eclipse Theia Towards A Common Platform for Automotive appeared first on EclipseSource.

The world of web-based tools and IDEs continues to advance rapidly, with new innovations emerging constantly. At the same time, the ecosystem has reached a level of maturity, offering well-established …

The post Building Web-Based Tools and IDEs - Pitfalls and Best Practices appeared first on EclipseSource.

A year of roadtrips, writing, biking, sunrises, and sunsets

I drove more in 2024 than I can recall driving in a very long time. I went on two roadtrips to the Florida Keys. The two roadtrips accumulated thirty one days of driving and sightseeing. I also drove up to Maine two or three times and down to Virginia for a vacation. There were many sunrises and sunsets in 2024. Good food, good drink, quality time spent with family, and memories I will cherish forever. The sun has set on the year Two Thousand Twenty Four on Planet Earth, but many memories remain in hearts, minds, and photos.

Going back through my photos looking through sunsets, which felt like hundreds of pictures, I remembered other trips I took this year to Maine, Crete, Denver, Williamsburg, Long Beach Island.

I also got a decent number of bike rides in this year. The bike rides are limited to a park near my house and Long Beach Island, New Jersey. I will try and branch out to other places to ride my bike in 2025. This is not a resolution, just a reminder of something I didn’t do in 2024.

Anyway, the title of this blog is memorable sunsets. There are quite a few, so sit back, enjoy your coffee, and see the end of many days through the lens of my iPhone. Enjoy!

No sunset is ever the same. It’s a blessing to enjoy every beautiful day and sunset while we can. The sunsets in your backyard or local park can be just as beautiful as ones we see in far away places. The sun doesn’t care where you are. It will shine down on you as many days as you let it. Be good to yourself and each other in 2025. The sun is watching.

Happy New Year!

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.

Looking back at a year of many blogs

This is the 48th blog I have written and published this year. I’m pretty sure that’s the most blogs I’ve written in a single year. This year will be remembered for a long time, for a variety of different reasons. I probably won’t remember this year as the year I wrote a lot of blogs. I will remember it as the year I wrote my first technical book. Blogging became a kind of regular writing detox for me this year. It helped me find and keep my focus, amidst the ever distracting circus of social media and news.

Below are links to my top four blogs this year. Based on the number of reads, not views, my top four blogs this year were all about Java. Three of the blogs were also about Smalltalk. This was kind of an interesting surprise. Smalltalk brought me some new insights and fun experiments this year, which I am thankful for. Java brought me a wonderful community to share these insights with, and a great language and IDE to use for my code examples. Not everything we learn has to be less than thirty years old. We still have so much we can learn from the past seventy five years of programming language history.

Anyway, I am happy to have been able to share these blogs with the developer community in 2024. I hope the insights and lessons continue to help others on their journey of discovery and learning.

Thank you for reading! Happy Holidays and Happy New Year!

#1 — 6.2K reads

What if null was an Object in Java?

#2 — 4.2K reads

Map-Oriented Programming in Java

#3 — 2.6K reads

10 Billion Integers Walk Into an Array

#4 — 1.6K reads

What if Java had no if?

I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.

We are happy to announce the Eclipse Theia 1.57 release! The release contains in total 47 merged pull requests. In this article, we will highlight some selected improvements and provide an overview of …

The post Eclipse Theia 1.57 Release: News and Noteworthy appeared first on EclipseSource.

We are excited to announce that Theia AI and the AI-powered Theia IDE now integrate Anthropics’s Model Context Protocol (MCP), enhancing the capabilities of Theia-based, AI-powered tools and IDE with …

The post Introducing Anthropics's Model Context Protocol (MCP) for AI-Powered Tools in Theia AI and the Theia IDE appeared first on EclipseSource.

The Eclipse Theia project continues to redefine the possibilities for building IDEs and tools, offering a robust, open platform built on modern web technologies. As one of the most active projects in …

The post Eclipse Theia - News from the Next Generation Tools Platform 2024 appeared first on EclipseSource.

We’re excited to announce that accounts.eclipse.org will migrate from Drupal 7 to Drupal 10 on January 19, 2025. This is a significant milestone in our ongoing effort to modernize the Eclipse Foundation’s web infrastructure, following the successful migration of the Project Management Infrastructure (PMI) earlier this year. This migration aligns with our plans that we outlined in last year’s post, Navigating the Shift From Drupal 7 to Drupal 9/10 at the Eclipse Foundation.

To ensure a smooth transition, we’ve scheduled a maintenance window on January 19, 2025, from 02:00 am CET to 06:30 pm CET, during which accounts.eclipse.org will be in read-only mode.

During this period, users will be able to log in and access other Eclipse Foundation websites, such as projects.eclipse.org, gitlab.eclipse.org, and marketplace.eclipse.org. However, some functionality, such as the profile edit form and the create an account form will be temporarily disabled to prevent data loss while we migrate your profile data to a new database.

We’re excited about this migration and hope it will provide a better user experience for all. If you have any feedback or encounter issues, please visit our dedicated issue, which includes details on how to access the staging environment to preview the changes and how to share feedback with us!

For tool builders aiming to create a custom IDE or tool, forking VS Code might seem like a fast and effective solution. Its extensive feature set, vast extension ecosystem, and familiar interface make …

The post Is Forking VS Code a Good Idea? appeared first on EclipseSource.

The Eclipse Foundation has long been a leader in driving open source innovation across IoT, edge computing, and embedded ecosystems. For over 20 years the Eclipse C/C++ Development Tools (CDT) platform has seen broad adoption in the embedded market. For over a decade the Eclipse IoT and Edge community has been delivering great technology components, runtimes, and platforms. And more recently, the Eclipse Software Defined Vehicle working group and community have started to extend our footprint into the security and safety-conscious automotive industry. Now, the recent additions of Eclipse ThreadX and the OpenHW Group are cementing our position as the go-to destination for developers building embedded systems, particularly in safety-critical domains. These milestones, combined with the Foundation’s robust ecosystem, highlight our role as a hub for collaborative innovation in embedded technologies, especially at the intersection of software and hardware.

Expanding the Ecosystem: ThreadX and the OpenHW Foundation

The ThreadX journey at the Eclipse Foundation began in November  2023 when Microsoft contributed this trusted Real-Time Operating System (RTOS) to the Eclipse community. Originally developed by Express Logic and later acquired by Microsoft, ThreadX has been a cornerstone of safety-critical applications across industries like home appliances, medical devices, automotive, aerospace, and industrial automation. Renowned for its reliability and adherence to stringent functional safety standards, ThreadX continues to empower developers worldwide. Earlier this year the Eclipse ThreadX project was re-certified under functional safety standards IEC 61508, IEC 62304, ISO 26262, and EN50128, making ThreadX the world’s first community-driven, open source RTOS with functional safety certifications. 

Building on this strong foundation, we recently launched the ThreadX Alliance. This initiative unites key industry stakeholders to maintain a healthy ecosystem and advance ThreadX development and adoption, particularly in safety-critical applications. 

Adding to this momentum, the OpenHW Group has now joined the Eclipse ecosystem as the OpenHW Foundation, bringing its expertise in implementing RISC-V architectures to complement our software initiatives. OpenHW provides developers with permissively licensed, high-quality hardware IP, enabling the creation of advanced embedded real-time systems. In short, OpenHW takes the RISC-V instruction set architecture and makes it real by delivering verified open source-licensed processor designs written in industry standard System Verilog. 

Together, ThreadX and OpenHW deliver a powerful combination of proven RTOS capabilities and cutting-edge hardware innovation, providing a solid foundation for embedded and IoT applications.

By combining the proven safety-critical and real-time capabilities of ThreadX, the cutting-edge processor core designs of  OpenHW and other Eclipse initiatives—such as Eclipse Zenoh, Sparkplug, and the Software-Defined Vehicle (SDV) Working Group —we are building an unmatched environment for embedded developers. These advancements position the Eclipse Foundation as the premier destination for open source innovation in safety-critical and high-performance embedded systems.

A Strategy Built on Collaboration

Our vision is to create a cohesive ecosystem where projects across software and hardware domains can collaborate to accelerate embedded systems innovation. The Eclipse Foundation’s collaborative infrastructure ensures that projects like ThreadX and OpenHW are not siloed but rather integrated into a broader strategy that benefits developers and organisations alike:

• IoT and Connectivity: Fundamental protocols like MQTT, Sparkplug, Eclipse Zenoh and Eclipse uProtocol provide robust real-time data sharing and control for industrial IoT and automotive applications. Zenoh’s recent 1.0.0 release sets a new standard for connectivity, particularly in robotics and edge systems.

• Developer Tools: In addition to the widely adopted Eclipse CDT, Eclipse Theia, our modern, extensible IDE, supports safety-critical workflows and can be easily integrated with ThreadX-based projects, simplifying the development of complex embedded solutions.

• Software-Defined Vehicle (SDV): The SDV Working Group is shaping tomorrow’s automotive software landscape. Its intersection with ThreadX and Zenoh, as manifested in uProtocol, enables more robust functional safety and advanced vehicle connectivity, ensuring that developers can confidently build next-generation automotive and mobility systems.

• Multiplatform Integration: The Oniro Working Group develops a distributed operating system for smart devices, collaborating with projects like Theia or Kanto. This cross-project integration fosters an environment where developers can easily combine diverse technologies into coherent, scalable solutions.
  
• Eclipse Functional Safety Process: The emergence of ThreadX and Eclipse SDV as critical technologies for safety-critical applications will not be possible without a robust development process enabling requirements traceability and comprehensive testing. The evolving Eclipse Foundation functional safety process will guide project teams in the embedded realm and beyond towards code and product certifiability in a uniform, predictable way.

As the home for these initiatives and technologies, the Eclipse Foundation offers an unparalleled ecosystem for developing sophisticated, safety-critical, and connected embedded systems.

The Road Ahead

The additions of Eclipse ThreadX and the OpenHW Foundation mark the start of an exciting new chapter in embedded systems innovation. By uniting cutting-edge hardware, trusted RTOS software, and advanced connectivity solutions, the Eclipse Foundation is poised to become the leading destination for developers working on safety-critical and high performance embedded systems.

We invite developers, organizations, and contributors to join us in shaping the future of embedded technology. Whether you engage through the ThreadX Alliance, the OpenHW Foundation, Eclipse SDV, or other projects within our vibrant ecosystem, you’ll find endless opportunities for collaboration and innovation.

Together, let’s build the future of embedded systems.

Learn More About the Eclipse Foundation and our Projects

The development of AI-driven IDEs is at a crossroads. While advancements have unlocked incredible potential for developer productivity, the most popular solutions today remain proprietary, opaque, and …

The post Watch Now: Open, AI-Powered Development with Theia IDE appeared first on EclipseSource.

We are happy to announce the eighth Eclipse Theia community release “2024-11”, version 1.55.x! New to Eclipse Theia? It is the next-generation platform for building IDEs and tools for the web or …

The post The Eclipse Theia Community Release 2024-11 appeared first on EclipseSource.

As part of our migration to Drupal 10, we’ve decided to discontinue support for Gravatar on sites such as accounts.eclipse.org, projects.eclipse.org, blogs.eclipse.org, marketplace.eclipse.org, and newsroom.eclipse.org. This change enhances privacy compliance by giving users more control over their data and ensures a more consistent experience across many of our web properties.

Why Are We Dropping Gravatar?

• Improved Privacy: Moving away from Gravatar reduces reliance on external services, giving users greater control over their profile pictures and personal data.
• Inconsistent Profile Pictures: Users have experienced issues in the past with their profile pictures displaying inconsistently across some sites due to syncing problems between Gravatar and our internal systems. This update ensures a more consistent experience.
• Lack of Support with Drupal 10: The Gravatar integration module used with Drupal 7 is not compatible with Drupal 10, and maintaining support would require significant effort.

What Does This Mean for You?

To address these issues, we’ve introduced a new profile picture endpoint that ensures a consistent solution for displaying profile pictures across supported sites. This endpoint will show either the user’s uploaded picture or our default silhouette if no picture is available. This update also aligns with our goal to minimise personal data that we need to sync across our various web properties.

To display a community member’s profile picture on your project website, simply replace [:eclipse_username] with the user’s Eclipse username and use that URL as the href value in your image tag:

https://accounts.eclipse.org/user/[:eclipse_username]/picture

For example, my picture is available here (my Eclipse username is “cguindon”):
https://accounts.eclipse.org/user/cguindon/picture

The content of that image URL will automatically change if the user uploads a new picture or removes it in the future. If you display profile pictures on your project website, this new endpoint eliminates the need for you to sync profile pictures as-well!

Important: Some of our services, such as GitLab, manage profile pictures independently and do not use this new endpoint. This change will not affect your picture on GitLab. To update your GitLab profile picture, visit your Eclipse GitLab Edit Profile page.

If you currently use Gravatar for your profile picture, it will no longer be displayed on sites like accounts.eclipse.org, projects.eclipse.org, blogs.eclipse.org, marketplace.eclipse.org, and newsroom.eclipse.org. To ensure your profile has a picture, please upload an Eclipse profile picture now in your account.

On November 20, 2024, the Board of Director of the Eclipse Foundation approved version 1.2 of its Security Policy. This update brings significant enhancements aimed at improving the management, resolution, and disclosure of vulnerabilities within the Eclipse community. Here’s a rundown of the key changes and what they mean for Eclipse projects and users.

Renaming to “Security Policy”

One of the first noticeable changes is the renaming of the policy from the “Eclipse Foundation Vulnerability Reporting Policy” to the “Eclipse Foundation Security Policy.” This change reflects a broader scope, encompassing not just the reporting but also the overall management of security within the Foundation’s projects.

Introduction of the Project’s Security Team

The updated policy introduces the concept of a “Project’s Security Team.” This team is responsible for coordinating the resolution of vulnerabilities within their specific project. By default, all committers of a project are included in its Security Team, but projects have the flexibility to establish specific criteria for team membership.

Relationship with the Eclipse Foundation Security Team

The Eclipse Foundation Security Team (EF Security Team) plays a supportive role, providing guidance and assistance to Project Security Teams. While the EF Security Team oversees security coordination across the Foundation, the Project’s Security Teams are on the front lines, handling the specific vulnerabilities within their projects.

Clarified Roles and Responsibilities

The policy clarifies the roles and responsibilities of both the EF Security Team and the Project’s Security Teams:

• Discussion: Initial discussions about potential vulnerabilities occur privately between the reporter, the Project’s Security Team, and the EF Security Team. Once confirmed, these discussions are moved to an Eclipse Foundation-supported issue tracker to proceed with mitigation.

• Resolution: All vulnerabilities must be resolved. A vulnerability is considered resolved when a fix or workaround is available, or when it’s determined that a fix is not possible or desirable (in which case, a risk analysis must be provided).

• Distribution: Once resolved, updated software containing the fix should be made available to the community through regular or service releases.

• Disclosure: It’s strongly recommended that public disclosure occurs immediately after a bugfix release is available. In all cases, users and administrators must be informed of any vulnerabilities to assess risks and take appropriate actions.

Emphasis on Timely Resolution and Disclosure

The updated policy sets expectations for timely handling of vulnerabilities:

• Projects are expected to resolve vulnerabilities within no more than three months. Extensions may be granted by the Project Leadership Chain in consultation with the EF Security Team if necessary.

• Resolved vulnerabilities should be disclosed immediately after the release containing the fixes is available, ensuring transparency and enabling users to protect their systems promptly.

Enhanced Collaboration and Communication

The policy encourages close collaboration between the Project’s Security Teams and the EF Security Team. Projects are advised to communicate their preferred methods of contact and keep the EF Security Team updated on any changes. Additionally, the EMO (Eclipse Management Organization) will assist in setting up confidential channels for discussing undisclosed vulnerabilities when needed.

Conclusion

The updates in version 1.2 of the Eclipse Foundation Security Policy strengthen the security posture of the Eclipse community by clarifying processes and responsibilities. These changes aim to ensure that vulnerabilities are managed effectively, resolutions are timely, and communications are transparent.

We encourage all Eclipse project teams and users to familiarize themselves with the new policy to understand how it affects their roles and responsibilities within the community.

For more detailed information, please refer to the Eclipse Foundation Security Policy.

We are happy to announce the Eclipse Theia 1.56 release! The release contains in total 62 merged pull requests. In this article, we will highlight some selected improvements and provide an overview of …

The post Eclipse Theia 1.56 Release: News and Noteworthy appeared first on EclipseSource.