Filed in archive
Application Development
by jason on March 26, 2006

Anyway, Bill Venners and Bruce Tate are both trying and peel back the layers and help us understand these things better. I suggest Java developers read the two articles they have written recently (links above) to get a better understanding. Whether it is code generation or how Rails deals with the persistence layer the framework has hit on something of value. I for one am trying to take a deeper dive to figure it out so I can become better at what it is I do as an IT professional. Name-calling doesn't pay the bills.
Permalink: Rails Lessons Applied to Java
Trackback: http://publish.creative-weblogging.com/publish/mt-tb.pl/18895
Mr Wong
Vote for Rails Lessons Applied to Java:
|
Rating: 6.67 out of 3 vote(s) cast.
|
Response from:
nano -
(03/26/06 12:14pm)
Response from:
Jason
(03/26/06 8:02pm)
Thanks Nano.
Apache's Torque project is not something I've used before. I'll check it out soon.
I've have been using XDoclet with Hibernate a lot latley. After setting up my annotations in my JavaBeans it takes care of all the Hibernate mappings and generating the database schema. I haven't had to touch any SQl in the past six weeks and that is fine with me. It is not as easy as RoR but it beats the hell out of using JDBC.
Apache's Torque project is not something I've used before. I'll check it out soon.
I've have been using XDoclet with Hibernate a lot latley. After setting up my annotations in my JavaBeans it takes care of all the Hibernate mappings and generating the database schema. I haven't had to touch any SQl in the past six weeks and that is fine with me. It is not as easy as RoR but it beats the hell out of using JDBC.
Response from:
Solomon
(03/27/06 9:17am)
"Koolaid Point" was well used... Kathy Sierra's basic premise of "Creating Passionate Users" (http://headrush.typepad.com/)
has a wide degree of applicability for an entrepreneur ;)
has a wide degree of applicability for an entrepreneur ;)
Response from:
San Francisco News
(04/27/07 7:30am)
I think programmers often don't like code generators that come from the outside, because like any framework they will often only take you 90% of the way you need to go. After that you start fighting the framework, which in a code generator often means you want to tweak the generated code. But that usually defeats the purpose of the code generator, which is to give you huge leverage. An exception are things like the scaffold generation in Rails, which is intended to just be a quick start that you edit and carry forward. Our in-house code generators are the kind where we aren't supposed to touch the generated code, and we solve the 90% problem because when we need to change the generated code, we change the code generator (since we wrote it, we can change it). Read more about the subject : http://www.thesanfrancisconewsblog.com
Response from:
donate car
(04/27/07 5:23pm)
It seems that Rails has highlighted a very real problem with Java frameworks in general - and I’m speaking from bitter experience - that when a choice between ease of use and flexibility is presented, Java framework developers have tended to choose flexibility. With Rails the developers have done the opposite, to a relatively extreme degree, and it’s working. Good to see that some in the Java world are responding positively!
Subscribe
Use the search to look for other interesting posts
| RSS | See all blog subscribe options |
|
What is RSS? | |
| Yahoo! |
|
| Addthis |
|
| Bloglines |
|
| Newsletter | |
| Follow us on Twitter! |











and code generation using XDoclet it is easy to achieve RoR like easiness in persistence layer.