CUBA Platform Roadmap 2018

Hello everyone,
The strategic roadmap for the coming year has just been published in our blog. Your comments and feedback are very welcome!


Very much looking forward to the new IntelliJ plugin. My original question has been answered about this, so if I’m reading correctly:

You’re creating a plugin for the IntelliJ platform. I can download this plugin and use it for the commercial and free editions of IntelliJ

You will also bundle it with IntelliJ Community as an all-in-one package that can be downloaded from your site.

Sounds great.

It’ll be interesting to see what you do with the new data layer. I’ve had trouble with the existing one (especially when it comes to refreshing data sources after a commit), so I’m hoping for something a little easier to work with.

And a new multitenancy add-on! Intriguing.
Kotlin support! Fantastic

And you’re going to support different frameworks for the responsive clients (Angular, React). No idea how that’s going to work.

But definitely some exciting times ahead.

I think it’s a great idea to go with with IntelliJ platform (my personal choice too), but I think a few might disagree.

Hi Ray,
This is correct.
Just one thing - Kotlin support is more of an opportunity for now, we cannot promise it this year.

Thanks :slight_smile:

Okay, thanks.

Good to know.


It’s a plan with many functionalities for the development of business products. Personally I like a lot IMAP, Zookeper, Dashboards, Data Import, Data drafts, but also to improve one or another current component such as Calendars and Gantt.
I think that at the functional level and the end user level, also improving security at the form level is a process that depends a lot on the knowledge of the programmer, since the user must know the name of each component that is on the screen to grant or remove permits.
Kotlin sounds interesting, but I’m still old school :yum: with Java pure and hard for a good time :joy: .
Anyway, very happy with what was planned in the future, going to Cuba was the best decision I could make.

1 Like

I am most excited about the enhanced BPM. That has been at the top of my wish list so thanks for that.

Do you plan to allow assigning tasks to Roles instead of just Users?

The new BPM sounds like an overhaul, so would would you recommend not using the current BPM framework (if possible) until the new one is available?

The IntelliJ integration is also very exciting. I have been a long time Eclipse user but I’m not afraid of change. But one concern: Is it a problem that certain features (for example Vaadin) are only supported in the Ultimate Edition? Will I still be able to use all the old Studio features in the future integrated/community edition?

Thanks again for the great product.


Any plans to use Vaadin 10 whose beta was just released?

There does not appear to be an easy way to migrate Vaadin 7 or 8 to Vaadin 10.

Vaadin 10 stops using GWT and instead uses Polymer and Web Components. They appear to think that this is a great improvement.

1 Like

Will the new data API allow for more than two levels of composition?

I like the idea, but Vaadin 10 is still in beta. I think I would rather see them stick with Vaadin 8 and plan for a switch over for the next major upgrade, once Vaadin 10 has been released and had time to bed in.

Just my opinion of course.

Thank you guys for your interest and your kind words!

Let me answer some of the questions.

In fact, there is an old issue that we still had no chance to implement. Most probably we’ll return to these relatively little improvements after finishing major changes in 7.0.

All current Studio features will work in both IntelliJ Community and Ultimate editions. The screen layout designer will basically be the same as the current one, but it will run inside the IntelliJ window next to the source code editor.

Definitely not in CUBA 7. Vaadin 10 is a very different product and it is now on too early stage for us to adopt. Besides, Vaadin promised to support version 8 for the next 4 years, so we’ll have enough time to see how it will all go.

Yes, it will.

It would be good if Cuba would address this more concretely.

At this point Cuba Platform is now out of the running as a new platform for development for my company. There is no way that I can sell it to senior management here when it will be obsolete in just four years.

Vaadin have not helped with this. They don’t appear to have an easy migration path for Vaadin 7 or 8 users.

See Migrating to Vaadin 10 and beyond | Vaadin for details.

Even Vaadin is recommending that you stick with version 8 if you want full functionality and stability, which tells me that Cuba should be wary of starting work with something that will take a few iterations to reach full maturity.

