[hibernate-dev] Hibernate & Java 5 ?

[Alex Snaps]

What about the dirty reads? Should I mark all getters as synchronized
methods, or just leave it as is? Not knowing how intensively these
getters are being called...
Btw, would this be backported into older 3.x releases as well?

On Wed, Dec 9, 2009 at 1:39 PM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I don't think it's critical to backport this for 1.4 JDK users. But if you want to spare cycles...
>
> On 9 déc. 2009, at 12:48, Alex Snaps wrote:
>
>> I have finished a first version of it all:
>> It is supporting both jdk 1.4 and 1.5+. So that if the
>> java.util.concurrent classes are present, it will use the new
>> ConcurrentStatisticsImpl, otherwise will fallback to the current
>> StatisticsImpl. As mentioned, I had to extract interfaces for
>> EntityStatistics, CollectionStatistics, SecondLevelCacheStatistics and
>> QueryStatistics.
>> Now, there is still the issue of the dirty reads within the current
>> StatisticsImpl. (no synchronization on read)...
>> What would you guys think of fixing these with the
>> backport-util-concurrent ? So that even the 1.4 jdk get better
>> concurrency on these...
>> That would include a new dependency... I'm also currently looking into
>> not including the deps, and using the same tricks as they are doing to
>> diminish contention...
>> Their AtomicLong relies on synchronization, but at least every stat
>> gets its own lock, versus everyone competing for the same one as it is
>> currently the case.
>> wdyt?
>>
>> On Tue, Dec 1, 2009 at 3:59 PM, Steve Ebersole <steve at hibernate.org> wrote:
>>> I guess I have just been waiting until we can actually leverage 1.5
>>> features (ala utilize enums or expose generics/typing).  That will not
>>> happen for 3.5.
>>>
>>> Now statistics are encapsulated behind a set of interfaces (Statistics
>>> and StatisticsImplementor).  We could make this alterable like I did for
>>> JDBC 3/4 based on the JVM.  That would mean reflection code though.
>>>
>>> I do not actually know of any real cases of Hiberate being used in 1.4
>>> environments today.  So maybe we can just make it 1.5 compatible.
>>>
>>> Votes?
>>>
>>>
>>> On Tue, 2009-12-01 at 14:38 +0100, Alex Snaps wrote:
>>>> We've been doing some improvement to the Hibernate statistics at
>>>> Terracotta, when we realized how much the synchronization on it was
>>>> impacting throughput in our tests.
>>>> That is work we wanted to contribute back to you guys, should
>>>> Hibernate Core be target at 1.5. As it seems that's not yet the case,
>>>> so there isn't much you guys will be able to do with these changes...
>>>> We discussed about that at Devoxx with Max and Emmanuel and thought it
>>>> was okay to have 1.5 impl. of the specs (java.util.concurrent based)
>>>> already. Apparently not :( What timeframe do you see 1.4 support being
>>>> dropped?
>>>>
>>>> On Tue, Dec 1, 2009 at 1:44 PM, Steve Ebersole <steve at hibernate.org> wrote:
>>>>> I have issues reloading Maven-based projects in IntelliJ as well.  I
>>>>> simply try to minimize the number of times I reload.
>>>>>
>>>>> Hibernate is *built* with JDK 1.5, but not all the modules are 1.5
>>>>> compatible.
>>>>>
>>>>> What "statistics work" discussion?  I must have missed that.  But for
>>>>> sure the hibernate-core module should remain 1.4 compatible.  Dropping
>>>>> 1.4 support is on the roadmap, but not for 3.5
>>>>>
>>>>>
>>>>> On Tue, 2009-12-01 at 11:32 +0100, Alex Snaps wrote:
>>>>>> Hey,
>>>>>> Doing a svn update of the Hibernate trunk, I realized I probably had
>>>>>> changed the project to be Java5 manually as it reverted to 1.4
>>>>>> (because of some pom.xml change) in IntelliJ.
>>>>>> Talking to Max and Emmanuel at Devoxx I thought trunk was now to be
>>>>>> Java 5? Is this not the case after all, or are poms only update when
>>>>>> the first Java5 language/jdk feature sneaks in?
>>>>>> As discussed we discussed, all the statistics work heavily rely on
>>>>>> java.util.concurrent classes, so that is "more or less" important for
>>>>>> that patch...
>>>>>> Btw do you guys have a contributor agreement somewhere, I couldn't find it.
>>>>>> Thanks,
>>>>>> Alex
>>>>>>
>>>>> --
>>>>> Steve Ebersole <steve at hibernate.org>
>>>>> Hibernate.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> --
>>> Steve Ebersole <steve at hibernate.org>
>>> Hibernate.org
>>>
>>>
>>
>>
>>
>> --
>> Alex Snaps <alex.snaps at gmail.com>
>> Software Engineer - Terracotta
>> http://twitter.com/alexsnaps
>> http://www.linkedin.com/in/alexsnaps
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>



-- 
Alex Snaps <alex.snaps at gmail.com>
Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps