The latest version of Eclipse GlassFish 8.0.2 was released on May 5, 2026, with fixes for several critical vulnerabilities. It builds on top of a lot of subtle work and improvements in GlassFish components like the Eclipse Grizzly HTTP framework, or in related components like Eclipse OpenMQ message broker and Eclipse ORB (CORBA) for remote EJB calls. The release of GlassFish 8.0.2 serves as further evidence that GlassFish remains an actively evolving platform, backed by the dedicated maintenance and commercial support of the OmniFish team. As I was deeply involved in this release, I'd like to share a deeper look into the technical advancements within this new version.

Security fixes

First and foremost, GlassFish 8.0.2 brings a few important security fixes, which alone should be a good-enough reason to upgrade GlassFish:

• CVE-2026-24457 (9.8 CRITICAL) in OpenMQ 6.9.0
• 2 yet undisclosed CVEs in the Admin Console with severity scores of 9.6 CRITICAL and 9.1 CRITICAL

The two currently undisclosed CVEs were reported directly to the Eclipse Foundation and the Eclipse GlassFish team. While OmniFish collaborated closely on these fixes and possesses full knowledge of the vulnerabilities, we are unable to share specific details before the CVE details are officially published. These security flaws have been successfully resolved in GlassFish 8.0.2 and are currently in the process of being formally published by the Eclipse Foundation through a recognized CVE authority.

Stability and other Improvements

GlassFish 8.0.2 introduces enhanced hostname resolution for localhost. While this might appear to be a minor refinement, it effectively addresses numerous edge cases where GlassFish previously logged errors or even failed to boot when it incorrectly derived the hostname or local IP address.

This latest GlassFish version also includes an improvement for the @EJB annotation when utilizing the beanName attribute in an appclient. Although this specific functionality is rarely used in applications, the update was essential to ensure synchronization with the recent Jakarta EE 11 TCK service release, enabling GlassFish 8.0.2 to achieve full compliance.

Component upgrades

The GlassFish 8.0.2 release brings several component upgrades. However, this time many of the updates weren’t simple “bump version, test, and merge” tasks. They involved components maintained by the Eclipse GlassFish project itself or related Eclipse projects in which OmniFish is also involved. In several instances, an improvement in one component triggered changes in others, leading to a chain of multiple dependent releases. This required careful coordination with other committers and project leads before the changes could finally be integrated into GlassFish.

The most notable update is the Grizzly HTTP framework, now at version 5.0.1. Beyond functionality improvements, this release fixes a major issue that previously required a fragile workaround when using Grizzly as a build dependency in Maven projects. Version 5.0.0 had been released with this flaw accidentally because the release checks already included the workaround (an enabled Maven snapshots repository) and passed without issues. We have since improved the release checks to ensure this situation doesn’t repeat.

Other Eclipse Foundation components that were released by the OmniFish team and were upgraded in GlassFish 8.0.2 include Mojarra, OpenMQ, ORB, Grizzly NPN and HK2.

We originally tried to upgrade to Eclipse JAXB Impl 4.0.7, but we had to roll it back since it caused some regressions in several Jakarta EE TCK tests. So, GlassFish 8.0.2 is sticking with version 4.0.6 for now. The good news is that a fix is already in a newer JAXB Impl release, which will be included in the upcoming GlassFish 8.0.3 update.

Some notable third-party component upgrades include Jackson, Helidon Config, Nimbus JOSE JWT, JNoSQL, Commons IO and Commons Codec.

GlassFish 8.0.2 is a patch release of GlassFish 8, which brought Jakarta EE 11 and many other new features and enhancements. Learn More About What’s New In GlassFish 8

Conclusion – GlassFish is a platform you can trust

A patch release might not sound exciting, but 8.0.2 tells a clear story: GlassFish is a platform where security issues get fixed quickly, components are kept up to date, and the team is paying attention to what matters in production – security, stability and performance.

Meanwhile, work is already in progress on GlassFish 8.0.3, which will bring additional security fixes. We’re also working on startup enhancements of Embedded GlassFish, which will save about 10% of startup time and make microservices and Docker containers start even faster.

If you are evaluating Jakarta EE platforms for a new project, or looking for a reliable home for existing applications, Eclipse GlassFish backed by OmniFish is worth a serious look. Download 8.0.2 and see for yourself, or reach out to us if you want to talk through your specific setup.

More information:

• Download GlassFish 8.0.2

OmniFish - Jakarta EE experts

• Enterprise Support For Eclipse GlassFish
• Jakarta EE Support: Payara Community, Piranha, Quarkus
• Jakarta EE Consulting, Training & Development

For more information about OmniFish, ask them via their contact page, X/Twitter or LinkedIn.

The post GlassFish 8.0.2 Released: With important security fixes, other improvements, and commercial support appeared first on foojay.

Something has been in the works since Azul completed its acquisition of Payara in December 2025, and today we're ready to share it: the community edition of Payara has a new name and logo – but not so very different from the one you already know!

Payara Platform Community is now Azul Payara Community, made up of two distributions you already know and love - Azul Payara Server Community and Azul Payara Micro Community - plus the tooling and connectors that go with them.

It's a small change in letters but an important one. The new name reflects where we are: fully part of the Azul family, with all the backing that brings, while staying true to what this project has always been - an open-source runtime built by and for the Java and Jakarta EE community.

The iconic Payara fish has also had a bit of a refresh. The Azul Payara commercial logos were updated back in December, and now the community edition gets the same treatment - same fish character the Payara community knows well, just updated to match its new home at Azul.

What the acquisition means for the Community

We believe the open-source community is the heart of the Payara ecosystem. The contributors, committers and developers using Azul Payara Community for testing, education, side projects or apps that haven't gone commercial yet all matter to us. Growing that community, listening to it and investing in it is central to how we think about Azul Payara's future.

The rebrand is part of bringing Azul Payara Community properly into the Azul portfolio alongside Azul Zulu (OpenJDK), Azul Prime, Intelligence Cloud and Azul Payara’s commercial offering. It's the same open-source project with a new home in the broader Azul ecosystem.

What's changing (and when)

Over the coming weeks and months, you can expect to see updates to Payara documentation, resource names, technical content and the blog. Downloads are still available at payara.fish for now, but will be moving to Azul website before long - we'll announce that when the time comes.

One thing we're particularly excited about: we'll be increasing our presence here on Foojay sharing everything that is relevant for the Friends of OpenJDK community - educational content, tutorials, community updates and more.

For social media, we're consolidating onto Foojay and Azul's official channels. Make sure you're following us there, so you don't miss a thing.

Getting out and meeting you

Together with the Azul DevRel, Product and Engineering Teams, we're planning to visit a lot of Java User Groups over the coming months, and we're really looking forward to meeting community members face to face. If your JUG would like a visit or a talk on Azul Payara Community, OpenJDK or Jakarta EE - let us know.

We'll also be at a number of Java conferences this year. More details to come, but if you spot us - come and say hello.

What's been shipping: April and May 2026 Azul Payara Community Releases

We didn't want to announce the rebrand without also catching you up on recent releases (download here!), so here's a combined look at what landed for Azul Payara Community in April and May.

May: Azul Payara Community 7.2026.5

Security fixes (critical - please upgrade):

• Remote arbitrary file read vulnerability via unsafe parsing of OpenMQ configuration
• Restricted access to vulnerable EL expressions

Bug fixes:

• Admin Console freezing after upgrading from Payara 6 to 7

Improvements:

• Updated JACC Provider Compatibility Startup Service

• Audit Modules removed

• warlibs support added to Admin Console redeployment

• Reduced INFO logging for the Jakarta Data implementation

• New deployment descriptors created with deprecated properties removed

• Fix for Jakarta Data @Repository methods not throwing UnsupportedOperationException when no implementation logic can be injected at deploy time

Component upgrades: Docker JDK images refreshed to 21.0.11 and 25.0.3, with dependency updates for Jakarta Faces, MicroProfile Config, Project Reactor, and other libraries.

The critical security fix is also backported across Azul Payara 6.38.0, 5.87.0, and 4.1.2.191.55 — we recommend all users upgrade regardless of which branch they're on.

April: Azul Payara Community 7.2026.4

April's community release was a significant cleanup milestone, removing three long-standing deprecated items: the start-domain --upgrade service (replaced by the Payara Upgrade Tool), all methods previously annotated @Deprecated, and all deprecated configuration properties.

Bug fixes:

• Asadmin Recorder generating invalid commands when recording MicroProfile property changes

• Rendering issue in the Admin Console connection pool Advanced tab

• Broken news link in the Admin Console

• Race condition in application-scoped QueryData under concurrent access

• OpenMQ unclosed stream warnings

Community contributions from Lenny Primak:

• Fix for CDI annotation type resolution failing when annotations were defined in WAR library dependencies
• Resolution of an SLF4J class loader leak that could accumulate memory in long-running deployments

Component upgrades: EclipseLink 5.0.0-B08 → 5.0.0-B13, OpenMQ updated to 6.8.0, plus bumps to Jackson BOM, Reactor Core, Kotlin Stdlib, and several others.

A lot more to come

The rebrand is just the start. As part of Azul, Payara Community gains access to more resources, more engineering investment and a broader platform to grow.

We have exciting plans - for the runtime, the tooling and connectors available to community users, content, and the events we put on - and we'll be sharing them with you as they take shape.

A huge thank you to everyone who has been part of the Payara community over the years - the contributors, the committers, the developers who have filed issues, submitted fixes, written content and shown up at conferences and JUGs. This project is what it is because of you, and that doesn't change with a new name. We're genuinely excited about what comes next, and we hope you are too!

For now: download the latest release from payara.fish, join us on Foojay, and follow Azul's official social channels for updates.

The post A New Chapter for the Payara Community appeared first on foojay.

The May 2026 release is the largest Payara milestone since the project's inception. Azul Payara Server 7 and Azul Payara Micro 7 ship as generally available, both certified against Jakarta EE 11. This is the first major Payara product release under the Azul brand, arriving six months after Azul completed its acquisition of Payara in December 2025.

Azul Payara Community 7 (download here), the open-source distribution, was the first implementation of any kind to certify across all three Jakarta EE 11 profiles (Full, Web Profile, Core Profile). Azul Payara Server 7 brings that certification to a commercially supported product with enterprise SLAs, making it the first commercially supported Jakarta EE 11 runtime from a major enterprise application server vendor. Both products ship with MicroProfile 6.1 (Config, Metrics, Health, Fault Tolerance, JWT, OpenAPI, REST Client, Telemetry Tracing). Azul Payara Server 7 holds Final TCK certification across all three profiles:

No other major enterprise application server vendor holds Final certification across all three profiles at Jakarta EE 11. Oracle WebLogic 15.1.1 sits at Jakarta EE 9.1. IBM WebSphere tWAS is frozen at Java EE 7. Red Hat JBoss EAP ships Jakarta EE 10.

Existing Jakarta EE 10 applications deploy without code changes; the jakarta.* namespace is stable between EE 10 and EE 11, so Azul Payara 6 applications move to Payara 7 by upgrading the runtime, not rewriting the codebase. JDK 21 is the minimum (Docker images ship for JDK 21 and JDK 25, the latest LTS). The same .war runs on both Server and Micro without modification. Jakarta Data, the headline API addition in Jakarta EE 11 introduces the @Repository annotation and a standardized data access layer.

This release also ships a critical security fix across every version: Azul Payara Community 7.2026.5, and Azul Payara 6.38.0, 5.87.0, and 4.1.2.191.55.

A critical security fix, patched across every supported branch

A critical security issue has been addressed across Azul Payara Community 7.2026.5 and Azul Payara 6.38.0, 5.87.0, and 4.1.2.191.55.

The fix lands in Azul Payara branches dating back to 4.1.2. Shipping security patches across the full supported lifecycle, not only the latest major release, is one of the practices that long-running Azul customers rely on; this release is a clear example. Azul is a registered CVE Numbering Authority (CNA) under CISA/DHS oversight, with patches backported to all supported versions on a published monthly schedule.

Azul Payara Community 7.2026.5

Community 7.2026.5 tracks the Payara 7 development line and ships additional fixes ahead of the Enterprise cadence.

Security Fixes

• Remote attacker can read arbitrary files via unsafe parsing of OpenMQ configuration
• Restrict access to vulnerable EL expressions

Bug Fixes

• Fix Admin Console freezing after upgrading from Payara 6 to 7

ImprovementsImprovements

• Update JaccProviderCompatibilityStartup Service
• Remove Audit Modules
• Add warlibs support to redeployment via Admin Console
• Reduce INFO logging for the Jakarta Data implementation
• Create new deployment descriptors with deprecated properties removed
• Fix Jakarta Data @Repository methods not throwing UnsupportedOperationException when no implementation logic can be injected at deploy time

Component Upgrades

Docker JDK images refreshed to 21.0.11 and 25.0.3. Dependency updates for Jakarta Faces, MicroProfile Config, Project Reactor, and other libraries.****

Azul Payara 6.38.0: Continued Jakarta EE 10 Support

Azul Payara 6.38.0 continues the Jakarta EE 10 and MicroProfile 6.1 line for customers who are not yet on Payara 7.

Bug Fixes

• Fix HTTP 403 Forbidden response on correctly authenticated and authorized calls to protected JAX-RS resources
• Fix illegal reflective access by org.glassfish.pfl.basic.reflection.Bridge when starting Payara Server in Verbose mode

Improvements

• Deprecate Audit Modules
• Remove Yubikey Extension

Component Upgrades

Docker JDK images refreshed for JDK 21, 17, 11, and 8 (21.0.11, 17.0.19, 11.0.31, 8u492). Dependency updates for Mojarra and Project Reactor.

Azul Payara 5.87.0: Jakarta EE 8 Support Continues

Azul Payara 5.87.0 retains the javax. namespace, Jakarta EE 8, and MicroProfile 4.1 platform for customers running long-lived applications that have not yet migrated to the jakarta. namespace.

Bug Fixes

• Fix illegal reflective access by org.glassfish.pfl.basic.reflection.Bridge when starting Payara Server in Verbose mode
• Fix OIDC proxy support failing due to incorrect redirect URL comparison

Improvements

• Deprecate Audit Modules
• Remove Yubikey Extension

Component Upgrades

Docker JDK images refreshed for JDK 21, 17, 11, and 8 (21.0.11, 17.0.19, 11.0.31, 8u492).

Azul Payara 4.1.2.191.55: Legacy Branch Still Maintained

Azul Payara 4.1.2.191.55 receives security updates and targeted bug fixes for customers still running on the Payara 4 branch.

Bug Fixes

• Fix Payara failing to start OpenMQ Broker in a separate JVM when using LOCAL mode on JDK 11 or later
• Fix unclosed streams warnings from OpenMQ

Looking Ahead

With Payara 7 GA, the Azul Payara product line now covers the full enterprise Java surface: the JDK (Azul Zulu, Core and Azul Prime), the full application server (Azul Payara Server), and the cloud-native runtime (Azul Payara Micro). All three ship under one Azul contract with monthly security patches, a long term lifecycle per major release, transparent per-vCore pricing, 24-48 hour bug fix SLAs, and 2-hour critical incident response with dedicated support engineers.

