CodeCatalyst is designed to make it easier for developers to spend more time developing application features and less time setting up project tools, creating and managing continuous integration and continuous delivery (CI/CD) pipelines, provisioning and configuring different development and deployment environments, and engaging project contributors.

CodeCatalyst aims to empower professional developers to create and deploy applications on AWS. There are four core elements of CodeCatalyst that are designed to help minimize distractions and maximize satisfaction in the software development process.

The four foundational elements of CodeCatalyst:

– Blueprints get you started quickly. CodeCatalyst blueprints set up an application code repository (complete with a working sample app), define cloud infrastructure, and run pre-configured CI/CD workflows for your project. Blueprints bring together the elements that are necessary both to begin a new project and deploy it into production. Blueprints can help to significantly reduce the time it takes to set up a new project. They are built by AWS for many use cases, and you can configure them with the programming languages and frameworks that you need both for your application and the underlying infrastructure-as-code.

– Actions-based CI/CD workflows take the pain out of pipeline management. CI/CD workflows in CodeCatalyst run on flexible, managed infrastructure. When you create a project with a blueprint, it comes with a complete CI/CD pipeline composed of actions from the included actions library. You can modify these pipelines with an action from the library or you can use any GitHub Action directly in the project to edit existing pipelines or build new ones from scratch.

– Automated dev environments make consistency achievable A big friction point for developers collaborating on a software project is getting everyone on the same set of dependencies and settings in their local machines, and ensuring that all other environments from test to staging to production are also consistent. To help address this, CodeCatalyst has Dev Environments that are hosted in the cloud. Dev Environments are defined using the devfile standard, ensuring that everyone working on a project gets a consistent and repeatable experience.

– Issue management and simplified team onboarding streamline collaboration. CodeCatalyst is designed to help provide the benefits of building in a unified software development service by making it easier to onboard and collaborate with teammates. It starts with the process of inviting new collaborators: you can invite people to work together on your project with their email address, bypassing the need for everyone to have an individual AWS account. Once they have access, collaborators can see the history and context of the project and can start contributing by creating a Dev Environment.

CodeCatalyst also has built-in issue management that’s linked to your code repo, so you can assign tasks like code reviews and pull requests to teammates and help track progress using agile methodologies directly in the service. As with the rest of CodeCatalyst, collaboration happens without the distraction of managing separate services with separate logins and different commercial agreements. Once you give a new team member access, they can quickly start contributing.

This is the latest development in a years-long effort to provide the ability to compile Java applications into machine code prior to program execution. And although such an idea might seem strange, one of the first things a new Java developer learns is that “Java doesn’t compile to machine code, it compiles to JVM bytecode”.

The Java platform relies on a powerful dynamic runtime, the JVM, for execution. This runtime enables dynamic techniques, such as class loading and reflection, that are unparalleled in compiled-ahead-of-time (AOT) languages. This is the starting point for many of Java’s strengths.

Two of the few Java Enhancement Proposals (JEPs) that relate to GraalVM are: JEP 243 and JEP 295. Both of these JEPs arrived in Java 9 and, together, they introduced the Graal compiler into the OpenJDK codebase.

What we need to know is that the Graal compiler is one of the main components of GraalVM – it is a compiler that works with Java bytecode and creates machine code. It can run in either JIT or AOT mode.

Galahad will be managed as a subproject of OpenJDK and will support a separate repo that will periodically overwrite the main repo. And when the features are ready, they will be transferred to the main repo. This is the same model that has been successfully used by long-running projects like Lambda.

Project Galahad would start with a clone of the current JDK mainline release, JDK 20, and track mainline releases going forward. The plans call for incrementally merging the Java-related GraalVM technologies from the Graal repository into the JDK 20 clone. This might include side repositories for experimentation. Project Galahad will be delivered over time in a series of Java enhancement proposals that likely will span multiple feature releases.

It is important to know that not the entire GraalVM codebase will be handed over, but only the core JIT and AOT components, as well as the Native Image toolkit. Oracle’s proprietary features present in GraalVM Enterprise Edition are not expected to be passed on to the project.

Most influential members of this community welcomed the idea of Galahad and described it as another important step forward in Java’s quest to remain at the forefront of Cloud Native technology stacks.

GitHub New Command Palette

Try using the new command palette and send your feedback to GitHub team here.