Re: [hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net

Hi Sanne, I would second Dalibor's request to share your feedback! Thanks,Rory On 19/05/2017 13:06, dalibor topic wrote: > On 19.05.2017 13:49, Sanne Grinovero wrote: >> Hi Rory, >> >> thanks, I'll update our ci.hibernate.org build servers today. >> >> Status reminder: we had good progress some

Re: [hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net

Hi Rory, thanks, I'll update our ci.hibernate.org build servers today. Status reminder: we had good progress some months back, but since Gradle broke again we're stuck on our flagship project (Hibernate ORM). Some progress can be monitored here: - http://ci.hibernate.org/view/JDK9/ Please bear

[hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net

Hi Sanne, *JDK 9 Early Access* build 170 is available at the new location : - jdk.java.net/9/ A summary of all the changes in this build are listed here . Changes which were introduced since the last availability email that may be o

[hibernate-dev] [Search] Deprecating @Boost and related options

Index time boosting is deprecated in Apache Lucene 6, and will be removed in Lucene 7. While we currently are using Lucene 5, since we'll likely jump directly to Lucene 7 with the next major version of Hibernate Search, I think we should prepare our users already. Let's deprecate @Boost and any o

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

On 19 May 2017 at 10:50, Adrian Nistor wrote: > +1 for 'local-heap'. thank you so much to help bringing some consensus! > But I still like 'Buster' :) it's cool, but I don't think we can include your geeky explanation in all logs and error messages :) > > > > On 05/19/2017 10:34 AM, Gustavo Fe

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

On 19 May 2017 at 10:10, Yoann Rodiere wrote: > Sanne, the confusions you pointed out were: > > Thinking it's more efficient than other providers (it's not) > Thinking it's integrated to replicated in-memory datastores such as > Infinispan (it's not) It's also not scalable in terms of concurrency

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

+1 for 'local-heap'. But I still like 'Buster' :) On 05/19/2017 10:34 AM, Gustavo Fernandes wrote: > -1 to demote it to "testing" > > Let me show the other side of the coin :) > > RAMDirectory has its uses, as long as one understands its limitations. It > is convenient for small non-persistent i

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

On 19 May 2017 at 08:34, Gustavo Fernandes wrote: > -1 to demote it to "testing" > > Let me show the other side of the coin :) > > RAMDirectory has its uses, as long as one understands its limitations. It is > convenient for small non-persistent indexes, and last time I measured, it > was faster t

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

Sanne, the confusions you pointed out were: - Thinking it's more efficient than other providers (it's not) - Thinking it's integrated to replicated in-memory datastores such as Infinispan (it's not) So you'd want a name that says "it's not persistent" and probably "it's easy to set up" w

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

-1 to demote it to "testing" Let me show the other side of the coin :) RAMDirectory has its uses, as long as one understands its limitations. It is convenient for small non-persistent indexes, and last time I measured, it was faster to load than the FS directory. So it could be used in productio