Azul Payara 6, 5, and 4 continue to receive monthly security and bug-fix releases on the published schedule. Migration assessments to Azul Payara 7 are available through your Azul account team for customers planning the move.

Upgrading and Feedback

We recommend upgrading to your version’s latest release in this cycle. A critical security patch is available across every supported branch, so there is no reason to delay the upgrade based on the major-version line you run.

For detailed upgrade instructions, see the Payara documentation. To report issues, contribute fixes, or follow the Payara 7 roadmap, visit the Payara GitHub repository. For commercial support, your Azul account team.

Happy deploying!

The post Azul Payara May 2026 Release – What’s New appeared first on foojay.

 💪😤 THE 12 LABOURS OF PRIMEFACES 15.0.15 #release

PrimeFaces 15.0.15 has just been released. 🚀

And no, this is not “React for Java”.

PrimeFaces is a component library for JSF / Jakarta Faces.

Its goal is simple:

build server-side Java web applications with rich UI components without writing everything manually in HTML, CSS and JavaScript.

This release is mostly about polish:

▪️ security hardening
▪️ accessibility fixes
▪️ better component behavior
▪️ fewer UI edge cases
▪️ smoother developer experience

Let’s look at what changed, then at the most common PrimeFaces concepts with small code examples. 👇
https://github.com/primefaces/primefaces/releases/tag/v15.0.15

🔵 TL;DR

A quick overview of why PrimeFaces 15.0.15 matters and what kind of improvements it brings.

▪️ PrimeFaces 15.0.15 is a maintenance release, not a “big feature” release
▪️ The most visible change is the new escape behavior on p:schedule tooltips
▪️ Accessibility keeps improving around ARIA attributes
▪️ Several components received small but useful fixes: SelectOneMenu, Panel, ConfirmDialog, TextEditor, BlockUI, AutoComplete, Slider
▪️ PrimeFaces remains a good fit when your application is strongly Java/server-side oriented

🔵 WHAT PRIMEFACES 15.0.15 BRINGS

🔵 1. SCHEDULE TOOLTIP ESCAPING

PrimeFaces now gives better control over how tooltip content is escaped in p:schedule.

<p:schedule value="#{calendarBean.eventModel}"
            tooltip="true"
            escape="true" />

The escape property controls whether HTML content in schedule tooltip descriptions is escaped.

Explanation:

▪️ escape="true" is the safe default
▪️ HTML is rendered as text
▪️ this helps avoid unwanted HTML injection in tooltips
▪️ if you explicitly need trusted HTML, you can opt out carefully

For newbies: do not set escape="false" just because “it looks nicer”. Only do it when you fully control and sanitize the content. 🔐

🔵 2. SCHEDULE TOOLTIP WITH TRUSTED HTML

HTML tooltips can still be rendered when the content is trusted and properly controlled.

<p:schedule value="#{calendarBean.eventModel}"
            tooltip="true"
            escape="false" />

Explanation:

This allows richer tooltip rendering when event descriptions contain HTML.

Useful for:

▪️ internal dashboards
▪️ trusted admin content
▪️ formatted calendar events

But it comes with responsibility.

If the content comes from users, databases, imports, or external systems, escaping should stay enabled.

Security is not an aesthetic option. 😉

🔵 3. SELECTONEMENU ACCESSIBILITY

SelectOneMenu gets improved ARIA behavior for better accessibility support.

<p:outputLabel for="country" value="Country" />

<p:selectOneMenu id="country"
                 value="#{userBean.country}"
                 required="true"
                 ariaLabel="Country">
    <f:selectItem itemLabel="Select one" itemValue="" />
    <f:selectItems value="#{userBean.countries}" />
</p:selectOneMenu>

Explanation:

PrimeFaces 15.0.15 restores some ARIA attributes on SelectOneMenu.

Why it matters:

▪️ screen readers understand the component better
▪️ invalid/required states are clearer
▪️ forms are more accessible
▪️ enterprise applications become more usable for everyone ♿

Accessibility is not decoration. It is part of the component contract.

🔵 4. PANEL TOGGLE HEADER BEHAVIOR

Panel headers now expose more accurate accessibility behavior when toggleable headers are used.

<p:panel header="Advanced filters"
         toggleable="true"
         toggleableHeader="true">

    <p:inputText value="#{searchBean.keyword}" />
</p:panel>

Explanation:

The Panel fix makes ARIA behavior more precise.

The header should behave like a button only when the header is actually toggleable.

Why it matters:

▪️ better semantics
▪️ less confusing screen reader output
▪️ cleaner keyboard navigation
▪️ more predictable UI behavior

Small fix, real UX impact.

🔵 5. CONFIRM BEFORE SHOW CALLBACK

Confirmation dialogs can better respect logic executed before the dialog is displayed.

<script>
function canShowDeleteConfirm() {
    return confirm('Do you really want to open the confirmation dialog?');
}
</script>

<p:commandButton value="Delete"
                 action="#{userBean.delete}">
    <p:confirm header="Confirmation"
               message="Delete this user?"
               icon="pi pi-exclamation-triangle"
               beforeShow="return canShowDeleteConfirm();" />
</p:commandButton>

<p:confirmDialog global="true" />

Explanation:

The beforeShow callback is now properly respected.

That means you can decide before the confirmation popup opens.

Useful for:

▪️ business pre-checks
▪️ client-side conditions
▪️ avoiding unnecessary dialogs
▪️ custom UX flows

It is a small fix, but it makes confirmation flows more reliable.

🔵 6. INPUTNUMBER AND AUTONUMERIC UPDATE

Numeric inputs benefit from improvements around formatting, precision and user interaction.

<p:inputNumber value="#{invoiceBean.amount}"
               symbol="€"
               decimalPlaces="2"
               thousandSeparator=" "
               decimalSeparator="," />

Explanation:

PrimeFaces 15.0.15 updates/fixes behavior around AutoNumeric, the JavaScript library behind p:inputNumber.

Why developers care:

▪️ numeric input is tricky
▪️ currencies are tricky
▪️ decimal separators are tricky
▪️ undo/redo, backspace, formatting and parsing must stay consistent

This is the kind of fix users may never notice…because the component simply behaves correctly. ✅

🔵 7. TEXTEDITOR PASTE CLEANUP

Text pasted into the editor is handled more cleanly, especially around invisible spacing issues.

<p:textEditor value="#{articleBean.content}"
              height="300" />

Explanation:

The TextEditor fix handles non-breaking spaces during paste operations.

Why it matters:

▪️ copy-paste from Word, websites or rich editors can introduce invisible characters
▪️ invisible characters create formatting surprises
▪️ text storage and rendering become cleaner
▪️ content editing feels less buggy

Rich text editors are never “just text”. This fix helps reduce one of those annoying content-editing edge cases.

🔵 8. PANELMENU STATEFULNESS

Nested menu items better remember their expanded or collapsed state after navigation.

<p:panelMenu stateful="true">
    <p:submenu label="Administration">
        <p:submenu label="Users">
            <p:menuitem value="Search users"
                        outcome="/admin/users" />
        </p:submenu>
    </p:submenu>
</p:panelMenu>

Explanation:

The release improves statefulness for nested menu items. (submenus better remember their expanded/collapsed between navigations)

Why it matters:

▪️ expanded menu state is preserved better
▪️ nested navigation becomes less frustrating
▪️ admin dashboards feel more stable
▪️ users do not lose their navigation context

In back-office applications, navigation stability matters a lot.

🔵 9. AJAX ERROR HANDLING

Ajax behavior is improved around redirects and error situations during partial page updates.

<p:commandButton value="Save"
                 action="#{profileBean.save}"
                 process="@form"
                 update="messages profilePanel" />

