Object-Relation Mapping without the Container 49
Justin Powell writes "If you follow the latest developer buzz then you've likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming). Like many developers, however, you may not see where these technologies fit into your development efforts. Learn where they can fit with a hands-on introduction to using Hibernate and Spring to build a transactional persistence tier for your enterprise applications."
Yeehoo, more tools....... (Score:3, Interesting)
Re:Yeehoo, more tools....... (Score:5, Interesting)
Your comment seems to sum up J2EE fairly well. This is why Spring was created. A container should provide a framework for containing things. period. If you want persistence, add a persistence framework. If you want transactions, add a transaction framework. If you think you need all the extra complexity, feel free to add it.
J2EE, however is complex by default. Spring tries to get away from that. Whether Spring itself can replace J2EE has yet to be shown, but it's philosophy will (at least in those companies flexible enough to change).
J2EE was a good first step, I suppose. They combined all the complex middleware software of the early to mid 90's into one giant all-inclusive spec. Anyone with a couple million man hours could implement the spec and join the market. I guess it made sense at the time.
Now we have a handful of application servers each costing tens of thousands of dollars (not including two very nice open source implementations). Most companies opt to spend $20k on WSAD just for transaction support, or just so they can use the app server's security. They never stop and ask if they need all the power their buying. Spring (and the light weight containers that are sure to follow) will give people an alternative.
Re:Yeehoo, more tools....... (Score:3, Informative)
Actually, take another look. These tools are a response to that very criticism. They are part of a move towards a more light-weight Java. I've used them both, and they are a dream to use. Hibernate in particular.
Why is Slashdot so anti-Java?
Re:Yeehoo, more tools....... (Score:4, Insightful)
Even Microsoft copied it with
And so, I might like to add is Perl, in which
Java does have complexities, but a lot of that is solved in 1.5. The API's are complicated but then, so is the real world. They are also complete. And I really do not think that the few (standardized by Sun) API's are worse than the hordes of modules you get for Perl on CPAN.
Re:Yeehoo, more tools....... (Score:5, Insightful)
The billions of dollars of advertising that got managers and HR people to take Java classes because it was the way of the future.
All the things that don't live up to their billing: AWT, Swing, keep trying.
Anyone else feel like the "write once run anywhere" philosophy just reduced java to the lowest common denominator of functionality?
Sun has spent a lot of money promising Java will do a lot of things it hasn't done.
Then there are all the fanboys of java that drive some of us nuts on a daily basis. Just trying to explain to them that even though Java is compiled, it is still interpreted (in the same fashion as Perl or Python) falls on deaf ears.
Other languages popular here are popular because they bend to the programmers will. With Java it is the programmer who must bend.
Java is and has been all about marketing. Marketing isn't well liked here.
To me, java is like ms-windows. It is usable, but only after you go out and get someone else's add-ons that should have been included in the first place.
Oh, and I hate java because it isn't LISP.
Re:Yeehoo, more tools....... (Score:3, Insightful)
Other languages popular here are pop
Re:Yeehoo, more tools....... (Score:2, Interesting)
Java is less programmer friendly that Python, Perl and LISP. It's that simple. Look no further than all the nice things they are putting into 1.5. All things that are in C# apparently that Sun used to say weren't necessary until C# showed up. I promise autobox
Re:Yeehoo, more tools....... (Score:1)
Re:Yeehoo, more tools....... (Score:2)
It does need basic things that I take for granted after working with Perl, Python or LISP. Regexes and flexible data structures come to mind.
Java has had regexes since 1.4.
Re:Yeehoo, more tools....... (Score:2)
Re:Yeehoo, more tools....... (Score:2)
Let me predict that we'll soon see jobs requiring "2 years Spring 2.309 and Hibernate 1.75, and don't bother applying if you haven't worked with those specific versions."
Re:Yeehoo, more tools....... (Score:2)
Yes, anything thats made by a company and marketed is evil because we're all communist hippies who think all software should be free as in beer.
All the things that don't live up to their billing: AWT, Swing, keep trying.
I was never impressed with AWT or Swing, and therefore don't usually use Java for projects requiring a GUI, rather (as I think is most often the case) use Ja
Re:Yeehoo, more tools....... (Score:1)
You mention yourself that C++ doesn't exactly bend to the programmer's will. This is certrainly true, of course I didn't mention C++ as an example of that (nor will you find it among the most popular languages here on slashdot).
The languages you find popular here just flat out do what
Free Hint :) (Score:2)
You should try reading about LISP macros. Paul Graham has written mostly about macros; it's available here [paulgraham.com]. To really get it, you require a bit of LISP knowledge, but you can get the general idea of the power of macros just by skimming the introductory parts of some of the later chapters. If you've got the time, I recommend reading through, it's very well written and really shows off what LISP can do for you.
Re:Yeehoo, more tools....... (Score:2)
If you actually believe this, you don't know Lisp very well. While Schemers often emphasize the functional use of their language, Common Lispers move about as they wish in the realms of procedural, object-oriented, and functional programming in order to most easily solve their problems.
You might ha
aspect-oriented programming (Score:2, Interesting)
Re:aspect-oriented programming (Score:4, Insightful)
AOP has the small problem that it is patented. It was, at the time of creation, genuinly new, so it is only right the the creators should be able to patent it. But doing so has limited the ability of OSS tools to support AOP properly.
Re:aspect-oriented programming (Score:2, Informative)
Re:aspect-oriented programming (Score:1)
Re:aspect-oriented programming (Score:1)
If that is true, then that alone would probably doom it unless it was so clearly better than what came before it that people live with a "patent tax".
Re:aspect-oriented programming (Score:1)
As long as you can say "A class is also an object, so I should be able to define its class to control its behavior any way I want", you can replicate AOP behavior very easily, with much more power too. Smalltalk for example can do everything AspectJ does for Java and so much more. And let's not even get started with Lisp-based OO languages! Having said t
Why is this insightful? (Score:4, Insightful)
I mean, what exactly were the buzzwords here? 'Tier?' 'Enterprise?' 'Build?' 'Introduction?' Do tell!
So, what was +5 insightful about this comment, other than its pandering to a the Slashdot contingent that doesn't bother reading or thinking very hard about the issues at hand?
More comments on J3EE... (Score:2)
A lament to Java. (Score:4, Interesting)
Unlike EJB CMP CMR and like JDO, Hibernate can work inside of or outside of a J2EE container, which is a boon for those of us doing TDD and agile development.
Acronym hell. Java used to be pretty easy to understand. There was Swing, there was AWT, there was the language and the development environment was concise. Not all of it was good, but I knew where I stood. Right now I know that 4 of those 6 acronyms aren't relevant to my work as a programmer. And none of them relate to Java as a language. People talk about ATL, STL, MFC and whatnot, but C++ the language has endured as a language independent of its modules. Love it or hate it, it's a language that deserves respect for this endurance. Right now I can't say that for Java. Whatever happened to plain Java?
Maybe I'm just not getting it, but me "getting it" is what's the deciding factor in my choice of tools, since I have to get it to do my work. I get .NET; there's the language (C#,VB,C++,WinForms, all .NET) and there's the tool (Visual Studio, maybe Mono). I know for a fact I can write code using VS that can compile on linux with the minimum of modification. I also know which modules lock me to windows (VB.NET, Winforms) and which ones don't (maybe C# if Mono succeeds, Strict C++ saves the day for portability). I learnt this from documentation, research and testing by my own hand. I've researched Java, kept informed of it, but all I see now is a concoction of marketing hype and a bad case of constant scope creep. Another quote:
The starting point is an enterprise application for which you are implementing a transactional persistence layer.
Overkill! I'm sorry, my customers aren't going to spend the money buying our software when they need to install an entirely new infrastructure to support it. The margins aren't that high in my industry. Besides, why do I need yet another framework? What was wrong with the old one? If the old one was so bad it had to be replaced, why promote it in the first place? I don't care about an implementation of the newest development methodology. I care about development cost, infrastructure, what customers will put up with, and what I can support without costing me a fortune in time, effort and understanding.
This article showed me nothing that gives me any clue to how useful this is really going to be "in the field". I think I'll just go hibernate until Java springs into action...
Re:A lament to Java. (Score:1, Insightful)
It died like 5 years ago, sorry you didn't get the news. "The Framework" is now J2EE.
Besides, why do I need yet another framework? What was wrong with the old one?
A lot of things, starting with cost and complexity. Sure if you've already spent the $100K to rollout WebLogic, this isn't for you. But for smaller projects and non-banks, having something lighter-weight than J2EE would be a godsend. Especially since the basic functionality is "free" with
Re:A lament to clue (Score:5, Insightful)
We got tired of reinventing the wheel. These API's exist because the solve problems. By not having to deal with these problems, you can focus on your specific business needs.
Have fun writing everything in C++ (no STL mind you) and no linking to external libraries. Let me know how it goes talking to the database, or parsing that XML file some vendor just sent you.
I can't tell you how many times someone has said to me "Gee if we just had our own implementation of platform and vendor neutral database connectivity API it would solve a critical business need!".
Re:A lament to clue (Score:1)
Apparently your sarcasm detector was not properly calibrated.
Re:A lament to Java. (Score:3, Insightful)
J2EE is the result of monster corporations fighting over huge unmanageable solutions. The compromise usually involves using *everyone's* solution (example - both session beans and entity beans exist because IBM and Oracle couldn't agree on a strategy for persistence). Spring is simply the open source community's response: Smaller, lighter, pluggable
Re:A lament to Java. (Score:2)
I lost track of the number of frameworks that came up promising "an easier way" to develop X or Y for Java. As much as I'd like to stick around to support something non-MS, which I know could be good if not better, I don't know as yet how long Spring will last.
Re:A lament to Java. (Score:3, Interesting)
Unlike EJB CMP CMR and like JDO, Hibernate can work inside of or outside of a J2EE container, which is a boon for those of us doing TDD and agile development.
Acronym hell. Java used to be pretty easy to understand. There was Swing, there was AWT
I call bullshit, or at least Apples to Oranges! What are you talking about - developing a desktop GUI app? Then there still is Swing, and there is AWT, and not that much has changed.
Or are you talking about database-backed server applications? For smalle
Re:A fruity lament to Java. (Score:2)
I'm comparing oranges to oranges. They're comparing apples to apples. I have no interest in apples; that's my point, which I think you missed. Having a whole fruit basket of API's to work with is sweet, but too much sugar gives you diabetes and makes you fat.
Sorry, got a bit carried away with my metaphor.
But just because you don't need these projects doesn't mean I don't need them (I do)
I'm not saying these projects aren't useful to
Re:A fruity lament to Java. (Score:2)
[...] the presentation and integration of these enterprise extensions as a part of the standard language is not beneficial to Java's perceived suitability for everyday programming work.
None of these projects is part of the standard Java library. JDO is a separate package. Hibernate is an open source library. So is Spring. EJBs are part of the J2EE package (hint: EE = Enterprise Edition), but not of the J2SE package (hint: SE = Standard Edition). Your point being?
Re:A fruity lament to Java. (Score:2)
Specifically, the article starts the discussion at the enterprise level. There are a dozen or so references to J2EE (zero to J2SE), and the example deals specifically with running on an application server. What exactly is the
Microsoft ObjectSpaces Initiative? (Score:3, Interesting)
CA/Fujitsu abandoned their Jasmine OO database product, and it looks like Progress is allowing ObjectStore to wither on the vine.
Oh, AND WE NEED 64-BIT DATABASES AND 64-BIT PROGRAMMING LANGUAGES LIKE YESTERDAY!!! SQL's 32-bit BLOB just doesn't cut the mustard. Hell, the following won't even compile on Java 1.5:
} Any advice as to 64-bit object-oriented databases would be MOST appreciated.Thanks!
Re:Microsoft ObjectSpaces Initiative? (Score:1)
More questions. (Score:2)
Hibernate is years ahead of ObjectSpaces. Even some beta
Re:More questions. (Score:1)
data mirroring is not performed by an ORM, because it's not its function or objective. That should be performed by the database.
security is also a different matter, in Java there are several schemes, like JAAS, but you can also use LDAP or active directory (MS's crappy version of LDAP).
Veritas is also something that an ORM is not aware of (nor should it be)
Good combination (Score:1)