Skip to main content

Xtext 2.18 – released!

by Sebastian Zarnekow (sebastian.zarnekow@itemis.de) at June 18, 2019 10:31 AM

The team around project lead Christian Dietrich has released version 2.18 of Xtext and Xtend. This version is also the one that enters the Eclipse release train number 2019-06, departing on time at June 19th.

More than 40 helping hands have made this Xtext release possible over the last quarter. A big shout-out especially to the first-time contributors! We are thankful for every reported issue, comment to a discussion, and proposed patch.

Even though the main focus was on stability and robustness, a couple of new features have been made available, too.

 

Playing catch-up with Java

Xtend eventually learned to understand the ternary expression and got support for try-with-resources. While the former is just expressing a matter of taste, being able to efficiently deal with closable resources is a big win. Forgetting to close a stream or a connection is just a little harder when you can benefit from the compiler auto-closing the thing. This is also available in legacy scenarios where code is still required to run on ancient Java versions.

Both features were implemented by Eva Poell, intern for 6 weeks at our Berlin office. We are thankful for her great work!

Improved “find references” view

When exploring a code base, software engineers navigate back and forth through the source, especially between references and declarations. If you want to take notes on the usage of a DSL concept, you can copy it directly from the “search results” page. Also, if you only want to deal with a subset of the results, it’s now possible to remove matches from the view.

 

Improved Find References View

New quick fixes for the Xtext grammar

The Xtext grammar editor received some love in this release cycle, too. The validation problems around invalid empty keywords can be automatically fixed from now on. Either a reasonable default is inserted, or the keyword is removed – it’s your call.

Xtext Grammar Editor

Rename refactoring

Long-running rename operations can now be cancelled by the user. Instead of waiting for the computation to finish and reverting the outcome, accidentally triggered renames are no longer a painful experience.

Rename class quick fix

Talking about renames: Even though Xtend allows to define as many public types per file as you want, it is a common usage pattern to have a single top-level class per file. If names get out of sync because of a change of mind, a quick fix is offered to align the two of them. If you decide to rename the type, a proper rename operation is triggered, and all the references are updated along with the declaration.

Language server fixes

The Xtext support for the Language Server Protocol has been improved in different areas. Extension implementations do now have access to the indexed resources, and the reporting of build results was fixed. Formerly, some notifications may have got lost such that the editors did not get any events about completed builds. The communication in the other direction was fixed, too. Sometimes the server did miss a couple of changed resources, thus its index information diverged from the code on disk.

Eclipse robustness

A few rarely-occurring issues around the startup of Eclipse and the processing of deleted projects have been fixed. It did not happen often, but if you were bitten by that bug, it was rather annoying. These issues have been resolved.

Your turn

The team is proud of the achievements in this release cycle. But we are also eager to know what your thoughts on this are. If you are missing a certain feature or do have suggestions how to improve Xtext or Xtend, just drop us a note and we are happy to discuss your ideas.

by Sebastian Zarnekow (sebastian.zarnekow@itemis.de) at June 18, 2019 10:31 AM

JCP Copyright Licensing request

by Tanja Obradovic at June 17, 2019 06:20 PM

The open source community has welcomed Oracle’s contribution of Java EE into Eclipse Foundation, under the new name Jakarta EE. As part of this huge effort and transfer, we want to ensure that we have the necessary rights so we can evolve the specifications under the new  Jakarta EE Specification Process. For this, we need your help!

We must request copyright licenses from all past contributors to Java EE specifications under the JCP. Hence, we are reaching out to all companies and individuals who made contributions to Java EE in the past to help out, execute the agreements and return them back to Eclipse Foundation. As the advancement of the specifications and the technology is in question, we would greatly appreciate your prompt response. Oracle, Red Hat, IBM, and many others in the community have already signed an agreement to license their contributions to Java EE specifications to the Eclipse Foundation. We are also counting on the JCP community to be supportive of this request.

The request is for JCP contributors to Java EE specifications, once you receive an email from the Eclipse Foundation regarding this, please get back to us as soon as you can!

Should you have any questions regarding the request for copyright licenses from all past contributors, please contact mariateresa.delgado@eclipse-foundation.org who is leading us all through this process.

Many thanks!


by Tanja Obradovic at June 17, 2019 06:20 PM

