Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Ebean - simple ORM

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interested in simpler Object Relational Mapping? Check out Ebean at http://www.avaje.org

Making ORM live a little simpler Ebean provides most of the features of JPA and Hibernate (and some they don't) without requiring a Session Object. No need to think about Attached and Detached beans.

Enjoy - Rob.
 
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hey Rob

doesn't the getObject() method described in the "Gerry Power" method at http://www.avaje.org/equals.html suffer from "double checked locking" ?

check out:
http://www-128.ibm.com/developerworks/java/library/j-dcl.html

it's still early here...

pascal
[ November 23, 2006: Message edited by: pascal betz ]
 
Rob Bygrave
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, yes, looks like it does.

Any suggestions to this?

It would be nice to know which JIT compilers/JVMs this is an issue on. If we limit ourselves to jdk1.5+ are we safe?
 
Rob Bygrave
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, after a second read of http://www-128.ibm.com/developerworks/java/library/j-dcl.html I am feeling unsatisfied by the article.

It seems that if you are using Sun or IBM JDK1.3+ then you are not going to have this issue (with their JIT compilers). There is a mention you may have 'another issue' but that is not stated what this other issue is? (Thats not very helpful).

For me, I'd say that double-checked locking code is so common I'd expect JIT compilers to follow the Sun/IBM approach to avoid the issue.

Do we know specifically which JIT compilers still have this issue? Sychronization is generally an expense we want to avoid if we can (so I am not keen on the recommendations of the article).
 
pascal betz
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If we limit ourselves to jdk1.5+ are we safe?


As long as it is not in the spec then i would not buil on it. There are people around here who know the JLS and JVM Specs pretty good (obviously i am not one of those :-) ).

But right now, if you think that you need syncrhonization (probably pretty rare situations where you need it - different threads calling the equals() on the same instance ... but still required to make it work in 100% and not just 99.9%) then you'll need to sync the whole method/block.

Or you could avoid the lazy init ? Just create this Object upfront or in some init block ? Or use super.equals() (as long super class is java.lang.Object this should not make any difference ?). Early in the mornin' here... so i did not think this trough.

Stupid collections anyway. Why do they need equals/hashCode. Can't they just do the job without bothering programmers ? They should know if Objects are equal. Just like that. Can't be that hard :-)

pascal
 
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving to Blatant Advertising.

Mark
 
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic