May 24, 2019

A few years ago at EclipseCon I gave a demo of a C++ app using libSDL2 and showed how you build it with CDT and launch it for multiple platforms, my desktop, a BeagleBone running QNX, and finally in a web browser using Emscripten. I used CMake for the build system and that worked fine for the first two, but Emscripten really fought the idea of something else driving the build. I finally figured it out but it left the impression that there had to be a simpler way to build WebAssembly apps.

Recently with version 8 of clang, they have made the wasm target a first class citizen available with the standard distribution. I thought I’d take a look and found at least one example on github that showed how. Here’s a quick summary on how to get started. Be warned, though, one of the arguments is nostdlib which means this is a very barebones example. But that’s another area where I think Emscripten has gone a little to far with. More on that later.

To start this example is a pretty basic Fibonacci calculator, pretty standard for WebAssembly. Here’s the C++ file.

I wanted to show C++ calling back into JavaScript so there’s a very contrived log method we import. The fib function itself is pretty basic. I’ve created a couple of macros in the wasm.h file to manage marking functions as import or export.

Since I’m writing C++ I want to make sure the compiler doesn’t mangle the names so I declare them as extern “C”. As you can see, the export also turns on the visibility of the symbol which is hidden by default in the Makefile.

I’m running this with node.js which has had WebAssembly support since at least version 8 that I have on my Linux box. The idea is to do some of the more computationally expensive tasks in my node server using wasm. Here’s my js file.

It simply loads up the wasm file and instantiates it passing in the log function. When that’s complete, I extract my fib function from the exports and run it. You should see the output of the log function (more times that I was expecting at least), then the result, 55.

There’s lots of magic flags here and I have to thank the author of the example I linked above for getting me started. I’ll have to play with them to see what’s actually necessary. The key here is that it isn’t Emscripten but straight clang 8 that I downloaded from llvm.org. There’s no standard library, so don’t go and try and do a printf. You’re a bit on your own for now.

But that’s somewhat a conclusion I reached. Emscripten allows C++ developer to easily port their apps to run on the web. It doesn’t make the C++ developer think like a Web developer. What would be interesting to me is what it would look like if you weren’t handed those fancy libraries you get with Emscripten and really just wanted to build a web app, like a game, using the standard JavaScript APIs you get with node or the browser. I think you’d end up writing programs like an Arduino developer where you don’t have printf either…

The Jakarta EE Working Group charter identifies three key committees to drive the various facets of the working group for which there are elected positions to be filled: the Steering Committee, the Specification Committee, and the Marketing and Brand Committee.

The elected positions are to represent each of the Enterprise Members, Participant Members, and Committer Members. Note that Strategic Members each have a representative appointed to these committees.

This way, we are announcing that the Foundation will hold elections on behalf of the working group using the proposed timetable listed below. This mimics the process used by other working groups as well as the process used by the Eclipse Foundation itself for filling the elected positions on our Board.

All members are encouraged to consider nominating someone for the positions, and self-nominations are welcome. The period for nominations will open later this week and will run through June 4th. Nominations may be sent to elections@eclipse.org.

Once nominations are closed, we will inform all working group members of the candidates and will distribute ballots via email to those eligible to vote. The election process will follow the Eclipse “Single Transferable Vote” method, as defined in the Eclipse Bylaws.

The winning candidates will be announced on this mailing list immediately after the elections are concluded.

Vert.x Rx usability improvements

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:

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

May 22, 2019

EclipseCon Europe is the leading conference for developers, architects, and open source business leaders to learn about Eclipse technologies, share best practices, and more. Taking in place in Ludwigsburg, Germany, October 21-24, 2019, ECE 2019 is our biggest event of the year and connects the Eclipse ecosystem and the industry’s leading minds under one roof. We are pleased to once again co-locate with the OSGi Alliance Community Event, adding more breadth and expertise to the program.

The ECE 2019 Call for Papers is now open. Please visit the CFP page for information on how to submit your talk. This year, the early-bird submission deadline is July 1 and the final submission deadline is July 15.

If you have an idea for a talk that will educate and inspire the Eclipse community, we would love to hear from you!

May 21, 2019

The world's leading technology vendors, including Fujitsu, IBM, Microsoft, Oracle, Red Hat, SAP, and Tomitribe, are collaborating at the Eclipse Foundation to advance enterprise Java technologies to support the migration of mission-critical applications to the cloud.

The world’s leading technology vendors, including Fujitsu, IBM, Microsoft, Oracle, Red Hat, SAP, and Tomitribe, are collaborating at the Eclipse Foundation to advance enterprise Java technologies to support the migration of mission-critical applications to the cloud. Jakarta EE and Eclipse MicroProfile offer a path for migrating Java EE legacy applications to a standard enterprise Java stack for a cloud native world. Within the collaborative, vendor-neutral environment provided by the Eclipse Foundation, a vibrant community of developers is directly influencing the future of Java.

Establishing Jakarta EE as the place where Java EE will evolve to create this migration path to the cloud is a significant effort, and the community involved in supporting this effort have made tremendous strides. These have included releasing Eclipse GlassFish 5.1 as Java EE 8 certified, thus ensuring backward compatibility, and establishing an open specification process as a replacement for the JCP. Next up is to release Jakarta EE 8 as an established specification and see the commercial vendors support this release, again ensuring the migration path forward. As this happens, all developers are encouraged to participate as Jakarta EE then evolves. The first step in doing this is to join the conversation by visiting https://jakarta.ee/connect/.

The Eclipse Foundation recently released the 2019 Jakarta EE Developer Survey that canvassed nearly 1,800 Java developers about their adoption of Jakarta EE and trends in Java programming. The goal of the survey, which was conducted in March 2019, was to help Java ecosystem stakeholders better understand the requirements, priorities, and perceptions of enterprise Java developer communities.

The findings indicate that cloud native is critically important with a third of developers currently building cloud native architectures and another 30 percent planning to within the next year. Meanwhile, the number of Java applications running in the cloud is projected to increase significantly over the next two years, with 32 percent of respondents expecting that they will be running nearly two-thirds of their Java applications in the cloud in two years. Furthermore, 43 percent of respondents consider the microservices architecture the dominant approach to implementing Java in the cloud.

While Spring and Spring Boot continue to dominate as the leading framework for building cloud native applications in Java, Eclipse MicroProfile’s usage growth more than doubled in adoption from 13 percent in 2018 to 28 percent today.

Survey respondents made it clear that as the community-driven evolution of enterprise Java coalesces around Jakarta EE, Java EE remains the platform they rely on most to build enterprise-class applications. According to the results, the top three community priorities for Jakarta EE are a tie at first with better support for microservices and native integration with Kubernetes (both at 61 percent) followed by product quality reference implementation (37 percent).

Access the full findings of the 2019 Java Community Developer Survey here.

Key Eclipse Projects for Cloud Native Application Development

In addition to Jakarta EE and MicroProfile, the Eclipse community is driving cloud native innovation with the following projects:

Eclipse IDE — As the leading open platform for professional developers, the standard Eclipse IDE is the critical development environment for more than 4 million active users. The Eclipse IDE was chosen by the Java developer community as the top IDE for building cloud native applications in the 2019 Jakarta EE Developer Survey.

Eclipse OpenJ9 — OpenJ9 is a Java virtual machine (JVM), the engine that runs Java applications, optimized for the cloud and microservices. OpenJ9 comes with improvements to memory overhead and startup times, achieved through shared classes and an aggressive focus on memory footprint.

Eclipse Vert.x — Vert.x is a toolkit for building reactive applications on the JVM.

Eclipse Jemo — Jemo is the leading open source multi-cloud function-as-a-service (FaaS) runtime for JVM based languages. Built to take advantage of Kubernetes, Jemo provides a platform, frameworks, and runtime support for building cloud native applications which run across multiple clouds without the need for re-engineering.

Eclipse Theia — Theia is an extensible open-source framework to develop multi-language IDEs for the cloud and desktop using state-of-the-art web technologies.

Eclipse Che — Che is a next-generation developer workspace server and cloud IDE that allows anyone to contribute to a project without installing any software. Che defines workspaces that include their dependencies including embedded containerized runtimes (including Kubernetes, OpenShift, and Docker support), Web IDE (based on Theia), and project code. This enables true team-based development by making workspaces distributed, collaborative, and portable.

How to Participate in the Future Of Cloud Native Java

To learn more about the collaborative efforts to build tomorrow’s enterprise Java platform for the cloud, check out the Jakarta Blogs and participate in the monthly Jakarta Tech Talks. Don’t forget to subscribe to the Eclipse newsletter and get involved in Jakarta EE, Eclipse MicroProfile and other cloud native Eclipse projects.

May 18, 2019

The Jakarta EE community is the driving force behind the future of cloud-native Java. Active participation represents the best way to drive the vendor-neutral and rapid innovation necessary to modernize enterprise systems for cloud use cases. That said, we’d like to make sure that the community is kept up-to-speed with the latest developments in the Jakarta EE ecosystem.

We’re launching a monthly email update for the Jakarta EE community which seeks to highlight news from various committee meetings related to this platform. There are a few ways to get a grip on the work that has been invested in Jakarta EE so far, so if you’d like to learn more about Jakarta EE-related plans and get involved in shaping the future of cloud-native Java, read on. We’d also like to use this opportunity to invite you to get involved in EE4J projects and join the conversation around the Jakarta EE Platform.

Without further ado, let’s have a look at what has happened this month:

Update on Jakarta EE Rights to Java Trademarks

The process of migrating Java EE to the Eclipse Foundation has been a collaborative effort between the Eclipse Foundation staff and the many contributors, committers, members, and stakeholders that are participating. The Eclipse Foundation and Oracle have agreed that the javax package namespace will not be evolved by the Jakarta EE community. Furthermore, Java trademarks such as the existing specification names will not be used by Jakarta EE specifications.

Since the ratified Jakarta EE specifications will be available under a different license (the Eclipse Foundation Specification License), we recommend that you update your contributor and committer agreements.

Read more about the implications and what’s next for the Jakarta EE Working Group in Mike Milinkovich’s latest blog.

In order to evolve Jakarta EE, we must transition to a new namespace. In an effort to bootstrap the conversation, the Jakarta EE Specification Committee has prepared two proposals (Big-bang Jakarta EE 9, Jakarta EE 10 new features and incremental change in Jakarta EE 9 and beyond) on how to make the move into the new namespace smoother. These proposals represent a starting point, but the community is warmly invited to submit more proposals.

Community discussion on how to transition to the jakarta namespace will conclude Sunday, June 9th, 2019.

EFSP v1.1

Version 1.1 of the Eclipse Foundation Specification Process was approved on March 20, 2019. The EFSP leverages and augments the Eclipse Development Process (EDP), which defines important concepts, including the Open Source Rules of Engagement, the organizational framework for open source projects and teams, releases, reviews, and more.

JESP v1.0

Jakarta EE Specification Process v1.0 was approved on April 3, 2019. Therefore, the Jakarta EE Specification Committee now adopts the EFSP v1.1 as the Jakarta EE Specification Process with a few modifications, including the fact that any changes or revisions of the Jakarta EE Specification Process must be approved by a Super-majority of the Specification Committee.

TCK process:

Work on the TCK process is in progress, with Tomitribe CEO David Blevins leading the effort. The TCK process is expected to be completed in the near future. The document will shed light on aspects such as the materials a TCK must possess in order to be considered suitable for delivering portability, the process for challenging tests and how to resolve them and more.

Jakarta EE 8 release

Jakarta EE 8 is a highly-anticipated release, especially since it represents the first release that’s completely based on Java EE to ensure backward compatibility. It relies on four pillars of work, namely specifications for the full platform, TCKs, including documents on how to use them, a compatible implementation for the release of Jakarta EE 8, and marketing aspects such as branding, logo usage guidelines, and marketing and PR activities.

All parties involved are far along with the planning process and work on specifications has already started. Please look at Wayne Beaton’s blogs on the work in progress with regard to specification project names and specification scopes.

But before you dive right in, you should read the latest blog from the Jakarta EE Specification committee, which recently approved a handful of naming standards for Jakarta EE Specification projects. While you’re at it, you should read Wayne Beaton’s blog on why changing the names of the specifications and the projects that contain their artifacts is a necessary step.

There’s no better time to get involved in the work for the Jakarta EE Platform than the present. As of now, the projects that demand the community’s attention are the Jakarta EE 8 Platform Specification, which is meant to keep track of the work involved with creating the platform specification for Jakarta EE 8, Jakarta EE 9 Platform Specification, intended to keep track of the work involved with creating the platform specification for Jakarta EE 9 and Jakarta EE.Next Roadmap Planning, which seeks to define a roadmap and plan for the Jakarta EE 9 release.

Community Engagement

Speaking of community engagement, there are a few ways to get a grip on the work that has been invested in Jakarta EE so far, learn more about Jakarta EE-related plans and get involved in shaping the future of cloud-native Java. One way to do that is by reading Tanja Obradovic’s blog series on how to get involved.

You should also be aware of the newly-created Jakarta EE community calendar, which is now open to the public and offers an overview of all the activities surrounding Jakarta EE. The community is invited to participate in Jakarta Tech Talks, which take place on a monthly basis, attend Jakarta EE Update monthly calls (the next one is on May 8), help build the Jakarta EE wiki with all relevant links and look for opportunities to engage and become part of the community.

Last but not least, the Jakarta EE Developer Survey will be released in the next few days. Head over to jakarta.ee to discover the latest trends, the community’s top priorities regarding the future of Jakarta EE and more. Stay tuned!

Conclusion:

Thank you for your interest in Jakarta EE. To help us build tomorrow’s enterprise Java platform, join the Jakarta EE community now or get involved by becoming a contributor or committer to one of the EE4J projects.

May 16, 2019

Eclipse has mechanism to recognize if the workspace to be used is created with older Eclipse version.In such case, to be safe, Eclipse shows dialog like:

As of today (Eclipse 4.12 M1), if you click on "Cancel" button, Eclipse will behave differently, depending on the use cases "history":

A. If the workbench was not started yet:

If Eclipse was started without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog.

If Eclipse was started with "-data" argument pointing to the incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).

B. If the workbench was started:

If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).

Fix Proposal #1

The proposal is, that independently on the way Eclipse was started, if user clicks on the "Cancel" button in the "Older Workspace Version" dialog, we always show the default workspace selection dialog (instead of termination):

In this dialog above user has two choices: launch any workspace or finally terminate Eclipse via "Cancel".

Proposal #1 Matrix

A1. If the workbench was not started yet:

If Eclipse was started with or without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog. To terminate Eclipse, user has to click "Cancel" in the workspace selection dialog.

B1. If the workbench was started:

If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer to select another workspace.

Fix Proposal #2

The proposal is, that depending on the way Eclipse was started, if user clicks on the "Cancel" button in the "Older Workspace Version" dialog, we may or may not show the default workspace selection dialog. So what happens after "Older Workspace Version" dialog is shown is not predictable by just looking on this dialog - it depends on the history of this dialog.

Proposal #2 Matrix

A2. If the workbench was not started yet:

If Eclipse was started without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog.

If Eclipse was started with "-data" argument pointing to the incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).

B2. If the workbench was started:

If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer to select another workspace.

Similarities

Both proposals fix second bullet in the use case B2.

Differences

We see that Proposal #1 has no second bullet for A1 case, and is always consistent in the way how UI behaves after clicking on "Cancel" in the "Older Workspace Version" dialog. Proposal #2 fixes only B2 use case, inconsistency in UI behavior for the second part of A1 use case remains.

Proposal #2 is not implemented yet. I assume that this will require more work compared to the patch #1. We will need a new command line argument for Eclipse to differentiate between "I want you not to terminate even if incompatible -data is supplied because I'm calling you from UI" and "Please terminate if incompatible data is supplied because I'm calling you from the command line". A new command line argument for Eclipse means not just Platform UI internal change, but also requires changes in the Equinox and Help, and also means public interface change.

May 13, 2019

Today we announced the launch of the openMobility Working Group that will focus on open and shared collaboration around one of the major issues in urban planning around autonomous vehicles and future transportation requirements.

The results of the 2019 Jakarta EE Developer Survey are out. Almost 1,800 Java developers from around the world have spoken. Taken together with the engagement and response to my recent posts on the future of Jakarta EE (see my latest blog here), the survey makes clear the developer community is focused on charting a new course for a cloud native future, beginning with delivering Jakarta EE 8. The Java ecosystem has a strong desire to see Jakarta EE, as the successor to Java EE, continue to evolve to support microservices, containers, and multi-cloud portability.

Organized by the Jakarta EE Working Group, the survey was conducted over three weeks in March 2019. Just like last year (see the 2018 results here), Jakarta EE member companies promoted the survey in partnership with the London Java Community, Java User Groups, and other community stakeholders. Thank you to everyone who took the time to participate. Access the full findings of the survey here.

Some of the highlights from this year’s survey include:

The top three community priorities for Jakarta EE are: better support for microservices, native integration with Kubernetes (tied at 61 percent), followed by production quality reference implementations (37 percent). To move mission-critical Java EE applications and workloads to the cloud, developers will need specifications, tools, and products backed by a diverse vendor community. Jakarta EE Working Group members have committed to deliver multiple compatible implementations of the Jakarta EE 8 Platform when the Jakarta EE 8 specifications are released.