Eclipse Individual Committer Agreement 4.0 Update

June 17, 2019 02:05 PM

On June 13th, we retired all versions of the Eclipse Individual Committer Agreement (ICA) prior to version 4.0. Update yours today!

June 17, 2019 02:05 PM

Eclipse Introduces New IDE-Agnostic Tools for Building and Deploying Cloud-Native Applications

by Dustin Schultz at June 17, 2019 05:35 AM

Eclipse Codewind is a new developer-centric project from the Eclipse Foundation that aims to assist developers by providing ways to quickly and consistently accomplish tasks that are common to cloud-native application development.

By Dustin Schultz

by Dustin Schultz at June 17, 2019 05:35 AM

My new book on TDD, Build Automation and Continuous Integration

by Lorenzo Bettini at June 12, 2019 04:59 PM

I haven’t been blogging for some time now. I’m getting back to blogging by announcing my new book on TDD (Test-Driven Development), Build Automation and Continuous Integration.

The title is indeed, “Test-Driven Development, Build Automation, Continuous Integration
(with Java, Eclipse and friends)
” and can be bought from https://leanpub.com/tdd-buildautomation-ci.

The main goal of the book is to get you started with Test-Driven Development (write tests before the code), Build Automation (make the overall process of compilation and testing automatic with Maven) and Continuous Integration (commit changes and a server will perform the whole build of your code). Using Java, Eclipse and their ecosystems.

The main subject of this book is software testing. The main premise is that testing is a crucial part of software development. You need to make sure that the software you write behaves correctly. You can manually test your software. However, manual tests require lots of manual work and it is error prone.

On the contrary, this book focuses on automated tests, which can be done at several levels. In the book we will see a few types of tests, starting from those that test a single component in isolation to those that test the entire application. We will also deal with tests in the presence of a database and with tests that verify the correct behavior of the graphical user interface.

In particular, we will describe and apply the Test-Driven Development methodology, writing tests before the actual code.

Throughout the book we will use Java as the main programming language. We use Eclipse as the IDE. Both Java and Eclipse have a huge ecosystem of “friends”, that is, frameworks, tools and plugins. Many of them are related to automated tests and perfectly fit the goals of the book. We will use JUnit throughout the book as the main Java testing framework.

it is also important to be able to completely automate the build process. In fact, another relevant subject of the book is Build Automation. We will use one of the mainstream tools for build automation in the Java world, Maven.

We will use Git as the Version Control System and GitHub as the hosting service for our Git repositories. We will then connect our code hosted on GitHub with a cloud platform for Continuous Integration. In particular, we will use Travis CI. With the Continuous Integration process, we will implement a workflow where each time we commit a change in our Git repository, the CI server will automatically run the automated build process, compiling all the code, running all the tests and possibly create additional reports concerning the quality of our code and of our tests.

The code quality of tests can be measured in terms of a few metrics using code coverage and mutation testing. Other metrics are based on static analysis mechanisms, inspecting the code in search of bugs, code smells and vulnerabilities. For such a static analysis we will use SonarQube and its free cloud version SonarCloud.

When we need our application to connect to a service like a database, we will use Docker a virtualization program, based on containers, that is much more lightweight than standard virtual machines. Docker will allow us to

configure the needed services in advance, once and for all, so that the services running in the containers will take part in the reproducibility of the whole build infrastructure. The same configuration of the services will be used in our development environment, during build automation and in the CI server.

Most of the chapters have a “tutorial” nature. Besides a few general explanations of the main concepts, the chapters will show lots of code. It should be straightforward to follow the chapters and write the code to reproduce the examples. All the sources of the examples are available on GitHub.

The main goal of the book is to give the basic concepts of the techniques and tools for testing, build automation and continuous integration. Of course, the descriptions of these concepts you find in this book are far from being exhaustive. However, you should get enough information to get started with all the presented techniques and tools.

I hope you enjoy the book 🙂


by Lorenzo Bettini at June 12, 2019 04:59 PM

JBoss Tools 4.12.0.AM1 for Eclipse 2019-06

by jeffmaury at June 12, 2019 11:05 AM

Happy to announce 4.12.0.AM1 (Developer Milestone 1) build for Eclipse 2019-06.

Downloads available at JBoss Tools 4.12.0 AM1.

What is New?

Full info is at this page. Some highlights are below.

