Eclipse IDE for Java

Apache Camel development is improving on Eclipse Che 7 compared to Che 6. On Che 6, it is limited to XML DSL and without classical XSD-based XML support. With Che 7, Camel Java DSL is available and XSD-based XML support is working nicely with the ... [More] Camel XML DSL support. Please note that Che 7 is still in beta. Camel language features available Inside the same editor, there is access to classic XML tooling and Camel XML DSL support. Classic XML tooling completion based on XSD: Camel XML DSL tooling completion: Classic XML tooling validation: Camel XML DSL tooling validation: Inside the same editor, there is access to classic Java tooling and Camel Java DSL support. Classic Java tooling completion: Camel Java DSL completion: Classic Java tooling validation: Camel Java DSL tooling validation: How to configure on che.openshift.io Currently, some advanced steps are needed to have all extensions working together on a resource-limited Che environment, which is the default for che.openshift.io. Let’s see how to activate it. Go to che.openshift.io (you will have to register if you’ve not done so already). Create a workspace based on Che 7. Wait that workspace creation is finished. Import the Camel/Fuse project that you want. Go back to workspace configuration by using the top-left yellow arrow and clicking on Workspaces. Click on the running workspace. Click stop at the top right. Go to Plugins tab. Enable Language Support for Apache Camel, Language Support for Java and XML. Go to config tab. Search for “attributes”, add memory limits for each of the plugins, you should end with something like: "attributes": { "sidecar.redhat/java.memory_limit": "1280Mi", "sidecar.camel-tooling/vscode-apache-camel.memory_limit": "128Mi", "sidecar.redhat/vscode-xml.memory_limit": "128Mi", "sidecar.eclipse/che-theia.memory_limit": "512Mi", "editor": "eclipse/che-theia/next", "plugins": "eclipse/che-machine-exec-plugin/0.0.1,redhat/java/0.43.0,camel-tooling/vscode-apache-camel/0.0.14,redhat/vscode-xml/0.5.1" } Click on Open button on top right. Open a Java file and wait that the Java Language Server has started (it can take several minutes). Enjoy! What’s next? As you’ve noticed, the installation is currently a bit cumbersome as it requires you to touch the YAML config file. Don’t worry; there is work in progress to improve the installation experience, such as providing a specific Camel stack. This will allow you to create a workspace preconfigured, which means doing only the first three steps instead of the 11 steps of the configuration. Several other features are in the works by incorporating existing VS Code extensions inside Che 7. Stay tuned. The post Apache Camel development on Eclipse Che 7 appeared first on Red Hat Developer. [Less]

The world’s leading innovators in Java, including Fujitsu, IBM, Microsoft, Oracle, Payara, Red Hat, SAP, and Tomitribe, are collaborating at the Eclipse Foundation to advance enterprise Java technologies to support the migration of mission-critical ... [More] 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/.      Jakarta EE Developer Survey Results Show Cloud Native Adoption Accelerating Dramatically with Jakarta EE   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. Tags:  Jakarta EE MicroProfile microservices FaaS eclipse che kubernetes cloud native KubeCon Europe 2019 [Less]

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 ... [More] 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/.      Jakarta EE Developer Survey Results Show Cloud Native Adoption Accelerating Dramatically with Jakarta EE   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. Tags:  Jakarta EE MicroProfile microservices FaaS eclipse che kubernetes cloud native KubeCon Europe 2019 [Less]

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 ... [More] 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.   EE4J GitHub Get involved in Eclipse EE4J! There are currently three projects that you can be a part of, namely Specification Document Names, Jakarta Specification Project Names, and Jakarta Specification Scope Statements (for the specifications). Furthermore, there are plenty of repos that require your attention and involvement. 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. Head over to GitHub and join the conversation!   Jakarta EE Platform 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.    Help steer Jakarta EE toward its exciting future by joining the Jakarta EE working group! Tags:  #JakartaEE #JavaEE #Java #EclipseFdn [Less]

Eclipse Jakarta EE has been placed in the position that it may not evolve the enterprise APIs under their existing package names. That is, the package names starting with java or javax. See Update on Jakarta EE Rights to Java Trademarksfor the ... [More] background on how we arrived at this state.So this means that after Jakarta EE 8 (which is API identical to Java EE 8 from which it descends), whenever an API in Jakarta EE is to be updated for a new specification version, the package names used by the API must be renamed away from java or javax. (Note: some other things will also need to be renamed such as system property names, property file names, and XML schema namespaces if those things start with java or javax. For example, the property file META-INF/services/javax.persistence.PersistenceProvider.) But this also means that if an API does not need to be changed, then it is free to remain in its current package names. Only a change to the signature of a package, that is, adding or removing types in the package or adding or removing members in the existing types in the package, will require a name change to the package. There has been much discussion on the Jakarta EE mail lists and in blogs about what to do given the above constraint and David Blevins has kindly summed up the two main choices being discussed by the Jakarta EE Specification Committee: https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html.In a nutshell, the two main choices are (1) “Big Bang” and (2) Incremental. Big Bang says: Let’s rename all the packages in all the Jakarta EE specifications all at once for the Jakarta EE release after Jakarta EE 8. Incremental says: Let’s rename packages only when necessary such as when, in the normal course of specification innovation, a Jakarta EE specification project wants to update its API.I would like to argue that Jakarta EE should chose the Incremental option.Big Bang has no technical value and large, up-front community costs.The names of the packages are of little technical value in and of themselves. They just need to be unique and descriptive to programmers. In source code, developers almost never see the package names. They are generally in import statements at the top of the source file and most IDEs kindly collapse the view of the import statements so they are not “in the way” of the developer. So, a developer will generally not really know or care if the Jakarta EE API being used in the source code is a mix of package names starting with java or javax, unchanged since Jakarta EE 8, and updated API with package names starting with jakarta. That is, there is little mental cost to such a mixture. The Jakarta EE 8 API are already spread across many, many package names and developers can easily deal with this. That some will start with java or javax and some with jakarta is largely irrelevant to a developer. The developer mostly works with type and member names which are not subject to the package rename problem.But once source code is compiled into class files, packaged into artifacts, and distributed to repositories, the package names are baked in to the artifacts and play an important role in interoperation between artifacts: binary compatibility. Modern Java applications generally include many 3rdparty open source artifacts from public repositories such as Maven Central and there are many such artifacts in Maven Central which use the current package names. If Jakarta EE 9 were to rename all packages, then the corpus of existing artifacts is no longer usable in Jakarta EE 9 and later. At least not without some technical “magic” in builds, deployments, and/or runtimes to attempt to rename package references on-the-fly. Such magic may be incomplete and will break jar signatures and will complicate builds and tool chains. It will not be transparent.Jakarta EE must minimize the inflection point/blast radius on the Java community caused by the undesired constraint to rename packages if they are changed. The larger the inflection point, the more reason you give to developers to consider alternatives to Jakarta EE and to Java in general. The Incremental approach minimizes the inflection point providing an evolutionary approach to the package naming changes rather than the revolutionary approach of the Big Bang.Some Jakarta EE specification may never be updated. They have long been stable in the Java EE world and will likely remain so in Jakarta EE. So why rename their packages? The Big Bang proposal even recognizes this by indicating that some specification will be “frozen” in their current package names. But, of course, there is the possibility that one day, Jakarta EE will want to update a frozen specification. And then the package names will need to be changed. The Incremental approach takes this approach to all Jakarta EE specifications. Only rename packages when absolutely necessary to minimize the impact on the Java community.Renaming packages incrementally, as needed, does not reduce the freedom of action for Jakarta EE to innovate. It is just a necessary part of the first innovation of a Jakarta EE specification.A Big Bang approach does not remove the need to run existing applications on earlier platform versions.  It increases the burden on customers since they must update all parts of their application for the complete package renaming when the need to access a new innovation in a single updated Jakarta EE specification when none of the other Jakarta EE specifications they use have any new innovations. Just package renames for no technical reason.  It also puts a large burden on all application server vendors. Rather than having to update parts of their implementations to support the package name changes of a Jakarta EE specification when the specification is updated for some new innovation, they must spend a lot of resources to support both old and new packages name for the implementations of all Jakarta EE specifications.There are some arguments in favor of a Big Bang approach. It “gets the job done” once and for all and for new specifications and implementations the old java or javax package names will fade from collective memories. In addition, the requirement to use a certified Java SE implementation licensed by Oracle to claim compliance with Eclipse Jakarta EE evaporates once there are no longer any java or javax package names in a Jakarta EE specification. However, these arguments do not seem sufficient motivation to disrupt the ability of all existing applications to run on a future Jakarta EE 9 platform.In general, lazy evaluation is a good strategy in programming. Don’t do a thing until the thing needs to be done. We should apply that strategy in Jakarta EE to package renaming and take the Incremental approach. Finally, I am reminded of Æsop’s fable, The Tortoise & the Hare. “The race is not always to the swift.” [Less]

JSON Forms is a framework for efficiently developing form-based UIs based on JSON Schema. It provides a simple declarative JSON-based language...The post One size fits all – Rendering Material Design with React and Angular appeared first on EclipseSource.

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 ... [More] , 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 compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine. 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). This behavior is inconvenient (at least), so we have bug 538830.Fix Proposal #1The 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 compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine. 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 #2The 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 compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine. 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. Technical (biased) notes: Proposal #1 is implemented and the patch is available, along with the demo video. To test it live, one has to build Eclipse - but here I have SDK binaries with the patch applied. The patch is relatively simple and only affects Platform UI internal code. 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. Question to the masses! We want to know your opinion - which proposal should be implemented?Please reply here or on the bug 538830. [Less]

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.

You’ve probably heard about Quarkus, the Supersonic Subatomic Java framework tailored for Kubernetes and containers. We wrote an article on how to create your first Quarkus project in an Eclipse based IDE (like Red Hat ... [More] CodeReady Studio). You can read it at https://developers.redhat.com/blog/2019/05/09/create-your-first-quarkus-project-with-eclipse-ide-red-hat-codeready-studio/ [Less]

The results of the 2019 Jakarta EE Developer Survey are out. Almost 1,800 Java developers from around the world have spoken.