This page was moved to to Version 2
Click in the link above if you are not automatically redirected in 10 seconds.

This is a summary of features we do have in mind.

Getting ready for Java 11

For now we want Isis 2.x releases to run on JRE 8, but we need to be prepared for the coming long-term-support release of Java 11.

ISIS-1277 - Getting issue details... STATUS

We are keeping an eye on experimental builds utilizing the Java module path, while at the same time further try to get rid of 3rd party libraries. We've started to remove use of guava and began to utilize the Java 8 Stream API.

Extending persistence layer support

Current version does support JDO on top of DataNucleus (DN). We are considering to also support JPA. Supporting JPA on top of DN as a first initial step should be quite easy, and the first thing to be tackled.

ISIS-849 - Getting issue details... STATUS

Decoupling the framework from DN in order to support Spring Boot is another thing.

Jakarta EE

With version 2.0.0-M1 we enabled the framework to run on JEE platforms. Currently missing is proper documentation on best practices and how to setup your IDE.

ISIS-1767 - Getting issue details... STATUS

Though not specific to JEE but related, we also need to push the technique of skinny-war deployment.

Simplify setup for web.xml deployment descriptors

Since the Servlet 3.0 standard deployment descriptors can be replaced with an alternative solution utilizing annotations. We experimented with this but found that skinny-war-deployment could get more complicated, so at least we can simplify the setup.

ISIS-1895 - Getting issue details... STATUS

Improve the metamodel cache management and speed-up bootstrapping

The cache management we have with ObjectAdapter, might be simplified such that we just work with java.lang.Object so far as possible. We would have a "disposable" ObjectAdapter that we instantiate around an Object whenever we need it - to access into the metamodel - and then throw it away after. Or perhaps eventually we might not need ObjectAdapter at all, just simply use #getClass() to look up the ObjectSpecification.

It might also be useful to be able to serialize the metamodel into some sort of flat file, eg XML. One reason for doing this is as a safety net - to allow refactorings of the metamodel building and check that the output is still the same. A serialized metamodel might also be useful for tooling/static analysis.

ISIS-1974 - Getting issue details... STATUS

ISIS-1976 - Getting issue details... STATUS

related: Wrap Domain Entities by default

Quoting Dan:

As you know, we also have the ability to wrap domainObjects, used for testing and for emitting events when calling a method action from another class. One thing we've said we'd like to do (Oscar Bou pushed for this, they do this as a matter of course in their app) is to automatically wrap all domain objects. The wrapper then ensures that the object's invariants are not violated. We had ideas of maybe relaxing this rule for calls from "within" the module (however we define a module), but always enforcing it for inter-module calls.

Anyway, it occurs to me that maybe the functionality that's within ObjectAdapter could instead be moved into the wrapper object. As mentioned in another comment on this PR, the ByteBuddy/Javassist creates a subclass and can mix-in other interfaces for the wrapped object to implement - namely WrappingObject. This is currently a marker interface, but it could instead have the responsibilities of ObjectAdapter, eg to obtain the oid and the ObjectSpecification. In other words, the domainObject and the ObjectAdapter would in effect be the same object. (Actually, since WrappingObject is in the applib, probably we would have a further subtype which is visible only to the runtime, eg "WrappingObjectRuntime")

This would then mean that wherever today we pass around an ObjectAdapter, instead we would pass around a WrappingObjectRuntime.

ISIS-1807 - Getting issue details... STATUS

UI enhancement: support for more complex dialogs

We may introduce a new kind of support action, that contributes to action parameters: Delegates ISIS-1509 - Getting issue details... STATUS

UI enhancement: allow actions to be invoked for rows on a table

We envisage an additional column which provides "common" actions as a drop-down that can be invoked against the row instance without having to navigate into the object first. A simple modal dialog could suffice.

UI enhancement: allow to "peek" at domain objects