However, yes, sticking with version 8 forever would eventually lead to a dead end, but I don’t think they said they were going to do that.

The biggest problem with the current framework is that it’s not responsive, which means building two UIs. Vaadin 10 should fix that.


Konstantin, I’m also interested in this. We currently use the BPM engine with some additional customizations and up until this roadmap was published, were considering doing even more. Do you plan on still using Activiti, for instance? Do you recommend holding off on further customizations?

1 Like

Hi guys,

Regarding Vaadin 8, 10, etc.

Sorry if I wasn’t clear enough. Of course I didn’t mean that we are going to stay with Vaadin 8 forever. We successfully migrated from Vaadin 5 to 6 and then to 7 a while ago, and through all these migrations our GUI API and XML schema remained relatively stable, at least comparing to changes in Vaadin. Now we are working on the migration to Vaadin 8, and again we take all the heavy lifting on ourselves. For example, the data binding in Vaadin 8 has changed dramatically, it now provides only one-way bindings. So we are now implementing the whole data binding mechanism on our side for to keep your code compatible.

We will start thinking about further migrations as soon as we complete the current one, probably next year (2019). Will it be Vaadin 10, Vaadin 20, a fork or a hypothetical homegrown framework - I simply don’t know at the moment. Anyway, we understand the importance of the compatibility for long-living enterprise projects, so it is always our priority.

Regarding the BPM addon. We are now evaluating two ways of improving it:

  1. Continue with the current implementation based on Activity. Upgrade to the latest version and put efforts into improving the API and usability.

  2. Switch to Camunda or Flowable engines and modelers. Make significant changes in the integration architecture if we decide that it is needed.

Both ways assume that the current processes will continue to run. In the second approach, a new BPM-2 addon will appear, but the current one will be supported too, just without further active development. So I wouldn’t recommend you waiting for the new implementations if you are already using the BPM addon or planning to employ it in the near future. All your processes and business logic will continue working as long as they use the current public API, possibly requiring minor migrations. However, I’m not sure about your customizations, it depends on what you are doing.


Hi there, Konstantin

What do you see as the advantages of going from 7 to 8, rather than sticking with 7 then going to something more responsive a bit later?

Is there something in version 8 that is a must-have?


This is the best forum setup I’ve ever seen. Is it your own work?

1 Like


We want to use Vaadin 8 in the platform because of several important features:

  • New URL routing mechanism
  • Support for HTML5 History API
  • TreeGrid component

Also, we want to get latest updates due to bug fixes, performance improvements and security patches.

In addition, there are things that we would like to use in our projects and products:

  • Drag and drop in Grid
  • Drag and Drop interoperability with other apps
  • HTML imports
  • Eager field validation
1 Like

Thanks for the update, Konstantin. This is all good to hear! Keep up the great work over there.

Re Kotlin support, I understand that for you it is only an “opportunity”, from a purely developer perspective, and I agree.

But let me add that it could (potentially) be huge for marketing. I mean, Kotlin is very hot at the moment, especially after the official Google adoption for Android, or Gradle before that, etc.

Adding support to Kotlin in the gradle plugin (so for IDE only development) is a little effort IMHO, on the other hand I know that will be harder adding full support to Studio (automatic code generation, etc.).
In the meantime you could add Kotlin support to the IntelliJ plugin, so to have some “magic” at least in the IDE.

Announcing even a small step towards full Kotlin support, will then lead to mentions in popular Kotlin channels, communities, etc. raising the awareness of CUBA.

Just my 2c :wink:


Something else I’d be interested to hear more about is the support for alternative Javascript frameworks (though I can understand that it might be too early to talk about that). I’ve played around with the Polymer stuff, and I see it as something to add components to another app framework, rather than something I’d build a whole front end with. So support for a React or Vue module as part of the Cuba project would be great.

Our aim is to introduce more generic support for front-end clients in terms of build system and Studio templating. It will be possible to add client based on arbitrary framework, though Polymer will remain basic. I hope I can reveal more details soon.