Slashdot Mirror
Hibernate - A J2EE Developers Guide
What's To Like
The first thing that I liked is the way the book is written. Mr. Iverson has a very pleasant writing style that I found engaging. Not too formal and not too light. Naturally, there is a certain amount of Hibernate evangelism, but hey, if the author doesn't like the tool, then how am I supposed to feel good about it either? The evangelism does not feel like it strays from the bounds of truth, and there is much honesty in his first and last chapters where he discusses reasons for using a tool like Hibernate, and how Hibernate has influenced the design of the soon-coming version 3 of the EJB standard from Sun.
Chapters two, three and four cover the basics of using Hibernate. Each covers a different aspect, and each is independent of the other. Chapter two covers the use of the Hibernate mapping file as the reference that everything else is built from. This is the recommended mode of operation, where the database schema and data access objects are built for you. Chapters three and four are for those of us in the corporate world where the code or the database schema comes first and we have to adapt to and accommodate it.
Chapters seven and nine give the database theory-challenged amongst us a useful refresher in database relationships and transactions. The information, while provided in the context of Hibernate, serves as a useful refresher for the rest of us.
Hibernate has three query mechanisms. Given its relational database capabilities, one of the options is the use of plain old SQL, naturally. The two remaining options are the Hibernate Query Language (HQL) and the Criteria API. The HQL gets a fairly decent amount of coverage and left me to infer that it is the preferred means of expressing queries. The Criteria API gets only four and a half pages of explanation, which is still more than the single page dedicated to SQL.
The next to last chapter is a collection of real-world advice and tips for getting the best from Hibernate. This is a very useful chapter and looks like it contains good advice. The only thing I would suggest is that it's a little slim for a chapter of its own. Either the information could have been tucked in an appendix, or it could have been spread through the book in the form of embedded tips.
Naturally, the book has a website to accompany it.
What's To ConsiderThe book carries a copyright date of 2005 and a first printing date of November 2004. That being said, it should come as no surprise that the version of Hibernate covered is 2.1.2, but at the writing of this review (early April 2005) Hibernate 3 went final. I feel that the majority of the concepts and basic operations will be unchanged, but take this into account when deciding upon a purchase. While it is difficult to write books against the constantly moving target of an open-source or free software project, it is possible. I was involved in the technical review of a number of Struts books and they were challenged with the task of being available as version 1.1 was released. A massive undertaking, but one that they proved doable.
The typesetting seems crowded in this book. I'm not a white-space extremist, but I sure recognise when there's too little. The listings are often multi-page and have a slightly squashed feel to them.
Depending upon your point of view, chapter five is either a very useful annotated explanation of all of the available mappings within Hibernate, or it's a bad case of using available online documentation as filler (53 pages). Personally, I dislike this, but if you're in the market for an "all-in-one" style of book, this might work for you.
SummaryThis is a solid work that will take you from novice to a good working knowledge of Hibernate. If you can live with the fact that the book targets Hibernate 2.1.2 while the current production version available from the website is 3.0, then give this book a try.
You can purchase Hibernate - A J2EE Developers Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'm programming Java, bitch!
Hibernate, first of all, is becoming the de facto persistance layer for all modern java webapps. Tied up with the Spring Framework for transactions and either Struts or Tapestry on the front end, it is becoming a commonplace for tons of Java work.
This book, however, I found extremely lacking. It didn't really teach me anything new that I didn't already learn from the webpages. Granted, I've been using hibernate for over a year now and have kept up with the technology, so perhaps this is still a book for someone new to the technology.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Whenever I see "is a powerful, ultra-high performance" I just stop reading right there. Excess positive adjectives are a sure-fire sign of misrepresentation.
"I'm not a white-space extremist."
(Did anyone else almost misinterpret that?)
I don't know, you never can tell how crazy far-right those Java programmers are... them and their "non-free" interpreter. I for one thought we lived in a more enlightened time.
Isn't 351 pages a bit lightweight, for a complicated subject.
Yeah, really, it's not that bad. As a Java programmer, I've come to find out as long as you make sure you don't use more memory than you need (i.e. nulling variables that are no longer useful), things run fine... ...correction. Things run fine so long as you don't use Swing. Swing needs a serious makeover (yes I'm aware of alternatives, but Swing just looks so dang cool when it works)
Before you mod me funny, think, perhaps I was insightfully funny?
I can't believe a review of a book about Hibernate would not compare it to the book everyone recommends, Hibernate in Action. HiA is a great book, written by people who work on the project, including the lead developer. Of course, this review doesn't have much information that couldn't be obtained from skimming through the table of contents on Amazon.
Java isn't entirely interpreted anymore. In fact, much of it is just-in-time (JIT) compiled to machine language, meaning when you're about to run some Java code, the Java Virtual Machine compiles the byte code to native code on the fly.
.NET/Mono languages are all JIT'd, zero interpreting. Java is much the same now, it was just originally designed to be an interpreted language.
.NET/Mono have ahead-of-time (AOT) compilation, meaning you can compile your dll libraries or exe applications to native code at install time.
FYI, the various
Also,
Tech, life, family, faith: Give me a visit
SWT
Problem is, swing has been that way since the first time I saw it, in 1998!
I know the guy who did the swing grid control -- friends and I used to give him shit all the time for how slow it was.
Is it going to be replaced by C#? Perhaps, but it is possible to fully exploit it today, and with tools like Hibernate it's possible to rapidly deploy applications on a grand scheme. In today's business environment it is often a matter of getting it done fast rather than best, and if it's turning into a problem with performance it is always possible to turn to another language once you have something in place.
I never vote for anyone. I always vote against.
-- W.C. Fields
I am curious to know if this books spend a decent amount of space on actually using Hibernate in the context of a J2EE application (i.e., instead of using CMP)? I currently work with CMP and I am not a huge fan, I am very interested in alternatives and wonder if this book is the place to start looking.
The title of the book implies that the book does cover this, but the review doesn't actually mention this specifically.
Just curious, what do you mean that Swring needs a makeover? I've used Swing extensively (but I have no experience with any other GUI toolkit), and I am curious as to what it's problems are in your eyes. Do you mean visual problems, or (code) usage problems?
What is the latest on this battle?
There are so many soundbites floating around:
Hibernate is JDOish but does not follow Sun JDO Spec. But.. Gavin King of Hibernate became a member of JD02.0 Expert Group and would make it compatible with JDO 2.0 Spec.
JBOSS is adopting Hibernate as the underlying persistence mechanism for its Container-Managed Entity Java Beans.
EJB 3.0 rejected JDO 2.0.
So.. now I am confused. Who is the winner? Should I buy the book or not? Anyone care to enlighten us?
Perhaps blackmonday should insert a Clayton Bigsby quote here. But if not...
...or something.
Say White Space back at ya brother!
You can hold down the "B" button for continuous firing.
I know you were being sarcastic in your first post, but a lot of people (especially ex-VB6ers) don't understand that Java is JIT'd, or even what is JIT'd means.
Tech, life, family, faith: Give me a visit
Is this for newbies?
http://savescooter.sytes.net/
IMHO significantly better...but click and decide yourself
if (java.performace >= c.performace) I.eat_hat();
Bleh:
push ax
push bx
push cx
call test_speed_C
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move al,ds:[di+2]
call test_speed_asm
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move ah,ds:[di+2]
cmp al,ah
jb bwahaha_msg
pop cx
pop bx
pop ax
Chicks dig asm, but I'll concede it's so-so for rapid prototyping though...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Does hibernate compare to what I currently use:
:P
* Tomcat
* WebMacro
* Custom Web Deployment platform.
The web platform has its own connection pooling, user access management (before template is evin processed), caching (of ANY object or abritary data / response), fully Java OO scripting language (thx to WebMacro), persistence, threading, database query management and resultset object representation.
Although not as good as the system where I used to work, my system is getting there.
It is scalable, fast, and very quick to develop on.
I am at a loss as to why there is so much hype on Hibernate.
I guess I will have to rtfb
....... /
No, JAVA itself has never been an interpreted language. The Java program you write is in fact compiled, but not to native code. It's compiled to bytecode for the Java Virtual Machine, which is a stack machine(not too many physical stack machines exist nowadays, but hey, it seemed good at the time). The bytecode then can be compiled into native format as it runs inside the JVM.
Monstar L
Java JVMs are typically written in c/c++. Your comparison if flawed.
If you think Hibernate is good, then try Cayenne and really be blown away.
I am not affiliated with Cayenne at all - just a VERY satisfied customer.
http://objectstyle.org/cayenne/
To follow the usual java method naming conventions, your method should be named performAce(). Also, from a readability standpoint, a method named performXXX() should probably return void. Secondly, any C programmer worth his salt will remove some (but not all) of the vowels from a method name to mark his territory (i.e. c.prfrmce).
Lastly, would you like fries with that hat?
It's simple: I demand prosecution for torture.
Current JVMs are reasonably fast. In fact, most performance gap between java and C comes from its safety features.
Safety, however, is very important for web apps. Writing regular sites in C is just asking for C-style memory attacks, like buffer overflows.
Finally, nobody really complains about python's or perl's speed.
The Raven
Exactly my point. When I said "compiled", I was speaking of compiled to native code. Java, C# and other .NET languages are compiled, just not to native.
.NET/Mono apps depend on JITing and AOTing to get to native.
Java depends on interpretation and JITing to get to native, while
Tech, life, family, faith: Give me a visit
I thought this was a discussion about Hibernate, not the Slashdot Urban Myth about Java performance. And in some cases, you'd have to make sure that hat was edible..
The most important unanswered question: does it discuss XDoclet?
I know, many people like maintaining configuration files manually. Some people also like nailing their tongue to flaming coals.
Personally I prefer using a handful of @hibernate and @spring tags. But I haven't found a decent explanation of how to use the tags (e.g., if you use A you must also use B). It can be annoying - I only recently discovered the @hibernate.joined-subclass tag that permits me to use a common base object (for an integrated 'id' space) without creating a "kitchen sink" monster table.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
If you wanted those flame wars, you could just head over to theserverside
But on a slightly more serious note, it seems that there are moves afoot for reconciliation between EJB and JDO. There's a link with discussions here. Enjoy the reading. theserverside does have some infamous trolls and makes slashdot look like the greatest thing since sliced bread.
So does Anonymous Coward have good karma?
What you meant to type was:
.agrippa.
"I don't want to start a language flamewar, but I just finished reading a slashdot article comparing Ruby on Rails to Java + Spring/Hibernate and was hoping that was enough to interject into this conversation with the hope someone would click on my free Nintendo DS, GC, PS2, Xbox link."
Don't worry, it happens.
Why so damned many complicated wrappers just to hide from SQL? The probability of switching DB vendors is small for most projects (and is further dimished by a financing principle known as Future Value). And, it is usually more efficient machine-wise to take advantage of native vendor SQL features. And, one can use "value micro-wrappers" to avoid SQL hacker injection.
Learn SQL and embrace it. Stop hiding from it, people. The medicine is growing worse than the desease. The schema is the noun model, not your verbose classes.
Jalepeno is a JIT-based Java VM written in Java. It doesn't have an interpreter--it uses a fast-but-lousy code generator for most code, and progressively higher optimization levels for hotter code.
I've always wondered why the XDoclet folk thought it was a good idea to embed the app's configuration in the Java source (via the various @foo tags). As an XDoclet user, can you provide some insight?
Hey I know it's always open season on VB guys here on Slashdot, but what do they care about Java performance, JIT'd or not?
You say Tom-ah-toe and I say interpreted. Let's call the Java compilation off.
On that, would someone take time time and write a nice e-Book on JSP/JavaServlet for WikiBooks? Please! It'll only take a moment ;)
-- Bored? Check out my Portfolio
For those of us that want a simpler, faster, easier to use framework and just want to map your own queries to objects, is much better. And for those that like .NET it is available in that platform too.
e r);
Here's an example on how to execute a query called "myquery"
MyObject myobject = (MyObject)sqlMap.queryForObject("myquery",myinteg
And here is the query declaration:
<select id="myquery" parameterClass="java.lang.Integer" resultClass="mypackage.MyObject>
select * from mytable where id = #value#
</select>
Simple query to object mapping
Open Source Java Web Forum with LDAP authentication
Yeah, Java got a bum rap early on for speed. But people quickly showed that in many of Java's preferred domains, I/O latency was by far the primary reason for speed issues.
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue, but a lot of people got angry because their sluggish machines couldn't handle it. This continues even today. A common comment about Eclipse, for example, is that it's a terrific IDE so long as you have a very fast machine.
These days, when you hear educated people complain about Java, it's not usually because of the speed issues anymore. It's usually language issues (Java needs that, Java shouldn't have this, etc.). The validity of these complains depends entirely on your viewpoint.
Slashdot. It's Not For Common Sense
From the Hibernate homepage:
The Hibernate Query Language, designed as a "minimal" object-oriented extension to SQL, provides an elegant bridge between the object and relational worlds. Hibernate also allows you to express queries using native SQL or Java-based Criteria and Example queries.
So...I'm guessing you're using the phrase "SQL writer" in some new and unusual way. Does "SQL writer" mean "writes SQL output to standard output"? Do you mean "SQL optimizer?"
Hibernate can only talk to RDBMSs that use SQL. It writes SQL to them and recieves SQL from them.
Mod me down and I will become more powerful than you can possibly imagine!
switch to .NET...all J2EE IDE's suck...
From Hibernate in Action,
... from BID B inner join ITEM I on
Would you rather type:
select
B.ITEM_ID = I.ITEM_ID inner join CATEGORY C on
I.CATEGORY_ID = C.CATEGORY_ID inner join BID SB on
I.SUCCESSFUL_BID_ID = SB.BID_ID where C.NAME like 'Laptop%' and SB.AMOUNT > 100
than this:
from Bid bid join bid.item item where
item.category.name like 'Laptop%' and
item.successfulBid.amount > 100
Your call.
You do have a point about the schema being the noun but that doesn't really fly in a multi-tier system. You could easily argue that a single tier system is the best approach, thereby using the schema as a noun. There are serious benifits to this but I haven't seen a system that provides the necessary front end technology straight on top of a database. Although I dissagree with you I do like the lines that you seem to be thinking along.
FYI, the various .NET/Mono languages are all JIT'd, zero interpreting. Java is much the same now, it was just originally designed to be an interpreted language.
.NET/Mono have ahead-of-time (AOT) compilation, meaning you can compile your dll libraries or exe applications to native code at install time.
Wrong, and wrong.
First, off JIT doesn't mean "zero interpreting", no JIT VM compiles all code. It's simply not efficient to do so. And all that code is interpreted.
Second, Sun's first VM for Java was an interpreter, but Java was not at all designed to be an interpreted language. In fact, it was designed with allowing JIT VMs in mind. (And Sun's JIT VM was publicly released in '96, only two years after Java itself)
Also,
Yes, but please note that this is performing the compilation the JIT does ahead-of-time, which again isn't all of code. So it's not the same thing as conventional compiling to native code. (Although the difference isn't big performance-wise)
I'd rather call
MyObject obj = (MyObject)getmydamnobject(Object searchParamA, Object searchParamB);
Hell, I don't even want to have to cast it; what the hell else would I want? Why the hell would I try to cram an integer into a custom datatype?
Sadly.... ah fuckit.
Looks nice. I wish this all took less mental overhead; not saying it is *hard* persay -- just so much crap in the attic to pull down, dust off and use every time we need to write a decent prog.
We really are the mages of our time -- waving our hands in funny, highly scripted ways and producing... well, hopefully something interesting, but generally... I digress.
The above paragraph is language neutral -- we all have our own rituals. I am not referring to goats, silver daggers and moonlight here either people.
Hibernate's fans say it's the "right" way to handle extremely large, complex data models, especially if they already exist.
What you have to do is write yourself a new Java class (according a to big complex set of rules), one for each entity in the model. And there are a lot of different ways to handle various association-types and cascading-persistence requirements.
Once you've done all this, you have Hibernate's methods for "easily" loading and saving the objects.
So in a way you have to re-express an already-existing data model in code.
Anybody with experience in the tool care to argue whether it's worth the effort?
portability
Sure. Fuck off, spammer.
Some RDBMS can use "natural joins" which shorten join code. Or, one can use views for frequently-used join patterns. Joining is usually not where the bloat is anyhow if the schemas are well-designed in my experience.
I don't think it makes sense to have a slightly-different-than-SQL syntax. It increases the training and confusion. Better to stick with a standard unless you get significant benefits by deviating. If you are going to overhaul SQL, then let's go all the way and start over.
Here's an analogy - you're going on vacation. Deciding whether to go to Orlando or Cabo is a top-level decision comparable to what a deployer makes. The implementation of the embedded software in the navigation avionics of your flight is comparable to what XDoclet generates. You shouldn't touch it, not without a compelling reason.
Once you accept this the benefits of using XDoclet are obvious. First, you only have to update information once - the configuration file and generated source files will be automatically updated. You don't have to worry about getting called into an urgent meeting and forgetting to update the fourth auxillary file.
Second, the XDoclet tags help document the nature of the fields and how classes are related. E.g., if I see
@hibernate.property not-null="true" unique="true" length="20"
I know a lot more about the field than "String" alone tells me. It's also another example of "write once" since I don't have to worry about a block comment getting out of sync with a configuration file.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
How could people not have found that funny???
Aren't there Dave Chappelle Show fans in here??
Geez...
To me it makes somse sense to abstract the data access away from the business application. This metholdogy embraces the whole notion of object-oriented design, since switching out the data means you won't have to touch the business app - just the interfaces.
Ok, here are a few reasons why I *wouldn't* want to use that hibernate syntax:
1. how do I separately validate the syntax & query results? Can I run it in on a command-line? In a query tool, etc?
2. how do I diagnose subtle problems caused by hibernate join failures? Exactly what sql is it running?
3. how much flexibility does it have? Can it handle outer joins? Subselects? Group bys? Aggregate functions? No? Then why use such a poor subset? Yes? Then why not just use sql?
4. How do you leverage dbms-specific features? Yes, I know that it's best to stay generic, but when you need to add more analytical queries to your app (to deliver something beyond simple CRUD), you want to use olap functions, etc. Now, yeah, you could do this in your app. But it'll be slower. *Far* slower: you might have to process a hundred thousand rows - and the database will do it in less than a second. Your app? Maybe 5-10 seconds?
My recommendation is to learn sql, use standard sql whenever possible for portability. But learn the advanced sql required to deliver robust functionality. And when required be prepared to dip into vendor extensions.
Or stay away from huge, challenging, and powerful business applications.
If you choose a programming language based on its inclusion of unsigned types, you're an idiot. You're an old troll that will never succeed in the real world.
This metholdogy embraces the whole notion of object-oriented design, since switching out the data means you won't have to touch the business app - just the interfaces.
SQL is already an interface, and a rather high-level one at that. Putting interfaces around interfaces is overkill. IMO people wrap SQL because they don't like it or don't know it, not necessarily because it is inherently "bad". It "encapsulates" many collection-oriented concepts into a fairly decent standard. OO tends to allow roll-your-own collection oriented interfaces, producing inconsistcy and often reinvent the wheel in the process.
Table-ized A.I.
The new database benchmark "PolePosition" shows how much performance Hibernate costs:
c hmarks/).
http://polepos.sourceforge.net/
For overcoming the object-relational mismatch in resource constrained applications, like on mobile platforms, or where performance matters, you might want to look at the open source object database db4o (http://www.db4o.com/ which is up to 44x faster in the benchmark (http://www.db4o.com/about/productinformation/ben
Chris
Well in m:n relations in hibernate you need at least three tables beneath it, so no two table join limit there. As for the queries, yes simplistic queries are faster as long as you dont hit a cache. In the typical webapp 90% of the operations are done over and over again on almost the same data, and there hibernate can shine. You can add a query cache if your query is constantly started again and again, you can start to cluster on application cache level once you hit a maximum of possible site users your VM can handle so that you still run against one DB but have clustering due to a cluster cache on the Object level.
You dont have to write any JDBC to object binding code which almost every plain JDBC app does. You basically are 99% database independent thanks to the abstracted query language and abstracted data type mapping. You have automated connection management, to keep the number of connections small.
The list of stuff Hibernate adds to this mix is endless. But dont expect to run a single query on a plain table as fast as one in JDBC. The reason for this is, all this caching and query translation, object mapping stuff comes with a small constant speed penalty which goes away once you run into the caches or you have to do bigger work in JDBC and have to start to implement the caching and mapping yourself (which you almost always have to do)
You will start to love hibernate once a customer or your boss decides to switch databases for political reasons and wants a reasonable upgrade path.
Nice trolling. Java programmers don't go around 'nulling variables', the gc takes care of any object that isn't reachable.
As for Swing, yup - it needs fairly beefy hardware, but certainly beats the alternatives.
I personally like to keep the abstraction down, so I have so far avoided any object-relational mappers. (My favourite language is Perl, too, so those technologies you hear most about aren't even available.)
In many cases, the query needs to be written only once -- just like some other posters noted, wrapping the query inside a method and then calling it by its name is a pretty nice way to do whatever you need, from the application viewpoint.
From what it looks like, though, Hibernate has reinvented a simplified version of SQL suited for object stuff -- of course the hidden cost here is that for your simple query to work it needs to be backed up by some XML configuration. (Which looks a tad involved, just like SQL in general looks a tad involved.) But on the other hand, once the XML is there, any query should just work! So probably it's a win, after all: one painful configuration, then easier usage later on.
But in many cases you get past painlessly with just SQL views, which allow you to express the queries in terms so simple that even a manager could understand it.
I still hand-craft my SQL due to having worked with SQL for something like 5 years. It isn't bad, and in many cases it keeps typical web application very simple. Here's how the code for a view usually looks like:
$template->{param} = $dbi_wrapper->execute_sql($sql, @the_placeholder_values)->fetchall_arrayref({});
It's not pretty for the uninitiated, but it means that a typical webapp is driven by the SQL and the template language chosen (which could be Embperl or TT or something else). The only work for the code is validating the placeholder values and choosing the right SQL. I doubt this would be any faster or simple with a framework, though I _might_ be proven wrong.
if (java.performace >= c.performace) I.eat_hat();
e ck_section("SciMark 2.0");
open_url("http://www.shudo.net/jit/perf/");
ch
eat_hat();
I believe Bhavaya does along the same lines?
.
They will never know the simple pleasure of a monkey knife fight
There is a .NET port of Hibernate here: http://nhibernate.sourceforge.net/
Free Scotland!
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue
That is odd. As I sit here typing there are two major Java GUI apps open on my desktop, which have good interfaces and work without change on Windows and Linux. I have developed my own Java GUI apps and have had no porting problems for years. How is this untrue?
Ok, here are a few reasons why I *wouldn't* want to use that hibernate syntax:
It's been a year or so since I last used Hibernate, but IMHO, it rocks compared to hand-written SQL. Now, for your points:
1. how do I separately validate the syntax & query results? Can I run it in on a command-line? In a query tool, etc?
There exists a GUI tool for this, see http://www.hibernate.org/259.html
2. how do I diagnose subtle problems caused by hibernate join failures? Exactly what sql is it running?
You turn on the sql output switch in the config file, and look at the sql which depending on your configuration is output to the console or the log file.
3. how much flexibility does it have?
A lot.
Can it handle outer joins?
Yes.
Subselects?
Yes.
Group bys?
Yes.
Aggregate functions?
Hmm, I don't remember, but I suspect not. Of course it is possible and advisable to use both SQL and Hibernate in the same application.
4. How do you leverage dbms-specific features? Yes, I know that it's best to stay generic, but when you need to add more analytical queries to your app (to deliver something beyond simple CRUD), you want to use olap functions, etc. Now, yeah, you could do this in your app. But it'll be slower. *Far* slower: you might have to process a hundred thousand rows - and the database will do it in less than a second. Your app? Maybe 5-10 seconds?
In general, Hibernate has pretty good support for stuff that you can find in standard SQL. Also, the architecture of Hibernate makes it extremely suitable for CRUD style stuff, e.g. the caching works very well if the app has any notion of working set, and Hibernate saves huge amounts of time when retrieving complicated object graphs compared to writing SQL by hand. For reporting, OLAP etc. Hibernate is less well suited. The general consensus seems to be to take advantage of Hibernate for CRUD stuff and do complicated reporting/OLAP/whatever in (vendor specific) SQL.
My recommendation is to learn sql, use standard sql whenever possible for portability. But learn the advanced sql required to deliver robust functionality. And when required be prepared to dip into vendor extensions.
My recommendation to you is to at least take a look at Hibernate; it makes you look less like a fool when people see that you have at least a vague idea of what you're talking about.
Or stay away from huge, challenging, and powerful business applications.
Yeah, that's what I do these days, business apps tend to be very boring. Fortran (and computational physics) forever!
Many people, myself included, have made GUI apps with Java. And everyone goes in-full of optimism-and says, "This will be easy! Java makes it so that we can deploy on multiple platforms!"
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability. A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I've also developed apps for multiple platforms using Qt, and I have to say that the Qt experience in C++ and the Java experience were, all in all, about equal. Which is to say better than it would have been 10 years ago, but not painless by any stretch of the imagination.
Slashdot. It's Not For Common Sense
Why is this under the Hardware tag ?
It's OK - this is a rhetorical question, like "Why the Editors don't ?"
To an extent I agree, but there is still the issue of converting tables back and forth from the object models used in the business app.
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability.
I would say that it really does help significantly. I don't know of any other major language that is as easy to deploy, and I have had decades of experience. It sure isn't perfect, but compared to library and versioning issues, even within a supposedly single OS like Windows, Java has been a dream for my work.
A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
I would agree, but Java gets it better that almost any other system, I would argue. It gets you 90% there, and should be praised for that.
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I think is is far, far less of a problem that it used to be. Things have improved hugely since Java 1.3.x, and now with 1.5.x, I am finding Swing apps extremely responsive most of the time.
I know Java isn't perfect if you want to write apps that tie in to each platform in detail, but for cross platform apps, I think it is outstanding.
But I will reiterate that most people who dislike Java dislike it for the design of its library and its linguistic features and its developer culture, not because of any flaws in its implementation.
I don't want to poke a hornets nest, so please keep in mind I work with Java nearly every day, and the other language I get paid to work with is C++ (which I also dislike, somewhat). Here are some examples:
These are just a few examples of what I was really getting at.
Slashdot. It's Not For Common Sense
Hey thanks for the informative reply. Still suspicious of the value of something that thinly skins simple sql & doesn't help with complex sql - but I'll have to take a closer look.
ken
To an extent I agree, but there is still the issue of converting tables back and forth from the object models used in the business app.
Toss OOP then.
I know this comment will never get seen, but I'll bite anyways. The situation I'll give may not be quite right, because I'm writing this on the fly... Situation:Accessing a LARGE ArrayList. This is the last time it will be needed. Due to the function that it calls during it's loop, you get an out of memory error. Here's what you might do... for(int i=0; imyList.size(); i++) { iUseMemory(myList.get(i)); myList.set(i,null); } ...and voila. It helps out the memory problem. Garbage Collector is great, but can't do everything.
Before you mod me funny, think, perhaps I was insightfully funny?