Re: [hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net
by Rory O'Donnell
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 months back, but since
>> Gradle broke again we're stuck on our flagship project (Hibernate
>> ORM).
>
> Yeah :/ Aside from the ongoing discussion about getenv improvements
> for gradle on core-libs-dev, I hope that Mark's latest proposal will
> help remove some of the roadblocks in this area.
>
> Speaking of which - if you have a spare moment, I think this kind of
> feedback would be great to have directly on jigsaw-dev. As with many
> other JDK changes, the potential impact upon framework developers can
> best be understood by such developers themselves and should be brought
> back to JDK lists for discussions. In particular when default settings
> end up changing ;)
>
> cheers,
> dalibor topic
>
>> Some progress can be monitored here:
>> - http://ci.hibernate.org/view/JDK9/
>>
>> Please bear in mind that even the "green" projects had to disable
>> integration tests with various platforms: our goal is to fix our own
>> code but that doesn't mean that it's going to work in the thousands of
>> frameworks integrating our projects.
>>
>> Mark Reinhold's latest proposal looks like a great step into the right
>> direction.
>>
>> I can't speak for my colleagues: [I don't represent Red Hat Middleware
>> !] but indeed - as an opinion from the Hibernate team - having some
>> ways to mitigate the high time pressure is very well received.
>> Whatever is decided regarding the default value of that flag, we'll
>> certainly keep testing on the strictest setting, and keep stressing
>> integrating frameworks and containers to do the same.
>>
>> Also as a personal opinion, not having the ability to isolate modules
>> in terms of avoiding conflicting package names is going to make
>> progress much harder: several of the projects we integrate with are
>> extremely conservative in breaking APIs, so renaming packages for the
>> sake of making the modules system happy is not going to happen in a
>> long time. Also future evolution of our projects will likely be
>> affected. In my experience I've witnessed several times that excellent
>> libraries are "transferred ownership" across organisations and
>> maintainers, sometimes partially, and when they get split they are
>> typically not in a suitable time to rename all packages. Sure such
>> things get cleaned up, but such events have to be decoupled - often
>> for organisational, practical reasons.
>>
>> Successful OSS projects grow in size and complexity, but they don't
>> necessarily scale in funding when they rely on volunteers, so an
>> organic growth followed by splits is quite natural. The Java ecosystem
>> supported this nicely; good tooling has been accelerating the process
>> and allowing for larger projects but we're at a saturation point for
>> which we're hoping modules would be an enabler for the community to
>> avoid headaches with dependency alignment puzzles. With no isolation
>> of at least the not-exported classes this seems like a missed
>> opportunity.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 19 May 2017 at 11:37, Rory O'Donnell <rory.odonnell(a)oracle.com>
>> wrote:
>>> 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
>>> <http://download.java.net/java/jdk9/changes/jdk-9+170.html>.
>>>
>>> Changes which were introduced since the last availability email that
>>> may
>>> be of interest :
>>>
>>> * b168 - JDK-8175814: Update default HttpClient protocol version and
>>> optional request version
>>> o related to JEP 110 : HTTP/2 Client.
>>> * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
>>> o changes in command line options
>>> * b170 - JDK-8177153 : LambdaMetafactory has default
>>> constructorIncompatible change,
>>> o release note: JDK-8180035
>>>
>>> *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
>>> mailing list *[1]
>>>
>>> * Proposal: Allow illegal reflective access by default in JDK 9
>>>
>>> In short, the existing "big kill switch" of the
>>> `--permit-illegal-access`
>>> option [1] will become the default behavior of the JDK 9
>>> run-time system,
>>> though without as many warnings. The current behavior of JDK 9,
>>> in which
>>> illegal reflective-access operations from code on the class path
>>> are not
>>> permitted, will become the default in a future release. Nothing
>>> will
>>> change at compile time.
>>>
>>>
>>> Rgds,Rory
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
>>>
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 1 month
JDK 9 EA Build 170 is available on jdk.java.net
by Rory O'Donnell
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
<http://download.java.net/java/jdk9/changes/jdk-9+170.html>.
Changes which were introduced since the last availability email that may
be of interest :
* b168 - JDK-8175814: Update default HttpClient protocol version and
optional request version
o related to JEP 110 : HTTP/2 Client.
* b169 - JDK-8178380 : Module system implementation refresh (5/2017)
o changes in command line options
* b170 - JDK-8177153 : LambdaMetafactory has default
constructorIncompatible change,
o release note: JDK-8180035
*New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
mailing list *[1]
* Proposal: Allow illegal reflective access by default in JDK 9
In short, the existing "big kill switch" of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings. The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release. Nothing will
change at compile time.
Rgds,Rory
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 1 month
[Search] Deprecating @Boost and related options
by Sanne Grinovero
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 option to control index-time boosting,
so that people can start already to move to query-time boosting.
- https://hibernate.atlassian.net/browse/HSEARCH-2735
9 years, 1 month
Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory
by Gunnar Morling
Can't you just move it to the test JAR if it's for testing only?
Am 18.05.2017 6:29 nachm. schrieb "Sanne Grinovero" <sanne(a)hibernate.org>:
Right technically it's not a unit test. But I'd like to focus on the
testing aspect, as "local-ram" might still convey concepts as "fast",
maybe even expect it to engage Infinispan's off-heap capabilities, or
just being an option to consider for other reasons.
"testing" ?
On 18 May 2017 at 17:20, Adrian Nistor <anistor(a)redhat.com> wrote:
> I agree, but probably "unit-testing" is not such a good name either.
> Technically, that's a functional test.
> I think I like "local-ram" better, implying that it is not
> shared/distributed and it is also volatile.
>
>
> On 05/18/2017 06:07 PM, Sanne Grinovero wrote:
>>
>> As anyone who's bothered to read the manual knows, the "ram" directory
>> should really only be used for unit tests. The other implementations,
>> while typically disk based, are also faster (memory mapped files) and
>> more efficient (better locking design) so there's really no reason to
>> use it, not even performance except for trivial, small, non important
>> data sets.
>>
>> For example the Elasticsearch team is making sure of this by having
>> totally removed the option of using the RAMDirectory - something I
>> actually don't appreciate as our unit tests could benefit from it,
>> having slow storage on our test environments.
>>
>> Tristan is reporting that the "ram" terminology is confusing people,
>> not least in the Infinispan community as "RAM" might be ambiguous
>> since everything is in memory, and people get surprised it's not
>> replicated in the "in memory cluster".
>>
>> I wouldn't want to go to the extremes of the Elasticsearch team as I
>> believe having this option is very useful, especially for testing.
>>
>> Should we rename (rebrand) its short name "ram" into "unit-testing" ?
>>
>> I suspect that would make people think a bit more before pushing it
>> into production...
>>
>>
>> Thanks,
>> Sanne
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9 years, 1 month
"rebranding" the Hibernate Search "ram" directory
by Sanne Grinovero
As anyone who's bothered to read the manual knows, the "ram" directory
should really only be used for unit tests. The other implementations,
while typically disk based, are also faster (memory mapped files) and
more efficient (better locking design) so there's really no reason to
use it, not even performance except for trivial, small, non important
data sets.
For example the Elasticsearch team is making sure of this by having
totally removed the option of using the RAMDirectory - something I
actually don't appreciate as our unit tests could benefit from it,
having slow storage on our test environments.
Tristan is reporting that the "ram" terminology is confusing people,
not least in the Infinispan community as "RAM" might be ambiguous
since everything is in memory, and people get surprised it's not
replicated in the "in memory cluster".
I wouldn't want to go to the extremes of the Elasticsearch team as I
believe having this option is very useful, especially for testing.
Should we rename (rebrand) its short name "ram" into "unit-testing" ?
I suspect that would make people think a bit more before pushing it
into production...
Thanks,
Sanne
9 years, 1 month
org.hibernate.event.spi Listener changes for 6 ?
by Sanne Grinovero
Since 6 is coming I'd like to suggest two trivial changes for the listeners:
# Serializable
I assume we can drop the "extend Serializable" from all these interfaces ?
# PostInsertEventListener.requiresPostCommitHanding(EntityPersister)
I suspect there is a typo in this method?
N.B. there are some more copies of `requiresPostCommitHanding` in
other listeners, beyond the PostInsertEventListener.
Thanks,
Sanne
9 years, 1 month
[ORM] Event Listeners: what's the consequence of not implementing Serializable correctly?
by Sanne Grinovero
As you might know Hibernate Search is implemented mainly as a complex
Event Listener to events
from Hibernate ORM.
The Hibernate ORM event listener contracts "suggest" that such event
listeners need to be Serializable, but it seems our listeners is not
actually serializable since some time.
It appears to be serializable and there's quite some complexity to
make it happen, but I'm realizing that the tests are incomplete and
it's unlikely to work in practice.
Yet everything seems to be fine: no tests failing, no people
complaining, nor bugs have been raised.
Does someone know if there's a realistic use case being broken? How
would a reasonable test look like?
Thanks,
Sanne
9 years, 1 month
Test case for HHH-11740
by Gail Badner
HHH-11740 is a bug that shows up on DB2 because Hibernate is using the
wrong DDL to create a global temporary table that can be shared by multiple
sessions; instead it is creating a temporary table that is visible only to
the connection that creates it.
On Friday I pushed a test case to master that was intended to check that
bulk operations can be executed using two different connections. My
intention was to expose any other dialects that had the same issue as DB.
Unfortunately, the test I pushed caused pessimistic lock exceptions on
multiple dialects. I see that Vlad corrected the test to deal with the
pessimistic lock exceptions. I see now that I should have sent email about
the possible failures and kept a lookout for the test results to avoid the
extra effort on Vlad's part.
I have since pushed an update to that test that avoids the pessimistic lock
failure, and should expose similar problems with other dialects. I'll keep
an eye on it and deal with any failures that show up.
Regards,
Gail
9 years, 1 month
[SEARCH] Master nodes without class definitions
by Yoann Rodiere
Hello,
In our roadmap for 5.8, we have this:
Removal of class definitions from master nodes
> The integration of a "master node" needs to be simplified, both in terms
> of user configuration and implementation. We plan to not need user classes
> (entities) on such a node, so that in future it could be a separate
> download which works out of the box with minimal configuration.
I guess what you are doing, Sanne, about replacing Class<?> references with
an internal binding representation, is part of that, but there doesn't seem
to be any trace of those efforts in JIRA.
Is there a ticket about this? I don't think there is one with a 5.8 "Fix
version", but maybe somewhere else... ?
On a side note, there may be hidden complexity in having
mapping-independent master nodes: we can probably use a generic
representation of documents for document additions/updates, but with
Elasticsearch, and probably very soon also with Lucene 7, we need to
initialize indexes with a schema. So at least one node needs both write
access to the indexes *and* knowledge of the mapping... Which
mapping-independent master nodes would prevent.
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
9 years, 1 month