Discussions

News: Tech Talk with Gavin King on Hibernate

  1. Tech Talk with Gavin King on Hibernate (29 messages)

    Gavin King, founder of the Hibernate project, talks about how Hibernate got started, its success, and some of its best features. He discusses how Hibernate deals with stored procedures, the importance of transparent persistence, and the biggest challenges he faced building a persistence framework. He gives his opinion on JDO and bytecode manipulation, and describes how Hibernate uses CGLib.

    Watch Gavin King's Interview


    Update to Tech Talk UI
    =======================

    Due to popular demand, the full length text transcription of the interview has been integrated into the Tech Talk UI, which can be resized as needed.

    Threaded Messages (29)

  2. Tech Talk with Gavin King on Hibernate[ Go to top ]

    You go Gavin!

    Sandeep.
  3. Interesting take on JDO[ Go to top ]

    Gavin is very articulate and should definitely participate in the JDO 2.0 spec.

    He was, however, wrong when he said that JDO requires bytecode enhancement. JDO requires the PersistenceCapable interface to be implemented, and the enhancer is an automatic way to do it. But sourcecode enhancers, or plain old hand coding of the PersistenceCapable interface are perfectly OK as well.

    I think one thing that will close the gap between JDO and Hibernate (or unify them) is the capability to use straight SQL instead of JDOQL to specify queries. JDO allows alternate languages to be used besides JDOQL for query formulation, and SQL would be the most obvious alternative. There would be no issue with outer joins, ordering, etc. if SQL could be used to issue the query.

    Hoperfully Gavin can help bring JDO forward.

    -geoff
  4. My Ugly Head.[ Go to top ]

    A quick note: this was recorded at the TSS symposium, before the JDO 2 process started, and before I became involved.

    >>He was, however, wrong when he said that JDO requires bytecode enhancement.<
    I misspoke slightly. I tried to say that "JDO requires byte-code processing if /transparent/ persistence is required". Emphasis upon "transparent". (

    OK, I admit that you can also do it with sourcecode processing, but the same criticisms apply to sourcecode processing!)

    Anyway, this debate is becoming quite irrelevant, since changes are being made in the scope of JDO 2.0 (along the lines I describe in the interview).
  5. My Ugly Head.[ Go to top ]

    "this was recorded at the TSS symposium"

    ah, that explains why no questions about Hibernate-JBoss ;-)
  6. re: My Ugly Head.[ Go to top ]

    Gavin:
    Now that you are involved in the JDO expert group, what are your current thoughts on if or when Hibernate will become JDO compliant?
  7. Caching[ Go to top ]

    One of the nice (but not nearly nice enough) things to come out of a CMP2 (WLS 8.1) vs. JDBC comparison was the caching that the CMP2 takes off your hands.

    Does Hibernate support caching of the query results and if so to what extent?

    If it doesn't have it's own cache, what are people using on top of Hibernate?

    As for SQL in code not being ugly, well, maybe not, provided that the SQL is well encapsulated. One of the downsides of the exposed SQL approach is that developers use it! and use it, and use it, all over the place. So if your underlying schema changes you end up having to make multiple changes (after you've found them).

    How would this be achieved in a world where the SQL is distributed throughout the code?

    The reality of the matter is that if you present developers with SQL via Hibernate, they will use it like SQL and you suffer from the same issues.

    I haven't actually looked at Hibernate in any detail, and am relying on the interview alone so please excuse any ignorance on my part. If these issues I've raised are not issues then I'd love to know.
  8. Caching[ Go to top ]

    Looks like caching is priority in hibernate 2, it is not trivial to implement distributed cache for all use cases with transction isolation support, cache can be the overhead itself in some of use cases.
    But I found it is very trivial to implement it for specific use cases like web applications. Content cache in web applications saves more operations than cache in low level operations, filter "knows" specific needs and can optimize application very well. "Send-If-Modified" is a very good optimization for web application too (Cache on client). Tools like OSCache can help to optimize "Model 1" web app better than persistence layer too.
    I like this dream "no cache in client code and 100% of performance at low level", but I do not believe it.

    > One of the nice (but not nearly nice enough) things to come out of a CMP2 (WLS 8.1) vs. JDBC comparison was the caching that the CMP2 takes off your hands.
    >
    > Does Hibernate support caching of the query results and if so to what extent?
    >
    > If it doesn't have it's own cache, what are people using on top of Hibernate?
    >
    > As for SQL in code not being ugly, well, maybe not, provided that the SQL is well encapsulated. One of the downsides of the exposed SQL approach is that developers use it! and use it, and use it, all over the place. So if your underlying schema changes you end up having to make multiple changes (after you've found them).
    >
    > How would this be achieved in a world where the SQL is distributed throughout the code?
    >
    > The reality of the matter is that if you present developers with SQL via Hibernate, they will use it like SQL and you suffer from the same issues.
    >
    > I haven't actually looked at Hibernate in any detail, and am relying on the interview alone so please excuse any ignorance on my part. If these issues I've raised are not issues then I'd love to know.
  9. caching etc[ Go to top ]

    Does Hibernate support caching of the query results and if so to what extent? <

    * allows lookups-by-id may be cached with configurable semantics on a per-class level
    * query result sets may be cached in Hibernate 2.1, by calling Query.setCacheable(true)

    So, basically: to the full extent ;-)

    Currently, distributed caching is possible using tangosol coherence, and - through the JBoss connection - I am working with Bela Ban of JavaGroups to get an out-of-the-box distributed cache implementation.

    >> As for SQL in code not being ugly, well, maybe not, provided that the SQL is well encapsulated. One of the downsides of the exposed SQL approach is that developers use it! and use it, and use it, all over the place. <
    Actually, this was not quite my point. We don't encourage people to sprinkle SQL all through their code - we just encourage them to make full use Hibernate's query language and query API when working with large sets of data. The query language is an object-oriented query language similar to ODMG OQL.

    >>So if your underlying schema changes you end up having to make multiple changes (after you've found them).<
    Hibernate queries are always expressed in terms of classes and properties, not in terms of tables and columns, so this is just not a problem. The mapping document centralizes knowledge of the underlying relational schema.
  10. More caching questions[ Go to top ]

    Thanks for the info Gavin,

    It sound like the caching in 2.0 is exactly the same as the WLS 8.1 CMP2 caching (by primary index).

    One of the drawbacks of the WLS approach is that for a designated read only bean, a finder on anything other than the pk will involve a database hit. If it is read only then any finder should be cached but preferably only through a secondary cache that is keyed by name with the PK as the value which the container/Hibernate can use to query the main cache.

    You say that you have a query results cache and at first sight it seems that this would resolve the above use case, but does this mean it will literally cache the entire results of the query or is it clever enough to refer to the main cache by primary index? If not then I can see the heap getting used up quickly.

    How will Hibernate deal with cached data becoming invalidated as the result of a database change. For example, how would the read-mostly pattern be implemented in Hibernate effectively?
  11. More caching questions[ Go to top ]

    You say that you have a query results cache and at first sight it seems that this would resolve the above use case, but does this mean it will literally cache the entire results of the query or is it clever enough to refer to the main cache by primary index?<

    It is clever.


    >>How will Hibernate deal with cached data becoming invalidated as the result of a database change. <
    It invalidates cached results from queries that referred to the updated table. (And yes, this will also work in a cluster.)


    The only thing to mention is that the query cache is necessarily less fussy about transaction isolation than the object cache. But this is perfectly fine, actually.
  12. my bad[ Go to top ]

    How will Hibernate deal with cached data becoming invalidated as the result of a database change. <


    Ooops I think I misunderstood. You mean a change made from outside Hibernate? Well, my answer is basically the same as the Toplink guys and anyone else I've ever seen talk about this: you would have to manually implement some kind of callback from the database into the J2EE server (using a trigger + JMS, or whatever) and then call the API we provide for cache invalidation.

    Or, if the update is performed from inside the same application, but just not through Hibernate, just call the API directly. (There is an evict() method.)

    This is becoming a common question, actually.....
  13. cache forwarding[ Go to top ]

    it seems that it would be more efficient to forward
    the change set instead of an eviction notification.
    the question of how to notify other processes that
    an update has occurred outside of the applications
    persistence layer is common and there are techniques,
    as gavin notes, to solve this.

    one of the problems with the cache synchronization
    solutions that i've seen is that they all based on
    a peer type architecture. it's not really a problem,
    what i mean is they take an application perspective
    on the caching problem and developers must handle
    scenarios when data is modified outside of the
    applications persistence layer.

    i think a cache forwarding architecture would be
    interesting to see in the OR space and would take
    the burden of managing the possibility of having
    stale data/instances in the cache. so instead
    of peers sending messages between one another,
    change set notifications come from the back end
    forward. i know that this is a difficult and
    perhaps silly idea, but i saw how this worked
    in object store and it left an impression on me.
    damn i miss working with oodbms.
     
    sean
  14. optimization of sql queries[ Go to top ]

    Gavin,
    hibernate is certainly a great idea.
    However, i don't see why i really would need to use HQL which is another learning curve for me. Why is it so hard for developers to learn sql. Why is that so uncool? i really don't like HQL, and i prefer to be able to use my own sql statements.

    okay, since i like hibernate, let's say that i could live with HQL, but, how about when i really need to tune the sql statements. I might want to do table ordering (small table first maybe) i.e in joins , use hints and whether i want nested loops etc.. How do i do that. I understand that one can actually see the sql statement that is being created dynamically by Hibernate, and i suppose , i could optimize that, but then, what is the purpose of you creating the sql statement at the first place.

    I suppose , I am having a hard time with hibernate creating complicated join queries for me when these are the ones that can bring down a database. I know my database and know how the query needs to be written because, i have created the necessary indexes, i know my tables etc.. I have a hard time trusting that a dynamically random written query will ever reach the speed and optimization i can.

    I just would like to understand this part. I think, it is one of the points that i am resisting about most. this and the issue of stored procs. I really like stored procs and what i can do with them. It is a pity that hibernate doesn't accomodate them yet since there is no callable statement, from what i read.

    I like hibernate when the queries are simple. It takes care of lotsa complexities for me.. So, please enlighten me about the above issues. I would really appreciate it.
  15. optimization of sql queries[ Go to top ]

    Um, did you hear the part in the interview about fulfiling the need to be able to work with "sets of objects" vs. merely "sets of data".

    If you want to do the former, well its easier doing that with Hibernate, or any equivalent ORM tool, than with raw SQL and JDBC. Of course there are tools such as iBATIS that can help you in this realm as well.

    That said, if you want to really bridge the O & R worlds, while being able to leverage the strength of portable, POJO-based object-oriented progamming constructs, while maintaining the flexibility to do ad-hoc, querying a la SQL - well you really have no recourse but to use a utility like Hibernate.

    Also, did you also read the part about being able to use the native JDBC connection to execute your own SQL queries in the same transaction context as your HSQL queries/Hibernate persistence operations?

    Sandeep.
  16. right you are.[ Go to top ]

    since %90 of my interaction with my own database is batch inserts/deletes, stored procs, and very complicated reporting joins, and joins, which i can do through exposed jdbc, which i must do by not hiding behind hibernate, then, what does this leave me with.. And i have to learn hql besides.
  17. Hmm[ Go to top ]

    <gina>
    since %90 of my interaction with my own database is batch inserts/deletes, stored procs, and very complicated reporting joins, and joins, which i can do through exposed jdbc, which i must do by not hiding behind hibernate, then, what does this leave me with
    </gina>

    Sounds like you may have an application need that is not amenable to using Hiberate as advertised in Examples 1-10. ;-)

    There has been a lot of discussion on best practices with respect to batching DML using Hibernate. Here is a verbatim extract from the mailing list.

    <hibernate-devel>
    On 01 Sep (18:00), Butt, Dudley wrote:

    > Has anyone got any pointers on how to perform a batch insert into? like 3000 +
    > records

    With SQL and JDBC calls.

    --
    Christian Bauer
    </hibernate-devel>

    The same thing applies to stored procs and complex joins aimed at reporting.

    Also, maybe Hibernate isn't what you're looking for. After all, one size never fits everybody.

    If you want to abstract away complex persistence issues while focussing on your business logic, then Hibernate can really help you. If you persist with the perspective of dealing with persistence issues first (terribleainti!), then well, you are probably better off with SQL and JDBC.

    The one thing that you have to remember is that when using an ORM tool, you have to leave some of the procedural/SQL (not a reference to PL/SQL) mentality and paradigms behind. Gavin said it well when he talked about "working with sets of objects".

    With objects, it's mostly about the relationships between them. It's not about sets of data that can be joined together. This problem is accentuated because data models look deceptively similar to their corresponding object models.

    It's also important to remember that object models aren't just data models with some behavioral semantics thrown in for good measure.

    To quote Scott Ambler (loosely) - while the OO paradigm is based on proven software engineering principles, the relational paradigm is based on proven mathematical principles.

    Sandeep
  18. ibatis[ Go to top ]

    i did look at the iBatis (and i remembered that Gavin talks about it in the first chapter of the new Hibernate book.)
    yes, indeed, it looks like exactly what i would need. Thanks for bringing to my attention Sandeep. ;)
  19. ibatis[ Go to top ]

    i did look at the iBatis (and i remembered that Gavin talks about it in the first chapter of the new Hibernate book.)

    > yes, indeed, it looks like exactly what i would need. Thanks for bringing to my attention Sandeep. ;)

    Your welcome. ;-)

    I've used it myself. Its really best in its class.

    Sandeep.
  20. optimization of sql queries[ Go to top ]

    <Gina>
    okay, since i like hibernate, let's say that i could live with HQL, but, how about when i really need to tune the sql statements. I might want to do table ordering (small table first maybe) i.e in joins , use hints and whether i want nested loops etc.. How do i do that. I understand that one can actually see the sql statement that is being created dynamically by Hibernate, and i suppose , i could optimize that, but then, what is the purpose of you creating the sql statement at the first place.

    I suppose , I am having a hard time with hibernate creating complicated join queries for me when these are the ones that can bring down a database. I know my database and know how the query needs to be written because, i have created the necessary indexes, i know my tables etc.. I have a hard time trusting that a dynamically random written query will ever reach the speed and optimization i can.
    </Gina>

    That's exactly what I need. I have a performance issue with my database and the solution I found, is to optimize the sql query.
    How could I add hints in my HQL query ?
  21. optimization of sql queries[ Go to top ]

    The other thing is that nobody really said anything about SQL being uncool. For example, going back to Gavin's interview, he said:

    <Gavin>
    "I’m kind of ashamed to say that in the Java community, I think often, we look at that stuff and think it’s a bit dirty and people talk about persistence layers as being able to shield the developer from having to work with that kind of stuff. But if you actually sit down and spend some time thinking about the relational model and relational modeling, you realize it’s actually very elegant. What makes it dirty is the mismatch problem, is the mapping problem, that’s the only part that makes it dirty. What makes it dirty is working with JDBC and trying to map the stuff that comes out of JDBC onto a graph of objects. That’s what makes it dirty, not writing SQL, not working with SQL.
    </Gavin>

    If you understand SQL well, and from your post, I am guessing you are very well versed with SQL, there really is no "learning curve" to HQL. Its closer to SQL that most other object-oriented query languages.

    Sandeep.
  22. hey[ Go to top ]

    never said anything about Gavin saying that. Read my post. i was just complaining about the same thing exactly..
    Plus, there was a talk in the mailing list about making stored procs available through making callable available in hibernate which got me all excited. because that would solve lotsa problems for me. Don't get me wrong, i really like hibernate.. so, you don't have to defend it to me.
  23. direct SQL[ Go to top ]

    Why is it so hard for developers to learn sql. Why is that so uncool? i really don't like HQL, and i prefer to be able to use my own sql statements.<

    Max Anderson has added support for native SQL queries to Hibernate 2.1. It actually works out very nicely. You don't need to do all the yucky JDBC stuff - let Hibernate take care of that - and you can still do all the "hard" stuff like query hints, etc.

    OTOH, direct SQL queries are MUCH more verbose and much less readable than HQL. HQL and the new Criteria API - which is actually really cool - work at a slightly higher level of abstraction.
  24. yeppiee[ Go to top ]

    well, let's present heart felt thanks and gratitude to mr.Max Anderson then.. Thank you.. thank you.. thank you..

    about sql being more noisy. don't know.. it is like someone telling you that your native language is hard to learn, you don't understand why he/she says that, cause, you learned it as a child, bad example, but i am just so used to dealing with sql and how i can play around with it , it makes it rather fun and don't even think of it as being difficult.
    Thanks Gavin..
  25. I can say without exception that every complaint that I've heard about JDO1 is being addressed in JDO2. Hibernate and Toplink are fully on board, as far as I can tell (I'm on the expert group, too), with JDO2.

    * One of the explicitly stated goals of JDO2 is to broaden the number of implementations of transparent persistence, essentially making optional binary compatibility and the javax.jdo.spi.PersistenceCapable interface.

    * Since most, if not all, of the current JDO1 ORM implementations already expose the JDBC connection in a proprietary way, this will be standardized.

    * JDOQL will be enhanced to include support for aggregation and projections, including things like count, sum, avg, min, max, etc.

    * Recommendations will be made regarding SQL such that, if the user abides by them, all implementations are expected to be able to handle and map results into the appropriate objects. Personally, I throw this under the label "JDOSQL", but "SQL" might be just as appropriate here, because it's the very language for which support is intended. What the spec will use, I don't know, but I expect it to be enumerated along with JDOQL.

    * More concrete collections from the Java collections framework will be supported.

    * The ability to use simple object identities, much like how Hibernate's use of object identities, will be added.

    * The expression of object-to-relational mappings is also being standardized as well, so that you can change JDO implementations without having to go through a data migration, provided that your mappings abide by the portability requirements.

    There are also a number of additional things going into the spec, but these are certainly the highlights.

    I hope this helps ease some of the worries that people have about JDO.

    --matthew
  26. JDO 2.0 process[ Go to top ]

    * One of the explicitly stated goals of JDO2 is to broaden the number of

    > implementations of transparent persistence, essentially making optional
    > binary compatibility and the javax.jdo.spi.PersistenceCapable interface.

    I really dont care about binary compatibility regarding my enhanced Pojos, on this point, i agree with Gavin. Making the interface PersistenceCapable optional would mean that the implementor has full control over how things are done behind the scenes or are there other issues there?

    BTW how about dropping support for PersistenceAware classes. Direct access on attributes is bad style anyway, PAware classes will only enforce this behavior.

    > * JDOQL will be enhanced to include support for aggregation and projections, including things like count, sum, avg, min, max, etc.

    hardly to believe that this wasnt speced out in 1.0. Major shortcoming.

    > * The ability to use simple object identities, much like how Hibernate's use of object identities, will be added.

    dont know what you mean with this, because i dont know hibernates way of doing this ;-) But sounds interessting.

    > * The expression of object-to-relational mappings is also being standardized as well, so that you can change JDO implementations without having to go through a data migration, provided that your mappings abide by the portability requirements.

    This is also a MUST-DO.

    > I hope this helps ease some of the worries that people have about JDO.

    If you let aside the JDOQL issue, JDO is a very nice ORM spec from the user perspective. 1.0 has shortcomings, yes, but the overall direction is nice and 2.0 will hopefully the long awaited breakthrough.

    Marc
  27. Tech Talk with Gavin King on Hibernate[ Go to top ]

    TSS : "Why do you think Hibernate has become so successful? "

    Gavin : "...Secondly: Documentation. So many of the great Java open source projects that are out there could be so much more successful, and so much better as a project if people took the time to take pride in the documentation..."

    I wish folks at JBoss Group could learn from this advise. I am not refering to WEB or EJB containers but the new hot stuff (AOP, distributed/transacional cache/singletons, etc). Ok, we can read JavaDocs, but if JBoss Group is really trying to be Professional Open Source, why not produce some professional documents ? And what about Executive Summary kind of documents ? How I "sell" JBoss to my manager or to my clients ? (Please dont say me I need to get certified...).

    Ok, I can talk about the new business model around Open Source, etc but in general many people still did not got it !

    If I wish to convince some potential customer about JBoss, I cannot start talking things like "The truth is in the Code". Get real, get professional !

    Congratulations Gavin !
  28. Just to correct my name. I used my colleague workstation and he was previously logged in TSS so...

    :)
  29. Great interview[ Go to top ]

    " I’m not an expert on object databases but I suspect in the case of object databases they’re a bit more designed to cope with that method of data access. "

    Yeah, they tend to include collections that chunk up the persistent collecitons into buckets so they can be pulled into memory in batches as opposed to N+1.

    " And that’s not going to work because a relational database is fundamentally different. The way you access data in the relational database is fundamentally different from the way you access data in an object database"

    Key point. A lot of people actually wind up writing 1/3 of a relational query & index engine on top of their ODBMS when working with it (I know I did).

    "What makes it dirty is working with JDBC and trying to map the stuff that comes out of JDBC onto a graph of objects. That’s what makes it dirty, not writing SQL, not working with SQL. "

    This is is a key point and I wish more developers saw things this way. It would eliminate a lot of project and performance failures out there because people tried to hide something that is way too rich to be hidden.

    "Stored procedures are essentially a non-relational view of a relational database. They're a procedure oriented, a call oriented view of a relational database. So my view, and this is a controversy, not everybody agrees with it"

    I understand this view, and I used to agree with it, but there are problems with it. I had a disagreement with Gavin over this very idea a few weeks back.

    Certain kinds of security checks and semantic integrity constraints need to be written as SQL statements (they are too complex to be declarative CHECK constraints or simple foreign key constraints). This is a form of "data level" business logic.

    Anyway, such checks can either "front-end" your main SQL statement, or they can be implemented with triggers. The problem is that cascading triggers can really lead to hard-to-control side effects, not to mention some difficult to measure performance characteristics (when they get more complicated). Finally, with Oracle, their locking paradigm causes the mutating table problem when dealing with sets of data.

    All of this is why you see a lot of DBAs that insist on turning off dynamic SQL and insisting on stored procedures + views for data access. They are a way of ensuring complex integrity and security constraints BUT they still keep the possibility of "shared data" among applications. They prevent any non-approved means of accessing the data. This is widely used in production.

    The other defense for stored procedures is a pure performance argument: a stored procedure is in-process with the database. It is going to be an order of magnitude faster than pulling data across a network into an application server and hibernate. Plus, modern databases have features like "bulk binding" and "procedure pipelining" which can enable tremendous (order of magnitude) performance gains when dealing with large sets of data.

    Having said all of this, Gavin is, at the core, correct: stored procedures are a call oriented interface. But this is exactly what most distributed systems interfaces are - they're coarse-grained and call-oriented, just like a stateless session bean or a web service. Fine-grained stateful domain models don't make sense when you're building a network interface - something we learned the hard way with CORBA. What needs to happen, perhaps, is a greater emphasis on improving Java's performance in the database, as an alternative to PL/SQL or T-SQL: would you rather write code in them or in Java (assuming performance was the same)? This is the direction Microsoft is going with SQL Server Yukon by embedding C# inside the database with the same performance characteristics of T-SQL: it will give Oracle and Sybase more incentive to improve their "Java in the database" implementations.

    "Firstly, to address the first part: that some vendor’s customers aren’t asking for that. Well, my view on that is that who are they defining as their customers? Are they defining their customers as the developers who work with their products day to day? ... To me, it appears, the interest in Hibernate should demonstrate, that in fact, that developers are very, very, interested in the problem of transparent persistence. "

    I said this before, and I'm not sure Gavin will believe me, but I'll re-iterate it: developers in most enterprise shops in the telecom and financial industry that I've dealt with (and I've dealt with quite a few) write their systems with JDBC and stored procedures, and think writing a stored procedure is a lot easier than setting up an ORM tool.

    I've tried to sell them on the merits of ORM, it has been a very slow process. In the ensuing years, I've tended to come around and see the merits of the stored procedure approach, but I still think ORMs are very useful, just as long as the team using it is careful about understanding its tradeoffs.

    Most Java people "in the trenches" that have a C++ heritage aren't hanging out on theserverside.com, they're not really aware of the Java community out there. It's a bit of a paradigm shift. This is slowly changing: a recent client has their main global trading system built on top of Persistence Powertier, primarily for its caching abilities. It's unfortunate that Powertier hasn't really been updated much in recent years (they're focusing on EdgeXtend) as it gives developers a taste for the clunky EJB-1.1 style of ORM.... whereas lightweight ORM technology has really matured recently.

    The trend I notice is that shops tend to look towards the more modern frameworks when they start to hire "fresh perspective" CS graduates and java developers that are popping up out there, those that haven't been coding for 10+ years with a C++ heritage (or perhaps those from a Smalltalk heritage). They manage to convince management of the brave new world of the Java approach - ORMs, EJBs, Struts, AOP, etc... and things progress from there. Unfortunately, these "blue sky" developers don't have the 10+ years of C++ behind them to see the merits of the old approach and the trade-offs of the new approach. This can (quite often in my experience) lead to a lot of headaches and non-performing systems. I was guilty of this once, in the mid to late 1990s, but I was lucky in not presiding over too many disasters (but pretty close)... I've been trying to avoid that over the past few years.

    "Firstly, not every application needs a domain model. There are lots of applications for which a domain model is absolute overkill. There are lots of applications for which a view of sets of data coming out of the database is absolutely appropriate. "

    Very true, and I wish more of the Java purists understood this.

    Anyway, great interview.
  30. Rod Johnson's AOP hierarchy?[ Go to top ]

    Rod Johnson didwas he wrote up a hierarchy of the ways to implement

    > it where he started off with dynamic proxies and ended up with a new
    > language like AspectJ

    Where can I find this?