Server Tools

Wildfly 17 Server Adapter

A server adapter has been added to work with Wildfly 17. It adds support for Java EE 8.

Enjoy!

Jeff Maury


by jeffmaury at June 12, 2019 11:05 AM

Eclipse Tycho: Disable p2 dependency resolution with tycho.mode=maven

by kthoms at June 12, 2019 01:31 AM

In Eclipse Tycho based builds the first step is always computation of the target platform and depedency resolution. This takes quite some time and in certain use cases it is not necessary. Typical use cases are updating versions with the tycho-versions-plugin, or displaying the effective pom with help:effective-pom.

The p2 target platform & dependency resolution can be skipped by setting the tycho-mode system property:

mvn -Dtycho.mode=maven <goals>

This useful feature is a bit hidden in just a few posts, e.g. https://www.eclipse.org/lists/tycho-user/msg06439.html.


by kthoms at June 12, 2019 01:31 AM

2019 Annual Eclipse Foundation Community Report

June 11, 2019 06:05 PM

Read the eighth annual Eclipse Foundation Community Report! Comments and feedback on the style and content are welcome!

June 11, 2019 06:05 PM

Welcome Shabnam!

by Thabang Mashologu at June 05, 2019 09:13 AM

I am happy to announce that Shabnam Mayel has joined the Eclipse Foundation as a Senior Marketing Lead, Cloud Native Java. 

Shabnam brings with her several years of diverse marketing, business development, and technical sales experience. Most recently, she led marketing and brand management initiatives for tech startups in Southeast Asia. She holds an electronics engineering degree, an MBA and a Ph.D. in management. She is based in Toronto.

Shabnam will be responsible for developing and implementing global marketing programs to grow the awareness of and participation in Jakarta EE, Eclipse MicroProfile, and other Foundation projects in the cloud native application space.

Please join me in welcoming Shabnam to the Eclipse community!


by Thabang Mashologu at June 05, 2019 09:13 AM

Jakarta Newsletter May 2019: Onwards and Upwards for the Jakarta Community

June 04, 2019 01:15 PM

The elected positions are to represent each of the Enterprise Members, Participant Members, and Committer Members.

June 04, 2019 01:15 PM

Integration Tooling for Eclipse 2019-03

by pleacu at June 03, 2019 08:03 AM

Check out our new branding for Eclipse 2019-03. We’re now Red Hat CodeReady Studio 12 Integration Stack.

crstudio12

JBoss Tools Integration Stack 4.11.0.Final / Red Hat CodeReady Studio Integration Stack 12.11.0.GA

All of the Integration Stack components have been verified to work with the same dependencies as JBoss Tools 4.11 and Red Hat CodeReady Studio 12.

What’s new for this release?

DataVirtualization support from Teiid Designer is no longer available through the Integration Stack. It can be installed directly from Teiid Designer

This release has an updated BPMN2 Modeler and jBPM/Drools/KIE.

Released Tooling Highlights

Business Process and Rules Development

BPMN2 Modeler Known Issues

See the BPMN2 1.5.1.Final Known Issues Section of the Integration Stack 12.11.0.GA release notes.

Drools/jBPM6 Known Issues

See the Drools 7.21.0.Final Known Issues Section of the Integration Stack 12.11.0.GA release notes.

What’s an Integration Stack?

Red Hat CodeReady Studio Integration Stack is a set of Eclipse-based development tools. It further enhances the IDE functionality provided by Developer Studio, with plug-ins specifically for use when developing for other Red Hat products. It’s where BRMS tooling is aggregated. The following frameworks are supported:

Red Hat Business Process and Rules Development

Business Process and Rules Development plug-ins provide design, debug and testing tooling for developing business processes for Red Hat BRMS and Red Hat BPM Suite.

  • BPEL Designer - Orchestrating your business processes.

  • BPMN2 Modeler - A graphical modeling tool which allows creation and editing of Business Process Modeling Notation diagrams using graphiti.

  • Drools - A Business Logic integration Platform which provides a unified and integrated platform for Rules, Workflow and Event Processing including KIE.

  • jBPM - A flexible Business Process Management (BPM) suite.

The JBoss Tools website features tab

Don’t miss the Features tab for up to date information on your favorite Integration Stack components.

Installation

