It really depends completely on what the developer is writing. For instance, if your program's only interaction with network servers is talking to a SQL database, then you'd have to be crazy to use low-level socket code instead of JDBC or something even higher level like Hibernate. If the high-level frameworks do what you need, great! By all means use them.
However, frameworks are never going to do everything. There will always be new protocols and network services that have to be implemented with low-level socket code before a framework can be layered on top of them. Someone has to write the frameworks, after all. But more importantly, the frameworks tend to be quite focused on the server side. People writing clients have much less sophisticated libraries to help them; and they do often need to use sockets or the URL/URLConnection/protocol handler framework built into Java.
Elliotte Rusty Harold<br />Author of <a href="http://cafe.elharo.com/web/refactoring-html/" target="_blank" rel="nofollow">Refactoring HTML</a>
posted 14 years ago
Coming to urlconnection approach, do you have any suggestion for a reliable timeout supported HttpUrlConnection kind of package.
I'm pretty sure there is still no way to do a timeout on URLConnection.
In Java 1.5, you can set a System property (which specifies a system wide timeout for the entire JVM -- not a good idea from inside an application server and may not even be allowed by the Security Manager).
The best solution that I have found is to use HttpClient from Jakarta
The Apache HTTP Client package has an HttpUrlConnection equivalent with timeout. I really need to read it and see how they did it one day.
A neat approach is to open the connection then pass it to another thread that waits a while and closes it. That causes the first thread to throw an exception. I needed something like this, but I'm running inside EJB and can't manage my own threads. Rats.
I spent a day playing with writing my own HttpUrlConnection-like class that had a raw socket with socket timeout. I only needed a small subset of the methods, but implementing HTTP is a non-trivial task.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi