A very interesting talk by Bruce Eckel (author of “Thinking in C++” and “Thinking in Java”) on Java issues and directions, at UC Berkeley, Haas School of Business on 25-Jun-2004. Link for Real streaming video here.
A Talk by Bruce Eckel: Java Issues & Directions
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Does he mean Avalon?
I tried grabbing the rm file (though, not knowing if it would work here on OS X) but no joy. Anyone have a text transcription? Eckel’s page on it: http://www.mindview.net/WebLog/log-0055
I don’t want to install the RealAdware player if I can help it.
More news of the Java camp at http://www.theserverside.com
Unfortunately it is a streaming source, not a downloadable file. I’m using Real Player 10; they seemed to have cleaned up their act a bit lately, but I guess it is still hard to trust them.
I’ve watched most of it…I got the link from http://www.serverside.com. He pulls no punches giving it to Sun regarding their stewardship of Java. He’s a big Python fan and gives some Java 1.5 examples…talks about stuff like how java’s threading model has always been broken until 1.5, how Sun was telling the community that they didn’t need foreach, enums, generics, etc..(until c# came along). There’s a good section on why Java generics is broken because of Type erasure. He gives Java enums some high praise.
…I’m getting to the audience questions part now, and the second question is already complaining about Eckel being negative about java. He blames part of Java’s problem on Sun’s marketing department controlling it, and how the Python and C++ community are much more open. It’s clear that he’s not a big fan of the JCP, which he rightfully notes that at the end of the day its still Sun that controls everything. The third question is from a guy that works at lawrence-berkley labs and how he hates java generics type erasure because of performance problems for scientific work.
streaming video (2 hrs 16 mins)
on first 50 mins, he covers
* garbage collection is the way for new languages to go — program managability
* problems with Java’s checked exception
* Java just has too many ‘words’ (too long code) — maintainability
* classpath nightmare — At the very least we need a equivalent of “which” (in Unix)
* Applets have failed
* Truly “Write Once, Run Anywhere” from other camps — Microsoft XAML + Aurora vs Macromedia Flash + MXML + Flex
* Java on Desktop
* Eclipse 3.0 as a rich client platform
* Java is good on server
* developers: write once learning curve (Java is bad. too complex)
* users: seamlessly run anywhere (Java is bad, too complex)
* …
with a lot mentionings to Python
start talking about JDK 1.5 (now JDK 5.0) features
generics, autoboxing, enumerations, attributes/metadata, new concurrency, syntax improvements (e.g. for-each), …
it should be at 42 min
Should be really awesome if someone with a kind of speech recognition app would try to transcript it to the mass ( at home I still use a phone modem 🙁 ).
Really,
How does Eckel deal with else clauses?
Pass back a return code, and/or an error string?
In java you write an exception, and throw it.
A checked exception allows you to write RESILIENT code.
If I need to find a record in a set of 100 backup files,
I want to have coded a checked exception for an IOError for example.
A FileManager class steps thru 100 files.
A FileSearcher class examines each file.
With a checked exception for an IOException, FileSearcher will throw the IOException. FileManager will log the error and continue with the next file.
With runtime errors most programmers won’t know ahead of time what the runtime error is for an IOException, so they won’t code for it.
So, when that first IOException occurs at 3am, with no one around, the program will crash and the job will stop.
Java author’s were enterprise programmers, so Java delivers an enterprise solution.
I don’t think he’s arguing against exceptions, but rather, against Java’s implementation of checked exceptions:
http://www.artima.com/intv/handcuffs.html
IMHO, what Java really needs is restartable exceptions. Applications throwing uncaught exceptions becomes much less of a problem if a human operator can go in and restart from where the exception was thrown. Given a restartable exception mechanism, even if the programmer had not handled the exception properly, you could still come in the next morning and restart the procedure from where you left off.
Eckel is right on the ball. Checked exceptions don’t make a great deal of sense within the exception model itself. The whole point of exceptions is that it allows you to localize error handling in two places: the place that generates the error, and the place that responds to the error. Checked exceptions break this model by requiring all intervening code to be aware of error handling that they take no part in.
Raynier Hashem wrote:
IMHO, what Java really needs is restartable exceptions. Applications throwing uncaught exceptions becomes much less of a problem if a human operator can go in and restart from where the exception was thrown. Given a restartable exception mechanism, even if the programmer had not handled the exception properly, you could still come in the next morning and restart the procedure from where you left off.
I wonder whether you have ever written a program that could not afford user interaction. I have written such a program, designed to analyse 5 GB of astronomical data (several hundred megapix images) which is produced each and every clear night. Then stuff this in a database and search for signatures. This pales in comparison to what the particle physicists have to deal with. In both cases, there is no time for humans to interact with the system. If the data pipeline breaks then catching up starts to get hard. The only way you can tell what operations fail is by putting the exception in the signature. Granted, I always do it, and you probably do too, but unless it is enforced then plenty of programmers would avoid it.
If you don’t like letting your users know what operations can fail then just catch the exception and re-throw as a RuntimeException. This is acceptible if you are writing stuff where you don’t care whether it fails (eg. all the applets that used to crash on the GNOME desktop), but is unacceptible as a software engineer. Perhaps you should use C# instead (or perhaps something nice and lax like PERL). There is no doubt that thinking hard about exceptions and documenting them is a pain in the jaxx, but some applications require it and Java helps those people out.
> Checked exceptions break this model by requiring all intervening code to be aware of error handling that they take no part in.
No, this is incorrect, checked exceptions require code to propagate the reasons it may fail to clients. It says nothing about how errors will be handled. You can, and should, wrap and re-throw the exceptions into an exception type appropriate for your interface (covered in Joshua Bloch’s “Effective Java “IIRC). Your clients should be told what operations can fail (eg. open a file which may not exist), and what can’t (check whether a file exists).
I wonder whether you have ever written a program that could not afford user interaction.
I’m working on such a program right now. Nobody likes coming into work in the morning and finding out that a multi-hour simulation run has died overnight! However, when something does go wrong (and something always goes wrong — the harddrive could die on you, for example), restartable exceptions provide a way to at least salvage something.
The only way you can tell what operations fail is by putting the exception in the signature. Granted, I always do it, and you probably do too, but unless it is enforced then plenty of programmers would avoid it.
Good idea in theory, but checked exceptions don’t do that. Programmers can easily get around them, and in my experience, programmers *do* get around them, simply because they are lazy. This problem is real enough that mandatory exception specifications were actually taken out of the CORBA C++ binding, because they proved to be utterly useless. Now if exception specifications did no harm, then there wouldn’t be much of a problem keeping them, as useless as they may be. However, they get in the way of incremental development methods (see the article I referred to earlier), and as such are an overall loss rather than a gain.
If you don’t like letting your users know what operations can fail then just catch the exception and re-throw as a RuntimeException. This is acceptible if you are writing stuff where you don’t care whether it fails
This is precisely what people end up doing, and exception specifications do *nothing* to prevent that. I’m not opposed to solving the problem at hand, I’m just saying that checked exceptions are too much of a half-assed solution to the problem. And a half-assed solution is worse than no-solution at all.
There is no doubt that thinking hard about exceptions and documenting them is a pain in the jaxx, but some applications require it and Java helps those people out.
Java documents my exceptions for me? No, of course it doesn’t. I’m a firm believer in fully documenting all data flow and control flow in and out of a piece of code (or better yet, eliminating all such flow that is not absolutely necessary). However, exception specifications cannot guarantee that such documentation happens.
No, this is incorrect, checked exceptions require code to propagate the reasons it may fail to clients.
The thing is, that a given piece of code shouldn’t have to do such propogation. Unless you throw an exception, or you catch an exception, you shouldn’t need to deal with exceptions. Once you start requiring code to explicitly specify the flow of exceptions, you’re back to the C method of propogating error codes up the call stack. Let me give you a concrete example:
Consider something like a transparent middleman. Say, a plug-in manager. It should not know about any error-handling (that includes exception types) outside it’s domain (which is plugin-loading). If a plug-in throws a plug-in specific exception, the client should be allowed to handle it, without requiring the plug-in manager to know anything about it. The checked-exception model makes this impossible, which means that the plug-in manager must now either anticipate all possible plug-in errors, or it must (as happens in practice), convert all plug-in errors to a generic (and thus fairly useless) exception.
CORBA code, which until recently mandated exception specifications in the C++ mapping, illustrates the basic problem with exception specifications quite nicely. The ORB will throw an exception, and somebody will catch it, and convert it to some generic error. By the time the client code get’s the exception, it has absolutely no idea what has happened, because some dimwit somewhere in the line has converted the exception to “CORBA: Unknown exception”.
Hi Rayiner
> convert all plug-in errors to a generic (and thus fairly useless) exception.
What if the exceptions are converted to the interface type of your hierarchy (eg. PluginException) so that clients would expect an object of this type but specific instances derived from this interface provide specific exception types. By the way, I don’t believe in having an exception class for each type of exception, but in having exceptions which match more broad classes/categories of exceptions (otherwise you get a meaningless explosion of exception classes).
> because some dimwit somewhere in the line has converted the exception to “CORBA: Unknown exception”.
Well, how do you stop bad programmers? That is the million dollar question we are all seeking. Getting rid of exceptions specifications in signatures won’t stop such horrendous coding. Besides, even if an exception is transmuted into a generic type you can still see the cause of the exception (using the Throwable(cause) type constructor for the new exception).
> Once you start requiring code to explicitly specify the flow of exceptions, you’re back to the C method of propogating error codes up the call stack. Let me give you a concrete example:
Not quite. In C it was easy for a function to supress the error code so that it didn’t propagate up (which was the real sin), or for a caller to forget to check for an error code (just as heinous, as it is potentially fatal to a program when the caller forgets an error may have occurred).
Checked exceptions are a pain, but they *force* you to think about exceptions, just as a strong type system *forces* you to think about what objects you are passing around. Yes there is a certain intellectual overhead to this, it is unavoidable if you want to make robust complicated systems. If you have idiot programmers that supress exception information (converting it to a generic type, rather than a type appropriate for a method’s interface level) then they are probably the type that would do dodgy type casts too.
You could say in C++ having ‘const’ forces unncessary overhead on the programmer, but it turns out that the effort of writing ‘const-correct’ programs helps a client of a class work out what is safe and what isn’t. Is it a good things that C++ doesn’t force users to write const-correct code? Possibly, but it makes it harder for clients.
Python gives you all the info you need to fix the problem, which is why exceptions are built into code in the first place.
there is noe thing interesting that you missed to report:
”
matz, ruby creator, has been able to held a talk named ‘how ruby sucks’. If gosling did this in the early days of java probably now we would be living in a better world. But the sun marketing machine just keep on with the ‘we are already perfect’ c*ap. That is why other languages do evolve better than Java.
“
Good idea in theory, but checked exceptions don’t do that. Programmers can easily get around them, and in my experience, programmers *do* get around them, simply because they are lazy.
That is exactly why you would need checked exceptions becuase programmers are lazy and will ignore an excpetion if they can. Having an empty catch block atleast tells the next poor slob who looks at the code that some exception needs to be handled.
The ORB will throw an exception, and somebody will catch it, and convert it to some generic error. By the time the client code get’s the exception, it has absolutely no idea what has happened, because some dimwit somewhere in the line has converted the exception to “CORBA: Unknown exception”.
And this is better than some dim wit didn’t bother to catch an exception becuase he didn’t want to and now nobody knows why something failed.
You must read this after your read your link.
http://www.artima.com/intv/solid.html
Which language is more successful? C and C++. Period. You should force bad programmers, but good programmers don’t like to be forced. If i can write a perfectly good program which never crash without writing a stupid exception handler, i would like to have flexibility to write one.
Java tried too hard to force programmers into its way of thinking and hence many people like me hate it..
strange, after reading the posts reminded how online banking transactions were written in languages that doesn’t provide–guess what–exception handling.
http://www.mindview.net/Etc/Discussions/CheckedExceptions
If i can write a perfectly good program which never crash without writing a stupid exception handler
Wow, if you can write programs that never crash you might be millionaire by now, you’re the first guy in the world to achieve that
@Pipo wrote:
strange, after reading the posts reminded how online banking transactions were written in languages that doesn’t provide–guess what–exception handling.
Well, perhaps you should take Raptor’s advice and read page 4 of that article
http://www.artima.com/intv/solid4.html
it mentions 13 billion dollars going missing due to a bug. In general, banks don’t mention when they screw up (or their security is cracked) because it is bad for business – doesn’t mean it doesn’t happen though.
It is possible to write reliable software without thinking hard about exceptions (ie. being forced to deal with checked exceptions). I’ve maintained a real-time pre-exception C++ control program in DOS, but the time and effort to do so is much larger than in a language that can use exceptions – epecially if it method signature alerts different parts of the system what can go wrong.
IMHO, the big advantage of checked exceptions is that they make an API self-documenting. Checked exceptions simply remind you of the many ways that a program might fail in the real world. (network or IO error, invalid user input, invalid XML, etc.) That said, a badly designed API will force too many checked exceptions on the programmer, but that is a problem with the API, not with the principle of checked exceptions itself.
Another perspective is that the more checked exceptions an API declares, the less it becomes suitable for direct use by the programmer and the more desirable it becomes to wrap the API in a framework. JDBC is a prime example of an API that needs to be wrapped in a framework. In fact, I believe most serious JDBC work is handed over to frameworks. (I.e. JSP tag libraries or frameworks like Spring.)
I used to work on such a system (discount brokerage for a major CDN bank)…. a real b*tch if/when things fail. Spent 3 days (xmas eve and the weekend that followed) to rescue $$$millions… I forget how much… when a cash transfer job failed. Luckily for the 1000s of accounts, everything balanced out in the end (not one cent unaccounted for). Very stressful. I can only imagine how much worse it gets for developers of medical systems…. where people actually die.
🙂
ps: this was largely a poorly designed cash xfer system that made recovering from a failure difficult/impossible to recover from (I showed the team it wasn’t impossible 😉 The concept of a “recoverable” exception would have been gold if it existed.
Funny, have worked on Online Banking Software written in Java. And we used EJBs too.
Can you see that you are outnumbered by other Java supporters that care “more or less” about checked exceptions. The reason is that not everyone is in the business of writting libraries that are going to be used by other peoples’ clients.
Let me quote Raptor:
“That is exactly why you would need checked exceptions becuase programmers are lazy and will ignore an excpetion if they can. Having an empty catch block atleast tells the next poor slob who looks at the code that some exception needs to be handled. ”
LOL.
The reason is that not everyone is in the business of writting libraries that are going to be used by other peoples’ clients.
Let me guess you are still in high school or college. Only a person with no realworld experience would say anything remotely resembling what you said.
“Having an empty catch block atleast tells the next poor slob who looks at the code that some exception needs to be handled.”
Is it good exception handling to do just that? Is it something to be proud of and brag about? Is it a good defense for checked exceptions? After all, you could be more pragmatic than just that.
checked exceptions is a big discusion, with no prefect solution. instead of discussing the necessity of forced cheked exceptions, one should “learn” how to use exceptions.. check down links for example
http://www.manageability.org/blog/stuff/exceptional-exception-handl…
http://today.java.net/pub/a/today/2003/12/04/exceptions.html
and if matter is that adding exception handling to the code in the java is difficult, advanced editors are making it a “no-problem”. it takes two clicks for me to add an exception to a method signature, or wrap a line exception handling, and it hadles all kind of syntax errors, interitance issues automatically. Therefore, in that aspect exceptions is not a big issue. IDEA is great on this, Eclipse does a good job too.
No Dewd,
A lazy programmer on the team is a pain in the butt.
That’s why teams need code review, or extreme programming.
Or, we should ask Sun to automatically add a Runtime exception in the JVM to empty catch clauses.
When I code, I thank the Gods when I see checked exceptions on method calls. It’s a clear indication that a professional coded the API and in partnership with me to write high quality software. After all that’s what we get paid for. No user expects half a**ed software.
Secondly, I don’t often see checked exceptions rising up 4 levels in the code. I usually see, at least 90% of the time, a checked exception handled just 1 level up.
Having one big catch clause on the outside really only works if your exception handling philosophy is simply to die. — Gosling
And isn’t that Microsoft’s philosophy?
Is there a mirror for the video?
Checked exceptions is indicative of Sun’s general philosophy regarding Java. And that philosophy is “We know what’s best, you don’t need this, you don’t want this, don’t ask questions”. Generics, enums, foreach, metadata…were things that we were told that we didn’t need. And then all of a sudden c# comes along and magically these things start to appear. I was watching the video and during the discussion of Enums, Eckel noted that Sun had recently mandated that enum members be capitalized(I’m pretty sure that’s what he said). Well, what’s up with that? Why the hell is sun trying to enforce that. Let programmers come up with their own conventions. Java’s biggest problem is Sun itself.
wow, my comment seem to have made some impact. anyway, not that i’m knocking java or exceptions off, but most critical applications written–for example–online banking already have facilities necessary to produce solid and reliable procedures, with the help of tools like transaction servers whose job is to make sure all transactions get completed or everything gets rolled back. Now, the question of having exceptions get thrown-in the equation doesn’t make sense anymore. ask any programmer who has written online banking apps about exceptions and you’ll probably get a blank stare right away.
Is it good exception handling to do just that? Is it something to be proud of and brag about? Is it a good defense for checked exceptions? After all, you could be more pragmatic than just that.
No. No. Yes.
The “atleast” in my statement means something, correct? It means at the very least it allows someone else to know that there is something that can be improved. With un-checked exceptions a user can choose to completely ignore an or all exceptions and there is nothing to tell someone else looking at the code that a particular routine would have thrown a exception. Paricularly in large projects with a large number of objects and files.
Ecspecially now with OSS, someone will always look at a piece of code and want to do something with it, at the very least fix some bug. Imagine the debugging hell one would have to go through if the original author conviniently forgot/ was lazy to catch and exception.
The more I hear what Eckel has to say, the more curious I get to really give Python a try.