The easiest way to install the Integration Stack components is through the stand-alone installer or through our JBoss Tools Download Site.

For a complete set of Integration Stack installation instructions, see Integration Stack Installation Guide

Let us know how it goes!

Paul Leacu.


by pleacu at June 03, 2019 08:03 AM

Getting Started with Papyrus UMLLight

by tevirselrahc at June 03, 2019 08:00 AM

Well… It took some time but there is finally a tutorial for Papyrus UMLLight!

This tutorial was developed within the Papyrus UMLLight wiki, so it is available online .

It covers the audience we targeted for this tool, how Papyrus UMLLight is both different and similar to Papyrus , and provides exercises to show its capabilities.

And yes, you can comment about it (on its discussion page)

And now to start work on the musical! 😉


by tevirselrahc at June 03, 2019 08:00 AM

VS Code Vert.x Starter Extension

by danielpetisme at May 29, 2019 12:00 AM

Hi Vert.x community! Today, we are really excited to announce the Visual Studio Code Vert.x Starter extension.

The extension is a community contribution made by Daniel Petisme (@danielpetisme).

VSCode Vert.x Starter extension

Click on the image to watch the video on YouTube

Usage

Visual Studio Code is a popular code editor with a lot of additional extensions.

Visual Studio Code Vert.x Starter extension allows your to:

  • Create a Vert.x project
  • Customize the creation (Vert.x version, language, build tool, groupId, artifactId, package name, JDK version)
  • Search for dependencies

The extension can be configured to match your context (e.g. defining your default company groupId).

How it works

Behind the scene, the extension relies on the Vert.x application generator API and demonstrate how easy it is to develop your own IDE plugin or custom tooling to generate Vert.x projects. For further details about the start.vertx.io API, please refer to the Vert.x Starter project on GitHub.

Questions?

Feel free to ask questions or propose new features on the VSCode Vert.x Starter GitHub repository.


by danielpetisme at May 29, 2019 12:00 AM

EclipseCon Europe 2019: Call for Papers open until July 15 - Submit a talk today!

May 28, 2019 04:15 PM

Submit your proposals to be part of ECE's 2019 speaker lineup. The conference is in Ludwigsburg, Germany Oct 21-24, 2019

May 28, 2019 04:15 PM

Election time for Jakarta EE Working Group Committees!

May 28, 2019 04:15 PM

The elected positions are to represent each of the Enterprise Members, Participant Members, and Committer Members.

May 28, 2019 04:15 PM

Graduating from Minimal to Rich Java APIs

by Donald Raab at May 28, 2019 03:35 AM

Combining ease of learning with reduced code duplication for greater productivity.

Happy Birthday Java!

Happy Birthday Java

Java turned 24 years old on May 23rd, 2019. This is an impressive amount of time for a programming language to be successful and to continue growing its developer community. Java continues to evolve, and the Java Community continues to innovate and grow.

Up until Java 8 (released in 2014), Java has more or less adhered to a minimal API design philosophy. This has worked out extremely well for Java, as a minimal API design tends to lower the initial learning curve and increase adoption by only requiring developers to learn a few basic concepts.

Minimal API Design of Collections

The Collection interface has been available in Java since December 1998 when Java 2 was released. Collection has several mutating APIs including add, addAll, remove, removeAll, retainAll and clear. There are several testing methods including contains, containsAll, isEmpty and size. Every Collection can return its contents using the method toArray. The method iterator allows for any iteration pattern to be implemented using a for loop or while loop. In March 2014, Java 8 was released and the Stream interface was added with built-in iteration patterns (e.g. filter, map, reduce). The Collection interface was updated to include new default methods including the forEach, stream and parallelStream methods.

Collection API (1998), and Stream API (2014), with new default methods added on Collection

Graduating to higher-level APIs

As a programming language matures and enjoys mass adoption, it becomes important to address the needs of a more experienced developer population and to remain competitive with newer more nimble programming languages that may not be as concerned with preserving backwards compatibility between versions. The Java developer population (estimates around 12 million now) is already very familiar with the Java Collections APIs that have been available for over 20 years. Java is a great general purpose programming language, and gives developers the basic tools they need to create great applications. Since Java 8 was released, Java has started introducing higher-level APIs, especially in the Collections space. The Stream API which was added in Java 8 adds functional APIs to the existing Collection interfaces.

The List interface has also had a few new default methods added since Java 8. For example, we finally have a sort method available directly on List. Developers have been using the Collections class to sort instances of List since Java 2. Here is what the List interface looks like since Java 8.

List interface (December 1998) with default methods added (March 2014)

Most of the new functionality provided in Java 8 for Collection and List is available by calling the stream method, and then calling an appropriate method available on the Stream interface. The behaviors available on Stream interface are further extended by the collect method which can be passed a Collector. The method named collect on Stream is often described as a mutable reduction. There are a stock set of Collector implementations available on the Collectors class included since Java 8. Eclipse Collections adds its own set of Collector implementations in its Collectors2 class.

If we combine all of the functionality available in the List, Stream and Collectors class, you will see an evolution from the minimal API design of old, to a new richer API design.

Combining the List, Stream and Collectors APIs

Compare the combination API of List, Stream and Collectors with the existing rich API design in the Eclipse Collections MutableList class, and you will begin to see some common patterns between them (sometimes with different names). These patterns are not new. They have been known and available for a very long time in different programming languages, but are now being discovered and learned by the Java developer community.

MutableList methods in Eclipse Collections

Higher-level APIs help developers address a fundamental problem that minimal APIs can help create — Code Duplication. As you can see in the Eclipse Collections MutableList interface, there are a large number of iteration patterns that were not included in the original minimal API design of the Java List interface. Because these iteration patterns were not provided in higher-level Java APIs along with the language, developers were required to implement these patterns on their own using the basic building blocks of iterator and indexed list access.

See my previous blog on Code Duplication to learn more about iteration patterns.

Advanced Learning vs. Basic Duplication

Proponents of minimal API design will usually argue that a minimal API is easier to learn. This is true. If you believe that all you need to write code with Collections is an iterator and a for loop, you are correct. However, if all you have is an iterator, you will have to iterate the same patterns over and over again (Hammer, meet nail). More importantly, you will be leaving duplicate code for future readers to have to read.

The more code you have to write, the more code others have to read.

A Minimal API design results in more code having to be written, tested and maintained by application developers. A Rich API design results in more code having to be written, tested and maintained by library developers. If we all had shared code ownership over all the code written in the world, we would probably agree the least costly alternative would be to lean on library and language developers when appropriate to provide rich APIs for developers to use.

Once you know the basics, learning more advanced concepts is a good thing

Minimal API design has served its purpose well for the first 24 years of Java. It has led to mass adoption the Java programming language. Java developers have learned the basic patterns of using iterators, and are ready and willing to learn and graduate to using higher-level APIs.

Too Minimal == Anemic && Too Rich == Bloated

It is both possible to have too little or too much API. Somewhere in the middle, an API will feel “Just Right”. Java complicates this goal for API designers by having support of both Object and primitive types.

Eclipse Collections provides as much interoperability as possible between Object and primitive types in Java. This results sometimes in a multiplicative effect in the number of APIs required. For example, the collect and sort methods on MutableList all have primitive versions for each of the primitive types. If we reduce the total number methods down to the number of total core concepts, the number of new concepts a developer has to learn is more reasonable. For instance, if you learn the collect pattern in Eclipse Collections, which is a core concept, you will already know how all of the collect* (e.g. collectInt, collectShort, etc.) methods work.

In the following picture, I’ve included only the core conceptual API of MutableList. I have dropped all “With” methods and all of the primitive methods except for “Int”. This removed around 40 methods total from the output.

MutableList Core Concepts

It is enough to know how one primitive method works in order to understand how all of the other primitive methods work. If the developers of an API have Symmetric Sympathy, you will be able to easily understand and use each core API concept everywhere it is provided.

The evolution of Java Date and Time

Another example of an evolutionary change from a minimal API to a Rich API is in the Java Time library. Compare the methods on the Date class and LocalDate class available since Java 8.

Date compared to LocalDate

The Java time library has a much more humane API for dealing with dates and time. It does a great job balancing richness and minimalism.

The source of the source

The following source code was used to output all of the above APIs. You can use it output any methods of any classes you want. Try changing the Function for the grouping to get a different view into an API.

