Sockets, writing data and shutdownOutput

[Thomas Hawtin]

Many people are very dissatisfied with the handling of bug reports via
the bug parade, as it has been discussed here in the past. Many have
therefore given up on reporting bugs. Negative experiences include e.g.
that reports were rejected for no apparent reason, that bugs were marked
as duplicate, which weren't duplicates. That bugs were closed as "not a
bug" which were clearly bugs. That when bugs were marked as duplicates
the corresponding votes were not transfered. The habit of marking the
older of two bugs (the one with more votes) as duplicate. A lack of
action on trivial bugs for years.

You can't judge it in isolation. Compared to anything else it's great.

I am aware of the limitations. I had a bug in the Incident Review state
for around two years before a submitted a patch for it. There can't be
many bug reporting systems where the users aren't pissed off with it.
Incidentally you do get a fast, personal service if you report a
security bug.

The worst is maybe Sun's priorities. Instead of fixing what is broken -
often for years - they use their developers to add questionable new
features. I would for example happily live without the new 1.5 for-loop
if a bunch of old GUI bugs would have been fixed.

I believe the compiler implementation team was known as Neal. He fixed
all the open 1.4 compiler bugs. The majority of professional Java
programmers don't care about the few GUI bugs that Neal could have fixed
if he divided his time.

And when I see that of course they will once again change the class file
format for 1.6, that they add a smart-card API (how many applications
need that?), that they embed the Rhino JavaScript engine, that there are
discussions about adding XML support to the language in 1.7, etc., then
I think Sun has a serious case of featureritis.

You don't want the extra performance and consistency of the new class
file format? Nor the more secure security when it becomes compulsory
(optional now with a switch). Rhino has been around for ages. I don't
think there's any particularly good reasons for leaving it out. It's an
integration effort, and one the users of Rhino should be more
comfortable with. I don't know how serious the 1.7 XML support is. It
has been talked about by non-Sun people. Gotta keep up with the Gates'.

Tom Hawtin

 

[jan V]

I think Sun has a serious case of featureritis.

Totally agree.

 

[HK]

It is not an over-interpretation. From the API documentation;

... data will be sent followed by TCP's normal connection termination
sequence.

I read that as that a FIN is sent,

Yes, that's what I learned now the hard way.

triggering of course the close of the
connection on both ends.

This is not true for general TCP/IP.
When I do have control over client
and server, I regularly close the upstream end
on the client side when done but but keep sending response
data back just fine. Closing the socket as a whole when one end
is shutdown does not seem inevitable.
Rather it is an interpretation of the server, and
for HTTP servers it probably makes good sense.

Thanks anyway,
Harald.