[hibernate-dev] New disruptive API possibilities in Java8: what do we do?

[Sanne Grinovero]

Hi Jakub,
welcome!

Some comments inline:

On 15 August 2014 17:28, Jakub Narloch <jmnarloch at gmail.com> wrote:
> Hi Sanne,
>
> I've already grab the code and do some experiments by implementing the
> proposed API:
>
> https://github.com/jmnarloch/hibernate-orm/tree/java-8-optional
> https://github.com/jmnarloch/hibernate-orm/tree/java-8-streams
>
> Only to find that the build system itself it not yet ready to be moved to
> Java 8, by that I mean
>  - animal sniffer is not yet capable to generate the Java 8 signatures -
> (http://jira.codehaus.org/browse/MANIMALSNIFFER-45) - (that might be a minor
> thing)

Assuming this will be handled in a separate experimental module, we
could disable the animal sniffer in that one.
It's a known problem which affects our CI builds too: Animal Sniffer
relies on an older version of ASM which isn't able to decode the class
format generated by Java8.
I'm not sure how minor that is: there are newer ASM versions available
which support it but the API changed too so someone would need to work
on animal sniffer; it's certainly minor for us as this plugin is not
important in this context: it's meant to help spotting backwards
compatible changes and we know it breaks ;-)

>  - Gradle 2.0 or to be more exact Groovy 2.3.2 has an bug within
> (https://jira.codehaus.org/browse/GROOVY-7023 - well that is not exactly a
> bug that's a feature ;)) that makes the hibernate-enhance-maven-plugin build
> to fail. This is kind of blocker for now.

Thanks. I'm not an expert of Gradle at all, Steve might be able to help?


> As you may notice I've made the changes in the core module, which is not
> exactly the direction you would wish to take due to backward compatibiility
> with older JVMs. So since this changes affect so much basic API, could you
> deliberate more how would you expect this to be handled? What would be your
> approach?

Steve Ebersole is the project lead so I'm looking forward to his reaction.
What I wrote in the forum post, to create a wrapper and allow a bit of
rapid prototyping is I hope acceptable but it's his decision.

I suspect we'll want to at least maintain (some version) of Hibernate
compatible with Java7 for years still, and it would be good to not
have to backport a lot, i.e. to not have to maintain a separate
branch.
So if we start with some kind of experimental module separate from the
main jar which users can optionally use, this module could eventually
drop the "experimental" label but still be built separately: we could
then eventually merge it in the core jar but with the benefit of
postponing this decision.

Having already large independent projects such as Hibernate Search and
Hibernate OGM which deeply tie into the ORM lifecycle, but also
wrappers like the JPA compatibility layer (EntityManager) is I hope a
sign of maturity of the extension points: it should be easy to keep
things nicely isolated, and we can definitely help.

Also considering that all these other projects build on top of the ORM
API and integration points, merging such changes right away would
require those other projects to keep following up with changes; that
would slow us down too much if the API keeps changing - as I initially
expect while more people will join the brainstorming.


> I think that the migration to Java 8 is either way unavoidable and will
> happen at some point in time, If that's ok with you I will create an
> umbrella JIRA task, that could gather ideas for API changes.

Yes please do!

Regards,
Sanne

>
> Regards,
> Jakub
>
> 2014-08-15 13:02 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> As in this forum post:
>>  - https://forum.hibernate.org/viewtopic.php?f=1&t=1036010
>> and some conversations I catched on the twitter radar, SO and other
>> posts, lots of people are wondering what our "amazing plans" are
>> around powerful innovations we could to thanks to Java8.
>>
>> I understand we're all quite stretched and I don't think I can take
>> the lead on this either, but I think we should at least provide
>> potential contributors with some options to experiment and see where
>> we can get.
>>
>> As soon as we have confluence we could have a page to describe our
>> constraints and possibly to collect nice ideas. Beyond that, what
>> about having some kind of sandbox project for an ORM wrapper (and
>> maybe others) to play with experimental API proposals?
>>
>> I would love to be able to suggest some "get prototyping here" plan to
>> smart proposals like the one in this forum post.
>>
>> --Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
>
> 2014-08-15 13:02 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> As in this forum post:
>>
>>  - https://forum.hibernate.org/viewtopic.php?f=1&t=1036010
>> and some conversations I catched on the twitter radar, SO and other
>> posts, lots of people are wondering what our "amazing plans" are
>> around powerful innovations we could to thanks to Java8.
>>
>> I understand we're all quite stretched and I don't think I can take
>> the lead on this either, but I think we should at least provide
>> potential contributors with some options to experiment and see where
>> we can get.
>>
>> As soon as we have confluence we could have a page to describe our
>> constraints and possibly to collect nice ideas. Beyond that, what
>> about having some kind of sandbox project for an ORM wrapper (and
>> maybe others) to play with experimental API proposals?
>>
>> I would love to be able to suggest some "get prototyping here" plan to
>> smart proposals like the one in this forum post.
>>
>> --Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>