public void outputMethodsByFirstLetter(Class<?>... classes)
{
Function<Method, Character> firstLetter =
method -> Character.valueOf(method.getName().charAt(0));

String classNamesString =
ArrayIterate.collect(classes, Class::getSimpleName)
.makeString();

System.out.println(
classNamesString);
System.out.println(
StringIterate.repeat('-', classNamesString.length()));

MutableList<Method> methods =
ArrayIterate.flatCollect(
classes,
each -> ArrayAdapter.adapt(each.getMethods()));

String output = methods.groupBy(firstLetter)
.collectValues(
Method::getName,
TreeSortedSetMultimap.newMultimap())
.keyMultiValuePairsView()
.toSortedListBy(Pair::getOne)
.makeString("\n");

System.out.println(output);
System.out.println();
}

Update: June 3, 2019

The following source will show you the symmetric difference and intersection of two APIs. Just change the two classes you want to compare in the first method.

@Test
public void symmetricDifferenceAndIntersectionOfApis()
{
this.symmetricDiffAndIntersectionOfApis(Collectors.class, Collectors2.class);
}

public void symmetricDiffAndIntersectionOfApis(Class<?> classOne, Class<?> classTwo)
{
MutableSet<String> leftMethods =
Sets.mutable.with(classOne.getMethods())
.collect(this::methodNamePlusParms);
MutableSet<String> rightMethods =
Sets.mutable.with(classTwo.getMethods())
.collect(this::methodNamePlusParms);

String classNames = classOne.getSimpleName() +
", " +
classTwo.getSimpleName();
this.symmetricDifference(leftMethods, rightMethods, classNames);
this.intersection(leftMethods, rightMethods, classNames);
}

private String methodNamePlusParms(Method method)
{
return method.getName() + "(" +
ArrayIterate.collect(method.getParameters(), Parameter::getType)
.collect(Class::getSimpleName)
.makeString() + ")";
}

private void symmetricDifference(
MutableSet<String> leftMethods,
MutableSet<String> rightMethods,
String classNames)
{
System.out.println("Symmetric Difference (" + classNames + ")");
System.out.println(
StringIterate.repeat('-',
("Symmetric Difference (" + classNames + ")")
.length()));
this.outputGroupByToString(leftMethods.symmetricDifference(rightMethods));
}

private void intersection(
MutableSet<String> leftMethods,
MutableSet<String> rightMethods,
String classNames)
{
System.out.println("Intersection (" + classNames + ")");
System.out.println(
StringIterate.repeat('-',
("Intersection (" + classNames + ")")
.length()));
this.outputGroupByToString(leftMethods.intersect(rightMethods));
}

private void outputGroupByToString(RichIterable<String> methods)
{
Function<String, Character> firstLetter = string -> Character.valueOf(string.charAt(0));

String output = methods.groupBy(firstLetter)
.collectValues(
each -> each,
TreeSortedSetMultimap.newMultimap())
.keyMultiValuePairsView()
.toSortedListBy(Pair::getOne)
.makeString("\n");

System.out.println(output);
System.out.println();
}

Update: June 5, 2019

I refactored the code for calculating the symmetric difference and intersection to use MutableSortedSet instead of MutableSet.

@Test
public void symmetricDifferenceAndIntersectionOfApis()
{
this.symmetricDiffAndIntersectionOfApis(
Tuples.twin(StringBuffer.class,
StringBuilder.class));
}

private void symmetricDiffAndIntersectionOfApis(Twin<Class<?>> classPair)
{
MutableSortedSet<String> leftMethods =
this.getMethodNames(classPair.getOne());
MutableSortedSet<String> rightMethods =
this.getMethodNames(classPair.getTwo());

this.output(classPair, "Symmetric Difference",
leftMethods.symmetricDifference(rightMethods));
this.output(classPair, "Intersection",
leftMethods.intersect(rightMethods));
}

private void output(Twin<Class<?>> classPair,
String operation,
RichIterable<String> strings)
{
this.outputTitle(operation + " (" + this.classNames(classPair) + ")");
this.outputGroupByToString(strings);
}

private String classNames(Twin<Class<?>> classPair)
{
return classPair.getOne().getSimpleName() +
", " +
classPair.getTwo().getSimpleName();
}

private MutableSortedSet<String> getMethodNames(Class<?> classOne)
{
return ArrayIterate.collect(
classOne.getMethods(),
this::methodNamePlusParms,
SortedSets.mutable.empty());
}

private String methodNamePlusParms(Method method)
{
return method.getName() + "(" + this.parameterNames(method) + ")";
}

private String parameterNames(Method method)
{
return ArrayIterate.collect(
method.getParameters(),
parm -> parm.getType().getSimpleName())
.makeString();
}

private void outputTitle(String title)
{
System.out.println(title);
System.out.println(
StringIterate.repeat('-', (title).length()));
}

private void outputGroupByToString(RichIterable<String> methods)
{
String output = methods.groupBy(string -> string.charAt(0))
.keyMultiValuePairsView()
.toSortedListBy(Pair::getOne)
.makeString("\n");

System.out.println(output);
System.out.println();
}

Learn something new every day

Some developers may find a comprehensive API like Eclipse Collections intimidating. The good news is that with Eclipse Collections, you can learn and use the API at your own pace. For instance, MutableList extends java.util.List, so if you are familiar with the List API in Java, you are already familiar with the basics of the MutableList API in Eclipse Collections. If you have already been investing in learning Java Streams and Collectors, you can use these concepts with Eclipse Collections types as well. There are also more convenient eager methods directly on the collection types like MutableList themselves. If some of the different method names in Eclipse Collections seem strange, don’t worry there is a blog that can help you translate from Streams method names to Eclipse Collections method names.

Learning new things like iteration patterns will help you become a better developer in any language you program in. Over the years, I have learned and experimented with iteration pattern APIs in Smalltalk, Ruby, Scala, Groovy, Haskell, Clojure, Python and JavaScript. I’ve also written katas comparing five different Java Collections Frameworks. This makes it easier for me to travel between any of these languages and libraries when dealing with collections.

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.


Graduating from Minimal to Rich Java APIs was originally published in Oracle Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.


by Donald Raab at May 28, 2019 03:35 AM

Statement by the Eclipse Foundation on Huawei Entity List Ruling

May 27, 2019 02:15 PM

Open Source projects involving encryption software source code are still required to send a notice of the URL to BIS and NSA to satisfy the "publicly available" notice requirement in EAR § 742.15(b)

May 27, 2019 02:15 PM

Industry leaders Red Hat, Eurotech, and Cloudera join forces at the Eclipse Foundation

May 27, 2019 01:45 PM

Industry leaders Red Hat, Eurotech and Cloudera turned to the Eclipse IoT Working Group to overcome common challenges and provide their customers with an end-to-end IoT solution.

May 27, 2019 01:45 PM

Eclipse Vert.x 3.7.1

by vietj at May 27, 2019 12:00 AM

We have just released Vert.x 3.7.1, a bug fix release of Vert.x 3.7.x and a few small features.

Since the release of Vert.x 3.7.0, quite a few bugs have been reported. We would like to thank you all for reporting these issues.

In addition of bug fixes, this release prepares the ground for Vert.x 4 with a few enhancements and deprecations.

HTTP client Unix Domain Sockets

Since this release the HttpClient supports Unix Domain Sockets when using Netty’s native transports, which can be really useful if you need to connect to a local daemon such as Docker’s Daemon:

HttpClient httpClient = vertx.createHttpClient();

// Only available on BSD and Linux with native transport
SocketAddress addr = SocketAddress.domainSocketAddress("/var/tmp/myservice.sock");

// Send request to the server
httpClient.request(HttpMethod.GET, addr, 8080, "localhost", "/", resp -> {
  // Process response
}).end();

HTTP client WebSocket connect revisited

The HttpClient WebSocket methods have been revisited, indeed these methods were lacking of usability in general or with vertx-rx due to the optional error handling:

HttpClient client = vertx.createHttpClient();
client.websocket(80, "example.com", "/", websocket -> {
  // connected
});

// or

client.websocket(80, "example.com", "/", websocket -> {
  // connected
}, err -> {
  // handle error
});

The new webSocket method provides now the best developer experience for connecting a WebSocket:

HttpClient client = vertx.createHttpClient();
client.webSocket(80, "example.com", "/", ar -> {
  if (ar.succeeded()) {
    // connected
  } else {
    // handler error
  }
});

With RxJava2, you can use now:

HttpClient client = vertx.createHttpClient();
Single single = client.rxWebSocket(80, "example.com", "/");
single.subscribe(
  ws -> {
    // connected
  },
  err -> {
    // handle error
  });

Vert.x Rx usability improvements

As you may know, the Vert.x Rxified API is generated from the bare Vert.x API.

In this release, vertx-codegen has been improved to determine if an API object is an Iterable, Iterator, or Function. Then its Rxified equivalent will be an Iterable, Iterator, or Function too.

Let’s take an example. The Vert.x MultiMap class represents a multi-map of String keys to a list of String values. It’s useful to represent things like HTTP headers and parameters which allow multiple values for keys.

Since the bare io.vertx.core.MultiMap implements Iterable>, you can iterate through the content with a for-each loop. Starting with 3.7.1, the same is possible with the Rxified version:

io.vertx.reactivex.core.MultiMap headers = request.headers();
for (Entry header : headers) {
  // inspect header  
}

Or, for advanced transformations:

Flowable> headers = Flowable.fromIterable(request.headers());

GraphiQL IDE

Vert.x 3.7.0 added support for building GraphQL servers with Vert.x Web and GraphQL-Java.

In 3.7.1, the GraphQL handler can be configured to expose the GraphiQL IDE:

GraphQLHandlerOptions options = new GraphQLHandlerOptions()
  .setGraphiQLOptions(new GraphiQLOptions()
    .setEnabled(true)
  );

router.route("/graphql").handler(GraphQLHandler.create(graphQL, options));

Vert.x 3.8.0 is the next release

The next version of Vert.x will be 3.8 and targets end of June / early July with the following themes:

  • Introducing a Promise interface to be used instead of Future in a couple of places of the codebase such as Verticle start or executeBlocking. The goal is to move the completion part in Vert.x 4 from Future to Promise which becomes the object to be completed and Future is a view that is consumed by clients
  • Json Pointer support
  • The new SQL client will be released as tech preview (until v4)
  • RedisPool as tech preview (until v4) bring back connection management, lazy reconnect and scaling to all client modes (Single, Sentinel and Cluster)

Vert.x 3.7.1 release notes

Vert.x 3.7.1 deprecations and breaking changes

https://github.com/vert-x3/wiki/wiki/3.7.1-Deprecations-and-breaking-changes

The event bus client using the SockJS bridge are available from NPM, Bower and as a WebJar:

Docker images are also available on the Docker Hub. The Vert.x distribution is also available from SDKMan and HomeBrew.

The artifacts have been deployed to Maven Central and you can get the distribution on Bintray.

Happy coding and see you soon on our user or dev channels.


by vietj at May 27, 2019 12:00 AM

Inline Display of Error / Warning / Info Annotations in Eclipse

by Niko Stotz at May 26, 2019 10:11 PM

tl;dr: A prototype implementation shows all error, warning, and info annotations (“bubbles” in the left ruler) in Eclipse Java editor as inline text. Thus, we don’t have to use the mouse to view the error message. The error messages update live with changes in the editor.

Screencast showing the live effect

I’m an avid keyboard user. If I have to touch the mouse, something is wrong. Eclise has tons of shortcuts to ease your live, and I use and enjoy them every day.

However, if I had an error message in e.g. my Java file, and I couldn’t anticipate the error, I had several bad choices:

  • Opening the Problems view and navigating to the current error (entries in the Problems view are called “markers” by Eclipse)
  • Moving the mouse over the annotation in the left ruler (“annotation” in Eclipse lingo)
  • Guessing

Not so long ago, Angelo Zerr and others implemented code mining in Eclipse. This feature displays additional information within a text file without changing the actual contents of the file. Sounds like a natural fit for my problem!

I first tried to implement the error code mining based on markers, (Bug 540443). This works in general. However, markers are bound to the persisted state of a file, i.e. how a file is saved to disk. So they are only updated on saving.

Most editors in Eclipse are more interactive than that: They update their error information based on the dirty state of the editor, i.e. the text that’s currently in the editor. This feels way more natural, so I tried to rewrite my error code mining based on annotations. The current prototype is shown in above’s screencast.

The code is attached to Bug 547665. The prototype looks quite promising.

As above’s screencast shows, I have at least one serious issue to resolve: When the editor is saved, all code minings briefly duplicate. Thankfully, they get back to normal quickly.


by Niko Stotz at May 26, 2019 10:11 PM

Back to the top