Red Hat

Jigsaw’s Missing Pieces

Red Hat, with its years of experience supporting large scale software systems, has always been a strong proponent of modular Java. Over time, we have delivered many products and solutions that provide and support popular modular environments like Java EE, and OSGi. Since 2011, we introduced a flexible modular implementation called JBoss Modules, which is capable of supporting the core modularity needs of both Java EE and OSGi, but is usable in a standalone manner, without the need to bring in the full platform those specifications require. JBoss EAP and WildFly are built on this technology, which is a major contributor to the flexible runtime they provide.

While the above technology allows us to meet the needs of our customers as well as our own, we are hopeful that JSR-376 (Java Platform Modular System), also known as Project Jigsaw, will provide a standardized solution that could be embraced by the full Java community and lead to better software and better interoperability. Additionally, the Java EE expert group has long wanted to improve the overall modularity of the platform, but has deferred these goals hoping to leverage the common SE technology to be introduced by the above JSR.

These goals were widely shared as noted in the agreed upon JSR submission. Relevant sections include:

  • “This JSR will define an approachable yet scalable module system for the Java Platform. It will be approachable, i.e., easy to learn and easy to use, so that developers can use it to construct and maintain libraries and large applications for both the Java SE and Java EE Platforms.”

  • ”This JSR targets Java SE 9. We expect the module system to be leveraged by Java EE 9, so we will make sure to take Java EE requirements into account.”

  • ”Some members of the Java community have already invested significantly in applications and frameworks built on top of the OSGi Service Platform. The module system will provide a means for an OSGi kernel to locate Java modules and resolve them using its own resolver, except possibly for core system modules. This will enable OSGi bundles running in such a kernel to depend upon Java modules.”

Unfortunately, Jigsaw (JSR-376’s implementation), suffers from a number of significant gaps which may prevent these goals from being fully achieved. As currently defined, Jigsaw is not capable of fully supporting Java EE, OSGi, or any other system with similar dynamic capabilities. However in recent weeks, there have been a number of proposals and discussions to address these problems.

We believe it’s critical that these gaps are addressed, as the existence of multiple incompatible standards would likely fragment the Java ecosystem. Application developers would be forced to artificially choose between a totally new static oriented universe of software based on Jigsaw, and the already existing universe, which handles more use-cases and encompases traditional Java SE, Java EE, and OSGi. Framework developers may attempt to support both, but they will likely incur additional cost and potential defects to do so. Finally, divergence will likely increase as standards such as Java EE 9 are forced to consider other options.

While there are a number of issues under discussion, they can be categorized into the following areas:

  1. Reflection is disallowed from operating on non-exported types, even with the use of setAccessible [1]. This breaks anything using dependency injection or custom serialization (Java EE, Hibernate, Spring, CDI, JAXB, etc). The current proposal put forth by Oracle addresses this by allowing the user to declare packages “open” for reflection.

  2. Jigsaw has only limited support for the dynamic introduction and alteration of modules [2]. This prevents modeling Java EE deployments or OSGi bundles as sets of modules as both require support for dynamic installation and hot redeployment. While layers could potentially act as a solution, layers do not support peer-to-peer inter-layer dependency graphs [3]. Additionally everything is eagerly loaded, with a complete graph required to be known up front [4]. This problem is still under active discussion, with some partial proposals. If certain hooks are added, it may be possible to bypass Jigsaw’s native dependency resolution to work around the issue. On the other hand, this has some drawbacks. It requires replicating Jigsaw’s resolution in a dynamic fashion, and it will likely hide information from reflection that a developer might wish to see, but it opens the door for advanced/specialized behavior.

  3. Restrictions that make interoperability with alternative modular systems difficult. [5] [6] [7]. Bypassing or mangling Jigsaw’s dependency resolution would allow for a custom implementation to provide support for cyclic dependencies [5]. There is a proposal to allow more flexibility in terms of allowed characters and escaping with module names [6].

In summary, we believe fragmentation of the Java ecosystem must be avoided, as it will overly burden Java developers and stifle innovation. We remain hopeful that continued progress on these issues will not only prevent such an outcome, but allow the full Java community to embrace and benefit from standardized modularity.

WildFly 10.1 is now available!

WildFly 10.1 is officially complete and available for download!

Major new features include:

  • Out of the box HTTP/2 support with no JVM flags required !

  • TLS cert auto-generation

  • Load-balancing profile is now in our default domain.xml config

  • Support for clustering node discovery on Azure (jgroups AZURE_PING)

Additionally there was a massive 324 issues resolved in this release!

Out of the Box HTTP/2 and TLS

