Conventional wisdom has it that Java EE is a bad starting point for building cloud-native Java applications, but despite this most cloud-native frameworks are designed to use and extend Java EE. The issue has been not that Java EE can't be used, but deploying applications to new cloud platforms like Docker and Kubernetes so they can be efficiently updated and scaled requires new API's. Enter the Eclipse MicroProfile initiative which, combined with Jakarta EE, has been rapidly building out these gaps.
Eclipse Mars introduced the new Eclipse Automatic Error Reporting system (AERI), which lowered the hurdle to send error reports dramatically. Users will get into contact with this system when an error occurs in the IDE and a popup message requests to send this incident.
Every so often we need to introduce a new developer into our team who might not have experience with OSGi nor any other modular system. Have you ever thought how we can make adoption of new comers into your ecosystem easier?
Most of OSGi projects require some kind of tooling during both - build and development time. While we might live without second reliability of first one is a key of stable builds. As new hire you probably went over some introduction showing how to use properly tooling and surrounding infrastructure in order to become productive. Lets see together how much we can simplify.
While increasing amount of features usually result in poorer performance and more memory consumption, Eclipse Photon has proven the opposite: The Eclipse Platform got faster and less memory hungry than before. This has been achieved by intensive profiling of multiple use cases and refactorings derived from the analysis.
Web tools and cloud architectures are great but what does this actually change for developers?
Each contributor currently has to setup his local environment in order to actually contribute to a project. But how about configuring just a single environment for everyone in the cloud? What if your developers didn't even have to be using a specific local environment to work on a product? This is possible using a workspace server dispatching pre-configured containers to your teams, along with all the tools they need.
There is a new platform in town: Kubernetes. And it is establishing itself as the common denominator for public and private clouds with unprecedented momentum.
This talk is for you when you sensed that Kubernetes may be important and are wondering if using it is more straightforward than spelling its name.
Have you ever got upset and felt to cry out loudly (or you just did so) when you had an SQL statement failing somewhere deeply embedded in your code? Was it easy to find and fix it? Still today, many database libraries force us to embed SQL in the code, which is then very cumbersome to maintain. Fragments of query strings are scattered throughout the source code and we never really see the final SQL statements assembled and sent to the database. What is even worse, the SQL code is not processed at compilation time and – in the worst case – a syntax error can remain in production code.
Codegenerators are everywhere even when you don’t call them so. At the end something that is not text is translated to text. The technologies that are used are very diverse. There is no framework to rule them all, but there are modern technologies out there that will do things differently like we did it 20 years ago. From straightforward model to text to model to model to model to model to model to model to model …. to text - everything is there, but do you really know what is there today? Do you know what to use and why? Do you know when to use what?
OSGi Compendium R7 provides a major update to the OSGi LogService specification. A new logging API is added which supports logging levels and dynamic logging administration. A new Push Stream-based means of receiving log entries is also added. But it is quite often the case you need to use other code such as open source projects which are using slf4j for their logging API. This session will explore the new OSGi LogService changes and how you can integrate code using both slf4j logging and OSGi LogService logging.
Java 9 introduced the Java Platform Module System (JPMS) as a way to modularize the Java platform and it can be also be used by developers to modularize their own applications, although JPMS lack a number of important features for software running on the Java platform.
As people look to support the latest versions of the Java platform, changes introduced in Java 9 related to JPMS led to the needs for some features in the OSGi Core specification. OSGi framework implementations like Eclipse Equinox and Apache Felix and tools like Bnd were updated to support these new features.
As more Eclipse projects are migrated to the new cluster based build infrastructure, it's time for an update on the current status and to share best practices how projects can make the most of it. The following questions (and more) will be answered: Why does my build take so long and how can it be made faster? What are Jenkins pipelines and why/when should they be used? Can I finally run docker based builds?
The Eclipse Development Process is based on some very principles that are considered key for successful open source: openness, transparency, first-class intellectual property management, and vendor neutrality. Over many years, we've developed practices and processes to support these concepts. While most of these practices and processes are captured in the Eclipse Committer Handbook, keeping track of it all can be a challenge.
The Eclipse infrastructure is undergoing a massive overhaul, modernizing every* aspect from builds, to websites, our data and API, networking and virtualization. New tools and technologies are cropping up in our datacenter, including Kubernetes, Docker, 10GbE, nginx, and new developments with Gerrit and even our home-brewed Drupal-based codebase.
Let’s take 35 minutes to explain how you can write your new plugins using the Eclipse 4 concepts and definitively stop to use the E3 UI extension points.
Writing pure Eclipse 4 plugins is easier (thanks to injection, application model fragments, spies, …) and simplifies the unit tests for UI components.
This talk will also explain how to mix your pure E4 plugins properly with your E3 legacy plugins. It will be a complementary talk if you could not attend the E4 tutorial.
While moving Eclipse Sirius to the web, we have created an HTTP API to interact with the Sirius server. In this talk, you will have a look at the GraphQL API for EMF that we have integrated in Eclipse Sirius. With this API, you will have the ability to easily manipulate your models over HTTP. This API can even be parameterized using any metamodel to let users have a GraphQL API with their own concepts and relationships.
Eclipse OpenJ9 is an alternative Java Virtual machine that can be used with OpenJDK and is available for download at adoptopenjdk.net. Open J9 delivers performance, footprint and memory usage improvements over and above the HotSpot JVM. By adopting Open JDK and Open J9 as part of your Spring Boot applications, these improvements can significantly benefit your application. During this talk we will discuss OpenJ9 and how it can be used to improve your application.
All the Eclipse projects progress thanks to their contributors, and without these contributions the Eclipse eco system would die. For several years, the Eclipse foundation has provided a modern and efficient software factory usable by anyone who want to be involved in any project.
This talk will give you an overview and all the entry points of this professional contribution system so as to be involved easily and make Eclipse everyday better.
Defining DSLs in the Eclipse universe has become almost a normal thing and there are incredible frameworks out there to do that. Some of them are textual, others are graphical and from time to time there comes a flood of different attempts to mix both notations. The story of mixed notations is old, yet still not solved in a common way that has proven to be “the solution”. Of course there are plenty of interesting technical challenges, but let’s step back and rethink who is our target audience to see if we are solving a real problem.
Code formatting is an opinionated beast. It always has been a matter of taste, and it always will be a matter of taste. This is the reason, why professional formatting tools, such as Eclipse JDT, offer a gazillion number of options. Which is still not sufficient enough. After all, you can override them inline with tag-comments to make the formatter shut up. Can't we do better than that? What if we could use machine learning techniques to detect the preferred code style that was used in a codebase so far? Turned out, we can.
A containerized application that consumes less CPU, less memory and less bandwidth (by diminushing the container image size) will generates immediate savings on cloud workloads. Sadly, containerizing Java applications and optimizing them for running inside containers has been quite challenging until recently. Come and see how to improve the situation with distroless container images, Eclipse OpenJ9 (an open source Java virtual machine) and custom Java runtime images.