Hi,
i recently read this article about cuba and at the end of the article it says a little about the future plans for the platform. Since the article is already from beginning of 2014, it seems all things are already implemented. I would like to know, if how have any (in)official roadmap for further releases (especially major ones). Perhaps you already have a list of improvements that you come up internally or something.
Bye,
Mario
Hi Mario,
Thank you for your interest.
The article you mentioned looks like an automatic translation of our article in Russian published more than a year ago. We didn’t approve it and even were not aware of its existence. Please ignore this and similar posts on suspicious websites, as they can be outdated and confusing because of terrible translation.
We are now publishing new articles on our website quite regularly. For example, check out the latest one about product customization. We are also going to write more technical stuff about various platform features and use cases.
As for our plans, they are not a secret. In brief:
Platform version 5.6 (middle of August):
This is just a list of major features. If you are interested in details, feel free to ask.
Hello Konstantin,
you might be right with the artice.
As for the upcoming releases you wrote, that the OR-Mapper will be replaced. With a grails background, im not aware of all the details in the java OR-Mapper world, but as i know the OR-Mapper marketshare, Hibernate seems to be the big player, right? If this is true, is this an active decision against hibernate and if so, why (i’m not a hibernate fanboy by any kind, just asking)?
By the way, are there any possibilities, to get some syntactic sugar around orm queries in the java world (and especially in the cuba platform) as you would probably get with something like rails “activerecord” or “GORM”. Spring Data for example?
Another thing that i would think of and not really sure how the current state is, would be “mobile”? Any thoughts on that?
Hibernate seems to be the big player
You are absolutely right, Hibernate is by far the most widely used Java ORM. But it lacks one feature which we think is crucial for enterprise applications - ability to load “partial” entities. Partial means with not all local attributes populated. Key points are:
get some syntactic sugar around orm queries
If you mean some kind of typesafe queries, like JPA Criteria API - we don’t support it yet. They are undoubtedly good for writing dynamically changed queries and for refactoring. But they are harder to write and read than JPQL strings. Besides, with the Filter component and the datasource query filter facility you don’t need to write dynamic queries often, at least for UI - it is generated automatically by filter conditions.
But we are open for discussion, please share your thoughts.
As for “mobile” development support - this is the hard question. We have strong intention to implement our Generic UI for mobile platforms to be able to build mobile applications in the same way as web/desktop. But unfortunately, there is no such thing as Java SE on mobiles. So we are now at the early stage of researching possibilities.
At the moment, we recommend creating native mobile apps or mobile-friendly websites and integrating them with CUBA middleware through REST API.
Hello Konstantin,
interesting, how you think about hibernate. i’ve never put it that way. To play devils advocate here, one could ask how it had come to such a adoption curve, since the whole ecosystem in which it occurs: “The whole Java EE Land”, is mostly used by so called “enterprise developers” to create so called “enterprise applications”, right? 
Seriously, the arguments seems resonable and indeed, it is a pretty cool feature to just load the data, that is needed, like in the datasource screen definition.
With syntactic sugar, i meant something that is even more “sweet” like the JPA Criteria API (because, in fact, if you compare a plain old typed Criteria Expression to something like dynamic finders in Grails, it seem to be quite “sour”). Grails e.g. has Where Queries or in rails active record: dynamic finders (which is deprecated nowadays…)
Because of this, i thoug of the posibility to use Spring Data, to get something similar to this. And this whole things is just for business logic, of course. Since i’m not that familiar with the cuba APIs for getting data into business logic, it might be possible, that this use case is not that big, because of the mentioned generic filter solution.
Bye,
Mario
Hi Mario,
Actually, Hibernate provides some means to restrict the number of attributes fetched - you can list the attributes in the “select” clause of your JPQL explicitly. But the result of such query will be a flat structure - a map or a DTO. So you won’t be able to map the result to an object graph. Apparently such flat structures can be used instead of graphs - but I think it’s not Java way.
To be honest, I wasn’t aware of Spring Data until now. Its approach for facilitating data access looks great if your business logic has some frequently repeated data loading patterns. One of my colleagues has confirmed that he used Spring Data in experiments, so most probably you can use it in CUBA middleware as is. But you will definitely lose our “views” mechanism and hence partial entities mentioned above.
Another option would be to implement a similar “higher abstraction layer” on top of CUBA JPQL Query. It doesn’t seem difficult to create dynamic proxies for interfaces with methods with descriptive names or annotations and create JPQL under the hood. In this case, our views mechanism can be fully employed, as well as all other non-standard features. For example, in the future EclipseLink-based version of CUBA entity listeners are completely reimplemented on CUBA layer because the standard implementation is too dumb to be useful.
If you go for integrating Spring Data, please start another topic for further discussion of and related issues. I’m going for vacations and will be completely unplugged for 2 weeks, but my colleagues will help you in case of troubles with integration.
By the way, if you prefer Groovy over Java (which I can conclude from your experience), you can code in Groovy when creating CUBA screen controllers and middleware beans. If you are interested, again, please start a new topic and we will help you to configure the project.