With a third of developers reporting they are currently building cloud native architectures and another 30 percent planning to within the next year, cloud native is critically important today and will continue to be so;

The number of Java applications running in the cloud is projected to substantially increase, with 32 percent of respondents expecting that they will be running nearly two-thirds of their Java applications in the cloud within the next two years;

Microservices dominates as the architecture approach to implementing Java in the cloud, according to 43 percent of respondents;

Spring/Spring Boot again leads as the framework chosen by most developers for building cloud native applications in Java;

Java continues to dominate when it comes to deploying applications in production environments. It comes as no surprise that most companies are committed to protecting their past strategic investments in Java.

Once again, thanks to everyone who completed the survey and to the community members for their help with the promotion.

Let me know what you think about this year’s survey findings. We are open to suggestions on how we can improve the survey in the future, so please feel free to share your feedback.

I’d like to thank the community for the level of engagement we’ve seen in response to my post from last week. This post, which again represents the consensus view of the Jakarta EE Steering Committee, answers some questions about Jakarta EE 8, which is planned as the initial release of Jakarta EE, and is intended to be fully compatible with Java EE 8, including use of the javax namespace. We thought it would be useful to reiterate the messages we have been delivering about this release.

Note that this post is not about future Jakarta releases where the namespace will be changed. There is a vigorous discussion going on right now on the jakarta-platform-dev@eclipse.org list (archive), so if you are interested in that topic, I would suggest you participate there. We expect that it will be about a month before the Jakarta EE Spec Committee will determine the next steps in the Jakarta EE roadmap.

No, Jakarta EE 8 will not break existing existing Java EE applications that rely upon javax APIs. We expect Jakarta EE 8 to be completely compatible with Java EE 8. We expect Jakarta EE 8 to specify the same javax namespace, and the same javax APIs and the same behavior as is specified in Java EE 8. We expect that implementations that pass the Java EE 8 TCKs will also pass the Jakarta EE 8 TCKs, because the Jakarta EE 8 TCKs will be based on the same sources as the Java EE 8 TCKs. Jakarta EE 8 will not require any changes to Java EE 8 applications or their use of javax APIs.

Provide a compatibility and branding process for demonstrating that implementations are Jakarta EE 8 compatible.

Will there be Jakarta EE 8 compatible implementations?

Yes. Multiple compatible implementations of the Jakarta EE 8 Platform will be available when the Jakarta EE 8 specifications are released. We expect that any Java EE 8 compatible implementation would also be Jakarta EE 8 compatible, and the vendors in the Jakarta EE Working Group intend to certify their Java EE 8 compatible implementations as Jakarta EE 8 compatible. In addition, because the Jakarta EE TCKs are available under an open source license, we will “lower the bar” for other technology providers to demonstrate Jakarta EE compatibility for their implementations. The lower cost and more liberal Jakarta EE trademark licensing will allow more technology providers to leverage and strengthen the Jakarta EE brand in the Enterprise Java community. Jakarta EE 8 will provide a new baseline for the evolution of the Jakarta EE technologies, under an open, vendor-neutral community-driven process.

What is the process for delivery of Jakarta EE 8

The process for delivery of Jakarta EE 8 specifications will be fully transparent and will follow the Jakarta EE Specification Process. Expect to see in coming weeks the delivery of initial, draft Jakarta EE 8 component specifications corresponding to Java EE 8 component specifications. These will contain Javadoc defining the relevant APIs, and TCKs for compatibility testing. To publish specification text, we need to acquire copyright licenses for this text. We have obtained Oracle and IBM’s copyright licenses for their contributions, and intend to obtain the remaining copyright licenses required to publish the text of the Jakarta EE 8 Platform specification, and as much as possible of the component specifications. If you contributed to the Java EE specifications at the JCP in the past, expect to be contacted by the Eclipse Foundation to provide a license to use your contributions in Jakarta EE going forward. Providing such a license will be an important step in supporting the new specification process and the Jakarta EE community. You will see these draft specifications evolve to final specifications in an open community process. Join the specification projects and participate!

When will Jakarta EE 8 be delivered?

The Jakarta EE Working Group intends to release final Jakarta EE 8 specifications by the fall of 2019. This is an open community-driven effort, so there will be transparency into the process of driving the Jakarta EE 8 specifications, delivery of the Jakarta EE 8 TCKs, and Jakarta EE 8 compatible implementations.