On behalf of the Eclipse JKube team and everyone who has contributed, I'm happy to announce that Eclipse JKube 1.12.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:

• Support for CronJob controller generation
• Setting resource limits through XML/DSL configuration
• Concurrent Remote Dev sessions
• ğŸ�› Many other bug-fixes and minor improvements

Setting resource limits through XML/DSL configuration

You can now set resource limits for your containers through XML/DSL configuration. The following code snippet shows how you can leverage this new feature in your pom.xml configuration:

<plugin>
  <groupId>org.eclipse.jkube</groupId>
  <artifactId>kubernetes-maven-plugin</artifactId>
  <configuration>
    <resources>
      <controller>
        <containerResources>
          <requests>
            <cpu>1337m</cpu>
            <memory>42Gi</memory>
          </requests>
          <limits>
            <cpu>1337m</cpu>
            <memory>42Gi</memory>
          </limits>
        </containerResources>
      </controller>
    </resources>
  </configuration>
</plugin>

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.12.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.12.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

Getting Started with Eclipse Collections — Part 3

Converting between Collection types using Eclipse Collections

Getting Started with Eclipse Collections

In part 1 of this series, I explained how to download the Eclipse Collections library from Maven Central and create collections using Eclipse Collections factories. In part 2, I explained how to add items to and remove items from different collection types. In part 3, I will explain how to use converter methods to convert any RichIterable type to another Collection or Map type.

Converting between Collection types

The methods in Eclipse Collections that enable developers to convert from one RichIterable type to another, start with the prefix to. Using the to<Type> methods, the data is copied from a source collection to a target collection type, and it takes linear time (O(n)). There are also methods prefixed with as which create views, and execute in constant time (O(1)), but they will not be discussed in this blog. Calling a to<Type> method, will result in a shallow copy where only the references to the data are copied.

To Mutable Collections

In order to convert a RichIterable type to a MutableCollection type, start with the prefix to and look for the type you would like to convert to (List, Set, Bag, etc.). The converters to MutableCollection types were added before there were ImmutableCollection types in Eclipse Collections. There was a natural preference for the convenience of the shorter names, without Mutable in them.

The one exception of a to method answering a mutable type, is the method toString, which returns a familiar immutable Java type — String.

Mutable Converter Examples

The following are examples of converting a RichIterable<Integer> to various other mutable container types in Eclipse Collections. You may recall from the other blogs in this series that RichIterable is the parent type of most Eclipse Collections container types.

@Test
public void RichIterableTo()
{
    RichIterable<Integer> ri = Interval.oneTo(3);

    // Lists
    MutableList<Integer> list =
            ri.toList();
    MutableList<Integer> sortedList =
            ri.toSortedList();
    MutableList<Integer> sortedListBy =
            ri.toSortedListBy(Object::toString);

    // Sets
    MutableSet<Integer> set =
            ri.toSet();
    MutableSortedSet<Integer> sortedSet =
            ri.toSortedSet();
    MutableSortedSet<Integer> sortedSetBy =
            ri.toSortedSetBy(Object::toString);

    // Bags
    MutableBag<Integer> bag =
            ri.toBag();
    MutableSortedBag<Integer> sortedBag =
            ri.toSortedBag();
    MutableSortedBag<Integer> sortedBagBy =
            ri.toSortedBagBy(Object::toString);

    // Maps
    MutableMap<String, Integer> map =
            ri.toMap(Object::toString, Functions.identity());
    MutableSortedMap<String, Integer> sortedMap =
            ri.toSortedMap(Object::toString, Functions.identity());
    MutableSortedMap<String, Integer> sortedMapBy =
            ri.toSortedMapBy(Object::toString, 
                             Object::toString, 
                             Functions.identity());

    // BiMap
    MutableBiMap<String, Integer> biMap =
            ri.toBiMap(Object::toString, Functions.identity());

    // JDK Types
    Object[] array = ri.toArray();
    String string = ri.toString();
}

To Immutable Collections

In order to convert a RichIterable type to an ImmutableCollection type, start with the prefix to and look for the type you would like to convert to (ImmutableList, ImmutableSet, ImmutableBag, etc.). It was clear as soon as I had drawn the Immutable side of the mind map that there is currently some asymmetry with a missing method toImmutableSortedMap that should return an ImmutableSortedMap.

Immutable Converter Examples

The following are examples of converting a RichIterable<Integer> to various immutable container types in Eclipse Collections.

@Test
public void RichIterableToImmutable()
{
    RichIterable<Integer> ri = Interval.oneTo(3);

    // Immutable Lists
    ImmutableList<Integer> list =
            ri.toImmutableList();
    ImmutableList<Integer> sortedList =
            ri.toImmutableSortedList();
    ImmutableList<Integer> sortedListBy =
            ri.toImmutableSortedListBy(Object::toString);

    // Immutable Sets
    ImmutableSet<Integer> set =
            ri.toImmutableSet();
    ImmutableSortedSet<Integer> sortedSet =
            ri.toImmutableSortedSet();
    ImmutableSortedSet<Integer> sortedSetBy =
            ri.toImmutableSortedSetBy(Object::toString);

    // Immutable Bags
    ImmutableBag<Integer> bag =
            ri.toImmutableBag();
    ImmutableSortedBag<Integer> sortedBag =
            ri.toImmutableSortedBag();
    ImmutableSortedBag<Integer> sortedBagBy =
            ri.toImmutableSortedBagBy(Object::toString);

    // Immutable Map
    ImmutableMap<String, Integer> map =
            ri.toImmutableMap(Object::toString, Functions.identity());

    // Immutable BiMap
    ImmutableBiMap<String, Integer> biMap =
            ri.toImmutableBiMap(Object::toString, Functions.identity());
}

Primitive Collections

The converter methods available on primitive collection types are more limited than their object counterparts. There are currently only methods prefixed with to available on the primitive Iterable types (e.g. IntIterable, LongIterable, DoubleIterable, etc.) that return Mutable<Primitive>Collection types. There are no toImmutable<Type> equivalents today.

Primitive Converter Examples

The following are examples of converting an IntIterable to various mutable primitive container types. The converter methods in the examples below are available across all eight primitive Iterable types.

@Test
public void IntIterableTo()
{
    IntIterable ii = IntInterval.oneTo(3);

    // Primitive Lists
    MutableIntList list = 
            ii.toList();
    MutableIntList sortedList = 
            ii.toSortedList();
    MutableIntList sortedListBy = 
            ii.toSortedListBy(i -> -i);

    // Set
    MutableIntSet set = 
            ii.toSet();

    // Bag
    MutableIntBag bag = 
            ii.toBag();

    // JDK Types
    int[] array = 
            ii.toArray();
    int[] sortedArray =
            ii.toSortedArray();
    String string = 
            ii.toString();
}

From Mutable To Immutable (Object Collections)

There is a method named toImmutable available on every MutableCollection type that knows how to convert a MutableCollection to its ImmutableCollection equivalent.

Code examples of toImmutable (Object Collections)

The following are code examples showing the toImmutable methods available across various MutableCollection and MutableMap types.

@Test
public void toImmutable()
{
    // Collection
    MutableCollection<Integer> collection =
            Lists.mutable.with(1, 2, 3);
    ImmutableCollection<Integer> immutableCollection =
            collection.toImmutable();

    // List
    MutableList<Integer> list =
            Lists.mutable.with(1, 2, 3);
    ImmutableList<Integer> immutableList =
            list.toImmutable();

    // Sets
    MutableSet<Integer> set =
            Sets.mutable.with(1, 2, 3);
    ImmutableSet<Integer> immutableSet =
            set.toImmutable();
    MutableSortedSet<Integer> sortedSet =
            SortedSets.mutable.with(1, 2, 3);
    ImmutableSortedSet<Integer> immutableSortedSet =
            sortedSet.toImmutable();

    // Bags
    MutableBag<Integer> bag =
            Bags.mutable.with(1, 2, 3);
    ImmutableBag<Integer> immutableBag =
            bag.toImmutable();
    MutableSortedBag<Integer> sortedBag =
            SortedBags.mutable.with(1, 2, 3);
    ImmutableSortedBag<Integer> immutableSortedBag =
            sortedBag.toImmutable();

    // Stack
    MutableStack<Integer> stack =
            Stacks.mutable.with(1, 2, 3);
    ImmutableStack<Integer> immutableStack =
            stack.toImmutable();

    // Maps
    MutableMap<Integer, Integer> map =
            Maps.mutable.with(1, 1, 2, 2, 3, 3);
    ImmutableMap<Integer, Integer> immutableMap =
            map.toImmutable();
    MutableSortedMap<Integer, Integer> sortedMap =
            SortedMaps.mutable.with(1, 1, 2, 2, 3, 3);
    ImmutableSortedMap<Integer, Integer> immutableSortedMap =
            sortedMap.toImmutable();

    // BiMap
    MutableBiMap<Integer, Integer> biMap =
            BiMaps.mutable.with(1, 1, 2, 2, 3, 3);
    ImmutableBiMap<Integer, Integer> immutableBiMap =
            biMap.toImmutable();
}

From Mutable To Immutable (Primitive Collections)

There is a method named toImmutable available on every Mutable<Primitive>Collection type that knows how to convert a Mutable<Primitive>Collection to its Immutable<Primitive>Collection equivalent.

Code examples of toImmutable (Primitive Collections)

The following are code examples showing the toImmutable methods available across various Mutable<Primitive>Collection and Mutable<Primitive>Map types.

@Test
public void toImmutablePrimitive()
{
    // Collection
    MutableIntCollection collection =
            IntLists.mutable.with(1, 2, 3);
    ImmutableIntCollection immutableCollection =
            collection.toImmutable();

    // List
    MutableIntList list =
            IntLists.mutable.with(1, 2, 3);
    ImmutableIntList immutableList =
            list.toImmutable();

    // Set
    MutableIntSet set =
            IntSets.mutable.with(1, 2, 3);
    ImmutableIntSet immutableSet =
            set.toImmutable();

    // Bag
    MutableIntBag bag =
            IntBags.mutable.with(1, 2, 3);
    ImmutableIntBag immutableBag =
            bag.toImmutable();

    // Stack
    MutableIntStack stack =
            IntStacks.mutable.with(1, 2, 3);
    ImmutableIntStack immutableStack =
            stack.toImmutable();

    // Maps
    MutableIntIntMap intIntMap =
            IntIntMaps.mutable.with(1, 1, 2, 2, 3, 3);
    ImmutableIntIntMap immutableIntIntMap =
            intIntMap.toImmutable();
    MutableIntObjectMap<Integer> intObjectMap = 
            IntObjectMaps.mutable.with(1, 1, 2, 2, 3, 3);
    ImmutableIntObjectMap<Integer> immutableIntObjectMap = 
            intObjectMap.toImmutable();
    MutableObjectIntMap<Integer> objectIntMap = 
            ObjectIntMaps.mutable.with(1, 1, 2, 2, 3, 3);
    ImmutableObjectIntMap<Integer> immutableObjectIntMap = 
            objectIntMap.toImmutable();
}

The past, present, future of Converter Methods

I wrote a couple of blogs, two years ago, about the converter methods that were available in Eclipse Collections at the time and the ones I wanted to see in Java as well as future versions of Eclipse Collections. The blogs were inspired at the time by the introduction of the toList method to the Stream interface in Java 16.

• Stream.toList() and other converter methods I’ve wanted since Java 2
• Improving the symmetry of converter methods in Eclipse Collections

The future I envisioned two years ago is almost complete, at least for Eclipse Collections. There is minor work to do in the Eclipse Collections object collection hierarchy. There is also an opportunity to improve symmetry by adding the toImmutable<Type> variety of methods to the primitive collections.

“Into” the Unknown!

There is a method defined on RichIterable that can be used as a catchall method to convert a type to any possible Collection type. The method is named into, and can accept any implementation of Collection as a target. The into method has been available since Eclipse Collections 8.0 was released (September 2016), and provides great interoperability with Collection containers from other Java Collections libraries. The signature of the method is as follows:

/**
 * Adds all the elements in this iterable to the specific target Collection.
 *
 * @since 8.0
 */
<R extends Collection<T>> R into(R target);

Code examples of into on RichIterable

The following are code examples using into to convert a RichIterable implementation to a variety of specific JDK Collection types.

@Test
public void intoTheUnknown()
{
    RichIterable<Integer> ri = Interval.oneTo(3);

    // into JDK CopyOnWriteArrayList
    CopyOnWriteArrayList<Integer> cowal = 
            ri.into(new CopyOnWriteArrayList<>());

    // into JDK CopyOnWriteArraySet
    CopyOnWriteArraySet<Integer> cowas = 
            ri.into(new CopyOnWriteArraySet<>());

    // into JDK LinkedHashSet
    LinkedHashSet<Integer> lhs = 
            ri.into(new LinkedHashSet<>());

    // into JDK ArrayDeque
    ArrayDeque<Integer> ad = 
            ri.into(new ArrayDeque<>());
}

Final Thoughts

Thank you for taking the time to read this blog. I hope this will be a good reference for folks to refer to in the future. I tried to be as comprehensive as possible. In the next blog in this series, I will cover in depth some of the most commonly used methods for processing information in collections.

Enjoy!

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

Paris, France, le 09 mars 2023 – La Fondation Eclipse annonce aujourd’hui avoir rejoint la Société Informatique de France afin de collaborer à une démarche commune qui vise à rassembler toutes celles et ceux pour qui faire progresser l’informatique est un métier ou une passion : enseignants, chercheurs, ingénieurs, industriels, et consultants. La Fondation Eclipse est convaincue que cette démarche doit passer par une bonne compréhension de l’open source et de ses pratiques.

« Nous sommes très heureux et fier de rejoindre la SIF et faire partie de ses membres » explique Philippe Krief, directeur des relations avec la recherche à la Fondation Eclipse. La Fondation Eclipse s'implique d’ailleurs fortement dans les projets de recherche européens depuis dix ans, en les accompagnant dans la mise en œuvre et la pérennisation de leurs résultats sous forme de projets open source.

« Ces nombreuses rencontres avec la communauté de recherche européenne nous ont permis de mieux comprendre les questionnements comme les idées reçues que le milieu de la recherche peut avoir vis-à-vis de l'open source » poursuit Philippe Krief. « Notre travail consiste donc à expliquer et à rassurer nos partenaires académiques, comme industriels, sur les bonnes pratiques de l'open source, à casser certains clichés, et à les accompagner dans le développement d'un projet open source, de sa communauté, et de sa pérennisation.                          

«  La Société informatique de France est particulièrement heureuse d'accueillir la fondation Eclipse parmi ses membres. Cette adhésion est un signe visible de l’existence de valeurs communes et d’une ambition partagée pour une science plus ouverte et une innovation plus citoyenne. C’est bien en ce sens qu’œuvre la fondation Eclipse et que se développe chaque jour davantage l’écosystème du logiciel libre au bénéfice de l’ensemble de la société.»  souligne Yves Bertrand, président de la SIF.

– Fin –

À propos de la Fondation Eclipse

La Fondation Eclipse fournit à sa communauté mondiale de personnes et d'organisations un environnement mature, évolutif et convivial pour la collaboration et l'innovation en matière de logiciels open source. La Fondation héberge l'IDE Eclipse, Jakarta EE et plus de 400 projets open source, notamment des runtimes, des outils et des frameworks pour les applications cloud et edge, l'IoT, l'IA, l'automobile, l'ingénierie des systèmes, les conceptions de processeurs ouverts, et bien d'autres. La Fondation Eclipse est une association internationale à but non lucratif soutenue par plus de 330 membres, dont des leaders de l'industrie qui apprécient l'open source comme un catalyseur clé pour leurs stratégies commerciales. Pour en savoir plus, suivez-nous sur Twitter @ResearchEclipse, @EclipseFdn, LinkedIn ou visitez eclipse.org.

À propos de la Société informatique de France

La Société Informatique de France (SIF) est la société savante française d’informatique. Elle a vu le jour en 2012 et est reconnue d'utilité publique depuis septembre 2018. Au cœur de la société, elle a vocation à porter la voix de l’informatique, science et technique, et celle des femmes et des hommes qui la font chaque jour. À ce titre, elle vise à rassembler toutes celles et ceux pour qui faire progresser l’informatique est un métier ou une passion : enseignantes, chercheuses, ingénieurs, industriels, consultantes. Société savante, la SIF vise tout particulièrement à promouvoir l’informatique, à servir et à animer sa communauté scientifique et technique, contribuer à la culture citoyenne et à l’enseignement de la discipline à tous les niveaux. Elle aspire à participer aux réflexions et initiatives sur la formation et l’emploi des informaticiennes et informaticiens et à porter la voix de la communauté dans les débats de société. Pour en savoir plus, visitez https://www.socinfo.fr.
 

Contact Eclipse pour la presse:

514 Media Ltd for the Eclipse Foundation, AISBL (France, Italy, Spain)

Benoit Simoneau

benoit@514-media.com

M: +44 (0) 7891 920 370

Ref: ECF018D

Contacts SIF pour la presse :

Yves BERTRAND, president@societe-informatique-de-france.fr

+33 (0)643 348 313

Sylvie ALAYRANGUES, responsable communication, sylvie.alayrangues@societe-informatique-de-france.fr

Getting Started with Eclipse Collections — Part 2

Learn how to add items to and remove items from collections.

Getting Started with Eclipse Collections

In part 1 of this series, I explained how to download the Eclipse Collections library from Maven Central and create collections using Eclipse Collections. In part 2, I will explain how to add items to and remove items from collections.

Adding to and Removing from Collections

The most basic methods on a collection are the ones that add items to and remove items from the collection. Eclipse Collections has flexible and symmetric methods for growing and shrinking both MutableCollection and ImmutableCollection instances. Sometimes, there are type specific methods to add items to and remove items from a collection.

Mutable Collections

All MutableCollection types in Eclipse Collections, except for MutableStack, are descendants of java.util.Collection. MutableStack extends the java.lang.Iterable interface. The following class diagram shows the interesting mutable interfaces in the JDK and Eclipse Collections that define the adding and removing behavior for various Collection and Iterable types.

In the following sections, I will explain and show examples of the adding and removing methods at the various levels of the MutableCollection type hierarchy as they are introduced. Types in the the MutableCollection hierarchy extend the type java.util.Collection. This means the mutable collections in Eclipse Collections are compatible and interchangeable with JDK Collection types. I will start by explaining the methods inherited by the various JDK Collection types including java.util.Collection, java.util.List, java.util.Set.

java.util.Collection

The java.util.Collection interface in Java has add and remove methods that are the primary mechanisms for adding items to and removing items from a collection. The methods take an object as a parameter and both methods return boolean.

The return result for add is dependent on the Collection type. The general contract says the result will be true if the Collection is modified as a result of calling the add method. In the case of a List, the result will almost always be true. In the case of a Set, the result will depend on whether an item was added to the Set (true) or already existed in the Set (false). I recommend reading the JavaDoc for a particular type to understand the return result for add.

The return result for remove is consistent across Collection types. A result of true is returned if an items exists in the Collection and is removed.

The add method on Collection takes a generic type as a parameter. The remove method takes Object as a parameter. There are questions and answers on StackOverflow why remove takes Object as a parameter. It does allow the remove method to be less strict and more flexible.

There are also bulk mutation methods available on java.util.Collection. The three bulk mutation methods are addAll, removeAll, and retainAll, which all take a Collection as a parameter. There is also a special method named removeIf which takes a Predicate.

The following are examples using the mutating methods from java.util.Collection on an Eclipse Collections MutableList.

@Test
public void javaUtilCollection()
{
    Collection<String> collection = Lists.mutable.empty();

    // add
    Assertions.assertTrue(collection.add("1"));
    Assertions.assertTrue(collection.add("2"));
    Assertions.assertTrue(collection.add("3"));
    Assertions.assertEquals(List.of("1", "2", "3"), collection);

    // remove
    Assertions.assertTrue(collection.remove("2"));
    Assertions.assertEquals(List.of("1", "3"), collection);
    Assertions.assertFalse(collection.remove("4"));

    // addAll
    Assertions.assertTrue(collection.addAll(List.of("2")));
    Assertions.assertEquals(List.of("1", "3", "2"), collection);
    Assertions.assertTrue(collection.addAll(List.of("4", "5")));
    Assertions.assertEquals(List.of("1", "3", "2", "4", "5"), collection);

    // removeAll
    Assertions.assertTrue(collection.removeAll(List.of("2", "4")));
    Assertions.assertEquals(List.of("1", "3", "5"), collection);

    // retainAll
    Assertions.assertTrue(collection.retainAll(List.of("1", "3")));
    Assertions.assertEquals(List.of("1", "3"), collection);

    // removeIf
    Assertions.assertFalse(collection.removeIf(
            each -> Integer.parseInt(each) % 2 == 0));
    Assertions.assertEquals(List.of("1", "3"), collection);
    Assertions.assertTrue(collection.removeIf(
            each -> Integer.parseInt(each) % 2 != 0));
    Assertions.assertEquals(List.of(), collection);
}

java.util.List

The java.util.List interface inherits all of the adding and removing methods from java.util.Collection. List also includes an add and addAll method which allow for inserting elements at a specific index. There is also a remove method which takes an index. The remove method on java.util.List is an overload of the remove method defined on java.util.Collection. You should take care when calling remove on a java.util.List, to make sure you are calling the correct remove method. There are questions and answers on StackOverflow about the overloaded remove methods on java.util.List.

The following are examples using the mutating methods from java.util.List on an Eclipse Collections MutableList.

@Test
public void javaUtilList()
{
    List<String> list = Lists.mutable.with("1", "3", "5");

    // add(index, element) - Note: returns void, not boolean
    list.add(1, "2");
    list.add(3, "4");

    var expected1 = Lists.mutable.with("1", "2", "3", "4", "5");
    Assertions.assertEquals(expected1, list);

    // addAll(index, collection) - Note: returns boolean
    Assertions.assertTrue(list.addAll(0, List.of("0")));

    var expected2 = Lists.mutable.with("0", "1", "2", "3", "4", "5");
    Assertions.assertEquals(expected2, list);

    // remove(index) - Note: returns the element removed
    Assertions.assertEquals("0", list.remove(0));
    Assertions.assertEquals("2", list.remove(1));
    Assertions.assertEquals("4", list.remove(2));

    var expected3 = Lists.mutable.with("1", "3", "5");
    Assertions.assertEquals(expected3, list);
}

java.util.Set

The java.util.Set interface inherits all of the adding and removing methods from java.util.Collection. There are no additional adding or removing methods on java.util.Set. The return result of add on implementations of java.util.Set is slightly different than those of java.util.List. The result of calling add on java.util.List will always return true. On an implementation of java.util.Set, the return result is dependent on whether an equivalent item already existed in the Set. If an item doesn’t exist, add will return true. If an item does exist, add will return false.

The following are examples using the mutating methods from java.util.Set on an Eclipse Collections MutableSet.

@Test
public void javaUtilSet()
{
    Set<String> set = Sets.mutable.empty();

    // add - returns true if new element, or false if element exists
    Assertions.assertTrue(set.add("1"));
    Assertions.assertFalse(set.add("1"));
    Assertions.assertEquals(Set.of("1"), set);
}

MutableCollection

The base class for most Mutable collections in Eclipse Collections is MutableCollection. MutableCollection extends java.util.Collection. It adds several methods for growing and shrinking a collection. First, MutableCollection adds a set of bulk mutating methods that are symmetric with the bulk mutating methods in java.util.Collection, but that take java.lang.Iterable instead of java.util.Collection. The methods are addAllIterable, removeAllIterable, retainAllIterable. There is also a removeIfWith method which will take a Predicate2 and a parameter of some type.

The following are examples using the mutating methods from MutableCollection on an Eclipse Collections MutableList.

@Test
public void mutableCollectionPart1()
{
    MutableCollection<String> collection = Lists.mutable.with("1", "2", "3");

    // addAllIterable
    Assertions.assertTrue(
        collection.addAllIterable(Lists.immutable.with("4", "5")));

    var expected1 = Lists.mutable.with("1", "2", "3", "4", "5");
    Assertions.assertEquals(expected1, collection);

    // retainAllIterable
    Assertions.assertTrue(
        collection.retainAllIterable(Lists.immutable.with("4", "5")));

    var expected2 = Lists.mutable.with("4", "5");
    Assertions.assertEquals(expected2, collection);

    // removeAllIterable
    Assertions.assertFalse(
        collection.removeAllIterable(Lists.immutable.with("1", "2", "3")));
    Assertions.assertEquals(expected2, collection);
    Assertions.assertTrue(
        collection.removeAllIterable(Lists.immutable.with("5")));

    var expected3 = Lists.mutable.with("4");
    Assertions.assertEquals(expected3, collection);

    // removeIfWith
    Assertions.assertFalse(
        collection.removeIfWith(Predicates2.equal(), "5"));
    Assertions.assertTrue(
        collection.removeIfWith(Predicates2.equal(), "4"));
    Assertions.assertTrue(collection.isEmpty());
}

The other methods that MutableCollection includes for growing and shrinking a collection are with, withAll, without, and withoutAll. These methods are symmetric with add, addAll, remove, and removeAll from java.util.Collection. The difference is in the return type. The methods from java.util.Collection all return boolean. The with* methods on MutableCollection all return MutableCollection.

I wrote about the with* methods in the following blog.

As a matter of Factory — Part 3 (Method Chaining)

The with* methods allow collection instances to become fluent builders for themselves, by allowing chained calls to add, addAll, remove, and removeAll.

The following are examples using the with* methods from MutableCollection on an Eclipse Collections MutableList.

@Test
public void mutableCollectionPart2()
{
    MutableCollection<String> collection = Lists.mutable.with("1", "2", "3");

    // with - returns MutableCollection
    MutableCollection<String> with =
            collection.with("4").with("5");

    Assertions.assertSame(with, collection);
    var expected1 = Lists.mutable.with("1", "2", "3", "4", "5");
    Assertions.assertEquals(expected1, collection);

    // withAll - returns MutableCollection
    MutableCollection<String> withAll =
            collection.withAll(List.of("6"));

    Assertions.assertSame(withAll, collection);
    var expected2 = Lists.mutable.with("1", "2", "3", "4", "5", "6");
    Assertions.assertEquals(expected2, collection);

    // without - returns MutableCollection
    MutableCollection<String> without =
            collection.without("5").without("6");

    Assertions.assertSame(without, collection);
    var expected3 = Lists.mutable.with("1", "2", "3", "4");
    Assertions.assertEquals(expected3, collection);

    // withoutAll - returns MutableCollection
    MutableCollection<String> withoutAll =
            collection.withoutAll(List.of("4"));

    Assertions.assertSame(withAll, collection);
    var expected4 = Lists.mutable.with("1", "2", "3");
    Assertions.assertEquals(expected4, collection);
}

Covariant return types for with* methods

The interfaces MutableList, MutableSet, MutableBag, MutableSortedSet, MutableSortedBag, MutableBagIterable, and MutableSetIterable all override with, withAll, without, and withoutAll from MutableCollection providing a more specific return type. This is an extremely convenient and useful behavior.

The following code examples show how the with method is covariant by collection type in Eclipse Collections.

@Test
public void covariantReturnTypesForWithMethods()
{
    // with - MutableList
    MutableList<?> list = Lists.mutable.empty()
            .with("1")
            .with("2");

    Assertions.assertEquals(List.of("1", "2"), list);

    // with - MutableSet
    MutableSet<?> set = Sets.mutable.empty()
            .with("1")
            .with("2");

    Assertions.assertEquals(Set.of("1", "2"), set);

    // with - MutableBag
    MutableBag<?> bag = Bags.mutable.empty()
            .with("1")
            .with("2");

    Assertions.assertEquals(Bags.mutable.with("1", "2"), bag);

    // with - MutableSortedSet
    MutableSortedSet<?> sortedSet = SortedSets.mutable.empty()
            .with("1")
            .with("2");

    Assertions.assertEquals(SortedSets.mutable.with("1", "2"), sortedSet);

    // with - MutableSortedBag
    MutableSortedBag<?> sortedBag = SortedBags.mutable.empty()
            .with("1")
            .with("2");

    Assertions.assertEquals(SortedBags.mutable.with("1", "2"), sortedBag);
}

The with* methods are extremely helpful for defining Collector implementations similar to the ones defined in the Collectors2 class in Eclipse Collections. The covariant overrides that return the specific types make it possible to simply use method references, instead of having to write out a multi-statement lambda.

The following code shows how to use the withAll method as a method reference on MutableList and MutableSet to define the combiner argument for a Collector.

@Test
public void collectorsDefinedUsingCovariantWithAllMethods()
{
    var mutableListCollector = Collector.of(
            Lists.mutable::empty,
            MutableList::add,
            MutableList::withAll);

    MutableList<?> mutableList = List.of(1, 2, 3)
            .stream()
            .collect(mutableListCollector);

    Assertions.assertEquals(List.of(1, 2, 3), mutableList);

    var mutableSetCollector = Collector.of(
            Sets.mutable::empty,
            MutableSet::add,
            MutableSet::withAll);

    MutableSet<?> mutableSet = Set.of(1, 2, 3)
            .stream()
            .collect(mutableSetCollector);

    Assertions.assertEquals(Set.of(1, 2, 3), mutableSet);
}

Note, it is not nearly as nice or concise defining a Collector for java.util.ArrayList or java.util.HashSet, because addAll returns boolean.

The following code shows how a multi-statement lambda is required to implement the combiner argument of a Collector for ArrayList and HashSet.

@Test
public void collectorsDefinedUsingAddAllMethods()
{
    var arrayListCollector = Collector.of(
            ArrayList::new,
            List::add,
            (left, right) -> {
                left.addAll(right);
                return left;
            });

    List<?> list = List.of(1, 2, 3)
            .stream()
            .collect(arrayListCollector);

    Assertions.assertEquals(List.of(1, 2, 3), list);

    var hashSetCollector = Collector.of(
            HashSet::new,
            Set::add,
            (left, right) -> {
                left.addAll(right);
                return left;
            });

    Set<?> set = Set.of(1, 2, 3)
            .stream()
            .collect(hashSetCollector);

    Assertions.assertEquals(Set.of(1, 2, 3), set);
}

MutableBagIterable

The interface MutableBagIterable is a parent interface of MutableBag and MutableSortedBag. In addition to the methods it inherits from java.util.Collection and MutableCollection, it also includes addOccurrences and removeOccurrences. A Bag looks like a Collection and supports the same adding and removing semantics, but internally keeps a Map of keys to counts. These two methods allow you to increment or decrement the counts directly without having to loop and call add or remove a certain number of times.

The following code example shows how to use addOccurrences and removeOccurrences on MutableBagIterable.

@Test
public void mutableBagIterable()
{
    MutableBagIterable<Integer> bagIterable1 = Bags.mutable.with(1);

    // addOccurences
    bagIterable1.addOccurrences(2, 4);
    bagIterable1.addOccurrences(3, 6);

    // removeOccurences
    bagIterable1.removeOccurrences(2, 2);
    bagIterable1.removeOccurrences(3, 3);

    Bag<Integer> expected1 = Bags.mutable.withOccurrences(1, 1, 2, 2, 3, 3);
    Assertions.assertEquals(expected1, bagIterable1);
}

MutableStack

The one collection interface that does not extend java.util.Collection or MutableCollection is MutableStack. MutableStack defines push and pop for adding and removing elements in LIFO (Last-in, First-out) order. The return result of push is void, and the return result of pop is the element at the top of the stack that is removed. There are variations of pop that take a count, and that will return a List of elements popped off the stack.

The following code example shows how to use push and variations of pop on a MutableStack.

@Test
public void mutableStack()
{
    MutableStack<Integer> stack = Stacks.mutable.empty();

    // push
    stack.push(1);
    stack.push(2);
    stack.push(3);

    var expected1 = Stacks.mutable.with(1, 2, 3);
    Assertions.assertEquals(expected1, stack);

    // pop
    Assertions.assertEquals(3, stack.pop());
    Assertions.assertEquals(2, stack.pop());
    Assertions.assertEquals(1, stack.pop());

    // push
    expected1.forEach(stack::push);

    var expected2 = Stacks.mutable.with(3, 2, 1);
    Assertions.assertEquals(expected2, stack);

    // pop with count
    ListIterable<Integer> popCount = stack.pop(3);

    var expected3 = Lists.mutable.with(1, 2, 3);
    Assertions.assertEquals(expected3, popCount);
}

Immutable Collections

The ImmutableCollection interface is the base interface for all immutable collections in Eclipse Collections with the exception of ImmutableStack. ImmutableCollection does not extend java.util.Collection, because if it did, it would essentially be a contractually mutable interface.

In Eclipse Collections, the ImmutableCollection interfaces are contractually immutable. This means they have no mutating methods defined on the interfaces. The implementations of ImmutableCollection are also structurally immutable.

The following blog explains how an ImmutableCollection hierarchy could be defined using Sealed Types in Java to provide the trifecta of immutability — contractual, structural, and verifiable. Eclipse Collections only supports contractual and structural immutability today.

Immutable Collections in Java using Sealed Types

ImmutableCollection

Adding items to or removing items from an ImmutableCollection is not possible. What is possible is copying the elements of the ImmutableCollection to a new ImmutableCollection with a new element or without an existing element. While it is possible to grow and shrink ImmutableCollection instances this way, it may not be desirable. Every call to newWith* or newWithout* will result in a copy of the ImmutableCollection being made. If a lot of adds or removes are required, it would be advisable to convert the ImmutableCollection to a MutableCollection type first and then finally call toImmutable after all of the adds and/or removes are complete.

Here are some examples of using the methods newWith, newWithAll, newWithout and newWithoutAll on an ImmutableCollection.

@Test
public void immutableCollection()
{
    ImmutableCollection<Integer> collection = Lists.immutable.empty();

    // newWith
    ImmutableCollection<Integer> copyAdd1 = collection.newWith(1);
    ImmutableCollection<Integer> copyAdd2 = copyAdd1.newWith(2);
    ImmutableCollection<Integer> copyAdd3 = copyAdd2.newWith(3);

    Assertions.assertEquals(Lists.immutable.with(1), copyAdd1);
    Assertions.assertEquals(Lists.immutable.with(1,2), copyAdd2);
    Assertions.assertEquals(Lists.immutable.with(1,2,3), copyAdd3);

    // newWithout
    ImmutableCollection<Integer> copyRemove3 = copyAdd3.newWithout(3);
    ImmutableCollection<Integer> copyRemove2 = copyRemove3.newWithout(2);
    ImmutableCollection<Integer> copyRemove1 = copyRemove2.newWithout(1);

    Assertions.assertEquals(Lists.immutable.with(1,2), copyRemove3);
    Assertions.assertEquals(Lists.immutable.with(1), copyRemove2);
    Assertions.assertEquals(Lists.immutable.empty(), copyRemove1);

    // newWithAll
    ImmutableCollection<Integer> copyAddAll = 
        collection.newWithAll(Lists.mutable.with(1, 2, 3));

    Assertions.assertEquals(Lists.mutable.with(1,2,3), copyAddAll);

    // newWithoutAll
    ImmutableCollection<Integer> copyRemoveAll = 
        copyAddAll.newWithoutAll(Lists.mutable.with(1, 2));

    Assertions.assertEquals(Lists.mutable.with(3), copyRemoveAll);
}

Co-variant return types for newWith* methods

The interfaces ImmutableList, ImmutableSet, ImmutableBag, ImmutableSortedSet, ImmutableSortedBag, ImmutableBagIterable, and ImmutableSetIterable all override newWith, newWithAll, newWithout, and newWithoutAll from ImmutableCollection providing a more specific return type.

The following code examples show how the newWith method is covariant by collection type in Eclipse Collections.

@Test
public void covariantReturnTypesForNewWithMethods()
{
    // newWith - ImmutableList
    ImmutableList<?> list = Lists.immutable.empty()
            .newWith("1")
            .newWith("2");

    Assertions.assertEquals(List.of("1", "2"), list);

    // newWith - ImmutableSet
    ImmutableSet<?> set = Sets.immutable.empty()
            .newWith("1")
            .newWith("2");

    Assertions.assertEquals(Set.of("1", "2"), set);

    // with - MutableBag
    ImmutableBag<?> bag = Bags.immutable.empty()
            .newWith("1")
            .newWith("2");

    Assertions.assertEquals(Bags.mutable.with("1", "2"), bag);

    // with - MutableSortedSet
    ImmutableSortedSet<?> sortedSet = SortedSets.immutable.empty()
            .newWith("1")
            .newWith("2");

    Assertions.assertEquals(SortedSets.mutable.with("1", "2"), sortedSet);

    // with - MutableSortedBag
    ImmutableSortedBag<?> sortedBag = SortedBags.immutable.empty()
            .newWith("1")
            .newWith("2");

    Assertions.assertEquals(SortedBags.mutable.with("1", "2"), sortedBag);
}

Primitive Collections

The methods for adding elements to and removing elements from primitive collections are very similar to their object collection counterparts. On mutable primitive collections, there are methods named add, addAll, remove, removeAll, with, withAll, without, withoutAll. There are covariant overrides for the with* methods. On the immutable primitive collections there are methods names newWith, newWithAll, newWithout, newWithoutAll and there are also covariant overrides for each of these methods on the various container types (List, Set, Bag, Stack).

The following are some examples of using various adding/removing methods on mutable primitive collections.

@Test
public void mutablePrimitiveCollections()
{
    MutableIntSet set = IntSets.mutable.empty();

    // add
    Assertions.assertTrue(set.add(1));
    Assertions.assertFalse(set.add(1));

    // remove
    Assertions.assertTrue(set.remove(1));
    Assertions.assertFalse(set.remove(1));

    // with
    set.with(1).with(2).with(3).with(4);
    MutableIntSet expected1 = IntSets.mutable.with(1, 2, 3, 4);
    Assertions.assertEquals(expected1, set);

    // without
    set.without(2).without(4);
    MutableIntSet expected2 = IntSets.mutable.with(1, 3);
    Assertions.assertEquals(expected2, set);
}

The following are some examples of using various growing/shrinking methods on immutable primitive collections.

@Test
public void immutablePrimitiveCollections()
{
    // newWith
    ImmutableIntSet set1 = IntSets.immutable.empty()
            .newWith(1).newWith(2).newWith(3).newWith(4).newWith(5);

    Assertions.assertEquals(IntSets.mutable.with(1, 2, 3, 4, 5), set1);

    // newWithout
    ImmutableIntSet set2 = IntSets.immutable.with(1, 2, 3, 4, 5)
            .newWithout(1).newWithout(3).newWithout(5);

    Assertions.assertEquals(IntSets.mutable.with(2, 4), set2);

    // newWithAll
    ImmutableIntSet set3 = set2.newWithAll(IntSets.mutable.with(1, 3, 5));

    Assertions.assertEquals(set1, set3);

    // newWithoutAll
    ImmutableIntSet set4 = set3.newWithoutAll(IntSets.mutable.with(1, 3, 5));

    Assertions.assertEquals(set2, set4);
}

Final Thoughts

Thank you for taking the time to read this blog. I hope this will be a good reference for folks to refer to in the future. I tried to be as comprehensive as possible. In the next blog in this series, I will cover in depth how to convert between collection types using converted methods.

Enjoy!

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

Getting Started with Eclipse Collections — Part 1

Every journey has a beginning. This one has code and diagrams.

Finding Eclipse Collections at Maven Central

The Eclipse Collections project has been hosted at the Eclipse Foundation for over seven years. The library has two primary jars, and a couple of supplemental jars, that can be included in your project’s build files and downloaded from Maven Central.

The README.md for Eclipse Collections includes the coordinates for Maven, Gradle, and also an OSGi bundle.

The eclipse-collections-api jar is for the Eclipse Collections API, which primarily contains interfaces. The eclipse-collections jar contains all of the implementation classes.

To learn more about the two jars required for using Eclipse Collections, you can read the following blog.

Leverage Information Chunking to scale your Java library package design

Getting started with Eclipse Collections

Eclipse Collections is a comprehensive collections library for Java. There are a lot of interfaces and classes in the library, which can make it challenging to know where and how to start learning.

There are a few basic things you will want to learn in order to get started with Eclipse Collections, after you have included it in your project. The following blog posts will cover topics that will help speed you on your journey.

• Part 1 (This post!)— Creating Collections and Primitive Collections
• Part 2 — Adding to and removing from Collections
• Part 3 — Converting between Collection types
• Part 4 — Processing information in Collections

As you explore the library, you will learn how you can make your code more expressive and performant. The blogs in this getting started series will be as comprehensive as possible for each topic covered. I recommend reading the following blog if you would like to visualize how and why “Eclipse Collections is a comprehensive collections library for Java.”

Visualizing Eclipse Collections

If you prefer a hands-on approach to learning, then I would recommend completing some of the Eclipse Collections Code Katas. Many folks learn best by doing, and that is where the EC Code Katas can help.

The Eclipse Collections Code Katas

Creating Collections

The first thing you will want to learn in Eclipse Collections is how to create instances of various Collection types. Eclipse Collections has support for Mutable and Immutable types. Eclipse Collections also has support for both object collections and primitive collections. The primitive collections provide support for all eight Java primitive types (boolean, byte, char, short, int, float, long, double).

There are three ways to create collections in Eclipse Collections.

• Use a Constructor (e.g. new FastList())
• Use a Static Factory Method (e.g. FastList.newList())
• Use a Factory Class (e.g. Lists.mutable.empty())

The most convenient way to create collection containers in Eclipse Collections is to use the Factory classes. The constructor and static factory method approaches work fine, but require knowledge of the specific implementation class names you want to create. The only way to consistently create both Mutable and Immutable containers without having to learn and remember a lot of extra class names is using the Factory class approach.

Creating Containers using Factory Classes

In the following sections, there are examples of creating both Mutable and Immutable container types using Factory Classes in Eclipse Collections. Equivalent factory classes exist in both the eclipse-collections and eclipse-collections-api jars. The factory class duplication exists so default methods in the api jar can create instances of various collection types, without having to have direct references to the implementation classes. The factory classes from either jar work just as well.

The factory class names are Lists, Sets, Stacks, Bags, SortedSets, SortedBags, Maps, BiMaps, and Multimaps. If you know the collection type you want to create, just pluralize the collection type name to find the corresponding Factory class name (e.g. List -> Lists, Set -> Sets, Map -> Maps).

Object Collection Types

The following are the generic Object Collection types supported by Eclipse Collections. All object collections extend java.lang.Iterable, so they work with lJava’s forEach loop (since Java 5). All MutableCollection types extend java.util.Collection. ImmutableCollection interfaces do not extend java.util.Collection, and thus provide contractual immutability (no mutating methods). Links below take you to different sections on how to create each Collection type.

• List — Ordered Collections that allow duplicates. Memory efficient and good for fast iteration and indexed lookup.
• Set — Unordered Collection that does not allow duplicates. Good for uniquing and fast contains check.
• Stack — A “last in, first out” (LIFO) data structure. Stack does not extend Collection, and has its own methods for growing (push) and shrinking (pop).
• Bag—Unordered Collection that allow duplicates. Good for counting and for content equality test without requiring order.
• SortedSet — A sorted Collection that does not allow duplicates. Good for keeping data sorted and unique.
• SortedBag — A sorted Collection that allows duplicates. Good for keeping data sorted and for counting.
• Map — A Collection of key/value pairs. Fast lookup of values by key.
• SortedMap — A sorted Collection of key/value pairs. Fast lookup of values by key.
• BiMap — A bi-directional Map.
• MultiMap — A Map whose values are stored in a Collection type (List, Set, Bag, SortedSet, SortedBag)
• Interval — An inclusive range of Integer values. Interval implements java.util.List<Integer> and LazyIterable<Integer>.

Creating Lists

The following code examples show how to use the Lists factory class to create MutableList and ImmutableList instances.

// Empty MutableList
MutableList<String> emptyList =
        Lists.mutable.empty();

// MutableList with three elements
MutableList<String> list =
        Lists.mutable.with("1", "2", "3");

// Empty ImmutableList
ImmutableList<String> emptyImmutableList =
        Lists.immutable.empty();

// ImmutableList with three elements
ImmutableList<String> immutableList =
        Lists.immutable.with("1", "2", "3");

The following class diagram shows the relationships between MutableList and ImmutableList, and how the Lists factory class can be used to create either type.

The following sequence diagram shows the messages sent to the Lists class as well as the corresponding MutableListFactory and ImmutableListFactory types. This visualizes how the code example above works.

Return to TOC

Creating Sets

The following code examples show how to use the Sets factory class to create MutableSet and ImmutableSet instances.

// Empty MutableSet
MutableSet<String> emptySet =
        Sets.mutable.empty();

// MutableSet with three elements
MutableSet<String> set =
        Sets.mutable.with("1", "2", "3");

// Empty ImmutableSet
ImmutableSet<String> emptyImmutableSet =
        Sets.immutable.empty();

// ImmutableSet with three elements
ImmutableSet<String> immutableSet =
        Sets.immutable.with("1", "2", "3");

The following class diagram shows the relationships between MutableSet and ImmutableSet, and how the Sets factory class can be used to create either type.

Return to TOC

Creating Stacks

The following code examples show how to use the Stacks factory class to create MutableStack and ImmutableStack instances.

// Empty MutableStack
MutableStack<String> emptyStack =
        Stacks.mutable.empty();

// MutableStack with three elements
MutableStack<String> stack =
        Stacks.mutable.with("1", "2", "3");

// Empty MutableStack
ImmutableStack<String> emptyImmutableStack =
        Stacks.immutable.empty();

// ImmutableStack with three elements
ImmutableStack<String> immutableStack =
        Stacks.immutable.with("1", "2", "3");

The following class diagram shows the relationships between MutableStack and ImmutableStack, and how the Stacks factory class can be used to create either type. Noe, the Stack interfaces in Eclipse Collections are not related to the java.util.Stack class. There is no Stack interface in the JDK. MutableStack does not extend MutableCollection, as a MutableStack has a different mutable API (push, pop) than MutableCollection (add, remove). I will cover add, remove, push and pop in the next blog in this series.

Return to TOC

Creating Bags

The following code examples show how to use the Bags factory class to create MutableBag and ImmutableBag instances.

// Empty MutableBag
MutableBag<String> emptyBag =
        Bags.mutable.empty();

// MutableBag with three elements
MutableBag<String> bag =
        Bags.mutable.with("1", "2", "3");

// Empty ImmutableBag
ImmutableBag<String> emptyImmutableBag =
        Bags.immutable.empty();

// ImmutableBag with three elements
ImmutableBag<String> immutableBag =
        Bags.immutable.with("1", "2", "3");

The following class diagram shows the relationships between MutableBag and ImmutableBag, and how the Bags factory class can be used to create either type.

Return to TOC

Creating SortedSets

The following code examples show how to use the SortedSets class to create MutableSortedSet and ImmutableSortedSet instances.

// Empty MutableSortedSet
MutableSortedSet<String> emptySortedSet =
        SortedSets.mutable.empty();

// MutableSortedSet with three elements
MutableSortedSet<String> sortedSet =
        SortedSets.mutable.with("1", "2", "3");

// Empty ImmutableSortedSet
ImmutableSortedSet<String> emptyImmutableSortedSet =
        SortedSets.immutable.empty();

// MutableSortedSet with three elements
ImmutableSortedSet<String> immutableSortedSet =
        SortedSets.immutable.with("1", "2", "3");

The following class diagram shows the relationships between MutableSortedSet and ImmutableSortedSet, and how the SortedSets factory class can be used to create either type.

Return to TOC

Creating SortedBags

The following code examples show how to use the SortedBags factory class to create MutableSortedBag and ImmutableSortedBag instances.

// Empty MutableSortedBag
MutableSortedBag<String> emptySortedBag =
        SortedBags.mutable.empty();

// MutableSortedBag with three elements
MutableSortedBag<String> sortedBag =
        SortedBags.mutable.with("1", "2", "3");

// Empty ImmutableSortedBag
ImmutableSortedBag<String> emptyImmutableSortedBag =
        SortedBags.immutable.empty();

// ImmutableSortedBag with three elements
ImmutableSortedBag<String> immutableSortedBag =
        SortedBags.immutable.with("1", "2", "3");

The following class diagram shows the relationships between MutableSortedBag and ImmutableSortedBag, and how the SortedBags factory class can be used to create either type.

Return to TOC

Creating Maps

The following code examples show how to use the Maps factory class to create MutableMap and ImmutableMap instances.

// Empty MutableMap
MutableMap<String, String> emptyMap =
        Maps.mutable.empty();

// MutableMap with three elements
MutableMap<Integer, String> map =
        Maps.mutable.with(1, "1", 2, "2", 3, "3");

// Empty MutableMap
ImmutableMap<String, String> emptyImmutableMap =
        Maps.immutable.empty();

// MutableMap with three elements
ImmutableMap<Integer, String> immutableMap =
        Maps.immutable.with(1, "1", 2, "2", 3, "3");

The following class diagram shows the relationships between MutableMap and ImmutableMap, and how the Maps factory class can be used to create either type.

Return to TOC

Creating SortedMaps

The following code examples show how to use the SortedMaps factory class to create MutableSortedMap and ImmutableSortedMap instances.

// Empty MutableSortedMap
MutableSortedMap<String, String> emptySortedMap =
        SortedMaps.mutable.empty();

// MutableSortedMap with three elements
MutableSortedMap<Integer, String> sortedMap =
        SortedMaps.mutable.with(1, "1", 2, "2", 3, "3");

// Empty MutableSortedMap
ImmutableSortedMap<String, String> emptyImmutableSortedMap =
        SortedMaps.immutable.empty();

// MutableSortedMap with three elements
ImmutableSortedMap<Integer, String> immutableSortedMap =
        SortedMaps.immutable.with(1, "1", 2, "2", 3, "3");

The following class diagram shows the relationships between MutableSortedMap and ImmutableSortedMap, and how the SortedMaps factory class can be used to create either type.

Return to TOC

Creating BiMaps

The following code examples show how to use the BiMaps factory class to create MutableBiMap and ImmutableBiMap instances. The examples also show how to invert a BiMap using the inverse method.

// Empty MutableMap
MutableBiMap<Integer, String> emptyBiMap =
        BiMaps.mutable.empty();

// Inverting the MutableMap
MutableBiMap<String, Integer> emptyInverse =
        emptyBiMap.inverse();

// MutableMap with three elements
MutableBiMap<Integer, String> biMap =
        BiMaps.mutable.with(1, "1", 2, "2", 3, "3");

// Inverting the MutableMap
MutableBiMap<String, Integer> biMapInverse =
        biMap.inverse();

// Empty MutableMap
ImmutableBiMap<Integer, String> emptyImmutableBiMap =
        BiMaps.immutable.empty();

// Inverting the ImmutableBiMap
ImmutableBiMap<String, Integer> emptyImmutableBiMapInverse =
        emptyImmutableBiMap.inverse();

// MutableMap with three elements
ImmutableBiMap<Integer, String> immutableBiMap =
        BiMaps.immutable.with(1, "1", 2, "2", 3, "3");

// Inverting the ImmutableBiMap
ImmutableBiMap<String, Integer> immutableBiMapInverse = 
        immutableBiMap.inverse();

The following class diagram shows the relationships between MutableBiMap and ImmutableBiMap, and how the BiMaps factory class can be used to create either type.

Return to TOC

Creating Multimaps

The following code examples show how to use the Multimaps factory class to create MutableMultimap and ImmutableMultimap instances. There are List, Set, Bag, SortedSet, and SortedBag variations of Multimap. Each Multimap type has Mutable and Immutable variations.

// Empty MutableListMultimap
MutableListMultimap<String, String> listMultimap =
        Multimaps.mutable.list.empty();

// Empty MutableSetMultimap
MutableSetMultimap<String, String> setMultimap =
        Multimaps.mutable.set.empty();

// Empty MutableBagMultimap
MutableBagMultimap<String, String> bagMultimap =
        Multimaps.mutable.bag.empty();

// Empty MutableSortedSetMultimap
MutableSortedSetMultimap<String, String> sortedSetMultimap =
        Multimaps.mutable.sortedSet.with(Comparator.<String>naturalOrder());

// Empty MutableSortedBagMultimap
MutableSortedBagMultimap<String, String> sortedBagMultimap =
        Multimaps.mutable.sortedBag.with(Comparator.<String>naturalOrder());

// Empty ImmutableListMultimap
ImmutableListMultimap<String, String> immutableListMultimap =
        Multimaps.immutable.list.empty();

// Empty ImmutableSetMultimap
ImmutableSetMultimap<String, String> immutableSetMultimap =
        Multimaps.immutable.set.empty();

// Empty ImmutableBagMultimap
ImmutableBagMultimap<String, String> immutableBagMultimap =
        Multimaps.immutable.bag.empty();

// Empty ImmutableSortedSetMultimap
ImmutableSortedSetMultimap<String, String> immutableSortedSetMultimap =
        Multimaps.immutable.sortedSet.with(Comparator.<String>naturalOrder());

// Empty ImmutableSortedBagMultimap
ImmutableSortedBagMultimap<String, String> immutableSortedBagMultimap =
        Multimaps.immutable.sortedBag.with(Comparator.<String>naturalOrder());

The following class diagram shows the relationships between MutableMultimaps and ImmutableMultimaps, and how the Multimaps factory class can be used to create the different variations of Multimap.

Return to TOC

Creating Intervals

The Interval class is an inclusive range of Integer that implements List<Integer>. Interval is Immutable. Interval will throw an UnsupportedOperationException for any mutating methods it implements from the List API. An Interval has a from and to value that are inclusive, and a step value. The Interval class in Eclipse Collections does not have a separate factory class. It also does not have a separate interface, so only exists in the implementation jar.

// One element Interval
Interval one = Interval.fromToBy(1, 1, 1);

// One to Ten
Interval oneToTen = Interval.oneTo(10);

// Zero to Nine
Interval zeroToNine = Interval.zeroTo(9);

// Evens from 1 to 100
Interval evens = Interval.evensFromTo(1, 100);

// Odds from 1 to 100
Interval odds = Interval.oddsFromTo(1, 100);

// 1 to 20 by 5
Interval oneToTwentybyFive = Interval.fromToBy(1, 100, 5);

// 0 to -100
Interval negativeRange = Interval.zeroTo(-100);

Return to TOC

Creating other lesser known Collections

The following blogs explain more about the missing Java data structures that no one ever told you about. There is an explanation how to create HashingStrategy Collections/Maps, and MultiReader Collections.

• The missing Java data structures no one ever told you about — Part 1
• The missing Java data structures no one ever told you about — Part 2

Creating Primitive Collections

Eclipse Collections provides primitive collections support for all eight primitive types (boolean, byte, char, short, int, float, long, double). There are Mutable and Immutable forms of all primitive container types.

The convention used for the naming of primitive collection factory classes is simple. The prefix is the primitive type (Boolean, Byte, Char, Short, Int, Float, Long, Double) followed by the container type pluralized (Lists, Sets, Bags, Stacks, Maps). Some primitive factory class examples are DoubleLists, ShortSets, FloatBags, IntStacks, ObjectIntMaps, IntObjectMaps, and CharLongMaps.

Primitive Collection Types

The follow are the primitive Collection types supported by Eclipse Collections.

• List
• Set
• Stack
• Bag
• Primitive/Primitive Map
• Object/Primitive Map
• Primitive/Object Map
• String Adapter
• Interval

Creating Primitive Lists

The following code examples show how to use the DoubleLists factory class to create MutableDoubleList and ImmutableDoubleList instances. Equivalent primitive List factories exists for all eight primitive types.

// Empty MutableDoubleList
MutableDoubleList emptyList =
        DoubleLists.mutable.empty();

// MutableDoubleList with three elements
MutableDoubleList list =
        DoubleLists.mutable.with(1.0, 2.0, 3.0);

// Empty ImmutableDoubleList
ImmutableDoubleList emptyImmutableList =
        DoubleLists.immutable.empty();

// ImmutableDoubleList with three elements
ImmutableDoubleList immutableList =
        DoubleLists.immutable.with(1.0, 2.0, 3.0);

The following class diagram shows the relationships between MutableDoubleList and ImmutableDoubleList, and how the DoubleLists factory class can be used to create either type. Other primitive collection factory class diagrams will look very similar to this one, so I will not include additional ones.

The following sequence diagram shows the messages sent to the DoubleLists class as well as the corresponding MutableDoubleListFactory and ImmutableDoubleListFactory types. This visualizes how the code example above works.

Return to TOC

Creating Primitive Sets

The following code examples show how to use the ShortSets factory class to create MutableShortSet and ImmutableShortSet instances. Equivalent primitive Set factories exists for all eight primitive types.

// Empty MutableShortSet
MutableShortSet emptySet =
        ShortSets.mutable.empty();

// MutableShortSet with three elements
MutableShortSet set =
        ShortSets.mutable.with((short) 1, (short) 2, (short) 3);

// Empty ImmutableShortSet
ImmutableShortSet emptyImmutableSet =
        ShortSets.immutable.empty();

// ImmutableShortSet with three elements
ImmutableShortSet immutableSet =
        ShortSets.immutable.with((short) 1, (short) 2, (short) 3);

Return to TOC

Creating Primitive Stacks

The following code examples show how to use the IntStacks factory class to create MutableIntStack and ImmutableIntStack instances. Equivalent primitive Stack factories exists for all eight primitive types.

// Empty MutableIntStack
MutableIntStack emptyStack =
        IntStacks.mutable.empty();

// MutableIntStack with three elements
MutableIntStack stack =
        IntStacks.mutable.with(1, 2, 3);

// Empty ImmutableIntStack
ImmutableIntStack emptyImmutableStack =
        IntStacks.immutable.empty();

// ImmutableIntStack with three elements
ImmutableIntStack immutableStack =
        IntStacks.immutable.with(1, 2, 3);

Return to TOC

Creating Primitive Bags

The following code examples show how to use the FloatBags factory class to create MutableFloatBag and ImmutableFloatBag instances. Equivalent primitive Bag factories exists for all eight primitive types.

// Empty MutableFloatBag
MutableFloatBag emptyBag =
        FloatBags.mutable.empty();

// MutableFloatBag with three elements
MutableFloatBag bag =
        FloatBags.mutable.with(1.0f, 2.0f, 3.0f);

// Empty ImmutableFloatBag
ImmutableFloatBag emptyImmutableBag =
        FloatBags.immutable.empty();

// ImmutableFloatBag with three elements
ImmutableFloatBag immutableBag =
        FloatBags.immutable.with(1.0f, 2.0f, 3.0f);

Return to TOC

Creating Primitive/Primitive Maps

The following code examples show how to use the CharLongMaps factory class to create MutableCharLongMap and ImmutableCharLongMap instances. Equivalent primitive/primitive Map factories exists for all combinations of primitive/primitive types.

// Empty MutableCharLongMap
MutableCharLongMap emptyMap =
        CharLongMaps.mutable.empty();

// MutableCharLongMap with three elements
MutableCharLongMap map =
        CharLongMaps.mutable.with('1', 1L, '2', 2L, '3', 3L);

// Empty ImmutableCharLongMap
ImmutableCharLongMap emptyImmutableMap =
        CharLongMaps.immutable.empty();

// ImmutableCharLongMap with three elements
ImmutableCharLongMap immutableMap =
        CharLongMaps.immutable.with('1', 1L, '2', 2L, '3', 3L);

Return to TOC

Creating Object/Primitive Maps

The following code examples show how to use the ObjectIntMaps factory class to create MutableObjectIntMap and ImmutableObjectIntMap instances. Equivalent object/primitive Map factories exists for all eight primitive types.

// Empty MutableObjectIntMap
MutableObjectIntMap<String> emptyMap =
        ObjectIntMaps.mutable.empty();

// MutableObjectIntMap with three elements
MutableObjectIntMap<String> map =
        ObjectIntMaps.mutable.with("1", 1, "2", 2, "3", 3);

// Empty ImmutableObjectIntMap
ImmutableObjectIntMap<String> emptyImmutableMap =
        ObjectIntMaps.immutable.empty();

// ImmutableObjectIntMap with one element
ImmutableObjectIntMap<String> immutableMap =
        ObjectIntMaps.immutable.with("1", 1);

Return to TOC

Creating Primitive/Object Maps

The following code examples show how to use the IntObjectMaps factory class to create MutableIntObjectMap and ImmutableIntObjectMap instances. Equivalent primitive/object Map factories exists for all eight primitive types.

// Empty MutableIntObjectMap
MutableIntObjectMap<String> emptyMap =
        IntObjectMaps.mutable.empty();

// MutableIntObjectMap with three elements
MutableIntObjectMap<String> map =
        IntObjectMaps.mutable.with(1, "1", 2, "2", 3, "3");

// Empty ImmutableObjectIntMap
ImmutableIntObjectMap<String> emptyImmutableMap =
        IntObjectMaps.immutable.empty();

// ImmutableObjectIntMap with one element
ImmutableIntObjectMap<String> immutableMap =
        IntObjectMaps.immutable.with(1, "1");

Return to TOC

Creating String Adapters

There are three String adapter classes in Eclipse Collections. The classes are CharAdapter, CodePointAdapter and CodePointList. These classes can be instantiated via static factory methods on the classes directly, or by using the Strings factory class.

// Hello World! as a CharAdapter
CharAdapter charAdapter =
        Strings.asChars("Hello World!");

// Hello World! as a CodePointAdapter
CodePointAdapter codePointAdapter =
        Strings.asCodePoints("Hello World!");

// Hello World! from code point values
CodePointAdapter fromCodePoints =
        Strings.toCodePoints(72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33);

// Hello World! from char values
CharAdapter fromChars =
        Strings.toChars('H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!');

Return to TOC

Creating Primitive Intervals

There are two primitive Interval types. They are IntInterval and LongIterval. Unlike the Interval object collection which implements List<Integer> and LazyIterable<Integer>, IntInterval implements ImmutableIntList and LongIterval implements ImmutableLongList.

// One element IntInterval
IntInterval one = IntInterval.fromToBy(1, 1, 1);

// One to Ten LongInterval
LongInterval oneToTen = LongInterval.oneTo(10L);

// Zero to Nine IntInterval
IntInterval zeroToNine = IntInterval.zeroTo(9);

// Evens from 1 to 100 LongInterval
LongInterval evens = LongInterval.evensFromTo(1L, 100L);

// Odds from 1 to 100 IntInterval
IntInterval odds = IntInterval.oddsFromTo(1, 100);

// 1 to 20 by 5 LongInterval
LongInterval oneToTwentybyFive = LongInterval.fromToBy(1L, 100L, 5L);

// 0 to -100 IntInterval
IntInterval negativeRange = IntInterval.zeroTo(-100);

Return to TOC

More about primitive Collections

This blog focused primarily on how to create primitive collections. The following blog goes into more detail on leveraging primitive collections, and the benefits.

The missing Java data structures no one ever told you about — Part 3

More Factory Examples

For additional examples of creating Mutable and Immtuable collections, please read the following blogs.

• As a matter of Factory — Part 1 (Mutable)
• As a matter of Factory — Part 2 (Immutable)
• As a matter of Factory — Part 3 (Method Chaining)

Final Thoughts

Thank you for taking the time to read this blog. I hope this will be a good reference for folks to refer to in the future. I tried to be as comprehensive as possible. In the next blog in this series, I will cover in depth how to add and remove items from different collection types.

Enjoy!

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

Eclipse GLSP became the default solution for diagram editors for many web-based tool projects. Although GLSP can be used independently, Eclipse...

The post Diagram Editors in Theia with Eclipse GLSP appeared first on EclipseSource.

More news

Answering even basic questions about software supply chain security has been surprisingly hard. For instance, how widespread are the different practices associated with software supply chain security? And do software professionals view these practices as useful or not? Easy or hard? To help answer these and related questions, Chainguard, the Eclipse Foundation, the Rust Foundation, and the Open Source Security Foundation (OpenSSF) partnered to field a software supply chain security survey. The questions were primarily, but not exclusively, derived from the security requirements associated with the Supply-chain Levels for Software Artifacts (SLSA) supply chain integrity framework version 0.1 (the version when the survey was conducted), hence SLSA++.

In light of the recent White House National Cybersecurity Strategy, which emphasizes organizations use best practices and frameworks for secure software development, it’s important to understand how individual contributors responsible for this work–like developers, open source maintainers and security practitioners–are adopting software supply chain security practices and guidelines. The new SLSA++ survey provides insights into these trends, what’s working and what’s not working.

The survey, conducted in the summer and fall of 2022, includes data from nearly 170 respondents at a wide range of organizations, large and small, some security-focused in their role and others not. All respondents answered a series of questions for ten different software supply chain security practices. Three key findings stand out:

Some software supply chain security practices are already widely adopted.

Many practices already have strong or moderate adoption. For instance, over half of the respondents report always using a centralized build service. Other practices, such as digital signatures, were practiced less often: only 25% of respondents reported that their team always signs built artifacts. These findings are consistent with Google’s 2022 State of DevOps report.

Most practices are considered helpful though there is surprisingly little variation in the perceived level of helpfulness.

For each software supply chain security practice in the survey, at least 50% of the respondents labeled the practice as either extremely helpful or very helpful. Surprisingly though, the perceived helpfulness varies only slightly from practice to practice among the practices surveyed. Finally, the extent to which a participant views a particular practice as helpful is positively correlated with the likelihood that the participant’s organization adopts that practice. Whether these practices are viewed as helpful and then used or whether used practices are used and then viewed as helpful can’t be determined from the survey data.

Some SLSA practices are considered substantially more difficult than others.

Hermetic builds and reproducible builds were considered much more difficult than the other practices. Over 50% of respondents stated that those practices were either extremely difficult or very difficult. Other practices, such as scanning container images, were considered relatively easy. Additionally, the perceived difficulty of these practices had no statistically significant relationship with adoption.

In summary, the survey results suggest that software supply chain security practices are not an unattainable ideal. Some software supply chain security practices already enjoy widespread adoption. Also importantly, because perceived usefulness, not difficulty, appears to currently explain trends in adoption of these practices, parties interested in promoting these practices should consider explaining the benefits of these different practices rather than simply focusing on better tools.

A report detailing the survey, including its methodology, can be found here.

If interested in learning more about the findings and how organizations can implement the SLSA framework join Chainguard, OpenSSF, Rust Foundation and Eclipse Foundation for a virtual discussion on March 22, 2023 from 11-12 PM ET / 8-9 AM PT. Sign up for a calendar reminder here.

Authors: David A. Wheeler, The Linux Foundation; John Speed Meyers, Chainguard; Mikaël Barbero, Eclipse Foundation; and Rebecca Rumbul, Rust Foundation

BRUSSELS, Belgium – MARCH 14, 2023 – The Eclipse Foundation, one of the world’s largest open source software foundations, in collaboration with the Adoptium Working Group, today announced significant momentum for the global open source Java ecosystem. This momentum comes in the wake of new licensing fee structures being introduced into the industry. In some cases, enterprises that have paid tens of thousands of dollars are now facing fees of millions of dollars for access to Java. 

As a result, the uptake of free-to-use high-quality Java has never been higher. In February 2023 the Eclipse Foundation delivered over 12.3M downloads of Java SE TCK certified and AQAvit quality verified Eclipse Temurin binaries, more than double the number delivered in the same month last year. Eclipse Temurin has also become the default Java option for GitHub Actions, and multiple widely used cloud container images. As the entire open source Java ecosystem continues to experience a Renaissance, millions of developers and large Enterprise users are turning to the Adoptium Marketplace for their open Java runtimes. What’s more, the Adoptium Working Group is welcoming new strategic and enterprise members including Bloomberg, Google, and Rivos.

“In a macroeconomic climate where we are all forced to do more with less, options like Eclipse Temurin mean that businesses have choices for free-to-use quality Java runtimes without having to expend additional resources,” said Mike Milinkovich, executive director of the Eclipse Foundation. “With new members joining every month, the quality and consistency of the Adoptium Working Group’s output will only continue to grow to address that pressure.”

The Adoptium Working Group, which was founded by multiple participants, including many Java developers and vendors such as Alibaba Cloud, Azul, Huawei, IBM, iJUG, Microsoft, and Red Hat, provides the Java ecosystem with fully compatible, high-quality distributions of Java based on OpenJDK source code. For enterprises that rely on Java and wish to ensure an open, community-led future for this important open source option, joining the Working Group represents a critical step in taking control of their own technical destiny. 

“2023 is shaping up to be an incredibly productive year for the Adoptium Working Group and for the entire open source Java ecosystem,” said Tim Ellison, PMC Lead for Eclipse Adoptium. “With our focus on secure development practices and high quality deliveries there has never been a better time for organizations to choose a free-to-use Java runtime.”

The Eclipse Adoptium project and the governing Adoptium Working Group are the continuation of the original AdoptOpenJDK mission, which was established in 2017 to address the general lack of an open, vendor-neutral, reproducible build and test system for OpenJDK across multiple platforms. Adoptium is now the leading provider of high-quality OpenJDK-based binaries used by Java developers across embedded systems, desktops, traditional servers, modern cloud platforms, and mainframes. The Adoptium Marketplace extends this leadership role and gives even more organizations a means of distributing their binaries. 

If your organization is interested in participating in the Adoptium Working Group, you can view the Charter and Participation Agreement, or email us at membership@eclipse.org. You can also participate as a sponsor; interested parties can view the Sponsorship Agreement. Both membership and sponsorship help assure sustainability.

Supporting Quotes from Adoptium Members:

Google

“We are excited to participate in the Adoptium Working Group and contribute to the future of Eclipse Temurin. Google is committed to making Google Cloud a premier cloud for Java developers and workflows, and we believe an open, secure, and high-quality vendor-neutral JDK distribution is a critical component to that.” Dan Gazineu, Engineering Manager, Google Cloud SDK

Azul

“Third-party Java runtimes were already on the rise prior to Oracle’s recent pricing changes, and we expect that trend to accelerate rapidly moving forward,” said Simon Ritter, Deputy CTO, Azul. “Java provides immense value across the DevSecOps lifecycle, but Oracle’s new employee-based pricing is divorced from that value. Customers are increasingly frustrated over what they see as arbitrary pricing changes, audit risks and a lack of overall predictability. Thankfully, drop-in replacements for Oracle abound, and offer a compelling value for Java-based enterprises.” 

Red Hat

“As a long term contributor to open source Java SE, Red Hat applauds the sustained growth and uptake of OpenJDK and Temurin throughout modern, business-critical enterprise software solutions,” said Mark Little, VP, Engineering, Red Hat. “Adoptium is a leading example of a community-powered approach to delivering secure, reliable and high-performing open source software. Red Hat’s engagement in the Adoptium Working Group and confidence in the community is reflected in our expanded support offerings that include development and production use cases of Temurin, similar to the award-winning support that comes with the Red Hat build of OpenJDK. We wish Adoptium every continued success.”

About the Eclipse Foundation

The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation. The Foundation is home to the Eclipse IDE, Jakarta EE, and over 400 open source projects, including runtimes, tools, and frameworks for cloud and edge applications, IoT, AI, automotive, systems engineering, distributed ledger technologies, open processor designs, and many others. The Eclipse Foundation is an international non-profit association supported by over 330 members, including industry leaders who value open source as a key enabler for their business strategies. To learn more, follow us on Twitter @EclipseFdn, LinkedIn or visit eclipse.org.

Third-party trademarks mentioned are the property of their respective owners.

###

Media contacts:

Schwartz Public Relations for the Eclipse Foundation, AISBL

Stephanie Brüls / Susanne Pawlik

Sendlinger Straße 42A

80331 Munich

EclipseFoundation@schwartzpr.de

+49 (89) 211 871 – 64 / -35

Nichols Communications for the Eclipse Foundation, AISBL

Jay Nichols

jay@nicholscomm.com

+1 408-772-1551

In my previous two blog posts I discussed concerns with the European Cyber Resilience Act (“CRA”) which we believe will harm both the open source community and the innovation economy in Europe. But the CRA needs to be understood as part of a larger legislative framework. In this post we will examine the potential impact of the proposed changes to the European Product Liability Directive (“PLD”) on the open source community and ecosystem. 

As in previous discussions I think it is important to note that the intentions of the PLD are good. No one can argue that the time has come to protect consumers from poor software. But at the same time, it is important to ensure that the consumer liability obligations are borne by the economic actors who deliver products and services to consumers, and not by the open source community which enables so much benefit to society by providing free software but does not share in the profits of the delivery. 

As I understand it, the purpose of the CRA is to establish which parties are responsible for ensuring the quality of software products, particularly as it relates to cybersecurity. The purpose of the PLD is to establish which parties are liable for defects which cause harm to individuals or their property. So strictly speaking, my assertion in my previous blog posts that the CRA will break the limited liability obligations that underpins free software was incorrect. It is the PLD which is doing that. 

The European Commission presented a draft of the revisions to the PLD last September, and it is going through the process of being adopted by the European Parliament and the Council of the European Union. As a Directive, the PLD will be interpreted by each member state of the European Union and applied to updates of the local laws in each country. The specific intent of these revisions are to update the PLD of 1985 to address issues related to the modern digital economy. One of the key features of the PLD is its “no fault liability” model where injured parties can seek redress without demonstrating any error or fault on the part of the product manufacturer. The proposed revision explicitly expands the scope of no fault liability to cover software and artificial intelligence, and adds “loss or corruption of data” as a harm that could be suffered by a consumer. 

There are numerous legal summaries of the PLD available, but this one from the law firm Baker Mackenzie provides a nice overview, as does this one from the law firm Cooley. 

It has long been understood that product liability could not be completely waived by open source licenses in Europe. Hence, the “…to the extent permissible by law…” statements you see in many licenses. Since at least 1985, there have been strict provisions in Europe that you were always liable for harm caused to natural persons or their personal property as a result of using a defective product. From the perspective of an open source developer, the PLD extends and modernizes this legal framework in the following important ways:

• It explicitly extends the definition of product to include software and artificial intelligence;
• It explicitly extends the definition of harm to include loss or corruption of data;
• The definition of manufacturer (formerly producer) has been extended to cover developers, providers of software, providers of digital services, and online marketplaces;
• It makes it clear that a cybersecurity vulnerability is a product defect, and that failure to update a product to protect against a vulnerability may result in liability;
• It makes it clear that if a component is defective, liability may extend to the manufacturer of the component (e.g. the developer of the open source software), in addition to the manufacturer of the end product;
• Distribution of a product or component in Europe explicitly incurs liability obligations on the part of the distributor, unless they can identify a responsible economic actor in Europe; and
• There is an attempt to exclude open source from the provisions of the Directive, but as previously discussed the “…outside the course of a commercial activity…” language means that the exclusion is not helpful in practice. 

Article 7 of the PLD goes to great lengths to identify the economic operators who can be held liable for a defective product, with a particular emphasis on identifying an entity in Europe who can bear the responsibility for a defective product made available in the single market. If you parse Article 7, who get something like the following to determine the party in Europe liable for a defective product:

• If the manufacturer is European, then the manufacturer is liable.
• Otherwise, if the importer or manufacturer’s authorized representative are European, then the importer and/or manufacturer’s authorized representative are liable.
• If none of the above conditions apply, each distributor is liable (each distributor is given 1 month to identify one of the above economic operators to hold the bag)

Note that the manufacturer of a defective component also becomes liable.

Should Open Source Developers be Worried?

I think they should. Particularly if they are located in Europe. 

Huge caveat here. I’ve been studying the PLD for a couple of weeks now, and every time I read it I think of more corner cases and more scenarios. If anyone finds fault in my analysis or logic, do please let me know!

Scenario One

Imagine a scenario where a year ago or so a consumer in Europe lost data as a result of using the Wizbang product from BigCo GmbH. The vulnerability in Wizbang was caused by the famous Log4shell bug. As part of its normal build process, BigCo downloaded the Apache Log4j jar file from Maven Central. Under the PLD framework, the Apache Software Foundation  (“ASF”) is the manufacturer of the Apache Log4j jar file and Sonatype (the company controlling Maven Central) is the distributor of the Log4j component as they made the Log4j software available to the European market. (The relevant definition reads “…‘making available on the market’ means any supply of a product for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”). Both the ASF and Sonatype are US based organizations.

Under the PLD, BigCo, the ASF, and Sonatype are all ‘economic operators’ involved in the development of the Wizbang defective product. As mentioned above, Article 7 of the PLD lays out the liability obligations for each of the various types of economic operators. 

My read of the PLD is that as the European manufacturer of Wizbang and the importer of the Log4j component, BigCo GmbH would be liable to consumers of the defective product. I think the ASF would not be held liable for the defect in Log4j because it does not meet the definition of an economic operator in Europe. I.e. the ASF has no legal presence in Europe. Similarly, Maven Central is a distributor in this context, but the algorithm in Article 7 puts the importer ahead of the distributor in the queue for liability obligations. 

Scenario Two

Same as above, but instead the defective open source component is (say) the Eclipse Modeling Framework (EMF), so the component manufacturer is the Eclipse Foundation AISBL, a European-based open source foundation. 

My read of the PLD is that as the European manufacturers of the Wizbang product and the EMF component, BigCo GmbH and the Eclipse Foundation would both be jointly and severally liable to consumers of the defective product. If I am correct, this scenario puts European open source projects, communities, and foundations at a disadvantage relative to their international peers. 

Summary

The good news is that I can’t think of a scenario where Maven Central, or services like it, become liable as a distributor under the PLD. The components they distribute would be used by a manufacturer and there are several layers of economic operators in front of a component distributor before liability results. The same seems to be true for open source foundations based outside of Europe. 

The bad news is that it does appear that the PLD as currently worded would expose European-based open source projects to product liability. I have to assume that this was an unintended consequence.

Proposed Enhancements

I hypothesize that when some people think of open source software components and the open source supply chain, they think of something like a braking system module that is assembled into a passenger car. After all, terminology like “component” and “supply chain” lends itself perfectly to that interpretation. I believe that a closer analogy would be inputs to a chemical process. Don’t think of a “braking component”, think acetate or sulphuric acid. I think this analogy is correct because beyond the sheer malleability of software, it is important to recall that open source software is by definition not restricted to any field of use. Every piece of open source software can (and is) used for any purpose that anyone can find for it. To give just one example, the Eclipse IDE platform was designed to implement desktop developer tools. But over the years it has ended up being used in scientific instruments on the International Space Station, to control medical imaging devices, mission planning for the Mars Rover, operations control of major railway networks, and ground station control software for space satellites. The adopters of open source have rich imaginations indeed.

The point of the above is that it is essential that open source software be excluded from the strict, no-fault liability obligations of the PLD. Not because open source developers are entitled to special treatment, but because the liability truly rests with the organization that placed the open source software into a product, and placed that product into the hands of a consumer. It is the act of using open source software that makes it critical, not the act of publishing or distributing it. 

To that end, I feel that the correct enhancement is to strengthen the exclusion of open source in the PLD to make it much clearer than it currently is.

The Gory Details

For those who want to look into the language of the PLD, here are what I noticed as the relevant sections and what they mean. (Emphasis added by me in a few places.)

• (12) Products in the digital age can be tangible or intangible. Software, such as operating systems, firmware, computer programs, applications or AI systems, is increasingly common on the market and plays an increasingly important role for product safety. Software is capable of being placed on the market as a standalone product and may subsequently be integrated into other products as a component, and is capable of causing damage through its execution. In the interest of legal certainty it should therefore be clarified that software is a product for the purposes of applying no-fault liability, irrespective of the mode of its supply or usage, and therefore irrespective of whether the software is stored on a device or accessed through cloud technologies. The source code of software, however, is not to be considered as a product for the purposes of this Directive as this is pure information. The developer or producer of software, including AI system providers within the meaning of [Regulation (EU) …/… (AI Act)], should be treated as a manufacturer. 

So Recital 12 makes it clear that software is a product under the PLD and that the developer is the manufacturer. 

• (13) In order not to hamper innovation or research, this Directive should not apply to free and open-source software developed or supplied outside the course of a commercial activity. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. However where software is supplied in exchange for a price or personal data is used other than exclusively for improving the security, compatibility or interoperability of the software, and is therefore supplied in the course of a commercial activity, the Directive should apply.

Recital 13 provides a carve out for open source. However, it retains the same fatal flaw as the CRA in that the carve out applies only to “software developed or supplied outside the course of a commercial activity”, which is woefully misplaced if it is intended to provide any protection of the open source ecosystem from the scope of this legislation. To see why, please see Maarten Aertsen’s blog post. 

• (23) In order to reflect the increasing prevalence of inter-connected products, the assessment of a product’s safety should also take into account the effects of other products on the product in question. The effect on a product’s safety of its ability to learn after deployment should also be taken into account, to reflect the legitimate expectation that a product’s software and underlying algorithms are designed in such a way as to prevent hazardous product behaviour. In order to reflect that in the digital age many products remain within the manufacturer’s control beyond the moment at which they are placed on the market, the moment in time at which a product leaves the manufacturer’s control should also be taken into account in the assessment of a product’s safety. A product can also be found to be defective on account of its cybersecurity vulnerability.

Recital 23 makes it clear that a cybersecurity vulnerability can be considered a product defect, and hence explicitly incur liability. 

• (26) The protection of the consumer requires that any manufacturer involved in the production process can be made liable, in so far as their product or a component supplied by them is defective. Where a manufacturer integrates a defective component from another manufacturer into a product, an injured person should be able to seek compensation for the same damage from either the manufacturer of the product or from the manufacturer of the component.

Recital 26 makes it clear that if an open source component is integrated into a product, and that open source component is found to be defective, the developer of that open source component may be liable. 

• (38) The possibility for economic operators to avoid liability by proving that a defect came into being after they placed the product on the market or put it into service should also be restricted when a product’s defectiveness consists in the lack of software updates or upgrades necessary to address cybersecurity vulnerabilities and maintain the product’s safety. Such vulnerabilities can affect the product in such a way that it causes damage within the meaning of this Directive. In recognition of manufacturers’ responsibilities under Union law for the safety of products throughout their lifecycle, such as under Regulation (EU) 2017/745 of the European Parliament and of the Council, manufacturers should also be liable for damage caused by their failure to supply software security updates or upgrades that are necessary to address the product’s vulnerabilities in response to evolving cybersecurity risks. Such liability should not apply where the supply or installation of such software is beyond the manufacturer’s control, for example where the owner of the product does not install an update or upgrade supplied for the purpose of ensuring or maintaining the level of safety of the product.

Recital 38 makes it clear that a failure to properly update a product to protect any security vulnerabilities is considered a defect and incur liability on the part of the manufacturer. 

• (40) Situations may arise in which two or more parties are liable for the same damage, in particular where a defective component is integrated into a product that causes damage. In such a case, the injured person should be able to seek compensation both from the manufacturer that integrated the defective component into its product and from the manufacturer of the defective component itself. In order to ensure consumer protection, all parties should be held liable jointly and severally in such situations. 

Recital 40 makes it clear that the manufacturer of a defective component is liable to the consumer, as well as the manufacturer of the end product. 

• (42) The objective of consumer protection would be undermined if it were possible to limit or exclude an economic operator’s liability through contractual provisions. Therefore no contractual derogations should be permitted. For the same reason, it should not be possible for provisions of national law to limit or exclude liability, such as by setting financial ceilings on an economic operator’s liability.

Recital 42 makes it clear that the limitations of liability and no warranty clauses in open source licenses are superseded by the PLD.

We are happy to announce the second Eclipse Theia community release “2023-02”, version 1.34.x!  Don’t know about Eclipse Theia, yet? It...

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

Come see the Eclipse Foundation and Zettascale in Hall 4, Booth 4-554

BRUSSELS, Belgium – MARCH 8, 2023 – The Eclipse Foundation, one of the world’s largest open source software foundations, today announced a preview of what it will be showcasing at this year’s Embedded World Exhibition and Conference, taking place in Nuremberg, Germany from March 14-16. As one of the most highly anticipated technology events in all of Europe, Embedded World offers unprecedented insight into the world of embedded systems, from components and modules to operating systems, hardware and software design, M2M communication, services, and various issues related to complex system design. 

This year, the Eclipse Foundation will be showcasing its Software Defined Vehicle (SDV) Working Group and its SDV strategy, a look at open source security for the software supply chain, a spotlight on European Commission research projects on the Cloud-to-Edge continuum, its Eclipse IoT and Edge Native Working Group projects, and an overall educational strategy on how organizations can succeed with open source. The Eclipse Foundation will also be joined in its booth by OpenHardware and by member company Zettascale, an innovative firm contributing to open source communication middleware (Eclipse Zenoh & Eclipse Cyclone DDS) that underpin next-generation robotics, transportation, and mission-critical applications.

“We’re very excited to be back to this great event in person,” said Mike Milinkovich, executive director of the Eclipse Foundation. “Embedded World is the ideal event for us, as it matches our growth markets and technical priorities perfectly.”

The Eclipse Foundation intends to provide Embedded World participants with deep insights into the following areas:

Software Defined Vehicle: The SDV Working Group’s mission is to foster collaboration across industries to create an open technology platform for the software defined vehicle of the future. The working group community has chosen a “code first” approach to facilitate more agile and faster time-to-market software development.  Meet the thriving SDV community with projects from Bosch, Microsoft, Cariad, T-Systems and more. We will be presenting our projects, and our vision to build a first showcase SDV Distribution.

Security Best Practices for Embedded Systems: The Eclipse Foundation is committed to ensuring the security of its projects' software supply chain. We have a dedicated security team that focuses on developing and implementing robust security policies and we’re bringing this expertise to Embedded World. Our team is actively involved in providing guidance and education to our projects on the best practices for software security. You'll have the opportunity to learn about these best practices and how they can benefit your project and community. By promoting and implementing these best practices, we aim to create a secure environment that benefits both our projects and their communities. In addition to providing education and guidance on best practices, our security team also offers a range of services and resources to help our projects maintain the highest level of security. 

Eclipse Research and our research projects on Cloud to Edge Continuum: The Eclipse Foundation has been a partner in publicly funded research projects since 2014. We help organizations to successfully create, publish, and sustain an open source software platform, making the results of research projects available for commercial and public exploitation. Visit us to learn more about five ongoing research projects shaping the future of the European Cloud to Edge Continuum:

• EuCloudEdgeIoT.eu: Building the European, Cloud, Edge & IoT Continuum for business and research 
• NEMO: Next Generation Meta Operating System
• NEPHELE: A software stack and orchestration framework for the compute continuum
• SPADE: Multi-purpose physical-cyber agri-forest drones ecosystem for governance and environmental observation
• TRANSACT: Towards safe and secure distributed cyber-physical systems

IoT, Edge Native and Sparkplug: The Eclipse Foundation is the home of over 50 open source projects related to IoT and Edge Computing. From protocol implementations to comprehensive platforms for software updates and device connectivity, our toolkit is the most comprehensive in the industry. Drop by to get an overview or stop for a short demo of key components. We are particularly proud of our Sparkplug open specification, which brings out-of-the-box interoperability to MQTT infrastructure and is on its way to become an ISO/IEC international standard. You will also get to meet Frédéric Desbiens, author of “Building Enterprise IoT Solutions with Eclipse IoT Technologies,” published by Apress in December 2022. Bring your copy and get it signed!

Learn How to Succeed with Open Source: We will present how open source best practices, and how, beyond open source, the Eclipse Foundation enables open collaborations between industry players. This presentation targets more specifically companies that are new to open source and want to understand how to better embrace open source as a strategic advantage.

If your organization is interested in participating in these projects or would like to meet with us at Embedded World conference, please stop by our booth in Hall 4, Booth 4-554, or email us at membership@eclipse.org.

About the Eclipse Foundation

The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation. The Foundation is home to the Eclipse IDE, Jakarta EE, and over 400 open source projects, including runtimes, tools, and frameworks for cloud and edge applications, IoT, AI, automotive, systems engineering, distributed ledger technologies, open processor designs, and many others. The Eclipse Foundation is an international non-profit association supported by over 330 members, including industry leaders who value open source as a key enabler for their business strategies. To learn more, follow us on Twitter @EclipseFdn, LinkedIn or visit eclipse.org.

Third-party trademarks mentioned are the property of their respective owners.

About ZettaScale 

ZettaScale's mission is to bring to every connected human and machine the unconstrained freedom to communicate, compute and store — anywhere, at any scale, efficiently and securely. The company develops open source communication middleware (Eclipse Zenoh & Eclipse Cyclone DDS) that underpins next-generation robotics, transportation and mission critical applications. As devices in the physical world become connected, instrumented and interdependent, ZettaScale enables device creators to easily achieve robust, secure and scalable communication.

###

Media contacts:

Schwartz Public Relations for the Eclipse Foundation, AISBL

Stephanie Brüls / Susanne Pawlik

Sendlinger Straße 42A

80331 Munich

EclipseFoundation@schwartzpr.de

+49 (89) 211 871 – 64 / -35

Nichols Communications for the Eclipse Foundation, AISBL

Jay Nichols

jay@nicholscomm.com

+1 408-772-1551

The Eclipse Ditto teams is proud to announce the availability of Eclipse Ditto 3.2.0.

Version 3.2.0 brings a new History API, Eclipse Hono connection type, case-insensitive searches and other smaller improvements, e.g. on the Ditto UI and in the JS client.

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.2.0 are:

• New History API in order to be able to:
  • access historical state of things/policies/connections (with either given revision number or timestamp)
  • stream persisted events of things/policies via async APIs (WebSocket, Connections) and things also via existing SSE (Server-Sent-Events) API
  • configure deletion retention of events in the database for each entity
• Addition of new Eclipse Hono connection type for Ditto managed connections
• Option to do case-insensitive searches and addition of a new RQL operator to declare case-insensitive like: ilike
• UI enhancements:
  • Push notifications on the Ditto UI using SSE (Server-Sent-Events), e.g. on thing updates
  • Autocomplete functionality for the search slot
  • Added configuring Bearer auth type for the “devops” authentication
• JavaScript client:
  • Support for “merge” / “patch” functionality in the JS client

The following non-functional enhancements are also included:

None in this release.

The following notable fixes are included:

• Undo creating implicitly created policy as part of thing creation if creation of thing failed

Please have a look at the 3.2.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 Eclipse Ditto team

The Eclipse Foundation would like to thank everyone who participated in this year’s elections process and is pleased to announce the results of the 2023 Eclipse Foundation Contributing Member and Committer Member elections for representatives to the Foundation’s Board of Directors. These positions are a vitally important part of the Eclipse Foundation's governance.

Gunnar Wagenknecht is returning, and Johannes Matheis and Hendrik Ebbers will be joining as Contributing Member representatives. Ed Merks, Matthew Khouzam, and Shelley Lambert will all be returning as the Committer representatives. Congratulations! We look forward to working with them on the Board, effective April 1, 2023.

We would like to thank George Adams, Jan Westercamp, Otávio Santana, and Naci Dai for running in this year’s election. We would also like to thank Torkild Ulvøy Resheim for his many years of service to the Eclipse Foundation Board and the community which it governs.

Thanks to financial support from the OpenSSF’s Alpha-Omega project, the Eclipse Foundation is glad to have made significant improvements in the last couple of months.

Two Factor Authentication

Eclipse Tycho, Eclipse m2e, and Eclipse RAP have all enforced 2FA for all their committers on GitHub:

• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2701
• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2702
• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2611

Meanwhile, we’ve seen an increase of adoption of 2FA globally on all Eclipse Projects at Github, increasing from 63.7% to 67% since the begining of the year. We are now starting to actively enforce 2FA for projects with a dedicated GitHub organization.

Security Audits

We have successfully initiated the 3 security audits that will all be performed by Trail of Bits in collaboration with OSTIF. The projects that will be covered in these audits are:

• Eclipse Jetty: an open-source Java-based web server that provides a HTTP server and servlet container.
• Eclipse JKube: a toolkit for building container images and deploying them to Kubernetes.
• Eclipse Mosquito: an open-source IoT platform that enables the development and management of connected devices.

Threat modeling for one out of the three audits have been completed. Code review is underway. The timeline has been locked in for threat modeling and code review for the second security audit. The schedule of the third one is still a work in progress, but will likely be delayed due to project’s constraint. This last one will likely complete in May.

Hiring

We have build capacity since the beginning of the year, hiring 3 talented people:

• Marta Rybczynska, Technical Program Manager. They bring a wealth of experience and knowledge to the team. She initially focusing on improving security / vulnerability policies, procedures, and guidelines that adhere to industry best practices. She started early January.
• Thomas Neidhart, Software Engineer. He is initially focusing on SLSA attestation generation and GitHub management tooling. He started mid-January.
• Francisco Perez, Software Engineer. He will work closely with Eclipse Foundation Projects to enhance their software supply chain security. He started begining of March.

We’re also in talks with a SecOps professional to improve the security of our infrastructure and introduce new tools and services, such as a self-hosted sigstore.

Rework of the CVE process

We have started gathering feedback from projects about Eclipse’s security processes. We are performing interviews with committers and project leads, starting with projects selected for the audit or having a recent security vulnerability. We have contacted six projects, conducted four interviews, and gathered helpful feedback.

The common outcome is a request for more detailed documentation and clarification of the process. Proposals for updated documentations are currently under review. More interviews are planned. We’ve extended the experimentation of GitHub security advisories. We have also worked on a SECURITY.md template for all Eclipse Foundation projects.

GitHub organizations and repositories management

We have re-started the work on a custom tool to enforce and create security related configurations of organizations and their associated repositories on GitHub. The tool is codenamed OtterDog.

What is currently supported:

• descriptive definition of required organization settings / webhooks, repositories and associated branch protection rules
• mechanism to fetch the current configuration from an organization hosted on GitHub
• verification on how the required configuration differs from the current live configuration hosted on GitHub
• update mechanism to enforce the required configuration on GitHub

Some work has been done in order to improve the usability of the tool. The tool will output in a concise way what settings / resources will be changed / created prior to applying the configuration to GitHub by comparing the current live settings on GitHub to the intended configuration.

A credential provider for pass (in addition to existing one for Bitwarden) has been added to support using the tool for our first organization: Eclipse CBI which hosts various tools and projects for common build infrastructure at the Eclipse Foundation.

SLSA tools

We started to work on slsa-tools which is a collection of tools written in Java to operate on SLSA provenance files. The idea behind this project is to have a rich set of tools to verify / generate provenance files for the Java ecosystem.

Existing SLSA tools are implemented in Go which make it somewhat cumbersome to use them in certain settings, e.g. to develop a Jenkins plugin to generate provenance files for builds.

The medium-term goal is to develop such a Jenkins plugin with features similar to the existing slsa-github-generator action for GitHub.

We are happy to announce the Eclipse Theia 1.35 release! The release contains 45 merged pull requests and we welcome two...

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

Advanced shell prompts, such as those provided by theme engines like oh-my-zsh and oh-my-posh, have become increasingly popular among software developers due to their convenience, versatility, and customizability. However, the use of plugins that are executed outside of any sandbox and have full access to the developer shell environment, presents significant security risks, especially for Open Source Software developers.

Open Source Software (OSS) developers are primary targets for software supply chain attacks because they often have access to a wide range of sensitive information and powerful tools that can be used to amplify the impact of a successful attack. OSS developers often have access not only to source code, but also access keys and credentials, which can be exfiltrated and used for malicious purposes. By compromising a single OSS developer, attackers can potentially gain access to the sensitive information and powerful tools of many other developers and users. This can enable them to launch more sophisticated and damaging attacks, potentially affecting a large number of individuals, organizations, and even whole industries.

For these reasons, OSS developers are primary targets for software supply chain attacks, and it’s crucial for them to be aware of the risks and to take steps to protect themselves and their users. This includes verifying the authenticity and security of any software they use, keeping software up to date, and being vigilant for signs of compromise.

Shell theme engines and other advanced shell prompts is an example of the tools that have gain in popularity in the last couple of years and does not seem to considered as much as a threat as some others like projects dependencies or IDE plugins. A compromised shell prompt plugin can steal valuable information and credentials in several ways:

• Keylogging: The plugin can capture keystrokes, including sensitive information such as passwords, credit card numbers, and access tokens.
• Screenshots: The plugin can take screenshots of the user’s screen, potentially capturing sensitive information displayed on the screen.
• Data exfiltration: The plugin can exfiltrate data from the user’s system, such as sensitive files, source code, or even access tokens.
• Remote access: The plugin can open a remote connection to an attacker-controlled system, allowing the attacker to gain access to the user’s system and steal sensitive information.
• Credentials harvesting: The plugin can harvest sensitive information such as passwords, access tokens, and private keys from the user’s system, such as:
  • System keychain: Windows Credential Manager, macOS Keychain, Gnome Keyring or KDE KWallet. If misconfigured, they don’t require systematic authorization to read entries.
  • User’s configuration files which are sometime used to store sensitive information.
  • Shell history may contain sensitive information passed as arguments to commands (e.g., `curl -H ‘Authorization: Bearer xxxxxx’).
  • Environment variables: environment variables are sometimes used to share credentials with applications without having to pass explicit parameters.
  • Browser Cookies file store can be inspected to steal session tokens.
• Network reconnaissance: The plugin can gather information about the user’s network, such as IP addresses, hostnames, and open ports, which can be used to launch more targeted attacks.

It’s worth noting that these are just a few examples of how a compromised shell prompt plugin can steal valuable information and credentials. The actual methods used by attackers may vary and will depend on the attacker’s goals.

To mitigate these risks, it is important for software developers to properly configure and secure their advanced shell prompts. This includes verifying the authenticity and security of any plugins before use, regularly patching and updating systems, and monitoring for suspicious activity. Additionally, it is also important to educate developers on the proper use of advanced shell prompts, and the risks associated with them.

In conclusion, advanced shell prompts like oh-my-zsh and oh-my-posh are powerful tools that can greatly enhance productivity and automation for software developers. However, the use of plugins that are executed outside of any sandbox and have full access to the user shell environment, presents significant security risks. Software developers are particularly vulnerable to software supply chain attacks, which can have serious consequences for their software development environments. It is important for organizations to take appropriate measures to secure their command-line interfaces and educate their users on the risks associated with them, especially when it comes to using plugins from untrusted sources.

As part of our commitment to providing support to our community, we would like to take a moment to share some recommendations regarding the use of Google Analytics (GA) for Eclipse project websites.

As you may be aware, Google Analytics 4 is being rolled out as a replacement for Universal Analytics. While Universal Analytics is still supported at this time, Google has announced that they will stop processing new hits for all standard Universal Analytics properties on July 1, 2023.

Therefore, we strongly recommend that all projects currently using GA take some time to re-evaluate whether it is still necessary for their needs. If the data provided by GA is no longer useful or necessary, we recommend that projects remove GA from their website.

If it is determined that the data is still relevant and useful for the project, we recommend that it be migrated to Google Analytics 4 manually. Google has provided a migration guide for those who are looking to upgrade.

We believe this is the safest way for projects to confirm that all is well, as we cannot assume that the automatic GA migration will work as expected for everyone. Also, it’s the only way for projects to ensure that explicit consent has been given by the user via our cookie consent banner before enabling GA.

As a reminder, it’s possible to add our cookie consent banner to any website by adding the following code snippet in the section of each page:

<link rel="stylesheet" type="text/css" href="//www.eclipse.org/eclipse.org-common/themes/solstice/public/stylesheets/vendor/cookieconsent/cookieconsent.min.css" />
<script src="//www.eclipse.org/eclipse.org-common/themes/solstice/public/javascript/vendor/cookieconsent/default.min.js"></script>

A project website with GA must then ensure that the value of the eclipse_cookieconsent_status cookie is set to “allow” before loading GA on a webpage.

Additionally, we recommend that projects opt-out from letting GA make any changes to their account. This will ensure that projects have full control over their upgrade and can manage it in a way that best suits their needs.

Upgrading to GA 4 will not only provide access to new features and benefits but will also ensure that project websites are prepared for the future of Google Analytics before the end of support for Universal Analytics.

As always, we are here to support you with any questions or concerns you may have. Please do not hesitate to reach out to us via issue #2630 in our Helpdesk.

You can also find additional information and requirements around the acceptable usage of GA for Eclipse projects in our Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy.

Do you want to host your Theia-based application in the cloud and allow your users to use your custom IDE or...

The post Introducing Theia Cloud appeared first on EclipseSource.

In my previous blog post on the European Cyber Resilience Act (“CRA”), I touched on a topic which I feel warrants additional discussion. Specifically: 

Fundamentally, the core of the proposed legislation is to extend the CE Mark regime to all products with digital elements sold in Europe. Our assumption based on the current text is that this process will be applied to open source software made available under open source licenses and provided free of charge, ostensibly under licenses which disclaim any liability or warranty. We are deeply concerned that the CRA could fundamentally alter the social contract which underpins the entire open source ecosystem: open source software provided for free, for any purpose, which can be modified and further distributed for free, but without warranty or liability to the authors, contributors, or open source distributors. Legally altering this arrangement through legislation can reasonably be expected to cause unintended consequences to the innovation economy in Europe.

First, a mea culpa. In the quote above I stated that “…the proposed legislation is to extend the CE Mark regime to all products with digital elements sold in Europe.” That statement is inaccurate. It should have said “the proposed legislation is to extend the CE Mark regime to all products with digital elements made available in Europe.” That is a critical distinction, as it makes the CRA broadly extra-territorial. In today’s world where most software is downloaded over the internet, “made available” means that the documentation, certification, and liability requirements of the CRA are expected to apply to all software worldwide. 

I honestly believe that CRA was developed with the best of intentions. Software has become critically important to our economies and societies, and to date has been a completely unregulated industry. Recent events such as the SolarWinds and Apache Log4j vulnerabilities have shown that there can be very large economic impacts when something goes wrong. The Log4j event showed that open source software components can have a very large impact due to wide usage. Given that, it is a reasonable position that the time has come to implement regulations upon the software industry, and to ensure that open source software is included within the scope of those regulations. I want to stress that I believe that the open source community very much wants to be part of the solution to the industry problems that we all face with respect to supply chain security. The open source community provides extremely high quality software and takes great pride in the value that it provides to society. 

However, the CRA legislation (along with the companion revisions to the Product Liability Directive) in its current form will have enormous negative effects on both the open source community and the European economy. 

For the purposes of this blog post I am going to ignore for the moment the impact of applying the CE Mark regime to all software all at once, as that would be a long post in its own right. This post will focus on the unintended consequences of applying legal product liability obligations to the open source community and ecosystem. But before doing so, I want to spend a few moments describing what open source software is, and why it is important. If you have a good understanding of that topic, feel free to skip that section. 

The Economics of Open Source

Today’s software systems are mind-bogglingly complex. And for most systems, a very large percentage of the overall code base provides zero product differentiating features. For example, any modern system will require code which allows it to connect to the internet to acquire and share data. Open source at its core is a simple licensing model which allows individuals, researchers, academics, and companies to come together to develop and maintain software which can be freely studied, used, modified, and redistributed. The breadth of software which has been developed under this model encompasses every field of human endeavor. But arguably the most common use case is to share the cost of developing and maintaining software which implement non-differentiating technologies used across a broad spectrum of products and applications. To be clear, “non-differentiating technologies” means implementations in software of the types of technologies that many similar applications must implement. Examples include network access, database access, user authentication, and the like. It is impossible to overstate the economic benefits of being able to reuse software in this way. Reuse decreases lifecycle costs, reduces time to market, and mitigates development risk across every type of system which contains software. Which is to say, every single aspect of social and economic activity. That is why it is estimated that most modern software and cyber-physical products contain 80 to 90 percent open source. It is simply not economically viable to write all software yourself while your competitors are building theirs using open source. 

But the economic benefits of open source only start there. In fact, there is arguably even greater value in the pace of innovation which is made possible by open source. All developers today start their development off by selecting and assembling open source components to form the basis for their product or application. And they are able to do so without asking permission from any of the providers. This ‘permissionless innovation’ has vastly accelerated the pace at which new products in all fields can be developed and brought to market. When open source was first introduced, it was primarily used to commoditize technologies which were already well understood. Today, open source is used to introduce new technologies, in sectors such as Big Data, Cloud, Edge, AI and software defined vehicle, in order to accelerate adoption and create new market segments. 

It is important to remember that open source software is provided at zero cost to the consumer. This completely decouples its value from its sale price. And there are many examples of open source software which are almost immeasurably valuable: Linux, Kubernetes, Apache, and OpenJDK are just a few examples of open source which support multi-billion euro ecosystems. 

It is also important to recognize that open source software is a non-rivalrous good. In fact, it is an anti-rivalrous good in that the more a software component is used, the more valuable it becomes. This is incredibly important to understand: the value of a piece of open source software is not determined when it is made available. It becomes valuable (and potentially critical) when it is used. And the more it is used, the more valuable and critical it becomes. As a logging framework, Log4j was not a piece of software which at face value would be expected to be security critical; it became so because it was so broadly used and adopted. 

Finally, there is no open source business model. Open source licensing has enabled an incredibly successful collaborative production model for the development of software, but that is decoupled from the commercialization of that software. Obviously, given the massive investments in open source someone must be making money somewhere. And they are. Open source technologies are used in virtually every cyber-physical, software, SaaS, and cloud product on the planet. It is also very widely used in the internal bespoke software applications that run our governments, enterprises, and industrials. When we talk of the open source supply chain, it is important to recognize that what we are discussing is the use by governments and commercial organizations of freely provided software. Unlike any other market that I am aware of, the financial resources available to manage and secure the open source software supply chains are solely available to the consumers, rather than the producers. For this reason, it is important that any compliance burden be placed on the downstream commercial adopters and consumers, rather than the producers of open source. 

Unintended Consequences

Which brings me to the risks to Europe’s economy that I see from the CRA. The preamble to the legislation states: “For the whole EU, it is estimated that the initiative could lead to a costs reduction from incidents affecting companies by roughly EUR 180 to 290 billion annually.” On the cost side it states: “For software developers and hardware manufacturers, it will add direct compliance costs for new security requirements, conformity assessment, documentation and reporting obligations, leading to aggregated compliance costs amounting to up to roughly EUR 29 billion.” In other words, spend 29 billion to save 290 billion. The impact assessment further describes that an analysis was done which spurred the decision to extend to legislation to cover all tangible and non-tangible products: 

This option would ensure the setting out of specific horizontal cybersecurity requirements for all products with digital elements being placed or made available on the internal market, and would be the only option covering the entire digital supply chain.

As discussed in my previous blog post, the CRA as currently drafted will be extended to cover virtually all open source software. This will legally obligate producers of open source software to the documentation, certification, and liability provisions of the CRA. Let us focus here solely on the liability topic.

The fundamental social contract that underpins open source is that its producers freely provide the software, but accept no liability for your use, and provide no warranties. Every open source license contains “as is”, no liability, and no warranty clauses. I’ve always assumed that this is simple common sense: if I provide you with a working program that you can study, use, modify, and further distribute freely for any purpose, why should I accept any liability for your (mis)use of that program? It is the companies which commercialize the technology and make a business from it who need to accept liability and provide warranties to their paying customers, not the open source projects which they have freely consumed. The CRA fundamentally breaks this understanding by legislating non-avoidable liability obligations to producers of free software. 

What might be the consequences of forcing the producers of free and open source software made available in Europe to accept statutory liability for code that they provide? Remembering, of course, that all open source software is both developed and distributed over the internet so “made available in Europe” can arguably apply to it all. And also remembering that enormous amounts of open source software are produced worldwide by projects, communities, and nonprofit foundations which make no money off of their software, and who have always operated under the assumption that their liability obligations were extremely low. Thirdly, it is important to remember that open source software is provided for free. The producers of open source do not receive any revenue from users and adopters in Europe, so the usual market incentives to accept additional regulations to retain access to the European single market do not apply.

So with the caveat that these are all hypothetical scenarios, let’s look at some potential unintended consequences of the CRA’s liability obligations. (Some of these points are also made in Brian Fox’s excellent blog post.) 

1. A reasonable and rational response would be for non-European producers of open source code to state that its use is not permitted in Europe. If you are not willing to accept statutory liability obligations for something you make available for free, a notice file stating the above would be an obvious reaction. What would this mean to the European companies that build products on platforms such as Linux, Kubernetes, Apache, and OpenJDK? I would assume that the vast majority of their procurement and compliance organizations would conclude that they can no longer use those technologies in their product development. Cutting Europe off from these platforms would have catastrophic consequences.
   
2. European producers of open source will be at a significant disadvantage relative to their international peers. Since they cannot avoid the liability obligations, they will be forced to accept them as part of their operations. For a small project hosted at (say) Github, it would probably be simpler to just terminate the project and pull its source code off of the internet. For a foundation such as the Eclipse Foundation, amongst other things I would expect that we would be forced to procure a very large liability insurance policy to mitigate the exposure of the organization and its directors and officers to potential liabilities. The result would threaten the €65 billion to €95 billion that open source software development contributes to EU GDP, as per the Commission’s own study.
   
3. The CRA extends the liability obligations to distributors of software. In the open source context, some of the most important distributors include the language and platform-specific package distribution sites such as npm, Maven Central, PyPi and the like. None of those sites are in a position to accept liability for the packages they make available. As Brian Fox of Sonatype stated “…the consequence of this would be [Maven] Central, npm, PyPi and countless other repositories being suddenly inaccessible to the European Union.” As Brian is the leader of Maven Central, I am confident he understands what he’s talking about. I cannot stress enough how disruptive it would be to Europe’s business if that should occur.
   
4. The CRA liability obligations could also force European business to stop contributing to open source projects. At the moment, it is generally understood that the risk that contributions to open source may incur a liability to the company is low. The CRA changes that equation and as a result European companies may curtail their open source collaborations. This would be extremely damaging to the innovation economy in Europe, for the reasons described in the economics section above. It also runs counter to a number of European wide strategies such as digital sovereignty which explicitly have major open source components. Initiatives such as GAIX-X, Catena-X, Dataspaces, Digital Twins, and Industrie 4.0 all explicitly rely upon open source collaboration which could be at risk under the CRA. 

Europe’s Cyber Resilience Act was developed with the best of intentions. And it is certainly the right time to look at what regulations are appropriate for software generally, and given its importance open source software likely needs to be included in some manner. But the liability obligations imposed by the CRA upon projects, communities, and nonprofit foundations will have negative unintended consequences on Europe’s innovation economy and digital sovereignty initiatives.

BRUSSELS – February 21, 2023 – The Eclipse Foundation, one of the world’s largest open source foundations, today announced the availability of its 2022 IoT and Edge Commercial Adoption Survey report, based on an online survey of more than 260 IoT and edge professionals conducted from April 1st to June 15th, 2022. The survey’s objective is to gain a better understanding of the IoT and edge computing ecosystems by identifying the requirements, priorities, and challenges faced by organizations that deploy and use commercial solutions, including those based on open source technologies. 

“IoT and edge computing continued to accelerate in 2022 and into 2023 with no signs of slowing down, despite the current macroeconomic climate, ” said Mike Milinkovich, executive director of the Eclipse Foundation. “These trends suggest that IoT and Edge are thought to be strategic investments that deliver true ROI. The open source model will only augment these benefits.”

Survey participants represent a broad set of industries, organizations, and job functions. Nine of the top conclusions drawn from the survey data include:

• IoT technologies are being adopted at an accelerated rate. 53% of respondents currently deploy IoT solutions and an additional 24% plan to deploy within the next 12 to 24 months, while 18% are currently evaluating deployments.
• Edge computing adoption is also on the rise. 53% of organizations are either utilizing or planning to utilize edge computing technologies within 12 months. Another 20% are currently evaluating the use of edge deployments.
• There is a shift towards higher investments into IoT & Edge. 23% of respondents project spending between $100K - $1M in 2022, growing to 33% in 2023. 10% anticipate spending over $10M and growing to 12% in 2023.
• There is a trend towards a larger number of IoT & Edge assets managed per deployment. Deployments of fewer than 1K managed assets will remain steady or decline, while larger deployments are on the rise. In terms of asset implementation, 52% are a mix of both greenfield and brownfield.
• More organizations now see IoT and edge as strategic, with spending decisions being driven at the executive level 38% of the time. This increased by 3% compared to the year 2021. 
• 73% of organizations factor open source into their deployment plans. This clearly demonstrates that the dominant IoT & edge platforms will either be open source or based on open source. Only 27% of organizations using IoT and Edge technologies state they do not use open source technologies.
• The primary benefits of using open source according to respondents include: the ability to customize or influence code in projects (30%); flexibility (22%); as well as cost advantages (16%).
• The top 3 IoT and edge operational challenges are: 1) connectivity; 2) security; and 3) data collection & analytics.
• There is a trend towards a hybrid cloud strategy. 42% of respondents suggest that IoT deployments are using, or will use a hybrid cloud (i.e. composed of two or more distinct cloud infrastructures such as private and public).

The report also includes details on IoT and edge adoption by industry and the top concerns of commercial adopters. To find out more, interested parties can download the 2022 IoT & Edge Commercial Adoption Survey Report.

The IoT and Edge Commercial Adoption Survey is sponsored by the Eclipse IoT and Edge Native Working Groups. The adoption survey complements the annual IoT Developer Survey, one of the industry's most influential surveys from the development front lines, which the Eclipse Foundation has conducted for the last nine years and will continue to produce. The Foundation’s IoT and Edge Native communities represent one of the largest open source collaborations in the world spanning 45 projects from 45 members. Eclipse IoT and edge projects have been adopted by leading organizations across a variety of verticals to deliver commercial IoT and edge-based solutions and services.

To learn more about how to get involved with the Eclipse IoT, Edge Native, or other Eclipse Foundation Working Groups visit the Eclipse Foundation membership page. Working Group members benefit from a broad range of services, including exclusive access to detailed industry research findings, marketing assistance, and expert open source governance.

For further IoT & Edge related information, please reach us at:

IoT@eclipse.org

Edgenative@eclipse.org

Quotes From IoT & Edge Native Working Group Members

Eurotech

“Also this year, we are looking forward to receiving and analyzing the results presented in the IoT & Edge Commercial Adoption Survey Report, which provides up-to-date insights into challenges and trends in IoT and Edge Computing” commented Robert Andres, Chief Strategy Officer for Eurotech. “The report is a very valuable source of data, compiled from a significant primary research effort, conducted under the umbrella of the Eclipse Foundation.”

ZettaScale

“The survey reveals an interesting acceleration in the adoption of Edge Computing, which I think will be further fueled in 2023 by the technologies developed within the Eclipse IoT and Edge Working Group,” said Angelo Corsaro, PhD, ZettaScale’s CEO/CTO. “We are extremely proud to be contributing to this trend with some projects that are foundational for Edge Computing and the Cloud-to-Thing Continuum.” 

Edgeworx

“Every year this survey teaches us more about the workloads being deployed via Edge Computing and we continue to see strong Edge AI demand," said Kilton Hopkins, CTO of Edgeworx. “The Eclipse Edge Native Working Group is a central part of our strategy for meeting that demand.”

About the Eclipse Foundation

The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation. The Foundation is home to the Eclipse IDE, Jakarta EE, and over 400 open source projects, including runtimes, tools, and frameworks for cloud and edge applications, IoT, AI, automotive, systems engineering, distributed ledger technologies, open processor designs, and many others. The Eclipse Foundation is an international non-profit association supported by over 330 members, including industry leaders who value open source as a key enabler for their business strategies. To learn more, follow us on Twitter @ResearchEclipse, @EclipseFdn, LinkedIn or visit eclipse.org.

Third-party trademarks mentioned are the property of their respective owners.

###

Media contacts:

Schwartz Public Relations for the Eclipse Foundation, AISBL (Germany)

Stephanie Brüls / Susanne Pawlik

Sendlinger Straße 42A

80331 Munich

EclipseFoundation@schwartzpr.de

+49 (89) 211 871 – 64 / -35

Nichols Communications for the Eclipse Foundation, AISBL

Jay Nichols

jay@nicholscomm.com

+1 408-772-1551

514 Media Ltd for the Eclipse Foundation, AISBL (France, Italy, Spain)

Benoit Simoneau

benoit@514-media.com

M: +44 (0) 7891 920 370

On behalf of the Eclipse JKube team and everyone who has contributed, I'm happy to announce that Eclipse JKube 1.11.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:

• Eclipse JKube Remote Development (Preview) enhancements
• Init Containers via XML/DSL plugin configuration
• ğŸ�› Many other bug-fixes and minor improvements

Eclipse JKube Remote Development (Preview) enhancements

This release brings a few improvements to the Remote Development feature:

SOCKS 5 proxy

In addition to the standard remote and local service configuration, you can now enable a SOCKS 5 proxy. The proxy can be then used to dynamically forward ports and resolve cluster DNS names for your local applications that support a SOCKS 5 proxy configuration.

You can enable the SOCKS proxy just by setting its port in the <remoteDevelopment> configuration:

<plugin>
  <groupId>org.eclipse.jkube</groupId>
  <artifactId>kubernetes-maven-plugin</artifactId>
  <configuration>
    <remoteDevelopment>
      <socksPort>1080</socksPort>
    </remoteDevelopment>
  </configuration>
</plugin>

Once you start the session, you can use the SOCKS proxy to connect to a remote service:

curl --socks5-hostname localhost:1080 http://my-cluster-service:80/

Remote Service port discovery

Your application might expose different ports depending on the environment it's running. For example, a React application is usually exposed at port 3000 in development mode, but at port 80 in production mode.

With this release, we've improved the local service port forwarding to detect the port at which your application is being exposed in the cluster. This way you can provide a local service configuration with the port pointing to where your application listens locally. JKube will take care of analyzing the cluster service to determine the port where the Service listens and forward it to the local port.

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.11.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.11.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

BRUSSELS, Belgium – February 15, 2023 – The Eclipse Foundation, one of the world’s largest open source foundations, in conjunction with the Eclipse Software Defined Vehicle (SDV) Working Group,  today announced the launch of the Automotive Open Source Summit, the industry’s first and only conference focused on open source software (OSS) and collaboration-based innovation for the automotive industry. The primary goal of the summit is to help drive the future of automotive development towards an open source and community-friendly approach. Taking place on June 6th, 2023 at the Hotel Königshof in Garmisch-Partenkirchen, Germany, this exclusive conference will provide an intimate venue for automotive executives and tech leaders to come together and discuss the business of automotive-grade open source software, to network with like-minded individuals, and to learn about the organisational and cultural challenges in automotive software development. Interested parties can find out more here - https://automotive-oss.org/

“The Eclipse SDV Working Group is experiencing an unprecedented level of momentum, reflecting the industry’s desire and deep interest in achieving economic and technological benefits by collaborating to develop and utilize open source software,” said Mike Milinkovich, executive director of the Eclipse Foundation. “Market leaders such as Bosch, Cariad (VW Group), Microsoft, Mercedes-Benz Tech Innovation, ZF, and over 25 other organizations have come aboard to add their expertise to this journey. Based on this demand, we recognized a subject matter gap in conferences today. We believe our new summit will fill that gap and then some.”

Designed explicitly for automotive business and technology senior managers, executives, thought leaders, senior architects, high level officials (C-level & VP) from OEMs and suppliers, as well as tech companies interested in automotive, the Summit features speakers from Eclipse automotive initiatives as well as organizations and leaders from outside the Eclipse community. The Eclipse Foundation intends for the event to become the go-to-event of all high profile open source and open specification initiatives in the automotive industry.

Objectives of the summit include:

• Bringing together senior automotive experts and business leaders to openly discuss and collaborate on the future of the connected & autonomous driving experience.
• Allowing automotive initiatives from multiple open source and open specification communities to engage and collaborate in a transparent and neutral manner
• Establishing the requirements for an automotive-grade open source software stack targeted towards in-series production

Topics to be covered at the summit include:

• Automotive and Open Source – Cultural and Organizational Challenges
• The Automotive-Grade Open Source Software Stack
• Why Support Open Source Software from a Commercial Standpoint
• Legal and Regulatory Considerations for Open Source Software in the Automotive Industry

About the Eclipse SDV Working Group

The Eclipse SDV WG is the global center of gravity for software-defined vehicle innovation and collaboration. Industry leaders from diverse industries define our membership (Bosch, Cariad, Mercedes, ZF, Microsoft, etc.). Our code-first approach is generating innovation the industry uses today. We deliver a level playing field for all sizes of companies to contribute. Anyone interested in becoming a member can find out more here - https://sdv.eclipse.org/membership/

About the Eclipse Foundation

The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation. The Foundation is home to the Eclipse IDE, Jakarta EE, and over 400 open source projects, including runtimes, tools, and frameworks for cloud and edge applications, IoT, AI, automotive, systems engineering, distributed ledger technologies, open processor designs, and many others. The Eclipse Foundation is an international non-profit association supported by over 330 members, including industry leaders who value open source as a key enabler for their business strategies. To learn more, follow us on Twitter @ResearchEclipse, @EclipseFdn, LinkedIn or visit eclipse.org.

Third-party trademarks mentioned are the property of their respective owners.

###

Media contacts:

Schwartz Public Relations for the Eclipse Foundation, AISBL (Germany)

Stephanie Brüls / Susanne Pawlik

Sendlinger Straße 42A

80331 Munich

EclipseFoundation@schwartzpr.de

+49 (89) 211 871 – 64 / -35

Nichols Communications for the Eclipse Foundation, AISBL

Jay Nichols

jay@nicholscomm.com

+1 408-772-1551

514 Media Ltd for the Eclipse Foundation, AISBL (France, Italy, Spain)

Benoit Simoneau

benoit@514-media.com

M: +44 (0) 7891 920 370

Recently I migrated my WordPress-based site to the free version of the great OceanWP theme.
While many social icons are already supported, Mastodon is currently not supported.

So I filed a feature request here: https://github.com/oceanwp/oceanwp/issues/433

The friendly guys from OceanWP the explained, how I could add a Mastodon link with icon today.
After fiddling around a bit, their solution worked well for me:

• Save your OceanWP customizer settings
• Create an OceanWP child theme (you can use the Ocean Extra plugin for that task)
• Import your saved customizer settings => Now your website should look the same as before
• Activate child theme
• The theme icons to “Font Awesome”
• Open the Appearence/Theme File Editor
• Add the following code to functions.php and save

function my_ocean_social_options( $array ) {
	// Mastodon icon
	$array['mastodon'] = array(
		'label' => 'Mastodon',
		'icon_class' => oceanwp_icon( 'mastodon', false)
	);

	return $array;

}
add_filter( 'ocean_social_options', 'my_ocean_social_options' );

function add_new_icons( $icons ) {
	$icons['mastodon']= array(
                'sili' => 'fab fa-mastodon',
                'fai'  => 'fab fa-mastodon',
                'svg'  => 'fab fa-mastodon',
            ); 

	return $icons;
}
add_filter( 'oceanwp_theme_icons', 'add_new_icons' );

Now, whenever you want to add a social link, you will find “Mastodon” at the end and you can add your Mastodon link.
Mine is https://mastodon.social/@kaitoedter and you can see a live version of this at https://toedter.com.

Customize and extend your IDE for an Integrated Developer Experience.

Your productivity is worth investing in

If you are developing software in a programming language like Java, C++, C#, Python, Go, Ruby, Kotlin, Groovy, Swift, or JavaScript you are probably leveraging a powerful and productive Integrated Development Environment (IDE).

I have been using IntelliJ IDEA for Java development since 2002. Most developers I meet who use IntelliJ, Eclipse, NetBeans or VSCode for coding in Java love their IDEs. They are fiercely loyal. However, few developers I meet take the time to fully learn the capabilities their IDE provides to enhance their productivity. Many developers wind up treating their IDEs primarily as colorful code editors.

There is much more power available and waiting to be discovered. It may take you time to discover and master the features, but that investment will give you greater returns over time.

I’ve been using IntelliJ IDEA for Java development for 20 years. I feel some days like I’m only scratching the surface of productivity gains as my favorite Java IDE continues to evolve and put more power in my hands.

Discovering the keys to the kingdom

In the 1990s, I worked in a Smalltalk IDE. The IDE I used was IBM’s VisualAge for Smalltalk (VAST). VAST was the most amazing development environment I had ever seen or used, and remained so well into the 2000s. I learned that paying ~$5,000 per developer seat for an IDE was well worth the investment in terms of the productivity improvements.

With VAST and the live Smalltalk image I also learned I could change anything I wanted in my environment, on the fly. VisualAge was written in Smalltalk and was a running Smalltalk image and I could learn about and change all of the underlying code, in Smalltalk, dynamically.

When you own your IDE, you don’t just use it to type code, you extend it and enhance it to increase your productivity.

I kept programming in VisualAge Smalltalk through the early 2000s in my spare time. I used to occasionally demo building a ToDoList in under 2 minutes using VAST. I blogged about this recently and how I learned JavaFX as a result to try and replicate that same ToDoList demo-ability in Java using IntelliJ.

My first JavaFX application

VAST wasn’t really keyboard enabled. I was mouse dependent working in the IDE. After my first 2–3 years of programming Java using IntelliJ IDEA, I became keyboard obsessed. IntelliJ really unleashed my productivity using the keyboard. I learned many IntelliJ keyboard shortcuts in the early 2000s that I still use today. I loved using the keyboard so much, I decided to implement the same keyboard shortcuts in my VAST environment… because I could! I started with Ctrl-N (Find Class) and Ctrl-B (step into something like a class or method when the cursor is on the text). This helped balance my productivity when switching between my two favorite and most used IDEs.

Coding like a boss in IntelliJ

I’ve alternated between being an individual contributor and a manager at work over the past six years. I have been a manager of a core platform team at my current employer for the past three years. I read and review more code in this role than I write. I continue to code actively in open source and passed 500 contributions on GitHub last year. Following are some tips I can give you to help you maximize the out of the box capabilities of IntelliJ IDEA so you can code like a boss (me).

These features are built into IntelliJ IDEA. All you need to do to use them is learn them. Whether you pay for your IDE or download it for free, it pays to learn the features that are built-in. Learn them. Customize them. Own them.

Keyboard Shortcuts

Many developers I have worked with over the years have printed out one of these two keymaps and kept them on their desk for reference. In the new world of remote work and going green, maybe just keep a bookmark or save the PDF. Learning many of these shortcuts will save you time doing common every day coding activities. Link to PDF.

IntelliJ IDEA keyboard shortcuts | IntelliJ IDEA

Some of my personal favorite shortcuts:

Ctrl-N, Ctrl-B, Ctrl-H, Ctrl-F, Ctrl-Shift-F, Ctrl-Shift-R, Alt-F7, F5, F6, Shift-F6, Ctrl-Alt-M, Ctrl-Alt-N, Ctrl-Alt-Shift-N, Ctrl-W, Ctrl-O, Ctrl-I, Ctrl-P, Alt-F1

The most important basic short-cuts to learn and remember:

Alt-Enter (magic) and Shift-Shift (multi-purpose)

Postfix Completion

I hate typing types when I want to introduce a variable. Sure, I could use the Local Variable Type Inference (var keyword) feature introduced in Java 10. Most of the time I want to keep the types in the code for future readers, including myself, so using var is not an option. When you need to type the types in Java, you wind up repeating yourself, a lot. Don’t Repeat Yourself! Don’t type types for your local variables. Let IntelliJ do it for you, by using postfix completion.

Postfix Completion

This is truly a boss feature of IntelliJ. If you use another IDE, check to see if they have implemented this feature. This feature will change how you write your code.

Owning Postfix Completion

Once you incorporate postfix completion into your coding style, you can make this feature your own. Since IntelliJ 2018.1, you are able to customize the Postfix Completion by creating your own Java templates.

Go to Preferences | Editor | General | Postfix Completion

For some custom Postfix Completion examples, check out this blog from Craig Motlin.

IntelliJ postfix completions

Type Hints

A feature that was added in IntelliJ 2018.2 that I love was called “Type hints for long method chains� or more simply “Inlay Hints�. If you use a fluent coding style with libraries like Java Streams or Eclipse Collections, these type hints can help you read and understand your code without having to go digging into method chains in order to discover return types. This feature shows intermediate type hints next to the code with long method chains. It has various configuration options you can tweek. Here’s one example using the default settings.

Inlay hints | IntelliJ IDEA

Let’s take a look at some code as it would appear in a browser, with some standard syntax highlighting.

@Test
public void printTop10RandomFruitOrVegetableEmojis()
{
    CodePointAdapter emojis = Strings.asCodePoints("�������������🥥���🥑🥦🥬🥒🌶🌽🥕🧄🧅🥔");
    IntBags.mutable.withAll(new SecureRandom()
                    .ints(0, emojis.size())
                    .limit(1_000_000_000L)
                    .parallel()
                    .map(emojis::get))
            .collect(CodePointList::from)
            .topOccurrences(10)
            .forEach(System.out::println);
}

Here’s the same code in IntelliJ IDEA, with Type Hints enabled, with the default settings.

The only thing missing here is what the MutableIntBag is being constructed from. We can find this out by changing the default Type Hint settings.

The result is that we now additionally see the IntStream.

IntelliJ is smart enough to leave out types when they repeat. The calls to limit, parallel, and map all still return IntStream. Type Hints only displays type names when they change. I have decided to leave the minimal unique count setting at one.

Scratches

When I worked in VisualAge for Smalltalk, two of my favorite features were the Workspace and Transcript. Transcript was a special workspace, which was the equivalent of what we know in Java as System.out. The purpose of a Workspace was to allow developers to test out snippets of code to enable learning of new concepts and techniques. I’ve used JUnit tests for years for this purpose in Java. The benefit of using JUnit for this purpose is that little scripts could be easily turned into permanent tests.

IntelliJ has had Scratch Files for a long time, and they can be useful for experimenting with small snippets of code. I kind of think of it as JShell only built into IntelliJ IDEA.

Scratch Files and Scratch Buffers | The IntelliJ IDEA Blog

Live Templates

Learn about Live Templates in IntelliJ, and you may quickly create your own minimal programming language. Live Templates give you coding super powers. I haven’t had to write a for-loop by hand in years because of Live Templates.

As soon as you start typing in an editor in IntelliJ it will show you a filtered list of matching live templates. Below is where you can find the standard list of Live Templates for Java in IntelliJ.

There is a plus sign over the right of the screen which you can use to either add new Live Templates or a Template Group. I created a Template Group for Eclipse Collections Factories.

If I am in my IntelliJ editor writing some code, all I have to do to create a MutableList with some elements is type mlw followed by a tab.

As soon as I press tab, the code will expand as follows, and place the cursor in position for me to start typing the first element. As soon as I press tab, it will skip to the second element position, moving past the comma. It does the same when I press tab again for the third element.

When paired with Postfix Completion, I have a lot less text to type as the types on the left get filled in automatically.

This is the result, and then I pick the variable name I want from the list or just type my own.

So if you find yourself coding the same patterns over and over again, create a Live Template with a memorable shortcut. Even if you can’t remember it right away, IntelliJ will display it in the list and the more you use it, the more likely you will be to remember it.

The keyboard shortcut to bring up the list of Live Templates in the editor is Ctrl-J.

For some additional IntelliJ Live Templates tips, check out this blog from Craig Motlin.

Additional IntelliJ Live Templates for Java

Finding and Installing Cool Plugins

There is a a marketplace for plugins for IntelliJ and all JetBrains IDEs. You can find some neat plugins that give you useful features not provided by IntelliJ directly here. Some cool plugins that I discovered thanks to Emilie Robichaud are in the blog below.

5 Cool IntelliJ Plugins You MUST Try!

Some plugins are free and some are paid. I recommend reading the pricing and reviews of plugins and deciding for yourself which plugins are the most helpful. IntelliJ includes a lot of the productivity tools and plugins developers need in the Community Edition and even more in the Ultimate Edition. Here’s their online comparison of features.

JetBrains Products Comparison

Building Your Own Plugins

So far I have shown some features you can use and customize for good effect at increasing the productivity of your IDE. There is another super-power that you can leverage to extend the IDE for a truly comprehensive Integrated Developer Experience (IDX). Build your own plugins that integrate with your internal development platforms.

Sirisha Pratha gave a great talk tirled “Make IntelliJ IDEA Your Own�. I am linking to it here.

If you want to learn how to build custom plugins for IntelliJ, this is a great talk to watch.

Own Your IDE for Your Own Good

I clearly use IntelliJ IDEA as my IDE, and have shared some useful tips that can help you own it for improved productivity. Regardless of which IDE you use, I recommend taking the time to learn the facilities the IDE provides for you to increase your productivity. If your IDE is competitive, I would expect it to have equivalents of

• Keyboard Shortcuts
• Postfix Completion
• Scratch Files
• Type Hints
• Live Templates
• Plugin Architecture and Marketplace

If your IDE doesn’t have the equivalents of these things, then you might want to suggest implementing them to your IDE provider. If you use an OSS IDE, then you might consider contributing improvements.

You are responsible for your productivity. You need to own it, and that means investing in it. Whether you get your IDE for free or pay a vendor for it, the cost of learning and extending your IDE will be worth the investment.

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

“���������� ������ �� ���� �� ������ �� ��������, ��� ��� �������� probably was one of the mantra the Eclipse Modeling Framework team (Ed Merks, Marcelo Paternostro, Dave Steinberg among others…) sticked to when the created the core concepts which would allow the definition of all the others tools.

Ecore is a kernel, you define your domain specific model using these constructs. It boils down to classes, types, attributes and relationships, yet there is a lot of beauty in the way it has been designed and we can safely say it passed the test of time. In 2016 I tried to condensed all of it in a single reference card. I did not finished it to the point of publishing it but I’m doing it today (better late than never!)

To produce it I exclusively used Open-Source tools :

• Ecore Tools: Ecore diagraming editor built on top of Eclipse Sirius ,
• Inkscape : one of my favorite OSS tool to produce vector graphics.

I created 4 distincts diagrams from the Ecore.ecore model, then used the “Export as Image� feature of Sirius to get SVG files out of it. I dragged and dropped those file in Inkscape, scaled, composed a bit, and voilà ! Here is the refcard.

You can decorate your office now ;) Hope you enjoy

Do you know Ecore? Looking for a reference card? was originally published by Cédric Brun at CEO @ Obeo on February 09, 2023.

BRUSSELS, Belgium, February 08, 2023 – The Eclipse Foundation, the EU’s largest open source software foundation, today announced it has secured three new research programs under the auspices of the Horizon Europe (HEU) programme, including two Research and Innovation Action (RIA) projects (NEMO and NEPHELE) and a Coordination and Support Action (CSA) (Open Continuum). 

These three projects contribute to the definition of the Future European platforms for the Cloud-Edge-Iot continuum. 

“The Horizon Europe programme is leading the charge in ensuring that the EU is at the cutting edge of tech innovation,” said Mike Milinkovich, executive director for the Eclipse Foundation. “By securing the program funding for these research programs, we can do our part to catalyze the growth of new open source technologies that connect the Cloud to the IoT. The combination of the public and private sectors are slated to reap significant rewards in this endeavor.” 

The OpenContinuum CSA (https://eucloudedgeiot.eu/) contributes to a join effort with a second CSA, UNLOCK CEI CSA, focussing respectively on the demand and supply sides of the Cloud Edge IoT (CEI) Continuum. 

The core ambition of OpenContinuum is fostering European strategic autonomy and interoperability through an open ecosystem for the computing continuum. Such an ecosystem will contain the research and innovation action projects in the Cloud-Edge-IoT portfolio to be coordinated, the diverse community evolved from the current Cloud and IoT ones, with the addition of further actors, initiatives, and alliances of significance. Two of these projects are NEMO and NEPHELE.

The NEMO project (https://meta-os.eu/) (short for Next Generation Meta Operating system) RIA, is focused on building open European platforms for the Edge. Funded for three years, the expected outcomes of this RIA are a new generation of higher-level (meta) operating systems for the smart Internet of Things with strong computing capacity at the smart device, system and edge-level, embedded in a compute continuum from IoT-to-edge-to-cloud. Such an OS should be device independent and implement advanced concepts such as ad-hoc clouds, time-triggered IoT, and decentralised intelligence.

Increasing European autonomy in data processing required to support future hyper-distributed applications by building open platforms and an open edge ecosystem including business models, driven by European actors. Achieving trust in these (meta) operating systems among actors in diverse industrial ecosystems by leveraging open standards and - where applicable - open source.

The final RIA is NEPHELE (https://nephele-project.eu/), also funded for three years. A lightweight software stack and synergetic meta-orchestration framework for the next-generation compute continuum. Similar to NEMO, one possible outcome is the emergence of an open edge ecosystem including midcaps, SMEs and start-ups that foster the up-take of an edge operating system, e.g. through a modular functional spectrum of executable apps and services, for nurturing a European network of innovators and developers.

The Eclipse Foundation has decades of experience managing the governance of complex technology initiatives and multi-vendor organizations, making it the ideal organization to help manage projects where academia and the private sector converge. Its commitment to transparency, vendor-neutrality, and a shared voice will ensure that all participants have the opportunity to shape the future of the working group.

To learn more about getting involved with the Eclipse Foundation, please visit us at eclipse.org/research, or email us at research@eclipse.org. 

About the Eclipse Foundation

The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation. The Foundation is home to the Eclipse IDE, Jakarta EE, and over 400 open source projects, including runtimes, tools, and frameworks for cloud and edge applications, IoT, AI, automotive, systems engineering, distributed ledger technologies, open processor designs, and many others. The Eclipse Foundation is an international non-profit association supported by over 330 members, including industry leaders who value open source as a key enabler for their business strategies. To learn more, follow us on Twitter @ResearchEclipse, @EclipseFdn, LinkedIn or visit eclipse.org.

Third-party trademarks mentioned are the property of their respective owners.

###

Media contacts:

Schwartz Public Relations for the Eclipse Foundation, AISBL (Germany)

Stephanie Brüls / Susanne Pawlik

Sendlinger Straße 42A

80331 Munich

EclipseFoundation@schwartzpr.de

+49 (89) 211 871 – 64 / -35

Nichols Communications for the Eclipse Foundation, AISBL

Jay Nichols

jay@nicholscomm.com

+1 408-772-1551

514 Media Ltd for the Eclipse Foundation, AISBL (France, Italy, Spain)

Benoit Simoneau

benoit@514-media.com

M: +44 (0) 7891 920 370

We are happy to announce the Eclipse Theia 1.34 release! The release contains 51 merged pull requests and we welcome eight...

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

At the Eclipse Foundation conference last October, we had the opportunity to demonstrate an integration of Eclipse Sirius Web and Project Jupyter Notebook for seamless design, simulation, and analysis.

As a data enthusiast, I’ve always been impressed by the versatility of Jupyter. It serves as a hub for reproducible science and a gateway to a vast array of Python �frameworks for data science🔢 , visualization 📉, machine learning and much more. Even if the demo is fairly basic I wanted to showcase how such integrations can remodel the engineering process.

I can’t help but imagine the endless possibilities of quickly simulating design choices and making data-driven decisions on the spot. No more tedious data transfer between tools. The future of engineering is looking brighter every day with these open-source solutions.

What do you think? Have you used ������� or ������� ������ in your work? How? Would you consider it ?

What if you could design, simulate and analyze all at once using Open-Source solutions? was originally published by Cédric Brun at CEO @ Obeo on January 31, 2023.

2023 has been here for a month, and it’s time to hop into the year of the Water Rabbit according to the Chinese calendar. Preparing the Sirius Web project’s objectives, I was wondering: what’s in store for this year? And, just for curiosity, I searched for the chinese zodiac fortune predictions for 2023:

The year of the Water Rabbit is going to be a gentler year.
We’ll have time to take a breather.
We’ve been in the tunnel for the last few years, and the light is getting bigger now.

And “OMG! that’s exactly how I feel!”, we have been working on Eclipse Sirius Web really hard for the last two years, and we are gently landing to a new maturity stage. We introduced many new features in 2022 and in parallel, we are engaged in a quality process to ensure a sustainable product for the next decade.

Follow the rabbit and discover the new 2023.1 Sirius Web release (and its soundtrack, I know you like it!):

End user

Your node is fadin’

Sirius Web used to display all elements of a diagram but in a large diagram, the user may want to focus only on certain elements that are more relevant to his use. Since 2023.1, you can hide or fade a diagram element through the UI. If a diagram element is hidden, all contained nodes and connected edges have to be hidden too. After an element is hidden, in case of manual layout, the layout remains the same. If a diagram element is faded, there is no propagation to contained or connected diagram elements. Concerning faded graphic elements, they are still visible (from the user point of view) so the auto-layout will be applied.

Studio Maker

Provide your images at runtime!

Users can now upload their own images from a project’s new settings page. These images can be displayed in forms using the new image widget, or in View-based diagrams.

List compartments!

You loved the Sirius Desktop compartments? Now, it also exists in Sirius web. Starting from 2023.1, we support vertical compartments to display list elements. It’s a first step we will continue to improve in the next releases.

Circle of Edge and Completion!

We enhance the way to create your custom representations.

• We provide new arrow circle styles : Circle, FillCircle and CrossedCircle.
• We have support for completion in the View details for Domain types and AQL expressions. Any field in the property view which has a green background expects a Domain type and yellow background expects an interpreted expression.

In these fields, auto-completion can be triggered by hitting +.

When hitting auto-completion on an empty expression, the first completion proposal will correspond to the features, services, etc. which are available on the current element.

If I am a rich form

We introduced with 2022.7 a WYSIWYG editor to simplify and speed up the process of building a Form Description.

We continue our work to enrich forms, with support for:

• style preview: you can see the static styles directly in the form preview (for instance, on the previous screenshot the green and red buttons).

• a basic image widget:

• a rich text edition widget: The widget behaves in a similar way to the existing textfield and textarea widgets, except that the text value should be valid Markdown, and can be edited in a WYSIWYG way by the end user.
• groups : A Group is used to represent a Section in a details view tab.
• toolbar actions: A group can also define toolbar actions which will be used to create buttons in the toolbar of the group to let the end user execute some operations easily.

What’s next

• For the end user:
  • A “link with editor” option to disable the auto link between the explorer and the diagram view
  • Auto-wrap labels
  • Templates to ease the creation of new content
• For the studio maker:
  • Free form compartments
  • Updates on the View
• For the developer:
  • Switch to Java 17

That’s it for this release! As usual, you can find the detailed release notes in our documentation: https://docs.obeostudio.com/

Thanks to all our valued customers, we truly appreciate your involvement in sponsoring the Sirius Web open source project! You want to join us and become a Sirius Web backer, send me an email, or contact the team.

I wish you all a Hoppy New Rabbit Year!

Are you looking for a modern platform for building a custom tool or IDE that runs in the cloud but also...

The post Getting started with Theia – The nextGen Eclipse Platform appeared first on EclipseSource.

When you pick technologies to build tools empowering hundreds of your engineers, you aim at making the best choice. Open-Source is the best when you play the long term.

The Eclipse Foundation ensures that all the metrics related to an Open-Source project are exposed on its website, helping you to assess the effort which goes into maintaining and updating the technology.

With �� �������� �� ���� : 📦 📦 📦 📦 📦 📦 📦 📦 📦 📦 📦 📦 , the Eclipse Sirius project demonstrates its strength as a platform for building graphical modeling tools in any engineering domain. Each release brings a number of improvements and fixes to the core technology. �� ��� ���� � ����� ��� ���� ������ ������ ������� �� ���� ���� �� �������� !

We are committed to maintain a similar pace for 2023. We are still at the beginning of the year and both Sirius and Sirius Web have already shipped one, enjoy!

Building graphical modeling tools can be a complex undertaking, especially if they need to support many features and functions. At Obeo, we have extensive experience in this area and strive to make the process as easy and accessible as possible. To accomplish this, we rely on several strategies, including modular design, higher-level abstractions, and the ability to iterate quickly on a tool definition. In the last few years we have kept these principles while transitionning the technologies to the Web.

Are your engineering tools built on top of strong and well-maintained technologies? was originally published by Cédric Brun at CEO @ Obeo on January 25, 2023.

BRUSSELS, Belgium, Jan. 20, 2023 – The Eclipse Foundation, the EU’s largest open source software foundation, today announced it has teamed with 42 Wolfsburg/Berlin, an innovative software engineering academy using new pedagogical approach to training software developers, have entered into a strategic alliance under the auspices of the Foundation’s Eclipse Software Defined Vehicle (SDV) Working Group (WG). 

“Unlike more general open source software subjects, such cloud native applications and AI, there has been a dearth of resources focused on designing for the automotive industry,” said Michael Plagge, vice president, Ecosystem Development for the Eclipse Foundation. “Together, the Eclipse SDV WG and 42 seek to strengthen the automotive software ecosystem by establishing new, modern, interconnected collaboration methods and turn the education of software developers into an agile, demand-driven process by enabling students to directly work on relevant automotive software.” 

42 Wolfsburg is a unique Software Engineering Academy, where self-directed learning and expert mentoring, group fun and individual performance, superb campus facilities and career prospects come together. At 42, programming is not taught in a lecture hall: its training programs are fully practical and based on the principles of sharing, collaboration, and peer-evaluation.

“Most software for the automotive industry is proprietary, making it inaccessible for the vast majority of learners, which means they don’t have the opportunity to work with ‘real’ software before they start their job,” said Max Senges, CEO and headmaster of 42 Wolfsburg / Berlin. “Through our partnership with Eclipse SDV, we will build a curriculum of training projects around the SDV open source stack for automotive. Given that the materials will be Open Educational Resources they will enable students at 42, in companies and other educational institutions to learn, adapt and contribute to the evolution of relevant learning challenges. By doing so, we are helping to strengthen the automotive ecosystem while simultaneously growing the much needed developer talent pipeline for the industry.”

The Eclipse Foundation has decades of experience managing the governance of complex technology initiatives and multi-vendor organizations, making it the ideal organization to help manage projects where academia and the private sector converge. Its commitment to transparency, vendor-neutrality, and a shared voice will ensure that all participants have the opportunity to shape the future of the working group.

To learn more about getting involved with the Eclipse Foundation, please visit us at https://sdv.eclipse.org/, or email us at membership@eclipse.org. 

About the Eclipse Foundation

The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation. The Foundation is home to the Eclipse IDE, Jakarta EE, and over 400 open source projects, including runtimes, tools, and frameworks for cloud and edge applications, IoT, AI, automotive, systems engineering, distributed ledger technologies, open processor designs, and many others. The Eclipse Foundation is an international non-profit association supported by over 330 members, including industry leaders who value open source as a key enabler for their business strategies. To learn more, follow us on Twitter @ResearchEclipse, @EclipseFdn, LinkedIn or visit eclipse.org.

Third-party trademarks mentioned are the property of their respective owners.

###

Media contacts:

Schwartz Public Relations for the Eclipse Foundation, AISBL (Germany)

Stephanie Brüls / Susanne Pawlik

Sendlinger Straße 42A

80331 Munich

EclipseFoundation@schwartzpr.de

+49 (89) 211 871 – 64 / -35

Nichols Communications for the Eclipse Foundation, AISBL

Jay Nichols

jay@nicholscomm.com

+1 408-772-1551

514 Media Ltd for the Eclipse Foundation, AISBL (France, Italy, Spain)

Benoit Simoneau

benoit@514-media.com

M: +44 (0) 7891 920 370

More than just transparency, open source provides reflection.

Transparency and Reflection

Transparency is a benefit that is often touted about open source software. You can see the code and know exactly what it does and doesn’t do. From a consumer perspective, there are no surprises. You can read the code and like it and use it, cringe and avoid it, or maybe the code is good enough to start with and you choose to get involved and help improve it. The transparency of open source helps make your decision making process clearer.

Transparency is only one aspect of clarity that open source provides. Another aspect is reflection. You can learn a lot about the developers who contribute to an open source project based on their contributions. You can learn about the culture of a project and its community. The contributions members of an open source project make are clear reflections of the members of that community. The reflection comes not just from what is contributed, but how contributions are received and how the project engages with the community of contributors. How a project community conducts itself should be covered by a published Code of Conduct. A Code of Conduct of a project community is as important as the the code itself.

Seen and Unseen

I commend developers who have the courage to make themselves seen in the open source projects that they contribute to. I encourage developers to understand the benefits of reflecting themselves in the software that they use by also becoming a contributor.

The benefits may not be financial, at least at first. As someone who has hired software developers, I can tell you that the reflections you leave in the projects you contribute to and the evidence of how you conduct yourself in the community are potentially more valuable as a first impression to me than any opaque claims you make on your resume. If I can’t see your reflection in open source contributions and the way you conduct yourself in the community, I will need to rely on other verification mechanisms to validate any claims of awesomeness.

Developers whose contributions remain unseen and locked up in private repos and proprietary software may face tougher recruiting challenges in the long run. Of course, this may not concern you if you work on amazing proprietary software that is well known, profitable, and that you can substantiate any claims about contributions you have made.

Can you see yourself now?

The projects we work on for hundreds or thousands of hours are reflections of ourselves. They often reflect our abilities, our challenges, our great ideas, our hopes, our failures, and our triumphs. Most of the code and blogs I am most proud of, I will never see again. Neither will anyone else. If someone does still see the private contributions I made, they will probably never have met or known the person who originally made them. The proprietary code and blogs I wrote for the first 30 years of my career are locked up in the internal systems of my current or former employers. All current employers will eventually become former employers, no matter how much you enjoy working for them. None of us will work and live forever.

Open source is a more than just a mirror reflecting a temporary image. An open source project is a community portrait that evolves over time, and has embedded in it, the memory all of the artists that have contributed. The portraits may survive all of the original contributors. If you want to remain in the picture, well past the time when you made your contributions, and not be locked up and forgotten in some company’s private repositories, then open source is an answer to potential contribution immortality. The Arctic Code Vault Contributor badge is something I did not expect to see when I started contributing to open source projects on GitHub. Do I think anyone will ever see the millions of portraits stored in this code time capsule? Probably not, but the knowledge that it exists is oddly satisfying and comforting. The thought that something I contributed was important enough to be stored somewhere safe for a thousand years makes me smile. I enjoy having this badge on my GitHub profile.

Self-reflection

The great things that are built in open source are a reflection of the community of contributors that build them. Each person that contributes something to a project can see a bit of themselves in the picture. Every line of code, test, documentation, code review, and issue is a valuable contribution to a project.

I hope this blog sparks a little self-reflection, and motivates a few folks to cast a reflection or two as they begin their open source journey. Amazing problems are solved by ordinary people doing extraordinary things together in open source. There are many projects looking for more contributors.

I also hope this blog reminds the users of open source software, that there are many individual contributors out there who have given their time and energy to build the amazing free software that they are using. Open source is more than just source code that can be seen. It is the reflection of all of the contributors who invested their time in building it. Star a repo, or say thank you in a blog or tweet or perhaps in person to a contributor you know.

To all the open source contributors out there. I see you. Thank you for your contributions. �

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

Are you wondering how you should nowadays develop diagram editors to be durable, given the innovative and fast moving world of...

The post Diagram Editors with GLSP: Why flexibility is key appeared first on EclipseSource.

Europe has proposed new legislation intended to improve the state of cybersecurity for software and hardware products made available in Europe. The Cyber Resiliency Act (“CRA”) will mandate that all manufacturers take security into account across both their development processes and the lifecycle of their products once in the hands of consumers. 

This document discusses the legislation and the potential impact it may have on the Eclipse Foundation and its 400+ projects and community. Many of the issues noted could have a similar impact on other open source organizations and projects. It is written based on our reading of the current draft legislation and a number of assumptions stated below. Note that is consciously does not include a discussion of possible revisions to the legislation, although we may post a followup which does. It also does not include any discussion concerning the warranty and product liability provisions of the legislation as we have not yet analyzed the impact those may have on us.

We are sincerely looking for comments and feedback, as it is quite possible that we have misunderstood or misinterpreted the documents.

It is important to stress that the Eclipse Foundation is better positioned to deal with the fallout from the CRA than many other open source organizations. We have staff. We have some resources. We have common community processes and practices shared across our many projects. We have CI/CD infrastructure shared by most (but not all) of our projects. We have a security team, written security policies and procedures, and are a CVE numbering authority. Despite being in a better position than most, we fear that the obligations set forth by the legislation will cripple the Eclipse Foundation and its community. 

There are a number of other excellent summaries of the worrisome impact of this legislation on the open source ecosystem. We highly recommend reading:

• Open-source software vs. the proposed Cyber Resilience Act by Maarten Aertsen.
• The EU’s Proposed Cyber Resilience Act Will Damage the Open Source Ecosystem by Olaf Kolkman.

Both of those articles primarily focus on the potential impact of the CRA on individual open source projects. Olaf’s document in particular suggests improvements to the draft. In this document we want to focus on the impact on an organization such as the Eclipse Foundation and its open source projects if the CRA was approved in its current form. How the CRA should or could be amended is being discussed elsewhere. The purpose of this document is to provide a resource explaining the impact of the legislation as it stands today.

It is important to note that the CRA does make a laudable attempt to carve out free and open source software but only “…outside the course of a commercial activity…”. Maarten Aertsen does an excellent job of summarizing the problems with this carve out. In particular he references a definition of commercial activity used in EU Blue guide to the implementation of EU product rules which states:

Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context.

Assumptions

• The CRA references the term “product” over 600 times but does not appear to define it. The act does define the term ‘product with digital elements’. For the purposes of this document we will assume that for the purposes of the CRA, any Eclipse Foundation project software made generally available to the public as a downloadable, installable, and executable binary would be considered a ‘product with digital elements’ under the regulation.
  • In addition, there are at least some EF projects which may be considered ‘critical product with digital elements’ (e.g. Kura, Keyple, ioFog, fog05) or ‘highly critical product with digital elements’ (e.g. Oniro, Leda, 4diac) .
• The CRA defines ‘manufacturer’ as “any natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under his or her name or trademark, whether for payment or free of charge”. For the purposes of this document, we will assume that the Eclipse Foundation would be considered the manufacturer of the binaries produced by its projects. Among other reasons justifying this assumption, the Eclipse Foundation asserts that it owns the trademark rights for each of its projects and the binaries they release and (resources permitting) we market them as works of the Eclipse Foundation. 
• As mentioned above there is an attempt to exclude free and open source software produced outside the course of a commercial activity from the scope of the legislation. For the purposes of this document we will assume that Eclipse Foundation project software would be considered as produced under the course of a commercial activity, and would therefore be subject to the legislation. This assumption is based on the following:
  • The Eclipse Foundation is not a charity. It is a Belgian-incorporated international nonprofit association of hundreds of business members. 
  • Eclipse Foundation projects are not, generally speaking, developed by hobbyists. While some are, our projects are commonly developed by full-time employees of our member companies or by individuals who are making a living from consulting services related to their project work. 
  • Eclipse Foundation projects provide goods in a business related context. By that we mean that EF projects are largely intended to provide software which is immediately ready for adoption by businesses either as a component within a commercial product or by use by employees in their daily work.
  • Eclipse Foundation projects provide a regularity of supply. As one extreme example, the Eclipse IDE takes great pride in having not missed a single release date in over 15 years.
  • Eclipse Foundation projects deliver high quality software, equivalent to the quality found in commercial products. So the “characteristics of the product” are equivalent to commercial products. 

Having said all of the above it is important to remind the reader that all Eclipse Foundation projects provide their software for free, on a non-profit basis, and under OSI-approved open source licenses which permit further use, study, modification, and distribution. 

Impact Assessment

CE Markings for Software Products

Fundamentally, the core of the proposed legislation is to extend the CE Mark regime to all products with digital elements sold in Europe. Our assumption based on the current text is that this process will be applied to open source software made available under open source licenses and provided free of charge, ostensibly under licenses which disclaim any liability or warranty. We are deeply concerned that the CRA could fundamentally alter the social contract which underpins the entire open source ecosystem: open source software provided for free, for any purpose, which can be modified and further distributed for free, but without warranty or liability to the authors, contributors, or open source distributors. Legally altering this arrangement through legislation can reasonably be expected to cause unintended consequences to the innovation economy in Europe.

Without a clearer exemption for open source, in order to comply with the legislation the Eclipse Foundation will be required to:

• Develop, document, and implement policies and procedures for every project at the Eclipse Foundation to ensure they are conformant with the requirements of the CRA including:
  • All of the development and post-release security requirements set forth in Annex I, including providing notification and update mechanisms. 
  • All of the user documentation requirements set forth in Annex II.
  • All of the product technical documentation set forth in Annex V, including “…complete information on the design and development of the product…including, where applicable, drawings and schemes and/or a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing.”
• For each EF project release, prepare the project-specific documentation required by Annex V, including “…an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained…”.
• Determine for each project whether it meets the definition of ‘product with digital elements’, ‘critical product with digital elements’, or ‘highly critical product with digital elements’.
  • For each project which is a ‘product with digital elements’, establish, complete, and document a CE mark self assessment process.
  • For each ‘critical product with digital elements’ or ‘highly critical product with digital elements’ engage with an external CE auditing body and complete the additional processes required to get the CE mark approval. Note that it is not clear to us what the costs in time, resources, and money would be to implement these external audit processes. Our assumption is that they would be substantial.
    
    It is also important to note that in most other domains regulated with CE markings they are done where there are well known standards, specifications, and/or certification processes in place. These are not in place for most Eclipse Foundation open source projects. This could significantly increase the costs and risks associated with conformance.
• For each single project release, document that the relevant CE mark process is followed (as described above), that an EU declaration of conformity is written and signed by an officer of the foundation, that the CE mark is affixed, and that the technical documentation and EU declaration of conformity is made available for at least 10 years after the release. Note that we estimate that in any given year the Eclipse Foundation’s projects make available several hundred releases.

Article 4(3)

Member States shall not prevent the making available of unfinished software which does not comply with this Regulation provided that the software is only made available for a limited period required for testing purposes and that a visible sign clearly indicates that it does not comply with this Regulation and will not be available on the market for purposes other than testing.

Many Eclipse Foundation projects make integration, nightly, weekly, and milestone builds available under their open source licenses available indefinitely. The intent is to provide for community testing and for traceability. These binaries are marked as such, but the terms under which they are provided do not require that they be used for testing purposes only. 

It is not clear how this requirement could be implemented by any open source project using modern CI/CD infrastructure and operating under the principle of transparency. Even if the binaries were marked as “testing purposes only”, the open source licenses they are provided under do, in fact, permit uses other than testing. Further, it is common practice to provide intermediate builds for extended periods of time (often permanently) to provide testers with access to past builds for problem identification and remediation. Discontinuing that practice would be significantly disruptive. And any solution based on providing intermediate builds under non-open source licenses would be impossible for Eclipse Foundation projects, as the EF does not own the copyright and obtaining the approval of all contributors would be impractical. In summary, compliance with this CRA requirement would represent a significant blow to open source development best practices. 

Article 5(1) and Section 1 of Annex I

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks

At a minimum this would require the development and enforcement of written policies requiring every project to assess their level of cybersecurity risk and to implement processes to ensure that there is a determination of the risk level and a justification for the development processes adopted.

(2) Products with digital elements shall be delivered without any known exploitable vulnerabilities
(3) On the basis of the risk assessment referred to in Article 10(2) and where applicable, products with digital elements shall:
(a) …(j)

These would require a material change to our community’s release processes to require attestations that there are no known vulnerabilities and to comply with the many requirements listed. 

(k) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users.

With a few exceptions, EF projects do not “call home”, require any sort of user registration, and do not provide a mechanism for notifying all users that an update is either available or required. Implementing these requirements would require a whole new infrastructure to be mandated across all projects. 

Article 5(2) and Section 2 of Annex I “Vulnerability Handling Requirements”

In general, the Eclipse Foundation is in decent shape to deal with many of the stated requirements. As noted above we have a security team, written security policies and procedures, and are a CVE numbering authority. However, there are two notable elements in the requirements. 

(1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product

This would impose a legal requirement to produce SBOMs for all EF projects. Although it is something we aspire to, this is a very significant effort. It would also require actively monitoring all project dependencies for known vulnerabilities in dependencies. This is generally considered an unsolved problem within the open source ecosystem with no known path to implementation.

(3) apply effective and regular tests and reviews of the security of the product with digital elements;

These would require a material change to our community’s development processes to mandate a whole class of testing which is not currently mandated for our projects. This is a very significant effort both to implement and to maintain.

Recently I updated my web site to a new, fresh look. I chose the great OceanWP theme (free version). While the build-in functionality is already awesome, I wanted my header to be sticky and transparent.

I searched for a solution and was inspired by this article, but got better results when using position: sticky instead of position: fixed. Furthermore, I wanted the top-header to always scroll and only the main header to be sticky.

For the transparency, I used a (non-transparent) minimal header in the UI and overrode it in the CSS. I just decided to start with black and make the background as transparent that it fits my desired gray color at the beginning.

To implement this I just added a few lines of CSS in the template customizer (Custom CSS/JS):

@media only screen and (min-width: 768px) {
  #site-header {
    position: sticky;
    top: 0;
    background-color: #000000e1 !important;
    transition: height .3s
  }
}

Then I wanted to add shrinking of the header height and the logo. For that I added a bit JavaScript (could be optimized…):

window.addEventListener('scroll', function (e) {
  if (window.innerWidth > 768) {
    if (window.scrollY >= 30 && document.getElementById('site-header').style.height !== '40px') {
      document.getElementById('site-header').style.height = '40px'
      var list = document.querySelectorAll('#site-navigation-wrap .dropdown-menu >li >a');
      for (i = 0; i < list.length; ++i) {
        list[i].style.setProperty('line-height', '40px', 'important');
      }
      var el = document.querySelector('#site-logo #site-logo-inner a img')
      el.style.setProperty('max-width', '100px', 'important');
      el = document.querySelector('#site-logo #site-logo-inner')
      el.style.setProperty('height', '40px', 'important');
    } else if (window.scrollY < 30 && document.getElementById('site-header').style.height !== '60px') {
      document.getElementById('site-header').style.height = '60px'
      var list = document.querySelectorAll('#site-navigation-wrap .dropdown-menu >li >a');
      for (i = 0; i < list.length; ++i) {
        list[i].style.setProperty('line-height', '60px', 'important');
      }
      var el = document.querySelector('#site-logo #site-logo-inner a img')
      el.style.setProperty('max-width', '130px', 'important');
      el = document.querySelector('#site-logo #site-logo-inner')
      el.style.setProperty('height', '60px', 'important');
    }
  }
});

You can see the result when scrolling this blog post. But my approach is considered to be a quick and dirty solution that may have unexpected side effects. If you want even more features and a more professional implementation, you could take a look at the commercial “Sticky Header” plugin-in from OceanWP.

We are happy to announce the Eclipse Theia 1.33 release! The release contains 27 merged pull requests and we welcome eight...

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

Building graphical modeling tools can be a complex undertaking, especially if they need to support many features and functions. At Obeo, we have extensive experience in this area and strive to make the process as easy and accessible as possible. To accomplish this, we rely on several strategies, including modular design, higher-level abstractions, and the ability to iterate quickly on a tool definition. In the last few years we have kept these principles while transitionning the technologies to the Web.

The Fellowship of the Modules

Just like how the quest to destroy the One Ring in the Lord of the Rings was made easier by breaking it down into smaller tasks and delegating them to various members of the fellowship, we at Eclipse modeling technologies use a modular design to manage complexity in our software. Each project is responsible for a specific task, delivering components that can be reused and integrated into a tool for the end user.

For example,

• EMF handles model data and its API,
• Sirius focuses on editors and tooling,
• EMF Compare enables the comparison, merging, and conflict resolution of different versions of models,
• Acceleo allows for code or text generation from models,
• M2Doc produces reports and documents using models and diagrams as inputs.

This modular design has several benefits. It makes the software easier to understand and work on, as you can focus on one module at a time rather than trying to comprehend the entire system all at once. Modular design also facilitates code and functionality reuse. If you build a module that does something useful, you can use it in other projects. The Sirius project is a good example of this, as it provides a complete set of features that are reused and exposed through hundreds of graphical modelers. You can see some examples in the Sirius Gallery

While modular design is useful, it is not a perfect solution and does have some challenges. One challenge is ensuring that the modules work well together and do not have conflicts or dependencies. This can be especially difficult when the modules are evolving independently within their own projects. To address this issue, we coordinate with other projects within the Eclipse Release Train and build an integrated suite called the “Obeo Designer Community,” which is a ready-to-use packaging.

Inception: The Higher-Level Abstraction Edition

Just like Cobb and his team in Inception, we use higher-level abstractions to hide the underlying complexity of building a graphical modeling software and make the process more manageable for our users.

Higher-level abstractions can take many forms, such as libraries, frameworks, or domain-specific languages (DSLs). At Obeo, we use DSLs as our choice for higher-level abstractions. An example of this is Sirius.

When you define a tool using Sirius, you specify the graphical modeler you want to achieve in terms of graphical shapes and how these shapes are mapped to the domain model. You can also specify a set of editors, actions, and wizards that can be launched by the end user, without having to deal with the details of coding these features on the underlying platform. Sirius handles these details behind the scenes.

However, higher-level abstractions also have their challenges. One challenge is that they can add an extra layer of complexity to the software. Developers must understand how the abstraction works and how to use it correctly. To help with this, we offer support and expertise, training, and tutorials for getting started with Sirius. We also hold the SiriusCon conference each year since 2015 to help our community discover what they can do with Sirius.

Another challenge is that higher-level abstractions can be limiting. They may not provide all the features and flexibility that developers need, or they may make it difficult to do things in a different way. To address this, we allow for tool behavior to be extended with Java code when necessary. This is useful when the tool needs to interface with another tool directly, rather than through file exchanges, or when specific computations or user interfaces are required.

The Eclipse Modeling platform is generally extensible, and EMF, Compare, Acceleo, Sirius, and other projects provide dedicated extension points to allow their behavior to be customized using Java code and APIs. In addition, Sirius and Acceleo allow for branching out to simple Java code directly, without the need to fully understand the Eclipse platform.

The Fast and the Furious of Graphical Modeling Tools: Hot Reloading

Like the crew in the Fast and Furious franchise, we aim to reduce the complexity of building graphical modeling software by enabling fast iteration and turnaround.

Fast iteration means being able to make changes to the software quickly and easily, and see the results of those changes right away. In the case of Sirius two factors are enabling this, first by providing a higher level abstraction to define modeling tool one can express quicker and with more precision what the tool should look like and do. The second factor, and this one stands out quite a bit compare to the other frameworks you can use to build a graphical tool, is that Sirius will hot-reload your tool definition, you are able to instantly see the tool in action, adapt it’s definition, see the result, and iterate. It’s life changing, as then the cost of trying another way to represent the domain and interact with it is only minutes, and going back to the previous version of the tool is one CTRL-Z away.

With Sirius Web we even go one step further in reducing this feedback loop: you adapt the tool, it’s instantly usable by all the engineers accessing it directly from their web browser.

To summarize, building a graphical modeling tool can be complex, but there are several ways to approach this complexity. Modular design allows for easier understanding and reuse of code, while higher-level abstractions can hide underlying complexity from the user. Fast iteration and turnaround is also important for efficient development. Obeo has been working on technologies to make building graphical modeling tools more accessible for many years now, and we are excited by the prospects of what is to come on this path : while Sirius on the desktop has proven this is an efficient way to tackle this complexity, Sirius on the Web goes even one step further in making such tools accessible to anyone.

Building Graphical Modeling Tools, Approaches to Reducing Complexity was originally published by Cédric Brun at CEO @ Obeo on January 12, 2023.

Java developer blogging with coffee.

Coffee makes me Blog

Welcome to my blog! I write mostly about Java but occasionally write about other topics I find interesting or relevant at some point in time.

I drink three cups of coffee a day. I try not to drink any coffee after 4pm. I mostly drink Dunkin’ Donuts Keurig K-cups. I drink my coffee with half and half. I do not drink coffee with sugar.

150 blogs. 450 cups of coffee. Lots of Java code. I’m just getting warmed up.

That’s it. That’s the blog. Thanks for stopping by and reading! I appreciate if you leave some claps for any blogs you enjoy. I hope you enjoy reading, blogging and some great coffee in 2023!

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

An experiment in stream of consciousness writing.

I rode my bike today

I followed the road from my house to the park, and meandered down the path that I ride several times a week. Every ride is the same, in that it is always slightly different. Today I just rode, and didn’t stop to take any breaks or pictures. I listened to music and went around the lake several times. The weather was nice, and a lot of people were in the park walking around the lake. I was in the zone pedaling away, so I had to occasionally go off the path on the grass to avoid stopping or running into folks. I only rode 6.25 miles today, but it was refreshing.

I miss learning. I miss teaching.

I miss classroom style teaching with hands-on programming using code katas. I haven’t taught much at all in the past three years of the pandemic. I feel disconnected from my audience in blogs and miss getting interactive feedback from students where I always learn something new. I have enjoyed learning JavaFX recently, and I bought some new books to read for 2023, including one on JavaFX 17. I hope to get back to in-person class teaching in 2023.

I miss shopping in person for tech books

I used to spend a lot more time in Barnes and Noble Bookstores perusing the technology shelves. I went to my local Barnes and Noble and was disappointed to find that the technology section had moved and shrunk. It felt dumbed down and sad. So I went online to Amazon to order some new tech books. I bought five new tech books that just arrived this week. I hope the reading replaces the complete lack of joy I felt not being able to pick up the book from the shelf, scan through the pages and take it to the register knowing I had found something good.

The books I bought to read in 2023 are:

• Getting to Know IntelliJ IDEA — Helen Scott and Trisha Gee
• The Well-Grounded Java Developer (Second Edition) — Martijn Verburg, Ben Evans, Jason Clark
• Pharo 9 by Example — S. Ducasse and G. Rakic
• The Definitive Guide to Modern Java Clients with JavaFX 17 — Stephen Chin, Johan Vos, James Weaver
• Oracle Certified Professional Java SE 17 Developer — Jeanne Boyarsky and Scott Selikoff (blog)

I watched Bullet Train

I watched the movie Bullet Train late last night with my son. It was fun, and I enjoyed the movie. The movie brought back memories of riding the Shinkansen on one of my trips to Japan many years ago.

I brushed up on Clipper 5.3 syntax

I started my professional programming career programming in Clipper. I haven’t written any Clipper code in over 25 years. I found a site that has the entire Clipper 5.3 syntax. I learned Clipper by reading books.

Harbour Reference Guide · Index

I wanted to refresh my memory about the syntax and structure of statements like IF, FOR and DO WHILE. Clipper is not a curly brace language, but it has a clear structure. This really brought back some fond memories of my early days as a professional programmer.

I enjoy coding with Emojis

I’ve written quite a few Java code katas over the years. I hadn’t written any code katas with emojis until a few months ago. Emojis can help make code katas more fun. At least I think they do. I enjoyed reading this year-end Apache Groovy blog from Paul King, which revisited some of emoji programming fun we had over the past year.

Groovy Apache Groovy

When I stop babbling like a brook

Then my Stream of Consciousness has run out and I otter print out the Stream in Java.

Stream.of("�", "🚴", "📙", "📚", "🚅", "⛵�", "🦦").forEach(System.out::print);

This is my final blog for 2022. Thank you for reading! I hope you all have a safe, healthy and Happy New Year!

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

A game to help visualize effects of brace placement style in Java

The Objective is to be Objective

Several years ago, I came up with a creative approach to help establish and agree upon coding style with a new team I was working on. We were in the beginning stages of coding on a new project using the Java programming language. I requested that we decide and agree upon consistent code style guidelines as a team, up front. I knew I needed to come up with an objective and creative argument to address one of the contentious code style debates in Java — where to place the curly braces.

Choosing Creativity over Conflict

Swimming against the tide of “but everyone else does it this way” is hard. It’s even harder when a highly respected search company stamps their seal of approval on a particular Java coding style.

To help me present an objective argument for a particular brace placement style, I created a game I called “Connect the Braces”. I took code from two example classes I created and pasted them in a Powerpoint deck and literally drew lines on top of the code to connect the beginning and ending braces. The game was inspired from one of my favorite childhood games — “Connect the Dots”.

The great thing about “Connect the Dots” is is the rules are simple, and almost everyone has played the game in school. “Connect the Braces” is also very simple. Just connect the beginning and ending braces of each code scope by drawing a line between them. Easy.

I presented the game to the team, and after I was done, no one responded “but everyone else does it this way”. This confirmed that at least one team responded well to a creative argument about brace placement style.

Automating the game

I told my friend Vladimir Zakharov (Vlad) about this game, and how it effectively defused what I had previously experienced as an incendiary debate. I asked Vlad if he could write some Java code to visualize the game I described to him. Vlad is better at visual programming than I am, so I knew he would complete the code faster than I would.

Vlad did something even better than just connecting the braces in a source file. He also colored blocks of code in green highlight. This has the added benefit of visually highlighting whitespace.

The images in the following section were generated using Vlad’s automated version of “Connect the Braces” on actual code from the Eclipse Collections Kata.

Warning! Game on!

The following images are graphic. Some developers may find them disturbing. Actual source code was used in the creation of the following visuals. Any images that cannot be unseen after scrolling beyond this text is the sole responsibility of the person scrolling, not the author. Any fruit or pets that were harmed during the two “Connect the Braces” rounds were the result of code style choices, not the author. Choose wisely. You have been warned!

Round One: Fruit Enum

Round Two: PetType Enum

Choosing Clarity over Clutter

I know I probably just waded into a raging river filled with hungry piranha while wearing a pair of swim trunks made out of steak. I am not looking to convince everyone that a particular brace placement style is the “one true style”. There is definitely a style I prefer when I write code, and I have to argue for it on every project that I work on. I find that when I present my argument using this game, we can have a healthy discussion about the importance of aesthetics, white space, and visual tracking for code scanning and readability.

I choose clarity over clutter. Signal over noise. I choose the style on the right.

To quote my friend Vlad:

When I read code, I usually want to see either the “what”, e.g., what are the responsibilities of the this class, what is this method’s contract, what is the condition to trigger this branch — or the “how”, e.g., how does this method do what it does, what happens if I follow this branch, and so on. Having the whats and the hows visually segregated helps me scan the code and focus my attention on what matters at the time.

The vertical brace formatting style has a natural effect of cleanly separating the “what” from the “how” by introducing whitespace between signature (class and method definitions) and implementation (variables and code). The beginning and end braces are always in the same horizontal location, with variability based consistently on the depth of nested scopes (e.g. control statements like if, for and while). You expect to see the base of a pyramid shape with the braces, so can safely ignore where they are, because you know where they are. This style is easy to implement automatic formatting in your IDE and and enforce in a CheckStyle build.

I have been swimming against the tide by using this brace formatting style in Java for over 20 years. To developers who have to read or work in the code bases that are formatted using the vertical brace placement style because of me, I have something to say.

You’re welcome!

An Exception to the Rule

I choose a different brace placement style when creating Powerpoint slides or text for a book with Java code. In these two print media only, I almost always choose the style that favors fewer lines of code. Breaking code across pages is undesirable. This is a tradeoff that is made due to limits on available vertical space. This imposed limit does not exist in code you are reading in your IDE or in a browser reading source from a VCS like GitHub or GitLab where vertical scrolling works just fine.

Seven Ineffective Coding Habits of Many Programmers

A few months after I created the “Connect the Braces” game, I came across an amazing talk from Kevlin Henney who presents a great argument for a particular brace placement style, among many other great points he makes in the talk about coding style.

So therefore, what I have just told you, in case you were wondering, yes, there is a way to determine the correct way to align your braces… objectively.

No spoilers. I highly recommend watching this talk. Warning, this talk may be a constructive disruption to your current coding style.

A Call to Action on Java Code Style

We are leaving billions of lines of Java source code in version control systems to be maintained by our future selves and future generations of developers. Code style has a direct and subtle impact on clarity and readability. Not everyone reads code at the same speed. There may be accessibility challenges that you should discuss and consider as a team. Everyone should be able to parse code eventually by reading it line by line, regardless of style. If we can spend fewer cycles separating the what from the how and finding code we are looking for, it would be a good thing.

Here are my rules for building an acceptable coding style on a team.

1. Have discussions with your team about code style guidelines.
2. Apply consistent code style guidelines in your project using auto-formatting rules encoded and customized in your favorite IDE.
3. Run an automated continuous build that will break on inconsistent code style commits (e.g. CheckStyle).
4. Publish your code style guidelines in your project VCS.
5. Have the courage and take the time to evolve your code style guidelines when you discover or learn something new.

This blog focused on only one aspect of code style — brace placement. There are many others code style aspects to consider, and Kevlin does a great job of explaining some of them in his talk. I highly recommend watching Kevlin’s talk, “Seven Ineffective Coding Habits of Many Programmers”, that I linked above. I recommend discussing and agreeing as a team how you will address the long term readability properties of your code base. Do not just adopt someone else’s code style because it is convenient and readily available.

Feel free to use the Connect the Braces game to help facilitate rational and objective discussions about code style, especially as it applies to discussions around brace placement style in Java. If you like this style and want to see the the code style settings that we have used for in IntelliJ IDEA for Eclipse Collections for the past seven years, they are checked into GitHub here.

Enjoy!

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

As 2022 draws to a close, I would like to express my sincere gratitude to our contributors, committers, members, and the Eclipse Foundation team for your commitment, passion, professionalism, persistence, and tremendous contributions to our community’s success. 

This year included a number of accomplishments and milestones in the Eclipse community. We welcomed over 20 new projects, 55 new member companies, and a new working group with Eclipse Software Defined Vehicle. Also, this year, the Board of Directors approved the creation of Interest Groups, the next step in furthering the Eclipse Foundation’s governance framework to enable “innovation through collaboration” by empowering members to work together using a lighter-weight governance structure than our more formal working groups. Find out how to start a collaboration and share the opportunity with your colleagues and network.

After 3 years of virtual interactions, we held our first in-person EclipseCon in Ludwigsburg. This chance to connect with friends and colleagues, new and old, was not taken for granted with over 415 participants. We could not make it happen without our speakers, sponsors and participants! Mark your calendars for the next EclipseCon – October 16-20, 2023.

Moments like that remind us of the importance of coming together, and we hope that the new year will give us many more opportunities for our global community to collaborate.

All the best for 2023!

It has been an amazing year for Eclipse Theia, the next-gen Eclipse platform for building tools and IDEs. 2022 brought many...

The post The Eclipse Theia Update 2022 appeared first on EclipseSource.

Celebrating 7 years at the Eclipse Foundation and 11 years as OSS

TL;DR

Eclipse Collections continues to evolve and grow. This blog contains links and images that show the growth in usage and interest in Eclipse Collections over the years. I’ve included GitHub graphs of the top 10 Eclipse Collections contributors who have been active in its continued evolution this year and over the past seven years. Enjoy!

Quick Stats

• 282,590 downloads of eclipse-collections in Nov. 2022
• 1,084,354 downloads of eclipse-collections-parent in Nov. 2022
• 2,102 GitHub Stars
• 502 GitHub Forks
• 1,895 Commits
• ~100 Contributors

Quick Links

• GitHub Repo
• Kata Repo
• Website
• Maven Central

Maven Central Stats

Downloads of eclipse-collections over last 12 months

• 282,590 downloads in Nov. 2022

Downloads of eclipse-collections-parent over the last 12 months

• 1,084,354 downloads in Nov. 2022

GitHub Trends

Stars and Forks

• 2,102 stars and 502 forks today

Link: https://porter.io/github.com/eclipse/eclipse-collections

Commits

• 1,895 commits

Link: https://github.com/eclipse/eclipse-collections/graphs/contributors

Top 10 Contributors in 2022

Top 10 Contributors Overall

• ~100 contributors overall

Top Contributor Blogs

Here are links to the blogs of some of the top Eclipse Collections contributors. Please comment if I have missed any and I will add them here. If you’re looking for additional great content producers to follow here, I recommend following all of these folks.

• Craig Motlin
• Nikhil Nanivadekar
• Hiroshi
• Sirisha Pratha
• Alex Goldberg
• Vladimir Zakharov
• Desislav Petrov
• Emilie Robichaud
• Aqsa Malik

Happy Holidays and Happy New Year!

Thank you to all the users, advocates, contributors, committers and friends of Eclipse Collections. I hope you enjoy some downtime the next few weeks as we enter 2023.

If you’re looking for a new and fun OSS project to contribute to in 2023, I would recommend taking a look at Eclipse Collections. We welcome new contributors! The following blog can help you get started if you’re interested.

Help Wanted!

Have a safe, happy and healthy New Year!

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

2022 has been a fantastic year for the Eclipse Foundation. We’ve managed to grow all aspects of our organization, due in no small part to the ongoing proliferation of open source across industries worldwide. Perhaps no one Working Group exemplifies our efforts in 2022 more than the Eclipse Software Defined Vehicle (SDV) Working Group, which has seen significant momentum in terms of new members, innovation, and new projects. Just this week, Mercedes-Benz Tech Innovation has announced they will be lending their own resources and talents to Eclipse SDV. With this in mind and before we all part ways for the holidays, I wanted to cap this year with some exciting news related to just this subject. 

Coming in early June 2023, the Eclipse Foundation and the Eclipse SDV WG will hold the first automotive industry event focused on open source software and collaboration-based innovation. Named the Automotive Open Source Summit and based in the Munich  area, this event will highlight speakers from organizations throughout the auto industry, including organizations outside the Eclipse community, as well as leaders within our own automotive initiatives. This will be a one-day and a half  event and specific details will be finalized early in the new year. 

The Summit will focus on latest trends, “business” topics  targeting executives, senior technical leaders, and other decision makers. The main conference will be preceded by an exclusive executive round table attended by the industry’s most influential leaders. Our goal is that this conference becomes a “must attend” event for all participants in the automotive software ecosystem regardless of whether they are actively engaged with open source technology. In the coming years, we plan on extending the program for developers by designing a technical targeted track.

The Summit will feature speakers from Eclipse automotive initiatives as well as organizations and leaders from outside the Eclipse community. We want to  attract the participation of all high profile open source and open specification initiatives in the automotive industry.

This is just one of the exciting new developments the Eclipse Foundation has percolating for next year. We can’t wait to give you and the rest of the community more details. In the meantime, Happy Holidays to you and yours for 2022 and we look forward to engaging with all of you in 2023! 

Eclipse Theia celebrates its 5th birthday! It is amazing to see how fast Eclipse Theia has evolved to become the next...

The post Happy Birthday, Eclipse Theia! appeared first on EclipseSource.

The Eclipse Ditto teams is proud to announce the availability of Eclipse Ditto 3.1.0.

Version 3.1.0 brings policy imports, AMQP 1.0 message annotation support, conditional message sending and other smaller improvements, e.g. regarding shutdown/restart improvements.

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.1.0 are:

• Conditional message processing based on a specified condition targeting the twin state
• Support for reading/writing AMQP 1.0 “Message annotations” in Ditto managed connections
• Policy imports: Reference other policies from policies, enabling reuse of policy entries
• Several Ditto explorer UI enhancements
• Support for configuring an audience for Ditto managed HTTP connections performing OAuth2.0 based authentication

The following non-functional enhancements are also included:

• End-2-End graceful shutdown support, enabling a smoother restart of Ditto services with less user impact
• Support for encryption/decryption of secrets (e.g. passwords) part of the Ditto managed connections before persisting to the database
• IPv6 support for blocked subnet validation

The following notable fixes are included:

• Fixing that known connections were not immediately started after connectivity service restart

Please have a look at the 3.1.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 Eclipse Ditto team

I had no plans to learn JavaFX this year, and then it just kinda happened.

JavaFX makes me feel young again

I’ve been developing software for a long time. 40 years feels like a long time to me anyway. Software development has gotten increasingly and incredibly complex over the years. So much so that I find it takes an incredible amount of energy and motivation just to get started building an application, especially when building “full stack” applications. JavaFX and IntelliJ are the first things I’ve seen in quite a while which personally help me to address some of the manufactured complexity of building a working application with a user interface in Java.

The Challenge

On the evening before Thanksgiving day this year, I wanted to build a simple ToDoList UI in Java in under two minutes from start to finish. I could pretty much do this with my eyes closed in VisualAge Smalltalk in the 1990s. I have not been able to feel enabled like this in Java in the past 22 years. That is, until now.

Make easy tasks simple.
Make hard tasks possible.

Java has failed for a long time making easy tasks simple. Java has excelled at making hard tasks possible. This is why I have programmed in Java professionally for over 20 years. Java is the future, but some of its past has been an unfortunate burden, that we just need to leave in the past.

While I failed the two-minute challenge (hey it was my first time trying), I was able to build a working in-memory ToDoList in JavaFX with IntelliJ in about an hour. Several hours and blogs later, I wound up with a more feature rich ToDoList that actually could persist itself to JSON.

The absolute key to reducing the startup complexity for me building this ToDoList was IntelliJ. Getting a working Hello World JavaFX project structure generated for me by IntelliJ saved me at least an hour or two. This is extremely important to understand. I am familiar with Maven conventions so once the project structure was generated, I knew exactly where look for things.

I do believe with enough practice, I will be able to meet the two-minute challenge for the ToDoList in JavaFX with IntelliJ.

The following is the chronicle of four blogs that tell the story of my first JavaFX adventures.

The Story

Chapter One

Meeting the challenge of building an in-memory ToDoList in Java.

My first JavaFX application

Chapter Two

Exploring Java Records, LocalDate, DatePicker and TableView.

Experimenting with Java Records, DatePicker, and TableView in JavaFX

Chapter Three

Exploring Java Enums, emojis and ComboBox.

Experimenting with Java enums, emojis, and ComboBox in JavaFX

Chapter Four

Persisting my ToDoList to JSON using Jackson.

Using the Jackson library to persist my JavaFX ToDo List to JSON

Just the beginning

I decided a few months ago, I wanted to take a break from working on Eclipse Collections to get back to showing and teaching developers how they can have fun in programming. There are so many things to learn about programming, and I think I have some useful things to teach.

This adventure has been a whole lot of fun for me. I have experienced a joy of programming I haven’t felt in quite a while.

I plan to continue iterating on my JavaFX ToDoList, and sharing new things that I learn, as I learn them. I don’t know if I will become an expert in JavaFX, but I hope to learn enough so that I can build a working JavaFX application in a professional setting when I have the opportunity.

Thank you for reading my story so far. I hope you find the joy in programming in whatever language, IDE and libraries you are coding with.

Enjoy!

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

Other Java FX Resources

• 7 Best Java FX Online Courses for Beginners in 2022
• Top 6 Free Courses to learn Servlet, JSP, and Java FX in 2022 — Best of Lot
• Top 5 Courses to Learn JavaFX Online in 2023 - Best of Lot

My weird and wonderful first adventures with JavaFX was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

Subtypes can specialise their parent type or leave it as is. This specialisation can be done via either adding some members like fields or methods, or by overriding members and widen or narrow their types. However, manipulating types is very tricky and can only be done depending on how members are accessed. In general, the Liskov substitution principle applies.

Subtype Requirement: Let ${\displaystyle \phi (x)}$ be a property provable about objects ${\displaystyle x}$ of type T. Then ${\displaystyle \phi (y)}$ should be true for objects ${\displaystyle y}$ of type S where S is a subtype of T.

-- Barbara Liskov and Jeannette Wing, 1994

In other words: Whatever you can do with an object typed T you should also be able to do with an object typed S, where S is a subtype of T. However, let's have a look at what is possible in TypeScript but questionable from a type safety point of view (and hence not allowed in N4JS, Java, and other languages):

class C1 {
    fieldC1: boolean = true;
}
class C2 extends C1 {
    // Liskov substitution principle violated here since type of 'fieldC1' gets narrowed
    override fieldC1: true = true; // note: 'true' is a subtype of 'boolean'
}

const c2 = new C2();
c2.fieldC1 = false; // TypeScript ERROR: Type 'false' is not assignable to type 'true'.

const c1: C1 = c2; // up-cast
c1.fieldC1 = false; // assign 'false' via supertype

console.log(c2.fieldC1) // yields print out: "false"

if (c2.fieldC1 == false) { // TypeScript ERROR: This comparison appears to be unintentional because the types 'true' and 'false' have no overlap.
    // actually this is reachable
}
  
What we see in the example above is how the Liskov substitution principle was broken for fields in TypeScript: We cannot do with c2 what we are able to do with c1, despite the fact that the type of c2 is a subtype of the type of c1. In order to preserve the Liskov substitution principle we know from languages like Java, N4JS and others, that we are neither allowed to narrow nor to widen the types of fields along the type hierarchy. This is called type invariance. In TypeScript however, covariance is allowed, that means that the type of fields can be narrowed to a subtype, like shown in the example above.


by Marcus Mews

More news

Thanks to financial support from the OpenSSF’s Alpha-Omega project, the Eclipse Foundation is glad to have made significant improvements in the last couple of months. Our previous analysis helped us prioritize work area where improvements would be the most significant. Let’s see where we are today.

Protect the branches from GitHub project

One of the main issue that has been identified by Scorecard during our previous analysis is the lack of branch protection on our repositories at GitHub. Trying to set this up manually on all of our 1000+ repositories is not scaling. We need some tooling. We’ve reviewed the tool on the market that help to manage GitHub organizations and repositories at scale, but none were complying with our requirements in terms of security, workflow, or ease of use. Also, we are a strong proponent of As Code approach. We think this principle helps tremendously in being open and transparent. The Eclipse Foundation advocates these two principles as the basis for collaborating and innovating with Open Source.

As such, we’ve started to work on our own custom solution, based on an idea from George Adams. The project is named Otterdog (because 🦦ğŸ�¶ » ğŸ�™ğŸ�±). The idea is to let an administrator define a default configuration for organizations and repositories, and encode only the difference for specific projects. It’s still in its infancy and focus currently on retrieving (at scale) the configuration from GitHub and store the variation from the default configuration.

The project relies heavily on Jsonnet for the configuration as code part, Bash script and the Github CLI tool to interact with the REST and GraphQL API, and also with Puppeteer for all settings that are not available through Github APIs.

We’ve implemented a default setting in the repository. The settings file for the Eclipse OpenJ9 organization would look like:

local orgs = import './orgs.libsonnet';
orgs.newOrg('eclipse-openj9') {
api+: {
billing_email: 'webmaster@eclipse.org',
dependabot_alerts_enabled_for_new_repositories: false,
dependabot_security_updates_enabled_for_new_repositories: false,
dependency_graph_enabled_for_new_repositories: false,
},
puppeteer+: {
'settings/discussions'+: {
discussions_enabled: false,
},
'settings/member_privileges'+: {
members_can_change_repo_visibility: true,
members_can_delete_repositories: true,
readers_can_create_discussions: true,
},
'settings/packages'+: {
packages_containers_internal: false,
packages_containers_public: false,
},
},
repositories+: [
{
default_branch: 'master',
description: "Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.",
branch_protection_rules: [
{ pattern: 'v*-release' },
{ pattern: 'master' },
{ pattern: 'jitaas' },
],
name: 'openj9',
},
{
default_branch: 'openj9',
description: "Eclipse OpenJ9's clone of the Eclipse OMR (https://github.com/eclipse/omr) project. PRs should be opened against the upstream OMR project whenever possible.",
branch_protection_rules: [
{ pattern: 'v*-release' },
{ pattern: 'openj9' },
{ pattern: 'jitaas' },
],
name: 'openj9-omr',
},
...
],
}

Apply principle of least privilege to GitHub workflows’ tokens

We’ve been contacted by StepSecurity in order to evaluate their solution that makes it easy to submit PR with fixes for some issues reported by Scorecard. We’ve been quite impressed by the ease of use of their solution:

The dashboard provides a nice overview of the repositories and their scorecard results. Their is also an histogram of the security score for all repositories in the organization which is similar to what we did manually in our previous analysis. But the killer feature for this app is the ability to automatically create pull-requests to fixes some of the issues identified by scorecards, e.g.:

• Pin Actions to a full length commit SHA
• Restrict permissions for GITHUB_TOKEN

StepSecurity also recently released a new feature that helps with properly configuring dependabot on repositories.

We have started to use StepSecurity on some of our repositories and we are very satisfied of the results. A couple of missing features from the early days have already been implemented: previewing the pull-request before opening it, the ability to customize the PR comment… We will now use this across all our organization and repositories and will have a second run of full analysis to watch how our scorecard results improved.

SLSA badging program

Projects at Eclipse Foundation can now declare their SLSA compliance level on their Project Management Infrastructure (PMI) page. Next improvement will help projects with specifying how to comply with requirements for each level.

Some projects already have the SLSA compliance process well underway. Eclipse Temurin (part of Adoptium), for example, just recently completed the work necessary to reach level 2 SLSA compliance, and is working on achieving level 3.

Revise vulnerability reporting practices

An RFC has been published and socialized with the security team and the architecture council, proposing several changes and improvements to the vulnerability disclosure processes at the Eclipse Foundation. The RFC also outlines how to leverage tooling at gitlab.eclipse.org and github.com in order for projects to receive vulnerability reports in confidential channels and to work on security fixes under embargo.

Eclipse Californium and Eclipse Oniro have started to experiment with this tooling on github.com and gitlab.eclipse.org respectively.

Improve security of marketplace.eclipse.org

The Eclipse Marketplace is a successful service that serves more than 12 millions API requests per month. In an effort to better protect its users, we’ve started to enforce the use of HTTPS for all contents linked by the Eclipse Marketplace on October 14th, 2022. The Eclipse Marketplace does not host the content of the provided solutions, it only provides links to them. We are actively working with owners of existing solutions with plain HTTP entries to fix them. Beginning December 15th, non-compliant solutions will be unpublished from the Eclipse Marketplace. This effort can be followed on the tracking issue.

Public presentations

We’ve been busy presenting why securing the supply chain of open source software is important what we do at the Eclipse Foundation to help our projects do that:

• EclipseCon 2022: Open Source Software Supply Chain Security — Why does it matter? (slides, video recording)
• Open Source Experience: Open Source Software Supply Chain Security — Why does it matter? (video upcoming)
• Open CIO Summit: Les communautés open source et les enjeux autour du Secure & Green By Design (video upcoming)

We’re hiring!

We’ve still plenty to do:

• we are conducting code audits with OSTIF for a couple of our projects,
• we will soon start a campaign to promote the usage of Two-Factors Authentication to our committers,
• leverage our ORT setup and the SBOM it generates to help our projects publish a SBOM with their releases;
• implement a digital signature infrastructure for all Eclipse Foundation projects (best candidate for that is Sigstore).
• … and many other things

To do that, we are growing the team. We currently have 3 openings:

• Open Source Software Engineer
• Java/Go/Rust Software Engineer for Security Tooling
• SecOps Engineer

If you’re interested in the topic of Software Supply Chain security and would like to actively participate in securing the 420+ projects developed at the Eclipse Foundation, you should consider applying!

Open Source Software Supply Chain is at risk: threat actors are shifting target to amplify the blast radius of their attacks and as such increasing their return on investment. Over the past 3 years, we’ve witnessed an astonishing 742% average annual increase in Software Supply Chain attacks. To make it worse, the attack surface of the supply chain is wide. Covering it all requires a deep scrutinity of many factors. However, there is a simple thing, easy, and free, that every open source developer should do right now: activate multi factor authentication (also known as two factor authentication) on all development related accounts.

At the origin of any software, there is code written by developers. In the case of open source software, this code published on a publicly accessible code repository. The permission to write to these repositories is protected by the authentication system of the hosting platforms. By default, for most of them, it means basic password-based authentication. Simple and convenient, password-based authentication is also very fragile. It can be attacked by social engineering, credential theft or leakage, and many other low cost attacks to get access to developer accounts.

Compromised accounts can then be used to push malicious changes to code they have access to. The risk is of course for the developer associated with the compromised account, but all downstream users of the affected code are also at risk. It can be code from other developers that depends on the infected code, but also users of products that may now run malicious code that will be used for more credentials theft and reach an even larger number of targets.

As such, it is the responsibility for every Open Source developer to diligently protect their accounts. The very first line of defense is to move beyond basic password-based authentication and to activate two factor authentication (2FA). This is no silver bullet, and there are ways to compromise 2FA-protected accounts. But it is the most cost-effective solution to protect an account: attacking an account protected by 2FA is several orders of magnitude more complex than targeting an account using basic password-based authentication.

If you’re an Open Source software developer, I encourage you to activate 2FA today, on all platforms where it’s available. See below links to documentation how to activate 2FA for code under the stewarship of the Eclipse Foundation:

• For projects hosted at GitHub
• For projects hosted at gitlab.eclipse.org

If you are willing to make 2FA mandatory for all committers on your project, feel free to open a ticket at our help desk, and we will work with you to make it happen.

See also: Software security starts with the developer: Securing developer accounts with 2FA from https://github.blog.

On behalf of the Eclipse JKube team and everyone who has contributed, I'm happy to announce that Eclipse JKube 1.10.1 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:

• Introducing Eclipse JKube Remote Development (Preview)
• Automatic Health Check configuration for projects using SmallRye Health
• Improved support for Podman
• Updated base images
• ğŸ�› Many other bug-fixes and minor improvements

Eclipse JKube Remote Development (Preview)

The new Kubernetes remote development feature provided by Eclipse JKube allows you to run and debug your Java applications from your local machine while connected to your Kubernetes cluster. It's essentially like placing your local development machine inside your cluster. This means that you will be able to:

• Consume services that are only available in your cluster
• Expose your locally running application to the rest of the Pods and services running in your cluster

The following diagram shows the topology of a distributed application as deployed in a Kubernetes cluster:

Considering that Pod A is a Java application you are working on, by starting an Eclipse JKube remote development session, the topology will be updated as in the next diagram:

Users accessing Ingress A and Service A, will now receive traffic from your local machine instead of Pod A. In addition, your local machine will be able to access Service B and Service C since those services will be available at local ports in your system.

To be able to use the new feature, you'll only need to provide a minimal configuration:

<plugin>
  <groupId>org.eclipse.jkube</groupId>
  <artifactId>kubernetes-maven-plugin</artifactId>
  <configuration>
    <remoteDevelopment>
      <localServices>
        <localService>
          <serviceName>my-local-service</serviceName>
          <port>8080</port>
        </localService>
      </localServices>
      <remoteServices>
        <remoteService>
          <hostname>postgresql</hostname>
          <port>5432</port>
        </remoteService>
      </remoteServices>
    </remoteDevelopment>
  </configuration>
</plugin>