Unique to WildFly, is that HTTP/2 now works without any special JVM flags (even on Java 8!), configuration changes, or keystore changes. You simply point your browser at port 8443 and WildFly will automatically generate a self-signed TLS cert for you, and negotiate HTTP/2 if your browser supports it (most do). When you are ready to deploy in production, you simply update the keystore with whatever cert you would like to present to your users.

Load-balancing Profile

In order to make it even easier to get started with load-balancing, we added a profile to the default domain.xml file, called "load-balancer". You can now build a fully clustered topology using just our default profiles in domain mode, creating a server with the "load-balancer" profile, and a set of backend servers using the "full-ha" profile.

Jira Release Notes

The full list of issues resolved is available here.

WildFly 10 Final is now available!

WildFly 10 Final is officially complete and available for download! WildFly 10 adds a number of capabilities and improvements to the powerful, yet lightweight, open-source application server.

Java EE 7

As with WildFly 8 and WildFly 9, WildFly 10 implements the Java EE 7 Full and Web Profile standards.

Builds on WildFly 9

In addition to the key features mentioned below, this release includes all the major features from 9, such as HTTP/2 support and a built in load-balancer.

Java 8+

Java 7 support has been discontinued allowing for deeper integration with the Java 8 runtime. While Java 9 is still in development, this release runs on the current development snapshots.

ActiveMQ Artemis

A little over a year ago, the HornetQ codebase was donated to the Apache ActiveMQ project, and the HornetQ community joined to build a next-generation messaging broker. This materialized in the first major release of the ActiveMQ Artemis project. ActiveMQ Artemis includes many new features, and also retains protocol compatibility with the HornetQ broker. WildFly 10 includes this new exciting project as its JMS broker, and due to the protocol compatibility, it fully replaces the HornetQ project.

Offline CLI Support for Domain Mode

In addition to the offline CLI support for standalone mode, you can now launch a host-controller locally within the CLI. Using the embed-host-controller command you can edit the content of domain.xml and host.xml without launching additional processes or opening network sockets.

JavaScript Support with Hot Reloading

WildFly 10 includes the Undertow JS project, which allows you to write server side scripts that can pull in CDI beans and JPA Entity Beans. This can be quite useful for throwing together a quick view layer (perhaps using a templating language like Mustache, or a framework like Angular), or quickly developing a REST endpoint. You can edit the JS files live on the system, and they are dynamically reloaded, without having to redeploy your application.

For more details see the following blog post: Using Server Side Javascript with Wildfly

HA Singleton Deployments

WildFly 10 adds the ability to deploy a given application as a "singleton deployment". This is a new implementation of a feature that existed in AS 6.0 and earlier. When deployed to a group of clustered servers, a singleton deployment will only deploy on a single node at any given time. If the node on which the deployment is active stops or fails, the deployment will automatically start on another node. The policies for controlling HA singleton behavior are managed by a new "singleton" subsystem. A deployment may either specify a specific singleton policy or use the default subsystem policy. A deployment identifies itself as singleton deployment via a /META-INF/singleton-deployment.xml deployment descriptor (the schema for which can be found on GitHub), which is most easily applied to an existing deployment as a deployment overlay. Alternatively, the requisite singleton configuration can be embedded within an existing jboss-all.xml.

HA Singleton MDBs and MDB Delivery Groups

Another advanced clustering capability in WildFly 10, singleton MDBs supports infrastructures which require message delivery on only single host at a time. In the event of a failure, another host in the cluster with the same application deployed will take over message processing.

MDB delivery groups allow an administrator to selectively enable and disable a "delivery group" via a management operation, which is composed of one or more MDBs. This capability supports environments with an external custom failover mechanism. As with all management operations, these calls are accessible from the many management interfaces of WildFly, including the CLI, a Java API, and an HTTP/JSON API.

SLSB and MDB Automatic Pool Sizing

WildFly now pools stateless session beans by default, using a pool size that is computed relative to the size of the IO worker pool, which is itself auto-tuned to match system resources. Additionally MDBs now use a pool which is similarly tuned to a value derived from the number of CPUs on the system. Previously stateless sessions beans did not pool by default, and MDBs used a pool with a small hard-coded size. The values chosen are logged to an INFO message as part of startup. Manual tuning is still supported using the same max-pool-size attribute.

Note that the default configurations shipped with WildFly 10 enable automatic pool sizing by using the derive-size attribute. Configurations used with previous versions of WildFly will need to be updated to take advantage of this capability. The intention is to preserve existing behavior as past configurations may have been explicitly tuned to best match deployed applications. While this capability improves the default pool size, achieving maximum performance would likely require specifically setting the size to match the patterns and needs of the application.

Migration Operations for Discontinued Subsystems

To help users migrating from old subsystems such as jbossweb (AS 7.1), jacorb (WildFly 8), and hornetq (WildFly 9), we have introduced a set of management operations that can convert old configuration over to the new respective subsystem equivalent. Since these operations migrate the underlying management resource model, old CLI scripts or custom provisioning systems can also take advantage of these.

