Re: [hibernate-dev] Ready for JDK 9 ?
by Rory O'Donnell
Thanks Sanne for the update!
Rgds,Rory
On 11/08/2017 11:31, Sanne Grinovero wrote:
> Hi Rory,
>
> Thanks for all updates!
>
> we have several projects under the Hibernate umbrella, so our
> experience varies a bit.
>
> Let me start with the good news: both Hibernate Validator (Reference
> implementation of Bean Validation) and Hibernate Search (Hibernate ORM
> integration with Apache Lucene) seem to work just fine.
> We had to disable various integration tests as several other platforms
> and tools we use for more extensive testing aren't yet at the same
> level of compatibility, or possibly we need to still figure out the
> right combination of updates and JVM flags to get them working: we're
> in the process of refining that but it's not worrying as it's about
> running different components, our libraries work fine.
>
> Our "flagship project" Hibernate ORM seems like in good shape as well
> but it will still take us some time to be able to give a thourough
> answer, as many more essential build and testing tools are still
> affected by compatibility issues. So for this one we currently can't
> run the core testsuite which leaves us partially in the dark, but I'm
> optimistic as several key functional tests of the Hibernate Search
> testsuite indirectly rely on Hibernate ORM as well and they all work
> just fine.
>
> All build issues we found so far are in the "expected changes"
> cathegory so we're not having bugs to report to the OpenJDK; we might
> have to chase several of these tool maintainers. We'll keep working on
> this and let you know.
>
> Thanks,
> Sanne
>
>
> On 8 August 2017 at 11:07, Rory O'Donnell <rory.odonnell(a)oracle.com> wrote:
>> Hi Sanne,
>>
>> Thank you very much for all your testing of JDK 9 during its
>> development! Such contributions have significantly helped shape and
>> improve JDK 9.
>>
>> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
>> would like to ask if your project can be considered to be 'ready for JDK
>> 9', or if there are any remaining show stopper issues which you've
>> encountered when testing with the JDK 9 release candidate.
>>
>> JDK 9 b181 is available at http://jdk.java.net/9/
>>
>> If you have a public web page, mailing list post, or even a tweet
>> announcing you project's readiness for JDK 9, I'd love to add the URL to
>> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
>>
>>
>> Looking forward to hearing from you,
>> Rory
>>
>> [1] http://openjdk.java.net/projects/jdk9/
>>
>> --
>> 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
8 years, 4 months
Contributions - changes "CLA" process
by Steve Ebersole
Currently we have had to rely on a less-than-ideal CLA approach as part of
the process for accepting a contribution. That CLA app is a hassle for
contributors and it is a head-ache for the folks who manage them. So in an
effort to stream-line this process, we will be making the following changes
to this process:
1. We will no longer be using that CLA app.
2. CONTRIBUTING.MD will be updated to indicate that developers
implicitly agree to contributing their contributions under the terms of the
pertinent license (LGPL generally). Some documentation and some website
pages refer to the CLA process and will be updated to point to the
CONTRIBUTING.MD file directly.
3. Did I say we would no longer be using the CLA app? ;)
The end result is that when we process contributions (whether PR, patch
attached to Jira, etc) we no longer need to ask the contributor to sign the
CLA - such approval is implicitly given.
Note that this is not really even a change. The proposed process is the
general understanding of contributions to any project in terms of agreement
with the terms of that project's license. The point of the CLA was never
really acceptance of the terms of the license anyway. It was more
identifying contributors of pieces of code in case we ever want to
re-license.
This all came from a discussion with the Red Hat legal team, so I feel
extremely confident this is a good change and a sound one.
I will only be making said changes to the ORM repo. I leave it up to the
non-ORM team whether they want to change the non-ORM repos to follow these
guidelines as well.
8 years, 4 months
Ready for JDK 9 ?
by Rory O'Donnell
Hi Sanne,
Thank you very much for all your testing of JDK 9 during its
development! Such contributions have significantly helped shape and
improve JDK 9.
Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
would like to ask if your project can be considered to be 'ready for JDK
9', or if there are any remaining show stopper issues which you've
encountered when testing with the JDK 9 release candidate.
JDK 9 b181 is available at http://jdk.java.net/9/
If you have a public web page, mailing list post, or even a tweet
announcing you project's readiness for JDK 9, I'd love to add the URL to
the upcoming JDK 9 readiness page on the Quality Outreach wiki.
Looking forward to hearing from you,
Rory
[1] http://openjdk.java.net/projects/jdk9/
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
8 years, 4 months
ORM FAQ
by Steve Ebersole
I spent some time this a.m. working on changes to the ORM FAQ page:
http://staging.hibernate.org/orm/faq/
Let me know what you think. It's still not "done", but further along.
I am trying to avoid "usage" FAQ entries. These should be more generalized
project FAQs. We should decide how/where we want to handle "usage" FAQs,
if at all.
8 years, 4 months
Re: [hibernate-dev] [hibernate-users] Request Information for EAR and related exceptions
by Sanne Grinovero
Dear Lucia,
I'm afraid the lists you addressed are meant for technical
development: we're not familiar with such matters. The Hibernate
project is sponsored by Red Hat, inc., so I would suggest to contact
the legal department of Red Hat.
If you are a Red Hat customer you should be able to get directly in
touch for any legal concern with your account manager; we also have
offices in Milano and Roma. If you're not a customer I think they
might be willing to help you at opensource-legal(a)redhat.com .
Best Regards,
Sanne
On 4 August 2017 at 13:02, Calvi Lucia <lucia.calvi(a)italtel.com> wrote:
> Dear Sirs,
>
> this email is meant to ask what is the US ECCN code for “Hibernate 3.2.6 ”
> released under LGPL licence and, in case the code is 5D002, I’d like to know
> if “Hibernate 3.2.6 ” has been notified to The Bureau of Industry and
> Security (BIS), branch of the U.S. Department of Commerce, and to verify
> also if it is under TSU exception in EAR 740.13(e) or under any other
> exception.
>
> Looking forward to receiving your feedback
>
> Best Regards
>
> L.Calvi (Italtel)
>
> Internet Email Confidentiality Footer
> ********************************************************************************************************************************************
> La presente comunicazione, con le informazioni in essa contenute e ogni
> documento o file allegato, e' rivolta unicamente alla/e persona/e cui e'
> indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete
> i destinatari/autorizzati siete avvisati che qualsiasi azione, copia,
> comunicazione, divulgazione o simili basate sul contenuto di tali
> informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P.,
> D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se
> avete ricevuto questa comunicazione per errore, vi preghiamo di darne
> immediata notizia al mittente e di distruggere il messaggio originale e ogni
> file allegato senza farne copia alcuna o riprodurne in alcun modo il
> contenuto. ***************** This e-mail and its attachments are intended
> for the addressee(s) only and are confidential and/or may contain legally
> privileged information. If you have received this message by mistake or are
> not one of the addressees above, you may take no action based on it, and you
> may not copy or show it to anyone; please reply to this e-mail and point out
> the error which has occurred.
> ********************************************************************************************************************************************
>
> _______________________________________________
> hibernate-users mailing list
> hibernate-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-users
8 years, 4 months
[HV] Memory footprint improvements
by Guillaume Smet
Hi,
Stuart Douglas (in CC) opened an interesting issue here:
https://hibernate.atlassian.net/browse/HV-1437
I already made some good progress here:
https://github.com/hibernate/hibernate-validator/pull/814
but I would appreciate some feedback on a few additional things.
## AnnotationMetaDataProvider#configuredBeans
So, in AnnotationMetaDataProvider, we keep a cache of the annotation
metadata found while building the aggregated BeanMetaData.
It might be useful if you have a class hierarchy for instance as you would
only build the annotation of the parent class once.
But... as we initialize the bean metadata lazily, we need to keep this
cache during the whole lifecycle of the application.
So, here, we have to find a compromise:
1/ either favor the memory footprint but the annotation of a given class
could be analyzed several times in the case of a class hierarchy
2/ or favor the startup cost (it's not a runtime cost, it's paid only once
when validating the first bean of a given class) and have a higher memory
footprint
Usually, in HV, we take the 1/ route so I was a bit surprised 2/ was chosen
here.
Thoughts?
## Collection resizing
So, interestingly, enough, the small CollectionHelper#toImmutable*
utilities I introduced make quite a difference if there are a lot of
empty/one element collections - which is the general case in Stuart's
example.
The idea of these utilities is quite simple: instead of blindly wrapping a
collection using Collections#unmodifiable* to make a collection immutable,
we test the size of the collection and we return a static empty collection
or a singleton collection if the size is 0 or 1 respectively.
So this is nice when the size is 0 or 1 but considering that HV metadata
structures are mostly immutable once they are initialized, I would like to
go a step further and create a collection of the right size when making it
immutable in all the cases.
We don't use that many collection types and we could default to the current
wrapping method if the collection is not ArrayList, HashSet, LinkedHashSet,
HashMap and maybe LinkedHashMap.
Basically, for sets, we would have:
public static <T> Set<T> toResizedImmutableSet(Set<? extends T> set) {
switch ( set.size() ) {
case 0:
return Collections.emptySet();
case 1:
return Collections.singleton( set.iterator().next() );
default:
if ( set instanceof LinkedHashSet ) {
LinkedHashSet<T> copy = new LinkedHashSet<T>(
set.size(), 1 );
copy.addAll( set );
return Collections.unmodifiableSet( copy );
}
else if ( set instanceof HashSet ) {
HashSet<T> copy = new HashSet<T>( set.size(), 1 );
copy.addAll( set );
return Collections.unmodifiableSet( copy );
}
else {
return Collections.unmodifiableSet( set );
}
}
}
It's one more memory allocation but I think reducing the runtime memory
footprint would be worth it. Especially for data structures that are very
common (think of the executable metadata, the parameter metadata and so on).
I'm not sure I would generalize it to all our projects but I think it makes
sense for HV where nearly everything is immutable and we have quite a lot
of Maps and Sets in the metadata.
Usually, Yoann and I are on the "Let's do it" side and the others on the
"I'm not sure it's worth it" when it comes to CollectionHelper, but
considering how well the first round has paid, I think we should at least
give it a try.
Thoughts?
## Metadata, metadata, metadata
So, we have a lot of metadata. A. Lot. Especially, we have metadata even
when there are no HV metadata at all.
Think of Keycloak's RealmEntity (
https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/java/...),
it makes a lot of metadata for no useful information.
It's especially the method metadata that are heavy, even if I tried to
reduce them to the minimum in this case.
I once thought about completely removing the method metadata if the method
wasn't annotated at all but then I thought that the overriding rules would
prevent us to do that.
Gunnar, am I right on this?
So basically, I think we can't really do anything about this.
I also thought that it was useless to look for annotations on
java.lang.Object but then again I think the overriding rules force us to do
so.
That's it for today.
Comments welcome.
--
Guillaume
8 years, 4 months
PESSIMISTIC_FORCE_INCREMENT lock mode
by Arnold Gálovics
Hi all,
I'm a bit confused with the mentioned lock mode.
*The doc says the following:*
*"The entity is locked pessimistically and its version is incremented
automatically even if the entity has not changed."*
I'm checking this with an H2 DB and the current behavior is the following:
- the version attribute is incremented in advance, right after fetching
(I'm using EntityManager#find here, but with lock, it should be the same)
- the original fetching query contains the SELECT ... FOR UPDATE clause
Knowing this, it seems for me that this lock mode involves a DB lock,
however the doc doesn't say anything about this, especially whether it's a
shared or exclusive lock.
I've checked Vlad's article about this.
https://vladmihalcea.com/2015/02/16/hibernate-locking-patterns-how-does-p...
It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might lead
you into thinking that you are using a pessimistic locking strategy, while
in reality this Lock Mode is just an optimistic locking variation."*
So now I'm unsure what this really is.
Could you please briefly describe it to me if I missed something?
Thanks in advance!
Best Regards,
Arnold
8 years, 4 months
