Comments for JavaRant.com: News and tips to help you succeed in Java

Comment on Setting up an SDK in Eclipse by jeffrichley

jeffrichley — Tue, 10 Jun 2008 13:22:25 +0000

I used wink to create this video. It is pretty easy to set up and get going. Another good one is Jing. I have started using Jing on my new demos that I set up, it seems a bit more polished..

Comment on Setting up an SDK in Eclipse by Adam

Adam — Sat, 07 Jun 2008 01:06:11 +0000

If you don’t mind me asking, what did you use to create the video?

Comment on JavaOne Update - Day Three by Matt

Matt — Sun, 11 May 2008 15:20:34 +0000

Sounds like you guys had a great time and learned a bunch too! I went to JavaOne in 2004 and it definitely is a great experience — if for no other reason you come out re-energized and jazzed about what you do for a living. I’m jealous of you guys!

Comment on Groovy: The Red Pill by Scott Davis

Scott Davis — Fri, 09 May 2008 18:20:02 +0000

It was my pleasure. I think the Groovy’s strongest message is that you don’t have to throw away your Java skills (or source code) to get started. Keep us posted as you as you find new ways to mix Groovy in with your existing Java.

Cheers,
s

Comment on Groovy: The Red Pill by KoW

KoW — Fri, 09 May 2008 10:37:20 +0000

Just wait till you read and/or manipulate XML with Groovy…
This alone makes it worthwhile

Comment on Memory, memory everywhere and not a byte to eat by jeffrichley

jeffrichley — Mon, 21 Apr 2008 18:13:02 +0000

It isn’t that the logging isn’t guaranteed, it case of a JVM crashing because it is out of memory. When a JVM crashes, it is hard to tell what is going to be completed and what will not.

Also, it wasn’t so much Hibernate that was keeping it in memory, it was the Log4j loggers that had it queued up. Hibernate was the producer of the data being passed to Log4j. It is much like any production code, you typically don’t want to have tons of logging going on when in a production environment, certainly not at a “debug” level.

Comment on Memory, memory everywhere and not a byte to eat by Andries Inzé

Andries Inzé — Sun, 20 Apr 2008 19:11:36 +0000

Very intresting, it puzzled my mind quite a bit.

As you state, Hibernate keeps the logging in memory, until it has time to be processed. Does this mean that, when under heavy load, the logging isn’t guaranteed to be written down? I’d thought, when a transaction is finished, all logging of the transaction would at least catch up before starting the next one.
I find it very strange that the logging isn’t guaranteed.

Comment on Memory, memory everywhere and not a byte to eat by david

david — Mon, 24 Mar 2008 01:08:29 +0000

That’s a great hint Jeff, thanks for sharing this. It’s really coincidental that I just wrote a blog post on using 3rd-party libs and bug hunting: http://dlinsin.blogspot.com/2008/03/why-me.html

Comment on Memory, memory everywhere and not a byte to eat by Matt

Matt — Sat, 22 Mar 2008 02:07:50 +0000

Well, Jeff, you and I have had discussions many times on the pros and cons of Hibernate. What’s funny is that I have never, ever seen the logging from any system pile up so fast that it ate up all the memory, but it could certainly happen, particularly under heavy load.
Two additional things come to mind so you don’t have to completely give up on seeing the SQL all the time:
1) Look at your memory settings on your JVM, particularly -Xmx### setting, and the the too-frequently ignored -XX:MaxPermSize=### setting that controls your PermGen space
2) Rather than completely giving up on seeing the SQL, use different log4j settings in prod than you do in development. You can have “hibernate.show_sql” off and still see the sql if you set the logger for log4j.logger.org.hibernate.SQL=DEBUG.

Comment on Lies or Statistics? by Matt

Matt — Sat, 23 Feb 2008 16:57:26 +0000

It really drives me crazy when I hear people complain about how slow or how fast this language or that language is: the real cost of the vast majority of computing endeavors is not in cpu cycles but in human resource costs. Let’s say for giggles that Perl runs 10% faster than Java. I can almost guarantee you that writing, debugging, and maintaining Perl code is a lot more expensive than doing the same in Java. The labor pool of skilled Java people is also larger than people who are equally good in Lisp.

And if you are in the situation where you are at 99% cpu utilization and those 3 extra cycles are going to make a real difference, you are running your code on the wrong hardware. At that point you need to distribute your work across better servers. It is a simple fact that adding hardware to improve performance is cheaper than rewriting it in another language because Ada or Ruby or Pascal or whatever is too slow. (And yes, I acknowledge that crappy code will run slow no matter what kind of Cray supercomputer you run it on.)

It’s really quite simple: Language choice should be viewed as an economic decision, not a technical one. When a technical strength or weakness of a language is brought up, the question should be “so what?” — which is inherently an economic assessment. Does 5% faster execution translate into noticeably better user satisfaction and retention, or lower costs, or increased sales, or anything else like that? And does it do so more cost-effectively than the alternatives, when everything else is taken into consideration?