Capabilities and Requirements

Subsystem developers now have the ability to negotiate interaction with other subsystems in a more pluggable way. This allows for subsystems to have dependencies that can be satisfied by more than one subsystem, which is particularly useful in providing multiple implementations of the same underlying capability. Additionally it leads to improved error reporting. Instead of a failure being reported at the service layer, which is how the WildFly runtime is mapped, it is instead reported at a higher level that is easier to connect to the server’s configuration. As an example, a missing socket binding is now reported as a missing socket binding, as opposed to a list of services with an unsatisfied dependency. Expect to see overall error reporting in WildFly improve as subsystems begin to adopt this ability.

For more information, see the development guide.

Hibernate 5

Hibernate 5 includes several additional improvements, such as greatly improved bytecode enhancement, which is a useful performance optimization. Additionally a number of API improvements are provided, including use of generics in Hibernate Native, and an improved SPI for second level cache providers. Also included are new and improved schema update and validation tooling.

Powershell scripts

Powershell scripts ware added to bin directory of WildFly distribution and are meant to fully replace .bat scripts in future releases. They provide same functionality as .bat scripts and additionally address handful of issues found in batch scripts.

WildFly Jira Release Notes

The following table has the complete list of issues resolved against the "full" branch during the development of WildFly 10.

Table 1. WildFly 10 Releases
Release Notes Issues Resolved

10.0.0.Final

Full JIRA Release Notes

71

10.0.0.CR5

Full JIRA Release Notes

156

10.0.0.CR4

Full JIRA Release Notes

71

10.0.0.CR3

Full JIRA Release Notes

29

10.0.0.CR2

Full JIRA Release Notes

40

10.0.0.CR1

Full JIRA Release Notes

107

10.0.0.Beta2

Full JIRA Release Notes

42

10.0.0.Beta1

Full JIRA Release Notes

63

10.0.0.Alpha6

Full JIRA Release Notes

39

10.0.0.Alpha5

Full JIRA Release Notes

41

10.0.0.Alpha4

Full JIRA Release Notes

37

10.0.0.Alpha3

Full JIRA Release Notes

33

10.0.0.Alpha2

Full JIRA Release Notes

10

10.0.0.Alpha1

Full JIRA Release Notes

30

WildFly Core Jira Release Notes

The following table has the complete list of issues resolved against the "core" container of WildFly 10.

Table 2. WildFly Core 2 Releases
Release Notes Issues Resolve

2.0.8.Final

Full JIRA Release Notes

26

2.0.7.Final

Full JIRA Release Notes

2

2.0.6.Final

Full JIRA Release Notes

9

2.0.5.Final

Full JIRA Release Notes

9

2.0.5.CR1

Full JIRA Release Notes

19

2.0.4.Final

Full JIRA Release Notes

12

2.0.3.Final

Full JIRA Release Notes

11

2.0.2.Final

Full JIRA Release Notes

16

2.0.1.Final

Full JIRA Release Notes

2

2.0.0.Final

Full JIRA Release Notes

7

2.0.0.CR9

Full JIRA Release Notes

12

2.0.0.CR7

Full JIRA Release Notes

34

2.0.0.CR6

Full JIRA Release Notes

16

2.0.0.CR5

Full JIRA Release Notes

4

2.0.0.CR4

Full JIRA Release Notes

6

2.0.0.CR2

Full JIRA Release Notes

16

2.0.0.CR1

Full JIRA Release Notes

6

2.0.0.Beta7

Full JIRA Release Notes

20

2.0.0.Beta6

Full JIRA Release Notes

16

2.0.0.Beta5

Full JIRA Release Notes

21

2.0.0.Beta4

Full JIRA Release Notes

1

2.0.0.Beta3

Full JIRA Release Notes

13

2.0.0.Beta2

Full JIRA Release Notes

5

2.0.0.Beta1

Full JIRA Release Notes

2

2.0.0.Alpha13

Full JIRA Release Notes

10

2.0.0.Alpha12

Full JIRA Release Notes

4

2.0.0.Alpha11

Full JIRA Release Notes

14

2.0.0.Alpha10

Full JIRA Release Notes

9

2.0.0.Alpha9

Full JIRA Release Notes

31

2.0.0.Alpha8

Full JIRA Release Notes

9

2.0.0.Alpha6

Full JIRA Release Notes

14

2.0.0.Alpha5

Full JIRA Release Notes

26

2.0.0.Alpha4

Full JIRA Release Notes

10

2.0.0.Alpha3

Full JIRA Release Notes

18

2.0.0.Alpha2

Full JIRA Release Notes

4

2.0.0.Alpha1

Full JIRA Release Notes

12

back to top