<p:messages id="messages" />

Explanation:

PrimeFaces 15.0.15 improves Ajax handling around redirect/error edge cases.

PrimeFaces apps rely heavily on partial page updates.

That means small Ajax bugs can create strange UI effects:

▪️ blocked components
▪️ incomplete refreshes
▪️ broken redirect behavior
▪️ confusing user feedback

This fix is mostly invisible, but important for robustness.

🔵 10. BLOCKUI CLEANUP

Blocked UI areas are cleaned up more reliably after Ajax updates and widget lifecycle changes.

<p:blockUI block="formPanel"
           trigger="saveButton" />

<p:panel id="formPanel">
    <p:commandButton id="saveButton"
                     value="Save"
                     action="#{profileBean.save}"
                     update="formPanel" />
</p:panel>

Explanation:

BlockUI is used to prevent user interaction while an Ajax request is running.

The fix ensures the target element is properly unlocked during widget cleanup.

Why it matters:

▪️ fewer “stuck UI” situations
▪️ better behavior after partial updates
▪️ cleaner Ajax lifecycle
▪️ less frustration for users

A blocked screen after a save button is one of the fastest ways to lose user confidence.

🔵 11. AUTOCOMPLETE MORETEXT FIX

Autocomplete now handles the “more results” message more consistently.

<p:autoComplete value="#{cityBean.selectedCity}"
                completeMethod="#{cityBean.completeCity}"
                var="city"
                itemLabel="#{city.name}"
                itemValue="#{city}"
                moreText="More results available..." />

Explanation:

The moreText area is used when more suggestions exist than currently displayed.

This fix improves how that text is rendered and exposed.

Useful when:

▪️ suggestions are limited
▪️ search results are large
▪️ users need feedback
▪️ accessibility matters

Autocomplete is not only about search. It is about guiding the user.

🔵 12. SLIDER PRECISION

Slider values are displayed with precision that better matches the configured step.

<p:inputText id="discount" value="#{pricingBean.discount}" />

<p:slider for="discount"
          minValue="0"
          maxValue="1"
          step="0.05"
          display="discountOutput"
          displayTemplate="{value}" />

<h:outputText id="discountOutput" />

Explanation:

The Slider display now uses the same precision as the configured step.

Example:

▪️ step = 0.05
▪️ display should remain consistent with that precision
▪️ no strange rounding surprises
▪️ better display for percentages, ratings, thresholds and numeric filters

Small detail. Big difference when users manipulate numbers.

🔵 TAKEAWAYS

Small maintenance fixes can have a meaningful impact on security, accessibility and daily user experience.

▪️ PrimeFaces is still relevant when you want server-side Java UI development
▪️ It is especially useful for enterprise CRUD, admin panels, internal tools and data-heavy applications
▪️ PrimeFaces 15.0.15 is mostly about quality, not hype
▪️ Security and accessibility fixes matter as much as shiny components
▪️ New developers should understand the JSF lifecycle before judging PrimeFaces
▪️ The real power is not “drag and drop UI” — it is the combination of Java beans, components, Ajax updates and rich widgets

PrimeFaces is not the trendy kid in the frontend room. But in many Java enterprise applications, it is still doing serious work. ☕🎨

Java #JakartaEE #JSF #PrimeFaces #JakartaFaces #EnterpriseJava #WebDevelopment #JavaDevelopers #SoftwareEngineering #Accessibility #WebSecurity #BackendDevelopment #FullStackJava

Go further with Java certification:

Java👇

https://bit.ly/javaOCP

Spring👇

https://bit.ly/2v7222

SpringBook👇

https://bit.ly/springtify

JavaBook👇

https://bit.ly/jroadmap

✌️😎

The post 💪😤 THE 12 LABOURS OF PRIMEFACES 15.0.15 #release appeared first on foojay.

The key message of this article is simple and strong: any Java or Jakarta EE application is already ready to benefit from the advantages of unikernels.

Java and Jakarta EE, including modern frameworks such as Quarkus, can immediately take advantage of the unikernel model without waiting for new languages, new runtimes, or radical rewrites.

With Nanos Unikernel, Java applications run unchanged: the JVM is not modified, the application is not rewritten, and the well-known Java promise of write once, run anywhere remains fully valid — even in a unikernel environment.

This represents a major shift: unikernels are no longer a research topic or a niche experiment, but a first-class deployment target for enterprise Java workloads.

From Virtual Machines and Containers to Unikernels

Cloud-native Java applications have traditionally been deployed on virtual machines and, more recently, inside containers orchestrated by Kubernetes. While containers brought improvements in portability and density, they also introduced additional layers of software complexity.

Unikernels remove these layers by compiling the application and its required runtime components into a single-purpose, minimal image that runs directly on a hypervisor.

With Nanos Unikernel, this model becomes practical for Java and Jakarta EE workloads.

Proof of Concept Overview

Reproducibility and Artifacts

For this Proof of Concept, all the build and deployment steps are fully reproducible.

The artifacts used are publicly available and were generated by the GitHub Actions workflow:

• Repository and CI run: https://github.com/AngeloRubens/quarkus-faces-nanos/actions/runs/21218011985

These artifacts include the packaged Quarkus application and the IBM Semeru Runtime bundled for execution on Nanos Unikernel (ARM64).

Local Build and Image Creation

In the local environment, the Nanos unikernel image for AWS ARM64 was created using the following command:

ops image create \
  --imagename quarkusNanosArm64 \
  --package AngeloRubens/SemeruJREarm64Linux:25.0.1 \
  --arch arm64 \
  --nightly \
  -c configAws.json \
  -t aws

This step produces a bootable Nanos unikernel image containing:

• the Quarkus application
• the unmodified IBM Semeru Runtime (OpenJ9)
• the minimal Nanos kernel required to run on ARM64

Instance Creation on AWS

Once the image was created and uploaded, the EC2 instance was launched directly from the unikernel image using:

ops instance create \
  quarkusNanosArm64 \
  --arch arm64 \
  -c configAws.json \
  -t aws

This workflow highlights a key point of the article: Java applications can be deployed as unikernels without introducing container images, container runtimes, or orchestration layers.

This article builds on the original Foojay article, where the application image was executed on Oracle Cloud Infrastructure (OCI). The goal of this Proof of Concept is to demonstrate that the same Nanos Unikernel image can be deployed on a different cloud provider and hypervisor without modification.

PoC Environment

• Cloud provider: AWS
• Instance type: t4g.small (ARM64)
• CPU: AWS Graviton2
• Hypervisor: AWS Nitro
• Unikernel: Nanos (ARM64)
• Runtime JAVA: IBM Semeru Runtime 25 for Arm64
• Framework: Quarkus

This demonstrates that Nanos unikernels are hypervisor-agnostic and cloud-independent.

Architectural Diagram of the PoC

The application runs as a single unikernel image directly on top of the AWS Nitro hypervisor, without a guest operating system, container runtime, or Kubernetes node.

Containers vs Unikernels: A Stack Comparison

Container Stack

• Hardware
• Hypervisor
• Guest Operating System
• Container Runtime
• Container Image
• Java Runtime
• Application

Unikernel Stack

• Hardware
• Hypervisor
• Unikernel (Application + Runtime)

By removing unnecessary layers, unikernels reduce boot time, memory footprint, and attack surface.

Quarkus, Semeru, and Nanos on AWS Nitro Graviton

Quarkus is particularly well suited for this model thanks to its fast startup and low memory usage, while IBM Semeru provides a production-grade OpenJDK runtime. Combined with Nanos, the result is a highly efficient Java unikernel.

AWS Nitro: Cloud-Native Capabilities Without Kubernetes

AWS Nitro, like all modern hypervisors, already provides many of the foundational capabilities often associated with Kubernetes:

• Strong isolation and security boundaries
• Elastic scaling at the VM level
• High-performance networking and storage
• Hardware offloading for I/O and virtualization
• Integrated observability and telemetry
• Native IAM integration

Because these features are built directly into the cloud infrastructure, there is no technical requirement to add additional orchestration layers for many workloads.

Running Java applications as unikernels allows teams to:

• Exploit hardware more efficiently
• Reduce operational complexity
• Lower infrastructure and operational costs

Hypervisor Independence

In the original article, the application image runs on the Oracle OCI hypervisor. In this Proof of Concept, the same image runs on AWS Nitro.

This confirms that Nanos unikernels are not tied to a specific cloud provider or hypervisor. The same Java application can be deployed consistently across environments.

Why This Matters for Java and Jakarta EE

Java and Jakarta EE can benefit today from unikernel advantages:

• Faster boot times
• Smaller memory footprint
• Reduced attack surface
• Simpler deployment model

Most importantly, this comes without changing existing applications or the JVM.

Unikernels with Nanos represent an evolutionary step, not a disruptive rewrite, for the Java ecosystem.

Conclusion

The cloud is evolving, and unikernels are becoming a practical deployment option for real-world workloads.

With Nanos Unikernel, Java, Jakarta EE, Quarkus, and IBM Semeru Runtime can fully exploit modern ARM64 cloud platforms such as AWS Graviton2 and the Nitro hypervisor — today, without compromise.

Reference:

The poc on aws Free Tier t4g.small until 31-Dec-2026: http://3.127.237.11:8080/index.xhtml

FooJay Link: https://foojay.io/today/java-jakarta-ee-and-the-evolution-of-the-cloud-with-nanos-unikernel/

Nanovms Link: https://nanovms.com/

Semeru JRE Repo ops nanos package https://repo.ops.city/v2/packages/AngeloRubens/SemeruJREarm64Linux/25.0.1/arm64/show

The post AWS Nitro and CPU Graviton Meets Unikernels appeared first on foojay.

If you worked with MicroProfile Health, you already understand the value of exposing application health information through standardized endpoints. You know about liveness, readiness and startup probes. You implemented the HealthCheck interface and annotated your procedures with @Liveness, @Readiness and @Startup. Spring Boot Actuator follows a similar philosophy but takes a different architectural approach. This post will help you map your MicroProfile Health knowledge to Spring’s world.

The Conceptual BridgeThe Conceptual Bridge

At its core, Spring Boot Actuator serves the same purpose as MicroProfile Health: it provides a mechanism for validating the availability and status of your application in containerized environments. Both specifications recognize that modern cloud platforms like Kubernetes need machine-readable health information to make decisions about pod lifecycle management.

The fundamental concepts translate directly:

• Liveness probes determine whether an application should be restarted
• Readiness probes determine whether an application can accept traffic
• Startup probes handle slow-starting applications before liveness takes over
• Health status is aggregated from multiple contributors using a logical AND policy by default
• HTTP status codes signal overall health (200 for UP, 503 for DOWN)

Endpoint Mapping

In MicroProfile Health 4.0, you work with four endpoints: /health/ready, /health/live, /health/started, and the combined /health. Spring Boot Actuator uses a similar structure with some naming differences.

The Actuator health endpoint lives at /actuator/health by default, with separate probe endpoints at /actuator/health/liveness and /actuator/health/readiness. These endpoints automatically become available when Spring detects a Kubernetes environment, exposing the application’s availability state through dedicated health indicators. Platforms like Payara Qube use these Actuator endpoints to monitor the health of Spring Boot applications, automatically detecting application status and managing container lifecycle based on the probe responses.

For Kubernetes deployments, you configure your probes similarly to what you’d do with MicroProfile:

livenessProbe:
  httpGet:
    path: "/actuator/health/liveness"
    port: <actuator-port>
readinessProbe:
  httpGet:
    path: "/actuator/health/readiness"
    port: <actuator-port>

Writing Health ChecksWriting Health Checks

In MicroProfile Health, you implement the HealthCheck functional interface and return a HealthCheckResponse. The annotation determines whether it’s a liveness, readiness, or startup check. Spring Boot Actuator follows a similar pattern but uses the HealthIndicator interface instead.

MicroProfile Approach

@Readiness
@ApplicationScoped
public class DatabaseCheck implements HealthCheck {
    public HealthCheckResponse call() {
        return HealthCheckResponse.named("database")
            .withData("connection", "active")
            .up()
            .build();
    }
}

Spring Boot Actuator Approach

@Component
public class DatabaseHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        return Health.up()
            .withDetail("connection", "active")
            .build();
    }
}

Notice the similarities: both use a builder pattern, both support additional data/details, and both return a status. The naming is derived from the class name in Spring (DatabaseHealthIndicator becomes “database”), while MicroProfile requires explicit naming in the response.

Auto-Configured Health Indicators

One area where Spring Boot Actuator differs from MicroProfile Health is the extensive set of auto-configured health indicators. While MicroProfile specifies that implementations should support reasonable out-of-the-box procedures, Spring Boot ships with indicators for databases, message brokers, caches, and more.

Available auto-configured indicators include checks for:

• DataSource connections (database health)
• Disk space monitoring
• Elasticsearch, MongoDB, Neo4j, and other databases
• Redis and Hazelcast caches
• RabbitMQ and JMS message brokers
• LDAP servers
• SSL certificate validity

These indicators activate based on classpath detection. If you have a Redis client in your dependencies, the Redis health indicator appears. You can disable specific indicators through configuration properties like management.health.redis.enabled=false.

Response Format and Status Codes

Both specifications use JSON responses and HTTP status codes to communicate health status. MicroProfile Health 4.0 mandates specific status values (UP, DOWN) and HTTP codes (200, 503, 500). Spring Boot Actuator follows a similar convention but offers more flexibility in customization.

A typical Actuator health response looks like:

{
  "status": "UP",
  "components": {
    "db": {
      "status": "UP",
      "details": { "database": "PostgreSQL" }
    },
    "diskSpace": { "status": "UP" }
  }
}

Compare this to MicroProfile’s format using a “checks” array instead of a “components” object. The structure differs slightly, but the information conveyed is equivalent.

Security Considerations

Both specifications recognize that health endpoints may expose sensitive information. MicroProfile Health states that security is an opt-in feature that must not be enforced by default. Spring Boot Actuator takes a more secure-by-default approach: only the /health endpoint is exposed over HTTP by default, and when Spring Security is present, actuator endpoints are secured automatically.

Spring provides fine-grained control over what health information is displayed:

• never: Details are never shown
• when-authorized: Details shown only to authenticated users with proper roles
• always: Details shown to all users

Actuator’s Extended Capabilities

While MicroProfile Health focuses solely on application health, Spring Boot Actuator provides a broader observability story. The health endpoint is just one of many available endpoints including metrics, environment properties, loggers, thread dumps, heap dumps, and more. This makes Actuator a more comprehensive solution for application monitoring, though it means learning a larger API surface.

Key additional endpoints include:

• /actuator/metrics for application metrics
• /actuator/env for environment properties
• /actuator/loggers for runtime log level management
• /actuator/info for build and git information
• /actuator/prometheus for Prometheus-compatible metrics export

Practical Migration Tips

If you’re moving a MicroProfile application to Spring Boot or working on a team that uses both frameworks, here are key points to remember:

1. Replace annotations with components: Instead of @Liveness or @Readiness, create @Component beans implementing HealthIndicator and use health groups for organization.
2. Update endpoint paths: Change from /health/ to /actuator/health/ in your Kubernetes configurations.
3. Review auto-configured indicators: Check which indicators Spring activates based on your dependencies. You may need to disable some or configure others.
4. Configure security early: Spring’s secure-by-default approach means you may need to configure access rules for health endpoints to work with your infrastructure.
5. Consider reactive support: If you’re building reactive applications with WebFlux, use ReactiveHealthIndicator for non-blocking health checks.

Conclusions

Spring Boot Actuator and MicroProfile Health share the same goal: making applications observable and manageable in cloud-native environments. Your understanding of MicroProfile Health concepts transfers well to Spring. The main differences lie in the API surface (interface vs annotations), configuration approach (properties vs annotations), and scope (Actuator covers more than just health).

Whether you’re working with Jakarta EE and MicroProfile or Spring Boot, the underlying patterns for health checking remain consistent. Both ecosystems have learned from Kubernetes and cloud platform requirements, resulting in specifications that, while different in implementation details, serve the same operational needs.

For MicroProfile developers exploring Spring Boot, Actuator health will feel familiar. The learning curve is less about understanding new concepts and more about mapping the patterns you already know to a different syntax and configuration model.

The post Spring Boot Actuator Health for MicroProfile Developers appeared first on foojay.

GlassFish is an application server with a long history and has always had a special role in the Java world as the reference implementation of Java EE, being one of the most popular Java EE servers. Since Oracle lost interest in the project several years ago, developers and organizations have held certain beliefs about GlassFish, often based on their experiences with older versions.

If you still think of GlassFish as a slow, unsupported, and purely for-development application server, it’s time to take a fresh look. At OmniFish, we’ve been working hard to change that perception since 2022. The Eclipse GlassFish of today, particularly from version 7.0 onwards, is a completely different platform, and we’re proud to show you what we’ve helped to build with the rest of the Eclipse GlassFish contributors.

This article explores the key differences between the modern Eclipse GlassFish and its predecessor, Oracle GlassFish and older Eclipse GlassFish versions. We’ll show you how GlassFish has evolved into a robust, enterprise-grade platform with commercial support from our team at OmniFish, with frequent updates, and a strong commitment to modern Java standards and modern lightweight deployments. In short, this is no longer your father’s GlassFish.

The Myth of the Unsupported, Non-Production Server

One of the most persistent myths about GlassFish is that it’s not suitable for production environments and lacks commercial support. This might have been a valid concern in the past, but it is no longer true. Since 2022 and GlassFish 7.0, the landscape has changed dramatically. Eclipse GlassFish is now a production-ready, enterprise-grade platform with active community, frequent releases, and commercial support with enterprise guarantees from OmniFish, a company which is actively involved in the project and leads most of the development.

We founded OmniFish because we believe in GlassFish’s potential as a modern, enterprise-ready application server. We’re committed to providing comprehensive long-term support for Eclipse GlassFish. Moreover, we actively steer the GlassFish project within the Eclipse Foundation, regularly adding new features and improvements

This level of support and active development means that the claim that GlassFish is not production-ready is outdated. Organizations can now confidently deploy GlassFish in production, knowing that they have a team of experts backing them up and continuously improving the platform.

Key Differences: Eclipse GlassFish vs. Oracle GlassFish

To help you understand the evolution of GlassFish, let's briefly summarize the history of GlassFish and then compare the modern Eclipse GlassFish with the older Oracle GlassFish across several key areas.

There were multiple periods in the history of GlassFish::

• Until 2012: Commercially supported Oracle GlassFish
  • Last release was GlassFish 3.1.2.2, July 2012
• 2012-2022: Opensource releases of GlassFish with no commercial support
  • First release of Payara, the most successful GlassFish fork: Payara 4.1.144, October 2014
  • Last release from Oracle: GlassFish 5.0, September 2017
  • First release from Eclipse Foundation: Eclipse GlassFish 5.1, January 2019
• Since 2022 until now: Actively maintained GlassFish, commercially supported by OmniFish
  • First production-ready release: Eclipse GlassFish 7.0, December 2022
  • Latest major release: Eclipse GlassFish 8.0, February 2026

And here's how the Eclipse GlassFish since 2022 (starting with GlassFish 7.0) compares to Oracle GlassFish before 2018 (until GlassFish 5.0):

As you can see, Eclipse GlassFish has made significant strides in every important aspect of a modern application server. It is no longer the abandoned GlassFish of the past but a forward-looking platform designed for today’s enterprise needs.

What’s New in Eclipse GlassFish 7.0 and Beyond

Let’s look at some of the highlights that make Eclipse GlassFish a top choice for enterprise Java development.

Jakarta EE 11 and MicroProfile Support

Eclipse GlassFish was the first to pass the Jakarta EE 11 Web Profile and Jakarta EE 11 Platform TCKs. This means you can use the newest features of Jakarta EE with confidence. In addition, GlassFish now supports several popular MicroProfile APIs such as Health, Config, REST Client, and JWT. This makes it an excellent choice for building resilient and configurable microservices.

A New Era for Embedded GlassFish

Embedded GlassFish has grown from a developer-focused tool into a production-ready, lightweight runtime. It’s now a viable option for running microservices from the command line or in cloud containers. With the inclusion of MicroProfile APIs and JMX monitoring, Embedded GlassFish offers the same power and observability as the full server in a smaller footprint.

Performance and Security at the Core

The recent Eclipse GlassFish releases have focused heavily on performance and security. You can expect faster startup times, improved JDBC pool throughput, and better resource management. GlassFish also supports the latest Java versions, up to Java 25, allowing you to take advantage of the newest language features and JVM optimizations.

On the security front, GlassFish now supports the PKCS12 keystore format and uses it by default, and it addresses critical vulnerabilities, ensuring that applications are secure and compliant with industry standards.

Learn More About Modern GlassFish

• Eclipse GlassFish: Official website
• Eclipse GlassFish: OmniFish website
• GlassFish 8 Released: Enterprise-Grade Java, Redefined. What's new?
• Azul Acquires Payara: GlassFish Supported by OmniFish Is A Reliable Choice

OmniFish - Jakarta EE experts

• Enterprise Support For Eclipse GlassFish
• Jakarta EE Support: Payara Community, Piranha, Quarkus
• Jakarta EE Consulting, Training & Development

For more information about OmniFish, ask them via their contact page, X/Twitter or LinkedIn.

The post Eclipse GlassFish: This Isn’t Your Father’s GlassFish appeared first on foojay.

What is BoxLang? Zero-Config Spring Boot Integration

• GradleGradle

From Controller to Template in Minutes Full Web Scopes — Out of the Box Hot-Reload During Development Configuration That Stays Out of Your Way Coexist With Any Other View Technology Requirements How It Works Under the Hood Get Started Professional Support

Spring Boot developers know the pain of evaluating view technologies. Thymeleaf is great — until you need more expressiveness. FreeMarker is powerful — until the syntax fights you. What if you could write templates in a dynamic JVM language that gives you the full power of the platform, feels natural, and requires zero setup to integrate?

Meet the BoxLang Spring Boot Starter.

TL;DR: Drop one dependency into your Spring Boot 3 app and start writing dynamic .bxm templates powered by BoxLang — a modern, expressive JVM language. Zero configuration. Full web scopes. 100% Java interoperable. Not only that, you get full access to BoxLang's framework capabilities so you can integrate tons of features into your Spring Boot applications:

• Human & Fluent Scheduled Tasks
• Enterprise Caching Engine
• Cache Aggregator
• Enhanced Concurrency BoxFutures
• Attempts
• Data Navigators
• And so much more

Not only that, it is completely documented for you:

• https://boxlang.ortusbooks.com/getting-started/running-boxlang/spring-boot
• https://boxlang.ortusbooks.com/boxlang-language/templating-language

🌐 What is BoxLang?

BoxLang is a modern dynamic JVM language purpose-built for rapid application development. Think of it as what you'd get if Java's runtime, a scripting language's expressiveness, and a templating engine had a very productive meeting.

Key highlights:

☕ 100% Java interoperable — call any Java class, library, or Spring bean directly
🔩 Compiles to JVM bytecode — same performance guarantees you expect
🚀 Multi-runtime — run it on OS, Servlet containers, AWS Lambda, and more
🎨 Modern syntax — expressive, clean, and productive

// Access the BoxLang runtime directly from any Spring-managed bean
BoxRuntime runtime = BoxRuntime.getInstance();

✨ Zero-Config Spring Boot Integration

The starter follows Spring Boot's auto-configuration philosophy religiously. Add the dependency and you're done. No @EnableBoxLang. No manual bean registration. No XML.

GradleGradle

dependencies {
    implementation 'io.boxlang:boxlang-spring-boot-starter: 1.0.0'
}

Maven

<dependency>
    <groupId>io.boxlang</groupId>
    <artifactId>boxlang-spring-boot-starter</artifactId>
    <version>1.0.0</version>
</dependency>

Spring Boot's auto-configuration mechanism detects the starter on the classpath and wires BoxLangViewResolver, starts the BoxRuntime lifecycle, and registers all required beans automatically. Read more in our docs: https://boxlang.ortusbooks.com/getting-started/running-boxlang/spring-boot

🚀 From Controller to Template in Minutes

Your Spring MVC controllers stay exactly as they are. Return a view name, add model attributes — BoxLang handles the rest.

@Controller
public class HomeController {

    @GetMapping("/")
    public String home(Model model) {
        model.addAttribute("title", "Hello from BoxLang + Spring Boot!");
        model.addAttribute("framework", "Spring Boot 3");
        return "home"; // resolves to classpath:/templates/home.bxm
    }
}

Then write your template in src/main/resources/templates/home.bxm:

<bx:output>
<!DOCTYPE html>
<html lang="en">
<head>
    <title>#variables.title#</title>
</head>
<body>
    <h1>#title#</h1>
    <p>Framework: #framework#</p>
    <p>Rendered at: #dateTimeFormat( now(), "full" )#</p>
</body>
</html>
</bx:output>

Every attribute you add via model.addAttribute(...) is automatically injected into the BoxLang variables scope. No extra mapping, no boilerplate.

🌐 Full Web Scopes — Out of the Box

Unlike most view engines that only expose model data, BoxLang templates have access to the complete set of HTTP scopes natively, and the entire request/response servlet contexts.

<bx:output>
    <!-- Spring model attribute -->
    <p>#variables.title#</p>

    <!-- URL query param with default -->
    <p>Page: #url.page ?: 1#</p>

    <!-- Cookie with fallback -->
    <p>Theme: #cookie.theme ?: "light"#</p>
</bx:output>

🔥 Hot-Reload During Development

Switch to a file: prefix in a dev Spring profile and template edits take effect on the next request — no restarts required.

src/main/resources/application-dev.properties

boxlang.prefix=file:src/main/resources/templates/
boxlang.debug-mode=true

Activate it:

./gradlew bootRun --args='--spring.profiles.active=dev'

⚙️ Configuration That Stays Out of Your Way

All settings live under the boxlang.* namespace in application.properties or application.yml. Sensible defaults mean you only override what you need.

boxlang:
  prefix: classpath:/templates/
  suffix: .bxm
  debug-mode: false
  # runtime-home: /app/.boxlang  # great for containers

You can also supply a boxlang.json config file at src/main/resources/boxlang.json for advanced language-level settings like locale, timezone, and logging.

🔀 Coexist With Any Other View Technology

BoxLangViewResolver integrates cleanly into Spring MVC's resolver chain. If a .bxm template doesn't exist for a given view name, it returns null and Spring falls through to the next resolver — meaning Thymeleaf, FreeMarker, and BoxLang can all live in the same application without conflict.

# Lower number = higher priority in the resolver chain
boxlang.view-resolver-order=1

📋 Requirements

🛠️ How It Works Under the Hood

For the curious Java developer:

• Auto-configuration registers via META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports — the standard Spring Boot SPI.
• BoxRuntime starts as a SmartLifecycle at phase Integer.MIN_VALUE + 100, ensuring it's ready before the first HTTP request hits.
• BoxLangViewResolver resolves logical view names using prefix + viewName + suffix.
• BoxLangView wraps HttpServletRequest/HttpServletResponse in a SpringBoxHTTPExchange, builds a WebRequestBoxContext (exposing all web scopes), injects the Spring Model into the variables scope, executes the template, and flushes to the response.

Clean separation of concerns. No magic you can't trace.

🎯 Get Started

git clone https://github.com/ortus-boxlang/boxlang-spring-boot-starter.git
cd boxlang-spring-boot-starter
./gradlew :test-app: bootRun

Open http://localhost:8080 and see BoxLang rendering live in your Spring Boot app.

📚 Full documentation: boxlang.ortusbooks.com

🔌 VS Code Extension: BoxLang VSCode Extension

💼 Professional Support

BoxLang is free and open source. Ortus Solutions offers commercial support, custom development, migration services, and enterprise modules for teams that need it.

👉 boxlang.io/plans

The post Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring appeared first on foojay.

Last week, Eclipse Foundation and Payara hosted Jakarta Agentic AI, An Open Conversation, an open house Jakarta TechTalk session, exploring a brand new initiative under the Eclipse Foundation. If you could not join us live, the full recording is now available.

What is Jakarta Agentic AI?

Jakarta Agentic AI is an exploratory project looking at how AI agents could be built, deployed and run within Jakarta EE runtimes. As AI systems increasingly move from simple inference to autonomous, agent-based behaviour, the question becomes how these systems fit into enterprise Java environments that value reliability, security, and portability.

Find Jakarta Agentic AI on GitHub

What we discussed in the session

During the conversation, panel members actively involved in the project – Reza Rahman (Jakarta EE Ambassadors, Payara), Tanja Obradovic (Eclipse Foundation), Mike Redlich (Garden State JUG, InfoQ), Luis Neto (Payara) & Dominika Tasarz (Payara) – covered topics including:

• What agentic AI means in the context of enterprise Java
• Why Jakarta EE is a strong foundation for experimenting with agent-based systems
• The early goals and design principles guiding the project
• How openness, flexibility and community input are being prioritised from day one
• Where feedback and contributions are most valuable right now
• The discussion reflects a project at a very early stage, focused on learning, collaboration and shared exploration rather than predefined outcomes.

Why this matters for the Jakarta ecosystem

Jakarta EE has long provided a stable, open platform for enterprise Java applications. As AI-driven systems become more autonomous and more integrated into business workflows, it is important that Jakarta remains an active participant in that evolution.

Jakarta Agentic AI is one way the community can explore how emerging AI patterns align with existing enterprise concerns such as:

• Portability across runtimes and vendors
• Security, governance and observability
• Integration with existing Jakarta EE applications and architectures

Watch the recording and get involved

If you are interested in the future of Jakarta EE, enterprise Java or agent-based AI systems, the recording is a great place to start. You will hear directly from the people shaping the project and get a clear sense of where input from the community can make a real difference.

This initiative is open, early and very much a work in progress. Your questions, ideas and concerns are not just welcome, they are essential!

• See the slide deck here.
• Find out more about the project.

The post Shaping Jakarta Agentic AI Together – Watch the Open Conversation appeared first on foojay.

The final version of Eclipse GlassFish 8 is here, released on 5 February 2026. As a GlassFish committer, I'd like to share what it brings for the Java community and some behind-the-scenes stories from the development process