Another idea of saving the user from having to navigate away, is to somehow let the user "peek" at the main details of a domain object. This could be within a fieldset, or it could be in a row of a table. Perhaps this is enabled by the presence of supplementary xxx.layout.xml, eg Customer.row.xml or Customer.peek.xml which identify the properties to be rendered.

UI enhancement: "tab per item" for small collections

For small collections of domain objects, these could be presented as "tab per item" with full details, rather than "row per item" as with current tables.

UI enhancement: allow for entering grids of data

This is typically for bulk entry of data which is then validated all together.

Quoting Dan:

I haven't figured out the coding model yet, but it might be to resurrect the "validate()" supporting method on the domain class to check that all data entered is correct.  I see this being used with view models rather than with entities. There would also need to be some sort of "save()" method that would allow the view models to post their state into actual entities.

Authentication: support for OAuth 2.0

OAuth 2.0 support is a thing modern frameworks should not lack. We have no concrete plans yet but talked about integrating with [keycloak](

ISIS-1297 - Getting issue details... STATUS

UI architectural redesign

Decouple current Wicket UI from the framework's core components.

Quoting Dan:

At a rather grander scale, one long-term vision I have is to replace our Wicket UI with one that works across the REST API.  This is the direction that the .NET NakedObjects framework has taken.  In fact because both frameworks use [Restful Objects]( as their API (albeit slightly different dialects) then it ought to be possible for us to support their UI.  But I'd also like us to have our "own" Rest UI also, with the explicit goal of making it easier for developers to customise the UI ... it should be easy to move from fully generic to fully  customised, or any point in between.  At the moment the Wicket UI makes this too hard to do.  Having a REST UI based on Angular.x (and eventually, web components) will hopefully improve this. Sebastian Slutzky [...] is making steady progress on this. It'll take a while yet before we get to feature equivalence with the Wicket UI, though.

Allow for multiple backends to feed the UI with data.

Quoting Dan:

Moving to a REST UI also enables another idea, which is that of composite UIs.  At the moment the framework assigns an OID to every domain object, be that a domain service, an entity or a view model.  This is basically the object type (as in @DomainObject(objectType=... ) or @DomainService(objectType=...) ) along with an ID (for an entity, it's datastore Id and for a view model, a seriailsation of its internal state). With REST this OID is part of the URL, with the rest of the URL in effect specifying the "backend" that owns the domain object.  My idea is that the UI being rendered is made up of state that could be from multiple backends; they are all just URLs, after all.  What I haven't figured out is how to define references from one backend app (eg order_mgmt) to another backend (eg customer).  And I also don't know how to do mixins (eg  so that order_mgmt could contribute the "recentOrders" collection to a representation of a customer).  But if we could figure this out, then it could be possible to use an Isis REST UI on top of multiple backend microservices - all they would need is a REST API.  This also motivates [... as mentioned above] supporting different backend persistence runtimes such as SpringBoot/Hibernate and Axon/CQRS.

Feature Showcase

Deprecation Tracker


  • - entire enum, along with @Bulk annotation.
  • - entire annotation, use @Action(commandExecuteIn=...) instead
  • - entire annotation, use @Action(commandPersistence=...) instead

  • entire package.  These event classes supported only by WrapperFactory; redundant as @Xxx(domainEvent=...) on member achieves much the same effect using event bus


  •  - various methods to simplify API
  •     add(...) - use addResult(...) instead

  • -remove unused constructors  (8 usages found)

  • - deprecated methods, have overloads in BookmarkService2 subtype [suggest we retain these for now]

  •  - methods for working with interaction events (remove with those event types)
  •     flushActionInteractionEvents()
  •     peekActionInteractionEvent()
  •     popActionInteractionEvent()  
  •     pushActionInteractionEvent(ActionInteractionEvent<?>)

  • - push down to subtype, retain overloads for now


  • - remove ?  [suggest we retain the Snapshot service for now]

  • No labels