stack smashing Was: Re: Scanning Formats (TIFF vs. JPEG)

Well, I seem to have struck a nerve here, now haven't I? I was intending my comment to be mostly tongue-in-cheek, but I guess I failed on that count. Next time I'll use more smileys. So your argument seems to be that the experience to know that JDBC and file handles are the exception to the rule is necessary here. No argument there. It's an unfortunate issue with the language (or it may be an unfortunate issue with the way the JDBC libraries are written). The same mistakes can be made in any other language that lacks a GC. How does one write memory allocation code in Java? As far as I know, there's really only one interface to it and it's provided by the runtime. If you're talking about being wasteful with memory, that's one thing... but you can be wasteful with memory in any language with no skill involved. I posit that you can write crappy code in any language and still get away with it. Hell, I'd say it's a lot easier to write crappy code in C. The things I've seen done with pointers... ugh. As for C _enforcing_ writing better code (solely due to lack of a GC?) -- you're kidding right? It enforces _knowledgeable_ programmers to be 100 times more careful (and the key here is _knowledgeable_) , but it won't prevent _anyone_ from shooting themselves in the foot without even knowing it even if they think they are being careful (buffer overruns, invalid pointers, etc). That's why this thead about stack-smashing got started in the first place, eons ago... I don't know about Java specifically, but I know that for C# there are profiling tools to help you nail down memory leaks when they occur. I assume that these also exist for Java. If you're looking for memory leaks solely based on memory footprint of the process, then yes, you're going to have problems. I agree with the sentiment, but I still disagree that "inexperienced programmers" is a shortcoming of the language. I can see every programming language on earth falling into this bucket. I have done no such thing. I merely sought to point out a flaw in a proposition you made -- that it would be better to replace easily maintainable/portable (in the _right hands_) code written in a high-level language, dealing with high-level concepts (database access, multithreading) with hand-built assembly code. And you propose doing this _only_ because it somehow magically causes people to make fewer mistakes with memory allocation. I don't think this is a reasonable argument. There is a place for assembly code, but I don't believe this particular case is one of them. I'd also argue that one can make many more mistakes much more easily in assembly, even if one manages to allocate memory correctly. I think the argument you're really making here is that _experienced_ programmers (ones who have dealt with low-level languages like assembly and C) know the pitfalls of memory allocation, file handles, performance issues, etc... and as such could make much better use of Java. What you're really saying is that you need to hire better programmers, and that some programmers need to be better educated in computer architecture. I don't necessarily disagree. All languages have issues. What I disagree with is your earlier claim that rewriting code better suited for high-level languages in assembly is some sort of magic bullet that would somehow reduce programmer error. If you gave the same Java coder who's borking up the JDBC connections the task to rewrite it in assembly I doubt very much that person would come up with an error-free implementation in a reasonable timeframe. I think it would be far more productive to sit down with the coder, beat him with a LART and explain that JDBC and File handles need to be closed (and why!). Josh