Recently my company OmniFish published an announcement article introducing GlassFish 8.0.0 and covering all the major features: GlassFish 8 Released: Enterprise-Grade Java, Redefined

Here, I'd like to report on this article and also share some behind-the-scenes stories about my involvement in GlassFish 8 and why I think the new features matter for solving real pain points in the Java community.

What makes GlassFish 8 modern and developer-friendly

First and foremost, GlassFish 8 is fully compatible with Jakarta EE Platform 11 - meaning all Jakarta EE 11 APIs are available. Runs on Java 21 and 25. And will run on Java 29 LTS too as soon as it's out, that's our plan. On disk, the size is 150 MB, the size of the runnable GlassFish JAR is 87 MB. Requires 80 MB of RAM to run a REST microservices, or just 50MB of RAM if run using the runnable JAR.

GlassFish 8 brings all the modern advancements in Java and Jakarta EE. The biggest highlights are virtual threads and the new Data API. It also brings new Jakarta NoSQL support and MicroProfile Health. This empowers developers with new out-of-the-box APIs, mainly for simplified and flexible data access. And it also enable virtual threads in configuration to tune apps and monitor apps readiness and health using a standard mechanism. More functionality and options without additional dependencies in your apps and Maven/Gradle build setup.

The story of Jakarta Data in GlassFish 8

I was involved with the Jakarta Data implementation in GlassFish 8 from the very beginning and I'd be happy to share with you how it all happened. In the beginning, we had not easy way to support Data in GlassFish. None of the existing implementations were suitable. The one in Hibernate requires Hibernate ORM but GlassFish uses EclipseLink. The one in OpenLiberty is very tightly coupled with other OpenLiberty components. And JNoSQL only supported NoSQL, which was only half of the solution for GlassFish, which supports JPA.

In the end, I started looking into extending JNoSQL to also support JPA entities, to get a full solution into GlassFish. A simple proof of concept worked and it passed a few Data TCK tests. A year went by, and with some help of others in the community, JNoSQL passed the Java SE part of the Data TCK, with any JPA provider. Passing the whole Data TCK in GlassFish, including the part that tests integration with other Jakarta EE APIs, took a bit longer. As a result, you can now write applications that access database using Data repositories, and you can choose to use JPA entities or NoSQL entities backed by any driver that the JNoSQL project supports. For example Mongo DB or Cassandra.

Here's a simple example of a Data repository:

@Repository
public interface ProductRepository extends CrudRepository<Product, Long> {

    // Annotated query using @Find and @By annotations
    @Find
    List<Product> findProducts(@By("name") String name);

    // Custom query using Query Language
    @Query("WHERE price BETWEEN :minPrice AND :maxPrice ORDER BY price")
    List<Product> findProductsByPriceRange(BigDecimal minPrice, BigDecimal maxPrice);

    // Query defined by method name
    // Deprecated but supported for easy migration from similar APIs
    List<Customer> findByLastName(String lastName);
}

Product can be either JPA or NoSQL entity, it's your choice. Long is the type of the ID of the entity or the key, depending on the type of the database.

You can find detailed info with a lot more examples in the GlassFish Development Guide.

The story of virtual threads support in GlassFish 8

As you probably know, virtual threads originated as generally available feature in Java 21, long before GlassFish 8 was ready. GlassFish 7 supported Java 21 in the next version after it. First, OmniFish created a plugin for GlassFish that allowed using virtual threads for HTTP listeners. Then we collaborated with the community to improve it and donate it to Grizzly project that powers HTTP listeners in GlassFish. And then we found out that the Eclipse Grizzly project was dormant, without any active committers, and the whole effort got stuck.

Luckily, after a while, we managed to get Grizzly project merged into the GlassFish project, which allows us full control over it and its releases. It allowed us to release Grizzly 5 with the new virtual threads executor and integrate it into GlassFish. Turning into virtual threads is now as easy as running:

asadmin set server.thread-pools.thread-pool.http-thread-pool.virtual=true

Or, in Admin console, tick the "Use Virtual Threads" checkbox for the http-thread-pool.

Or, when running GlassFish JAR, place the following line in glassfish.properties:

command.vt=set server.thread-pools.thread-pool.http-thread-pool.virtual=true

Concurrent resources like managed executors also support virtual threads via the new "virtual" attribute in Jakarta EE annotations. We collaborated with Payara to support virtual threads in the Concurro component, which is used in both GlassFish and Payara Server.

GlassFish 8 beyond Jakarta EE 11

GlassFish 8 is not only about Jakarta EE 11. As I mentioned earlier, it also contains some MicroProfile 7.1 APIs: Config, JWT, REST Client, and Health. The latter one is newly added to GlassFish, since 7.1, released just 2 months before GlassFish 8.0.

And we went a little further to integrate Jakarta EE and MicroProfile in GlassFish. We saw a great synergy between MicroProfile JWT and Jakarta Security. In fact, MicroProfile JWT in GlassFish is already implemented as a custom Jakarta Security authentication mechanism. Jakarta EE 11 brings the ability to programmatically combine multiple built-in mechanisms exposed via standard qualifiers. However, MicroProfile JWT doesn't specify such a qualifier. So we did it. We add a qualifier to GlassFish API to allow injecting the built-in MicroProfile JWT mechanism so that you can combine it with other built-in mechanisms freely. For example, secure REST endpoints with JWT and other URLs via a login form.

Production-ready and supported

For a long time, there has been a narrative that GlassFish wasn't suitable for production environments. OmniFish has been working hard to change this. It started with GlassFish 7 where we tremendously improved stability. GlassFish 8, as explained in the article by OmniFish, makes it clear that this trend continued, with a lot of structural improvements in GlassFish 7.1 and 8. Since 2022, GlassFish has been on a new trajectory, with frequent updates and the backing of commercial support from OmniFish. This means companies can now confidently build and deploy mission-critical applications on GlassFish, knowing that we have a reliable and supported platform and strong partner to provide support and assistance.

If you remember GlassFish from a few years ago, you might have heard it wasn't suitable for production. That changed in 2022. Since then, we've been on a mission to improve stability, release frequently, and make GlassFish a solid choice for production workloads. GlassFish 7 brought major stability improvements, and GlassFish 8 continues that trend with structural improvements in 7.1 and 8. For companies that need commercial support, OmniFish provides that backing. But even without it, the open-source project is active, well-maintained, and has a growing community.

Dive deeper

Thank you for reading this far. I hope you enjoyed reading about my personal experience as a GlassFish developer and you now get my excitement from the new GlassFish release. I also highly recommend reading the GlassFish 8 announcement from OmniFish, and check out the GlassFish website for more info:

Read the OmniFish announcement about the GlassFish 8.0 release

If you want to get started with GlassFish 8 right away, here are some useful links:

• Download GlassFish 8
• OmniFish Blog
• OmniFish on YouTube

More information:

• GlassFish 8.0 Delivers Compatibility with Jakarta EE 11, Enhanced Security and Improved Data Access (InfoQ)
• GlassFish 8.0.0 Release Notes
• New Features in Jakarta EE 11, with Examples (OmniFish)
• Level up from Payara: Why GlassFish Is much better (OmniFish)
• The Eclipse Foundation’s Jakarta EE Working Group Announces Jakarta EE 11 Release (Eclipse Foundation)

OmniFish - Modern Jakarta EE Runtimes

• Eclipse GlassFish Support
• Support for Payara, Quarkus, Piranha
• Jakarta EE Consulting & Training

Contact OmniFish at their contact page, or LinkedIn at @OmniFishEE.

The post GlassFish 8 is here with Jakarta EE 11, virtual threads, and Jakarta Data appeared first on foojay.