StreamCorruptedException-s -- what to do?
Miss Elaine Eos
I'm getting StreamCorruptedException-s. What do I do about it? I mean,
is there any way to say "ok, great -- reset the stream and try again"?
It seems that, once you get one StreamCorruptedException, you just keep
getting them for the rest of eternity. Is there some way to "uncorrupt"
a stream?
For that matter -- how did it get corrupt in the first place? Is that a
fault in my program? Or just bad internet packets? I seem to be
getting a lot of them.
Thanks!
--
You have to remove stuff from my e-mail to reply, it's not difficult.
I will not, no matter how "good" the deal, ever purchase any product from
any company which gathers addresses from the usenet; period.
Kenny MacLeod
I get them occasionally between the two tiers on my current application.
I've never managed to satisfactorily explain them, and every time I try and
hunt them down, they vanish, the crafty little buggers.
The application in question serialises objects across a socket connection
between the two tiers.
"Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
news:Misc-25A6CD.0...@ca.news.verio.net...
Miss Elaine Eos
<Kenny_...@S.P.A.M.yahoo.com> wrote:
> Some context would be nice - where do you get these exceptions?
Sorry, from an input/output stream between a client and server (both my
apps), using a Socket object (TCP/IP), and it's related input/output
stream.
> I get them occasionally between the two tiers on my current application.
> I've never managed to satisfactorily explain them, and every time I try
> and
> hunt them down, they vanish, the crafty little buggers.
>
> The application in question serialises objects across a socket connection
> between the two tiers.
Yeah, they seem random -- but, once I get one, that's all I ever get for
the next 100 attempts to send/recieve data. (My program bails after 100
failures in a row.)
Thing is, they're random, but common, when they happen.
Uh... I'm not sure how much more context you want. Sorry, I'm new to
this Java stuff :)
Miss Elaine Eos
<tg...@spamcop.net> wrote:
> =< Quoted Text Info >=
> |- from: Miss Elaine Eos <Misc@*NO-SPAM*PlayNaked.com>
> |- to: comp.lang.java.help
> |- on: Tue, 20 Nov 2001 18:25:11 GMT
>
> > Uh... I'm not sure how much more context you want. Sorry, I'm new to
> > this Java stuff :)
>
> He speaks of source code.
>
> A simply program that shows what is happening while your error takes
> place. You can remove all not relevant parts, just the parts that are in
> action when the exception is thrown.
Ah, sure. Here's the relevant routine. I have a valid (well, it WAS
valid, to start with) Socket with which I've been communicating.
This seems to happen more frequently at client-launch -- but that might
be coincidence or sloppy data-gathering on my part.
---
private void ReadNextObject ()
{
ObjectInputStream objIn = null;
try
{
objIn = new ObjectInputStream (socket.getInputStream());
Object thisObject = objIn.readObject();
AddObjectToQueue (thisObject);
if (failureCount > 0)
failureCount--;
}
catch (StreamCorruptedException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext
StreamCorruptedException (ReadNextObject): ", e);
}
}
catch (IOException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext IOError
(ReadNextObject): ", e);
}
}
catch (ClassNotFoundException e)
{
failureCount++;
yield();
Utils.LogError ("BaseObjectIOThreadReadNext
ClassNotFoundException", e);
}
if (failureCount > kMaxIOFailures)
{
if (notifyThread == null) Utils.LogSystemMsg
("BaseObjectIOThreadReadNext lost connection. failureCount: " +
failureCount);
else notifyThread.LostConnection (this);
ShutDown();
}
}
---
What I'm getting are StreamCorruptedException-s Thing is, this is a
loop in a thread, and it typically works several times before failing.
It also seems that, once you get a corrupt-stream, you keep getting them
forever.
What I want to know is: how do you un-corrupt a stream? Is there a
reset() or flus() type method?
Kenny MacLeod
news:77rlvt4cp2hi97viv...@4ax.com...
>
> > Uh... I'm not sure how much more context you want. Sorry, I'm new to
> > this Java stuff :)
>
Well, not really. Just a description of the problem's context.
> A simply program that shows what is happening while your error takes
> place. You can remove all not relevant parts, just the parts that are in
> action when the exception is thrown.
The problem with client-server errors is they can be very hard to reproduce.
This bug is a good example.
kenny
Jim Sculley
> I'm getting StreamCorruptedException-s. What do I do about it? I mean,
> is there any way to say "ok, great -- reset the stream and try again"?
> It seems that, once you get one StreamCorruptedException, you just keep
> getting them for the rest of eternity. Is there some way to "uncorrupt"
> a stream?
>
> For that matter -- how did it get corrupt in the first place? Is that a
> fault in my program?
Probably.
> Or just bad internet packets?
Not likely. TCP/IP will request that bad packets be resent, which all
happens before your code even knows a packet has arrived.
> I seem to be getting a lot of them.
There are several scenarios which result in a StreamCorruptedException.
Can you post the full stack trace so that the source can be narrowed down?
Jim S.
Helpful GM
<nic...@abraxis.com> wrote:
> Miss Elaine Eos wrote:
>
> > I'm getting StreamCorruptedException-s. What do I do about it? I
> > mean,
> > is there any way to say "ok, great -- reset the stream and try again"?
> > It seems that, once you get one StreamCorruptedException, you just keep
> > getting them for the rest of eternity. Is there some way to
> > "uncorrupt"
> > a stream?
> >
> > For that matter -- how did it get corrupt in the first place? Is that
> > a fault in my program?
> Probably.
While I'm willing to believe this, I just don't get how it works
sometimes and not other times. Same code, same scenario. It seems
timing related, and that's weird...
> > Or just bad internet packets?
> Not likely. TCP/IP will request that bad packets be resent, which all
> happens before your code even knows a packet has arrived.
Yeah, that's what I thought.
> > I seem to be getting a lot of them.
> There are several scenarios which result in a StreamCorruptedException.
> Can you post the full stack trace so that the source can be narrowed
> down?
> Jim S.
Sure. If you prefer to help with this off-list until we have the
answer, I'll post our findings when we're done. Feel free to contact me
via e-mail.
Here you go, along with the relevant code, from another post:
2001/11/21 07:59:31 ??? ERROR: BaseObjectIOThreadReadNext
StreamCorruptedException (ReadNextObject):
2001/11/21 07:59:31 ??? ERROR: java.io.StreamCorruptedException:
InputStream does not contain a serialized object
java.io.StreamCorruptedException: InputStream does not contain a
serialized object
at java.lang.Throwable.<init>(Compiled Code)
at java.lang.Exception.<init>(Compiled Code)
at java.io.IOException.<init>(Compiled Code)
at java.io.ObjectStreamException.<init>(Compiled Code)
at java.io.StreamCorruptedException.<init>(Compiled Code)
at java.io.ObjectInputStream.readStreamHeader(Compiled Code)
at java.io.ObjectInputStream.<init>(Compiled Code)
at BaseObjectIO.BaseObjectIOThread.ReadNextObject(Compiled Code)
at BaseObjectIO.BaseObjectIOThread.run(Compiled Code)
2001/11/21 07:59:31 Dropped connection: PlayNaked.com/130.94.187.160
ShutDown();
}
}
---
(i.e., it successfully gets the first 9 packets, then gets corruptstream
on the 10th. The packets are all of the same format. On the next try,
it might get 12, then fail on the 13th, then get 6 and fail on the 7th.
The server sends the same initial-packets (login stuff), in the same
order, every login -- that's the very weird part.)
It also seems that, once you get a corrupt-stream, you keep getting them
forever.
What I want to know is: how do you un-corrupt a stream? Is there a
reset() or flush() type method?
Kenny MacLeod
"Helpful GM" <HelpfulGM@*NO-SPAM*PlayNaked.com> wrote in message
news:HelpfulGM-A70C5...@ca.news.verio.net...
Miss Elaine Eos
<Kenny_...@S.P.A.M.yahoo.com> wrote:
> Are there any errors on the server side?
Yes. Corrupt-stream errors on the write (server) side, similar to the
ones on the read (client) side, at the same time.
I guess I don't quite follow what all corrupts a stream. After I write
an object, do I need to fush()? That doesn't sound right. Are there
other considerations?
My initial login dance goes like this:
server: start a socket-listener-thread to grab new logins
client: open a socket
server: note new login, start a dataIO thread (to read
& write objects, cache objects read in a synchronized
array, offer-up read-objects when asked, etc.)
server: Send welcome! object.
client: display welcome! message
server: send about 20 "initial data" packets
client: update local array with initial-data
server: send "that's it for init-stuff"
client: note "Connected" state, begin regular work
after this, the client sends requests to the server, the server sends
answers back, etc. Once I get to "connected", I rarely lose connection.
The problem always comes (and it comes > 80% of the time!) in the
server: send about 20 "initial data" packets
part of the login-dance. Basically, my client gets anywhere from 6 to
15 of the packets, then both sides report stream-corrupt.
Again, if someone knows how to debug this stuff, I can send them a URL
privately. The project isn't far enough along to announce it in the
newsgroup, though.
For completeness, here is the error from the server side:
2001/11/21 16:00:13 ??? ERROR: BaseObjectIOThreadReadNext
StreamCorruptedException (ReadNextObject):
2001/11/21 16:00:13 ??? ERROR: java.io.StreamCorruptedException: Caught
EOFException while reading the stream header
java.io.StreamCorruptedException: Caught EOFException while reading the
stream header
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:727)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:165)
at
BaseObjectIO.BaseObjectIOThread.ReadNextObject(BaseObjectIOThread.java:80
)
at
BaseObjectIO.BaseObjectIOThread.run(BaseObjectIOThread.java:50)
...and the associated code:
---
public void SendObject (Object theObject)
{
try
{
ObjectOutputStream objOut = null;
if (socket == null)
{
objOut = null;
Utils.LogWarning ("null socket in
BaseObjectIOThread.SendObject()");
}
else
{
objOut = new ObjectOutputStream (socket.getOutputStream());
}
if (objOut == null)
{
//€ failureCount++;
}
else
{
objOut.writeObject (theObject);
objOut.flush();
if (failureCount > 0)
failureCount--;
}
// Utils.LogDebugging ("BaseObjectIOThread object sent: " +
((MS_S2SPacket) theObject).command);
}
catch (StreamCorruptedException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext
StreamCorruptedException (SendObject): ", e);
}
}
catch (IOException e)
{
failureCount++;
// Utils.LogError ("BaseObjectIOThread IOError (SendObject): ", e);
}
}
---
I just noticed, though, that the error comes AFTER the server believes
that it's sent all the data. That is, the server logs
server: Sending initial login packets
server: initial login packets sent
Server: [Error message, corrupt stream, as above.]
so the stream is becoming corrupt AFTER I've sent all the initial
packets. Does that indicate that the corruption is happening on the
reading (client) end?
---
Miss Elaine Eos
<Kenny_...@S.P.A.M.yahoo.com> wrote:
> Are there any errors on the server side?
Yes. Corrupt-stream errors on the write (server) side, similar to the
ones on the read (client) side, at the same time.
I guess I don't quite follow what all corrupts a stream. After I write
an object, do I need to fush()? That doesn't sound right. Are there
other considerations?
My initial login dance goes like this:
server: start a socket-listener-thread to grab new logins
client: open a socket
server: note new login, start a dataIO thread (to read
& write objects, cache objects read in a synchronized
array, offer-up read-objects when asked, etc.)
server: Send welcome! object.
client: display welcome! message. Send "InitMe" packet.
server: send about 20 "initial data" packets
client: update local array with initial-data
server: send "that's it for init-stuff"
client: note "Connected" state, begin regular work
after this, the client sends requests to the server, the server sends
answers back, etc. Once I get to "connected", I rarely lose connection.
The problem always comes (and it comes > 80% of the time!) in the
server: send about 20 "initial data" packets
part of the login-dance. Basically, my client gets anywhere from 6 to
15 of the packets, then both sides report stream-corrupt.
Again, if someone knows how to debug this stuff, I can send them a URL
privately. The project isn't far enough along to announce it in the
newsgroup, though.
For completeness, here is the error from the server side:
2001/11/21 16:00:13 ??? ERROR: BaseObjectIOThreadReadNext
StreamCorruptedException (ReadNextObject):
...and the associated code:
---
if (failureCount > 0)
failureCount--;
}
catch (StreamCorruptedException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext
StreamCorruptedException (SendObject): ", e);
}
}
catch (IOException e)
{
failureCount++;
// Utils.LogError ("BaseObjectIOThread IOError (SendObject): ", e);
}
}
---
I just noticed, though, that the error comes AFTER the server believes
that it's sent all the data. That is, the server logs
server: Sending initial login packets
server: initial login packets sent
Server: [Error message, corrupt stream, as above.]
so the stream is becoming corrupt AFTER I've sent all the initial
packets. Does that indicate that the corruption is happening on the
reading (client) end?
---
> > In article <3BFBA4EE...@abraxis.com>, Jim Sculley
Kenny MacLeod
write it into a ByteArrayOutputStream first, just to make sure it's
serializing properly, then throw away the byte array, then write it again to
the socket.
This way, you can seperate the serialisation errors from the networking
errors.
"Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
news:Misc-F433BF.0...@ca.news.verio.net...
> //? failureCount++;
Jim Sculley
OK. As you can see, the Exception is being thrown from inside the
readStreamHeader() method of ObjectInputStream. If you look at the
source for that method, you will see that the only circumstance in which
the exception is thrown with the specific message 'InputStream does not
contain a serialized object' is when the first short read from the
stream does not match the STREAM_MAGIC value of the
ObjectStreamConstants class. This should only happen if the object
being sent isn't properly serialized. How is the data being generated
on the server side before being sent to the client?
Jim S.
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
> "Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
> news:Misc-E3778F.1...@ca.news.verio.net...
> > Ummm. Ok. Forgive me for sounding dense, but here's what I've got:
> >
> > ---
> >
> > So, every SendObject() creates a new ObjectOutputStream, writes the
> > serialised object, then flushes the OOS.
> >
> > Every ReadObject() creates a new ObjectInputStream, reads the object,
> > then discards the OIS.
> >
> > Perhaps not the most efficient way of doing things, but I prefer
> > brute-force-and-works to tight-but-buggy-and-hard-to-fix.
>
> Is there any reason not to just create one OIS stream and one OOS
> once at the beginning and use just them until the end of time?
> It certainly seems cleaner to me.
>
> One thing that could cause your problem (in fact, I'd bet this is
> it) is if anything, anywhere, ever, on the server side, writes any
> bytes to your server socket's output stream that get read by
> your ReadNextObject method.
> Marshall
Oddly, reducing the size of the object sent seemed to clear up all my
problems.
Why? I have no idea.
But it might also explain why others had no problem at all, while I kept
getting corrupt streams.
They're DSL, I'm modem? Why would that matter? I thought TCP handled
keeping everything nice & tidy.
Anyway, I'll put more thought into it, tomorrow. Thanks again for your
help.
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
> > Of the 20 packets sent, they are ALL the same kind of object, and they
> > are all [de-]serialized the same way. Here's my packet-objects:
>
> Just a couple of comments on your code:
>
> Is there a reason you're writing your own readObject and writeObject?
> Because you don't have to. If you just say a class "implements
> Serializable"
> then you can use serialization without writing any code. I might suggest
> getting rid of all your custom readObject and writeObject methods unless
> you have a compelling reason to keep them.
>
> (And I'd make all my fields private if I were you.)
Uh... I thought i read in the docs that in order to say "implements
Serializable", I HAD to implement readObject & writeObject -- they're
abstract. What am I missing, here?
If they're private, I have to clutter my packets with accessor routines.
I use these classes as if they were C "struct"s -- for quick fill &
emptying. Calling dozens or hundreds of accessors to fill/drain
variables seems wasteful. What am I missing, here?
Thanks!
Miss Elaine Eos
Konstapel" <m.kon...@twi.tudelft.nl> wrote:
> In combination with other posts in the thread, this made me think of a
> possible problem: are you doing anything (really, *anything*), with the
> socket or socket.getInputStream() before calling this method? It looks
> like
> something is eating some of the Object{I/O]Stream header bytes.
>
> Michiel
Nope. The accessors are there to keep it all ...uh... "clean" (ok, you
can gripe about my code -- but it is easy for ME to follow...)
Marshall Spight
> OK. As you can see, the Exception is being thrown from inside the
> readStreamHeader() method of ObjectInputStream. If you look at the
> source for that method, you will see that the only circumstance in which
> the exception is thrown with the specific message 'InputStream does not
> contain a serialized object' is when the first short read from the
> stream does not match the STREAM_MAGIC value of the
> ObjectStreamConstants class.
I can state with a high degree of confidence that Jim is very, very
hot on the trail here.
I think I might be able to narrow it down some.
The write operations to the ObjectOutputStream need to be *exactly*
mirrored by read operations on the ObjectInputStream. Note that
*creating* the streams is also a write operation.
Since you're getting this exception, it means that you're creating an
ObjectInputStream at a time that doesn't correspond to the creation of the
ObjectOutputStream. Either you're already read some bytes on the
input side before the OIS is created, or you're writing some bytes on
the underlying stream before the OOS is created.
I'm fairly sure this is the only possible circumstance that could generate this.
It sounded like you were saying that this occurs after the stream has been
going for a while. Was that right? If so, apparently you're creating a new
OIS at some point. That won't work, unless it corresponds exactly
to the creation of a new OOS on the other side.
> This should only happen if the object
> being sent isn't properly serialized.
I'd say rather, it comes from misaligned reading and writing.
HTH
Marshall
Miss Elaine Eos
<nic...@abraxis.com> wrote:
> OK. As you can see, the Exception is being thrown from inside the
> readStreamHeader() method of ObjectInputStream. If you look at the
> source for that method, you will see that the only circumstance in which
> the exception is thrown with the specific message 'InputStream does not
> contain a serialized object' is when the first short read from the
> stream does not match the STREAM_MAGIC value of the
> ObjectStreamConstants class. This should only happen if the object
> being sent isn't properly serialized. How is the data being generated
> on the server side before being sent to the client?
Thanks for the lesson in debugging, btw -- this is the hardest part of
learning Java for me (since I'm already a skilled programmer.)
Uh... where would I get the source for the objectInputStream object? Is
that part of my SDK? (Never looked there, before. I guess this is one
of the dangers of self-teaching Java from a book, they don't discuss
this sort of thing ;)
Of the 20 packets sent, they are ALL the same kind of object, and they
are all [de-]serialized the same way. Here's my packet-objects:
---
public class MagnetsWordPacket implements Serializable
{
int wordNum;
String word;
long touched;
int wordID;
int x;
int y;
Color color;
private void writeObject (java.io.ObjectOutputStream out) throws
IOException
{
out.writeInt (wordNum);
out.writeObject (word);
out.writeLong (touched);
out.writeInt (wordID);
out.writeInt (x);
out.writeInt (y);
out.writeObject (color);
}
private void readObject (java.io.ObjectInputStream in) throws
IOException, ClassNotFoundException
{
wordNum = in.readInt ();
word = (String) in.readObject ();
touched = in.readLong ();
wordID = in.readInt ();
x = in.readInt ();
y = in.readInt ();
color = (Color) in.readObject();
}
}
public class MagnetsPacket implements Serializable
{
int command;
int intData;
Object objectData;
public MagnetsPacket (int cmd, Object obj)
{
command = cmd;
objectData = obj;
}
public MagnetsPacket (int cmd, int ii, Object obj)
{
this (cmd, obj);
intData = ii;
}
private void writeObject (java.io.ObjectOutputStream out) throws
IOException
{
out.writeInt (command);
out.writeInt (intData);
out.writeObject (objectData);
}
private void readObject (java.io.ObjectInputStream in) throws
IOException, ClassNotFoundException
{
command = in.readInt ();
intData = in.readInt ();
objectData = in.readObject ();
}
}
---
In this instance, MagnetsPacket.objectData is a Vector with 20
theVector.addElement (MagnetsWordPacket) done to it.
That is, the login sequence is
client: hi (get socket)
server: welcome packet (string msg)
client: send me init data
MagnetsPacket.command = initMe;
MagnetsPacket.intData = 0;
MagnetsPacket.objectData = null;
server: here's some init-data
myVector.addElement (MagnetsWordPacket);
myVector.addElement (MagnetsWordPacket);
myVector.addElement (MagnetsWordPacket);
[etc, 20 times]
MagnetsPacket.command = initData;
MagnetsPacket.intData = 0;
MagnetsPacket.objectData = myVector;
server: here's some more init-data
[etc, 20 times to send 400 words]
---
The part that's really baffling me is that somewhere between 3 and 17 of
these packets send just fine, then it chokes on the last one.
And, actually, the server seems to send them just fine, but the stream
becomes corrupt as the client reads them.
I'm going to try Kenny's idea of packing/unpacking the data through
ByteObjectStreams, first, for debugging, then sending them as I am, now.
Btw, thanks for all your help -- I'm really stumped on this one.
Marshall Spight
> In article <MiZK7.38705$RG1.18...@news1.rdc1.sfba.home.com>,
> "Marshall Spight" <msp...@dnai.com> wrote:
>
> > > Of the 20 packets sent, they are ALL the same kind of object, and they
> > > are all [de-]serialized the same way. Here's my packet-objects:
> >
> > Just a couple of comments on your code:
> >
> > Is there a reason you're writing your own readObject and writeObject?
> > Because you don't have to. If you just say a class "implements
> > Serializable"
> > then you can use serialization without writing any code. I might suggest
> > getting rid of all your custom readObject and writeObject methods unless
> > you have a compelling reason to keep them.
> >
> > (And I'd make all my fields private if I were you.)
>
> Uh... I thought i read in the docs that in order to say "implements
> Serializable", I HAD to implement readObject & writeObject -- they're
> abstract. What am I missing, here?
Serializable is a "marker interface." It has no methods in it that
you have to define. Note from the Javadoc for serializable:
"Classes that require special handling during the serialization
and deserialization process must implement special methods
with these exact signatures: [readObject, writeObject]"
Note "require special handling." Your classes do not require
special handling, so don't make those methods and save yourself
some time, effort, and potential sources of bugs.
And where did you get the idea they were abstract? They certainly
aren't.
> If they're private, I have to clutter my packets with accessor routines.
> I use these classes as if they were C "struct"s -- for quick fill &
> emptying. Calling dozens or hundreds of accessors to fill/drain
> variables seems wasteful. What am I missing, here?
Writing methods that do useful things is never "clutter."
If you are writing things that you think of as structs, you aren't doing
OOP yet. It certainly takes a while to get the hang of it; I'd say it
took me ten years. But it's worth it!
Consider: if you have a "struct" in and of itself, it's useless. It only
becomes useful when it is used in conjunction with code that
uses the struct as input. Those methods are good candidates for
being methods on the struct class. Once you start putting fields
and methods together, you start having real objects, and it's
time for the fields to be private. There are significant disadantages
to non-private fields, and the only advantage is saving typing.
Marshall
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
Ummm. Ok. Forgive me for sounding dense, but here's what I've got:
---
public void SendObject (Object theObject)
{
try
{
ObjectOutputStream objOut = null;
if (socket == null)
{
objOut = null;
Utils.LogWarning ("null socket in
BaseObjectIOThread.SendObject()");
}
else
{
objOut = new ObjectOutputStream (socket.getOutputStream());
}
if (objOut == null)
{
//€ failureCount++;
}
else
{
if (kDebugging)
{
}
objOut.writeObject (theObject);
objOut.flush();
if (failureCount > 0)
failureCount--;
}
// Utils.LogDebugging ("BaseObjectIOThread object sent: " +
((MS_S2SPacket) theObject).command);
}
catch (StreamCorruptedException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext
StreamCorruptedException (SendObject): ", e);
}
}
catch (IOException e)
{
failureCount++;
// Utils.LogError ("BaseObjectIOThread IOError (SendObject): ", e);
}
}
ShutDown();
}
}
---
So, every SendObject() creates a new ObjectOutputStream, writes the
serialised object, then flushes the OOS.
Every ReadObject() creates a new ObjectInputStream, reads the object,
then discards the OIS.
Perhaps not the most efficient way of doing things, but I prefer
brute-force-and-works to tight-but-buggy-and-hard-to-fix.
So, now I've got brute-force-but-buggy ;) Where's my problem?
Btw, both of these routines are inside of my BasicIOThread object -- a
thread that basically just blocks, waiting for IO, then stuffs the
results into a queue (Vector) until someone asks for them. My
"notifyThread" is one of my ThreadWithConnections objects that has
methods like GotNewConnection(), LostConnection() and
NewObjectHasArrived().
Thanks again for all your help. I apologise if I seem extra dense,
today -- this is new territory for me.
Marshall Spight
> Uh... where would I get the source for the objectInputStream object? Is
> that part of my SDK? (Never looked there, before. I guess this is one
> of the dangers of self-teaching Java from a book, they don't discuss
> this sort of thing ;)
When you install the jdk, there's a file, src.jar, that is an archive of
the source to all the java and javax classes. Unjar it and throw away
the jar itself. VERY useful.
> Of the 20 packets sent, they are ALL the same kind of object, and they
> are all [de-]serialized the same way. Here's my packet-objects:
Just a couple of comments on your code:
Is there a reason you're writing your own readObject and writeObject?
Because you don't have to. If you just say a class "implements Serializable"
then you can use serialization without writing any code. I might suggest
getting rid of all your custom readObject and writeObject methods unless
you have a compelling reason to keep them.
(And I'd make all my fields private if I were you.)
Marshall
Marshall Spight
> Ummm. Ok. Forgive me for sounding dense, but here's what I've got:
>
> ---
>
> serialised object, then flushes the OOS.
>
> Every ReadObject() creates a new ObjectInputStream, reads the object,
> then discards the OIS.
>
> Perhaps not the most efficient way of doing things, but I prefer
> brute-force-and-works to tight-but-buggy-and-hard-to-fix.
Is there any reason not to just create one OIS stream and one OOS
Michiel Konstapel
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
I follow what you're saying, I think you're overlooking a couple of
valuable uses of structs.
I want to pass you 20 parameters, all at once. These parameters go
together (sort of like fields in an object ;) and, if you're interested
in one, you're probably interested in all of them.
This is the perfect use for a public-fielded struct.
The reason for data-hiding is when it would be dangerous to the object
to have the fields manipulated externally, without updating some
internal gizmo. Sure, I see that -- but "there are significant
disadvantages to non-private fields" seems a bit hyperbolic, and "[no
advantages]" seems likewise.
What possible disadvantage is there to an object that only consists of
public fields, nothing else?
Here's another use:
Functions/methods where you want to return more than one value.
MyAnswerObject() [/struct] is the perfect place to put all 3 values.
Sure, sure, another way would be to set up an object and have
DoFunction(), GetAnswer1(), GetAnswer2() and GetAnswer3() -- but is that
REALLY better code? As a professional software developer for several
decades, I have to say that this strikes me as ripe for some subtle,
difficult to find bug to creep in -- keep all the code that works on the
same problem near itself! (Obvious exceptions for multiple-use
sub-functions, etc...)
Here's another, although I went to using "interface" instead of classes,
for this one:
Constants. As in:
public interface kM
{
public final int serverPort = 1232;
public final String serverAdxLocal = new String ("0.0.0.0");
public final int clientConnections = (1 << 0);
public final int consoleConnections= (1 << 1);
public final int isConnected = (1 << 2);
public final int allConnections = 0xffffFFFF;
public final int SecsPerHour = 60 * 60;
public final int SecsPerMin = 60;
public final int SecsPerTesting = 6;
public final int SecsToUse = SecsPerHour;
[etc]
}
so now my code can have
if (TimePassed() > kM.SecsPerHour)
{
DoHourlyTask();
}
(Ok, not my best example, as callbacks are probably a better way to
handle that, but you get the idea.)
Btw, I'm happy to learn of new, better way to handle "constants" in
Java. This way is... bleck!
---
So, I'm happy to hear your "better way" of doing things. But remember:
just because you & everyone you know does something a certain way
doesn't make that way better. "Better" implies things like "code works
more often", "broken code is easier to debug", "higher quality product
is delivered to the client earlier", etc.
Don't mean to seem argumentative -- it's just that I encounter a lot of
this sort of thing in my day-to-day... "but that's the way ALL the cool
kids do it!" doesn't really do anything for me <G>.
Misc., who'd like to shoot the person who invented
open-bracket-at-the-end-of-the-line as a style ;)
P.S. In case you missed it, I [sort-a] found the (original) problem:
smaller objects don't corrupt the stream. I thougth the stream was
supposed to handle breaking things into appropriately-sized packets, but
I'll worry about that when the rest of the product is complete. So now,
instead of sending a Vector with 50 words, I send two with 25, and
everything's happy. That's kM.maxWordsAtATime, btw ;)
Matt Francomb
[snippety...]
> Here's another, although I went to using "interface" instead of classes,
> for this one:
>
> Constants. As in:
>
> public interface kM
> {
[...]
> public final int SecsPerHour = 60 * 60;
> public final int SecsPerMin = 60;
> public final int SecsPerTesting = 6;
> public final int SecsToUse = SecsPerHour;
>
> [etc]
> }
[...]
>
> Btw, I'm happy to learn of new, better way to handle "constants" in
> Java. This way is... bleck!
This looks like the Right Way to do constants to me. I use it all
the time. The only thing wrong with it is the name of the interface.
(I still don't know what the name is supposed to mean - it took me
quite a while to realise it had nothing to do with kilometres).
I guess in a case like this, I'd split the constants up into a lot of
interfaces, each appropriately named, such as:
public interface Duration
{
public final long Millisecond = 1L;
public final long Second = 1000L * Millisecond;
public final long Minute = 60L * Second;
public final long Hour = 60L * Minute;
public final long Day = 24L * Hour;
}
and so on, giving:
if ((System.currentTimeMillis () - startTime) >= Duration.Hour)
{
DoHourlyTask ();
}
(And please, don't anybody go on about Capitalisation Conventions to
me - case-sensitivity in languages sucks anyway and shouting constants
look ridiculous).
> Misc., who'd like to shoot the person who invented
> open-bracket-at-the-end-of-the-line as a style ;)
You've got my vote on that one. Although shooting him might be a bit
extreme. I'd sneak into his office and stick a little blob of
Blu-Tack under the return key on his keyboard.
--
Matt Francomb
Unknown
<nom...@dovecot.demon.co.uk> wrote:
I was wondering why you dont use the 'static' modifier when defining
constants? -It seems logical not to have separate group of constants
made for each instance of your class.
In my book here it says that static final feilds are compile time
constants, maybe this means their calculation must be do-able at
compile time, so you cant wait for the interpreter to figure out other
values to derive them by.
I wouldnt consider a public final feild to be a constant then, it is
instantiated for each instance of its class and calculated fresh for
each instance -unchangable but potentialy different for each object.
-so for global constants, to be efficient the syntax is
public static final %type %name = %val ;
Thats not going to make the c programmer to happy :)
&y
Babu Kalakrishnan
>(And please, don't anybody go on about Capitalisation Conventions to
>me - case-sensitivity in languages sucks anyway and shouting constants
>look ridiculous).
>
>> Misc., who'd like to shoot the person who invented
>> open-bracket-at-the-end-of-the-line as a style ;)
>
>You've got my vote on that one. Although shooting him might be a bit
>extreme. I'd sneak into his office and stick a little blob of
>Blu-Tack under the return key on his keyboard.
:-)
I suspect you also prefer := as the assignment operator and = as the
equality check operator ?
Preferences aside, I think it is a good practice to stick to standard
conventions (like starting variables with lower case) when posting to
newsgroups because when someone else reads your code, it is that much
more easier for them to comprehend the problem. Making it more difficult
for them to understand your code can sometime cause you to not get help
with your problem which you might otherwise have got.
For example the moment when someone writes
Something.myMethod();
the first thing I tend to assume is that Something is a class and
myMethod is a static method in it. It takes a little more effort to
understand the code (i.e needs a second look at least) when "Something"
turns out to be variable instead.
BK
Kenny MacLeod
Explicity declaring them so is redundant and clutters up the code.
"&y" <Odd...@Ntlworld.Com> wrote in message
news:3bfe4bbd...@news.ntlworld.com...
Jean-Baptiste Nizet
"Odd...@Ntlworld.Com" a écrit :
> On 23 Nov 2001 10:39:29 +0000, Matt Francomb
> <nom...@dovecot.demon.co.uk> wrote:
>
> I was wondering why you dont use the 'static' modifier when defining
> constants? -It seems logical not to have separate group of constants
> made for each instance of your class.
>
The fields were not part of a class, but of an interface, and as specified
in the JLS
(http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#78642),
"Every field declaration in the body of an interface is implicitly public,
static, and final".
JB.
Thomas Weidenfeller
> open-bracket-at-the-end-of-the-line as a style ;)
This is 1TBS (The "One True Brace Style"). You have to shoot the
inventors of the C language: Kernighan and Ritchie. You will not make
much friends by doing so :-)
/Thomas
Marco Schmidt
[...]
Small note - you can drop both public and final from those constants:
>public interface kM
>{
> int serverPort = 1232;
...
will do. I would also recommend following the conventions and make it
SERVER_PORT instead of serverPort etc. Identifying constants will be
much easier for anyone studying the code.
[...]
Regards,
Marco
--
Please reply in the newsgroup, not by email!
Java programming tips (updated 2001-11-03):
http://jiu.sourceforge.net/javatips.html
Gordon Beaton
Have a look at the eighth commandment:
http://www.lysator.liu.se/c/ten-commandments.html
(applies just as well to Java as to C)
/gordon
--
[ do not send me private copies of your followups ]
g o r d o n . b e a t o n @ e r i c s s o n . c o m
Thomas Weidenfeller
> Have a look at the eighth commandment:
>
> http://www.lysator.liu.se/c/ten-commandments.html
Amen brother, you tell it :-)))
/Thomas
Matt Francomb
> On 23 Nov 2001 10:39:29 +0000, Matt Francomb <nom...@dovecot.demon.co.uk> wrote:
>
> >(And please, don't anybody go on about Capitalisation Conventions to
> >me - case-sensitivity in languages sucks anyway and shouting constants
> >look ridiculous).
> >
>
> I suspect you also prefer := as the assignment operator and = as the
> equality check operator ?
>
You got it in one! And I particularly like the way you can express
String doSomething (Object o)
{
String result = null;
if (o instanceof String)
result = (String)o;
return s;
}
as
do_something (o: ANY): STRING is
do
Result ?= o
end -- do_something
;)
> Preferences aside, I think it is a good practice to stick to standard
> conventions (like starting variables with lower case) when posting to
> newsgroups because when someone else reads your code, it is that much
> more easier for them to comprehend the problem. Making it more difficult
> for them to understand your code can sometime cause you to not get help
> with your problem which you might otherwise have got.
Yes, I normally (now) do it that way, but I think a single upper-case
letter at the start of a constant is enough - it's not as if there's
anywhere such an identifier could be used that would be syntactically
correct and susceptible to be mistaken for a class name, after all.
However, my reason for abiding by the capitalisation conventions is
only because it makes it easier for people to use my code when they're
stuck with case-sensitivity - i.e. so that they can predict how an
identifier ought to be spelt, not so that they can determine what type
of identifier it is. I think it's ridiculous to associate any
semantic meaning with the case of letters.
--
Matt Francomb
Helpful GM
<news1...@dovecot.demon.co.uk> wrote:
> Miss Elaine Eos <Misc@*NO-SPAM*PlayNaked.com> writes:
> [snippety...]
> > Constants. As in:
> >
> > public interface kM
> > {
> [...]
> > public final int SecsPerHour = 60 * 60;
> > public final int SecsPerMin = 60;
> > public final int SecsPerTesting = 6;
> > public final int SecsToUse = SecsPerHour;
> >
> > [etc]
> > }
> [...]
> >
> > Btw, I'm happy to learn of new, better way to handle "constants" in
> > Java. This way is... bleck!
> This looks like the Right Way to do constants to me. I use it all
> the time. The only thing wrong with it is the name of the interface.
> (I still don't know what the name is supposed to mean - it took me
> quite a while to realise it had nothing to do with kilometres).
You're right, it's probably a lame name. The name of my project starts
with an "M", and so it's "k" for kconstant (as in C-programming:
kSecondsInAnHour, etc.), so all my Java constants look like
kM.SecsPerHour, etc.
> I guess in a case like this, I'd split the constants up into a lot of
> interfaces, each appropriately named, such as:
>
> public interface Duration
> {
> public final long Millisecond = 1L;
> public final long Second = 1000L * Millisecond;
> public final long Minute = 60L * Second;
> public final long Hour = 60L * Minute;
> public final long Day = 24L * Hour;
> }
Sure, except I'd name it kDuration. I'll try that starting next project.
> (And please, don't anybody go on about Capitalisation Conventions to
> me - case-sensitivity in languages sucks anyway and shouting constants
> look ridiculous).
Agreed. I don't object to kOnstants_that_look_like_this, although I,
personally, find them difficult to type, so prefer kOnesThatLookLikeThis.
> > Misc., who'd like to shoot the person who invented
> > open-bracket-at-the-end-of-the-line as a style ;)
> You've got my vote on that one. Although shooting him might be a bit
> extreme. I'd sneak into his office and stick a little blob of
> Blu-Tack under the return key on his keyboard.
A good start, I suppose ;)
Miss Elaine Eos
kalakr...@vsnl.com wrote:
> Preferences aside, I think it is a good practice to stick to standard
> conventions (like starting variables with lower case) when posting to
> newsgroups because when someone else reads your code, it is that much
> more easier for them to comprehend the problem. Making it more difficult
> for them to understand your code can sometime cause you to not get help
> with your problem which you might otherwise have got.
I can see this is going to degenerate into a flame-fest, but I feel
compelled to point out that your premise is sound while your conclusion
is flawed.
The idea that one should stick to standard conventions to make code
easier to read (thus more maintainable, thus more bug-free, all good
things) is a great one.
The problem is -- while you guys are helpful in the extreme, the
important group to make my code readable for is the other engineers in
the shop. Hence, shop-standards, not those of a group of people who
"write funny looking code" (to my eyes), are the ones to be followed.
Of course, we could go on & on about the wisdom or lack thereof of
someone setting a shop standard different from yours, but there you go.
Marshall Spight
> In article <TP2L7.39520$RG1.19...@news1.rdc1.sfba.home.com>,
> "Marshall Spight" <msp...@dnai.com> wrote:
>
> I follow what you're saying, I think you're overlooking a couple of
> valuable uses of structs.
>
> I want to pass you 20 parameters, all at once. These parameters go
> together (sort of like fields in an object ;) and, if you're interested
> in one, you're probably interested in all of them.
>
> This is the perfect use for a public-fielded struct.
As the saying goes, if you're passing 10 parameters to a method,
you probably forgot a few. (Although I guess with 20, maybe
you remembered them all!) The point being, if you have a method
that takes more than ten parameters, you are likely doing something
wrong, and you need to break the method down further.
I would say this is doubly true for methods with 20 parameters!
> The reason for data-hiding is when it would be dangerous to the object
> to have the fields manipulated externally, without updating some
> internal gizmo. Sure, I see that -- but "there are significant
> disadvantages to non-private fields" seems a bit hyperbolic, and "[no
> advantages]" seems likewise.
Here's two disadvantages to having public fields: the class cannot
be subclassed with a different implementation of the attribute,
and the class cannot ever receive notification of changes to
the attribute. An example Chris Smith mentioned the other day
was wanting to have a subclass of java.awt.Point that fired
property change events; it's impossible, and the only reason
it's impossible is because the class uses public fields instead of
accessor methods.
I do consider these disadvanges to be significant.
As to advantages, there is exactly one: brevity. One can type
foo.x;
foo.x = 5;
instead of:
foo.getX();
foo.setX(5);
This saves 5 characters in the get-case and 4 in the set case.
I'd call that virtually no advantage.
> What possible disadvantage is there to an object that only consists of
> public fields, nothing else?
Again, such a thing is not an object oriented construct. An object is
data+methods: no methods, no object. Furthermore, such an struct
cannot easily be later converted into an object, because of the
disadvantages of public fields.
> Here's another use:
>
> Functions/methods where you want to return more than one value.
I've never seen a case where a method that supposedly needed to return
multiple values couldn't be refactored into several methods that each
returned one value, and were clearer and easier to understand.
> MyAnswerObject() [/struct] is the perfect place to put all 3 values.
> Sure, sure, another way would be to set up an object and have
> DoFunction(), GetAnswer1(), GetAnswer2() and GetAnswer3() -- but is that
> REALLY better code?
No, that'd be worse. That's not how I do it, though.
> As a professional software developer for several
> decades, I have to say that this strikes me as ripe for some subtle,
> difficult to find bug to creep in -- keep all the code that works on the
> same problem near itself! (Obvious exceptions for multiple-use
> sub-functions, etc...)
>
> Here's another, although I went to using "interface" instead of classes,
> for this one:
>
> Constants. As in:
>
> public interface kM
> {
> public final int serverPort = 1232;
> public final String serverAdxLocal = new String ("0.0.0.0");
> ...
Unfortunately, every time I make the point about public fields, I forget
to say "non-static, not-final fields." (Those constants should be static, BTW.)
Yes, constants can be public; constants do not suffer any of the problems
I described above with public instance fields.
> Btw, I'm happy to learn of new, better way to handle "constants" in
> Java. This way is... bleck!
>
> ---
>
> So, I'm happy to hear your "better way" of doing things. But remember:
> just because you & everyone you know does something a certain way
> doesn't make that way better. "Better" implies things like "code works
> more often", "broken code is easier to debug", "higher quality product
> is delivered to the client earlier", etc.
I absolutely agree here. I'd also add: code is more flexible to extension.
> Don't mean to seem argumentative -- it's just that I encounter a lot of
> this sort of thing in my day-to-day... "but that's the way ALL the cool
> kids do it!" doesn't really do anything for me <G>.
Sadly, I never have been a cool kid, and it's unlikely at this stage that
will ever happen. :-)
> Misc., who'd like to shoot the person who invented
> open-bracket-at-the-end-of-the-line as a style ;)
Me! That's probably the biggest boondoggle ever to hit
language formatting.
> P.S. In case you missed it, I [sort-a] found the (original) problem:
> smaller objects don't corrupt the stream. I thougth the stream was
> supposed to handle breaking things into appropriately-sized packets, but
> I'll worry about that when the rest of the product is complete. So now,
> instead of sending a Vector with 50 words, I send two with 25, and
> everything's happy. That's kM.maxWordsAtATime, btw ;)
That's just freaky. But I'm glad you found the problem.
Marshall
Helpful GM
(Odd...@Ntlworld.Com) wrote:
> I was wondering why you dont use the 'static' modifier when defining
> constants? -It seems logical not to have separate group of constants
> made for each instance of your class.
I think you mean, why don't I just do...
static final int kMyConstant = 12;
right? I think the static is redundant, here, as final means it's not
going to change, anyway.
Or do I misunderstand your suggestion?
> In my book here it says that static final feilds are compile time
> constants, maybe this means their calculation must be do-able at
> compile time, so you cant wait for the interpreter to figure out other
> values to derive them by.
Ooo, I missed that page. Something to experiment with :)
> I wouldnt consider a public final feild to be a constant then, it is
> instantiated for each instance of its class and calculated fresh for
> each instance -unchangable but potentialy different for each object.
However, "final" means it's not going to change. Ever.
> -so for global constants, to be efficient the syntax is
>
> public static final %type %name = %val ;
>
> Thats not going to make the c programmer to happy :)
> &y
<G>
C programmers, as a group, aren't as grumpy as a few might lead you to
believe. It's just that a few Java programmers are so in-your-face
about how they've revolutionized the world that a few C programmers feel
the need to bump chests with them.
It's great sport, if you have a good bookie and can get decent seats ;)
Miss Elaine Eos
> I was wondering why you dont use the 'static' modifier when defining
> constants? -It seems logical not to have separate group of constants
> made for each instance of your class.
I think you mean, why don't I just do...
static final int kMyConstant = 12;
right? I think the static is redundant, here, as final means it's not
going to change, anyway.
Or do I misunderstand your suggestion?
> In my book here it says that static final feilds are compile time
> constants, maybe this means their calculation must be do-able at
> compile time, so you cant wait for the interpreter to figure out other
> values to derive them by.
Ooo, I missed that page. Something to experiment with :)
> I wouldnt consider a public final feild to be a constant then, it is
> instantiated for each instance of its class and calculated fresh for
> each instance -unchangable but potentialy different for each object.
However, "final" means it's not going to change. Ever.
> -so for global constants, to be efficient the syntax is
>
> public static final %type %name = %val ;
>
> Thats not going to make the c programmer to happy :)
> &y
<G>
C programmers, as a group, aren't as grumpy as a few might lead you to
believe. It's just that a few Java programmers are so in-your-face
about how they've revolutionized the world that a few C programmers feel
the need to bump chests with them.
It's great sport, if you have a good bookie and can get decent seats ;)
Jon Skeet
> In article <3bfe4bbd...@news.ntlworld.com>, &y
> (Odd...@Ntlworld.Com) wrote:
>
> > I was wondering why you dont use the 'static' modifier when defining
> > constants? -It seems logical not to have separate group of constants
> > made for each instance of your class.
>
> I think you mean, why don't I just do...
>
> static final int kMyConstant = 12;
>
> right? I think the static is redundant, here, as final means it's not
> going to change, anyway.
>
> Or do I misunderstand your suggestion?
No, I think you misunderstand the meaning of "static". It has nothing to
do with being fixed. It has to do with not being related to any
particular instance of a class, but being related to the class itself.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Marshall Spight
> Member variables of interfaces are implicity public, static and final.
> Explicity declaring them so is redundant and clutters up the code.
Wow, I didn't know that. I knew that they were implicitly public,
but not static and final. Cool!
That actually seems like another reason in favor of using interfaces
to define constants, somehow.
Marshall
Unknown
<Kenny_...@S.P.A.M.yahoo.com> wrote:
>Member variables of interfaces are implicity public, static and final.
>Explicity declaring them so is redundant and clutters up the code.
>
I see. Thanks, I have only just got used to syntax and constructors. I
am learning about interfaces next.
&y
Unknown
<HelpfulGM@*NO-SPAM*PlayNaked.com> wrote:
<snip>
>However, "final" means it's not going to change. Ever.
But it doesnt mean theres only one instance of the feild created. You
could have a number of different final instances being created
-theoreticaly and least.
I think we both have some more learning to do about these terms.
>> -so for global constants, to be efficient the syntax is
>>
>> public static final %type %name = %val ;
>>
>> Thats not going to make the c programmer to happy :)
>> &y
>
><G>
>
>C programmers, as a group, aren't as grumpy as a few might lead you to
>believe. It's just that a few Java programmers are so in-your-face
>about how they've revolutionized the world that a few C programmers feel
>the need to bump chests with them.
>
>It's great sport, if you have a good bookie and can get decent seats ;)
>
Yes, c programmers and -even better machine code artists have my
highest regards. The route to 'high level' enlightenment is paved with
officious assertions ;)
Is good to be in touch with ones baser mechanisms,
&y
Kenny MacLeod
news:IswL7.41207$RG1.21...@news1.rdc1.sfba.home.com...
> "Kenny MacLeod" <Kenny_...@S.P.A.M.yahoo.com> wrote in message
news:53tL7.348$yw1....@news.uk.colt.net...
> > Member variables of interfaces are implicity public, static and final.
> > Explicity declaring them so is redundant and clutters up the code.
>
> Wow, I didn't know that. I knew that they were implicitly public,
> but not static and final. Cool!
I wasn't sure if you were being sarcastic there :-)
> That actually seems like another reason in favor of using interfaces
> to define constants, somehow.
I use it all the time.... for example, my servlet request-handlers generally
have inner interfaces called Attributes, Parameters, Constants, Templates,
etc, each of which has a number of constants. It improves readability quite
considerably.
> Marshall
kenny
Erki Suurjaak
> > public interface Duration
> Sure, except I'd name it kDuration. I'll try that starting next project.
^
Hope this does not turn into another long-standing argument, but -
what's with the Hungarian?
Erki
Jon Skeet
> > That actually seems like another reason in favor of using interfaces
> > to define constants, somehow.
>
> I use it all the time.... for example, my servlet request-handlers generally
> have inner interfaces called Attributes, Parameters, Constants, Templates,
> etc, each of which has a number of constants. It improves readability quite
> considerably.
I'm not sure whether or not I'll adapt it elsewhere, but in my JBench
configuration class I have two nested interfaces:
/**
* Interface for the property names appearing in the configuration
* file.
*/
public interface PropertyNames
{
String RUNS_PER_TASK = "jbench.runs";
String SYSTEM_INFORMATION = "jbench.sysinfo";
String LOG_FILE = "jbench.log";
String LOG_APPEND = "jbench.log.append";
String FAIL_FAST = "jbench.failfast";
String EXCLUDE_WORST = "jbench.stats.excludeworst";
String EXCLUDE_BEST = "jbench.stats.excludebest";
String PACKAGES = "jbench.packages";
String TIMER = "jbench.timer";
}
/** Interface for the default configuration values */
public interface Defaults
{
int RUNS_PER_TASK = 5;
String SYSTEM_INFORMATION = "vm, os, clock";
boolean FAIL_FAST = false;
boolean LOG_APPEND = true;
int EXCLUDE_BEST = 1;
int EXCLUDE_WORST = 1;
String TIMER = "clock";
Marshall Spight
> "Marshall Spight" <msp...@dnai.com> wrote in message
> news:IswL7.41207$RG1.21...@news1.rdc1.sfba.home.com...
> > "Kenny MacLeod" <Kenny_...@S.P.A.M.yahoo.com> wrote in message
> news:53tL7.348$yw1....@news.uk.colt.net...
> > > Member variables of interfaces are implicity public, static and final.
> > > Explicity declaring them so is redundant and clutters up the code.
> >
> > Wow, I didn't know that. I knew that they were implicitly public,
> > but not static and final. Cool!
>
> I wasn't sure if you were being sarcastic there :-)
Just to be clear, I wasn't being sarcastic. I really did know that
all things in an interface are implicitly public, but I didn't know
that fields in an interface were implicitly static and final. Although
come to think of it, I don't see how it could be otherwise.
> > That actually seems like another reason in favor of using interfaces
> > to define constants, somehow.
>
> I use it all the time.... for example, my servlet request-handlers generally
> have inner interfaces called Attributes, Parameters, Constants, Templates,
> etc, each of which has a number of constants. It improves readability quite
> considerably.
Yes, I've used the technique myself, but I'm still not sure how I feel
about it. It seems both good and bad.
Marshall
Jim Sculley
<snip>
>
> P.S. In case you missed it, I [sort-a] found the (original) problem:
> smaller objects don't corrupt the stream. I thougth the stream was
> supposed to handle breaking things into appropriately-sized packets, but
> I'll worry about that when the rest of the product is complete. So now,
> instead of sending a Vector with 50 words, I send two with 25, and
> everything's happy. That's kM.maxWordsAtATime, btw ;)
This screams 'threading problem' to me. There is no reason for a 25
element Vector to successfully serialize while a 50 element Vector will
not. The processes are identical except for the time required to
complete the task. You description of the intermittent nature of the
problem also points to threads. Are you sure you are synchronizing in
all the right places?
Jim S.
Miss Elaine Eos
Suurjaak <esk0...@student.mdh.se> wrote:
> On Fri, 23 Nov 2001, Helpful GM wrote:
>
> > > public interface Duration
> > Sure, except I'd name it kDuration. I'll try that starting next
> > project.
> Hope this does not turn into another long-standing argument, but -
> what's with the Hungarian?
Old C programming convention. You know how folks use "starts with
upper/lower-case" to imply things? "Starts with 'k'" implies that it's
a Konstant value. As in
#define kSecondsInAnHour (60 * 60);
etc.
Basically, that's what happens when you let C programmer use your
language ;)
Matt Francomb
> > > public interface Duration
> > Sure, except I'd name it kDuration. I'll try that starting next project.
> ^
> Hope this does not turn into another long-standing argument, but -
> what's with the Hungarian?
>
You took the words right out of my mouth!
--
Matt Francomb
Erki Suurjaak
> > > Sure, except I'd name it kDuration. I'll try that starting next
> > Hope this does not turn into another long-standing argument, but -
> > what's with the Hungarian?
> Basically, that's what happens when you let C programmer use your
> language ;)
I can see that. Horrible, just horrible :)
I would guess most Java programmers would squint fiercely when
they encountered your code. I've seen very little Hungarian in Java, and
it's always dealing with innards, like having "p" in front of arguments,
and "m_" in front of attributes. Your style is very exceptional. Naming
conventions are a good thing to follow, I'd think. Damn the indenting that
can be changed easily. Names are here to stay. Forever.
And one trouble with adopting Hungarian notation is - where do you
draw the line? Today it's kInterfaceForConstants, tomorrow it's
kFinalField. You will find yourself using
"lTemp.sfTransmogrify(mFoo, kFoo.kBar)" in no time :)
Erki
Marshall Spight
> And one trouble with adopting Hungarian notation is - where do you
> draw the line? Today it's kInterfaceForConstants, tomorrow it's
> kFinalField. You will find yourself using
> "lTemp.sfTransmogrify(mFoo, kFoo.kBar)" in no time :)
Let's not forget my old favorite, that blast from the past: lpszcstr!
Now *there's* a prefix!
Marshall
PS. Prefixes are evil.
Paul Murray
>
> I'm getting StreamCorruptedException-s. What do I do about it? I mean,
> is there any way to say "ok, great -- reset the stream and try again"?
> It seems that, once you get one StreamCorruptedException, you just keep
> getting them for the rest of eternity. Is there some way to "uncorrupt"
> a stream?
You'd need to have some sort of higher level packetization - in effect, a
protocol of your own.
> For that matter -- how did it get corrupt in the first place? Is that a
> fault in my program? Or just bad internet packets?
Yeah, something like that.
Or you are reading a header with buffered input stream, then using the
underlying unbuffered stream to make your ObjectInputStream from.
__________________________________________________
Spot the difference!
Jer 48:10 A curse on him who is lax in doing the Lord's work! A curse on him
who keeps his sword from bloodshed!
Mk 16:16 He that believeth and is baptized shall be saved; but he that
believeth not shall be damned.
Quran 2 And kill them wherever you find them, ... if they do fight you, then
slay them; such is the recompense of the unbelievers.
http://www.users.bigpond.com/pmurray .
Miss Elaine Eos
> In article <wmZK7.38727$RG1.18...@news1.rdc1.sfba.home.com>,
> "Marshall Spight" <msp...@dnai.com> wrote:
> > "Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
> > news:Misc-E3778F.1...@ca.news.verio.net...
> > > Ummm. Ok. Forgive me for sounding dense, but here's what I've got:
> > > ---
> > > So, every SendObject() creates a new ObjectOutputStream, writes the
> > > serialised object, then flushes the OOS.
> > >
> > > Every ReadObject() creates a new ObjectInputStream, reads the object,
> > > then discards the OIS.
> > >
> > > Perhaps not the most efficient way of doing things, but I prefer
> > > brute-force-and-works to tight-but-buggy-and-hard-to-fix.
> > Is there any reason not to just create one OIS stream and one OOS
> > once at the beginning and use just them until the end of time?
> > It certainly seems cleaner to me.
> >
> > One thing that could cause your problem (in fact, I'd bet this is
> > it) is if anything, anywhere, ever, on the server side, writes any
> > bytes to your server socket's output stream that get read by
> > your ReadNextObject method.
> > Marshall
Ok, I don't understand this statement. Of course the server writes to
the socket objects that are intended to be read by ReadNextObject().
I've been looking at this code all day, and I don't see the "if anything
ever writes to a stream something that later gets read" part. What am I
missing?
(And thanks for your patience, here -- it's a lot of help.)
For reference, the ReadNextObject() and SendObject() methods are listed,
below.
Note the the main loop of this thread is:
while (running)
{
ReadNextObject();
}
which blocks waiting for data, then stuffs it into an array
(synchronized). ThisThread.SendObject(obj) is used to send things the
other way. The client[s] and the server have their own threads set up
for communication.
And, oddly, everything works fine, 92% of the time. But it's that
1-in-10 packets, functionally identical to the others -- and not always
the same one, it moves around -- that seems to corrupt the stream.
Btw, earlier, I reported that making the packets smaller seemed to fix
things. I lied. Rather, I shrank the packets and the next 3 or 4
connections went without a hitch. Then I did some interface work and,
next test, it was back to the corrupt stream. (No changes in
communication -- I was just moving buttons around the client.)
So, anyway -- my server writes things to the socket with SendObject(),
and the client reads it with ReadNextObject(). What does your statement
"One thing that could cause your problem (in fact, I'd bet this is it)
is if anything, anywhere, ever, on the server side, writes any bytes to
your server socket's output stream that get read by your ReadNextObject
method." mean?
Thanks.
--- (for reference) ---
public void SendObject (Object theObject)
{
try
{
ObjectOutputStream objOut = null;
if (socket == null)
{
objOut = null;
Utils.LogWarning ("null socket in
BaseObjectIOThread.SendObject()");
}
else
{
objOut = new ObjectOutputStream (socket.getOutputStream());
}
if (objOut == null)
{
//€ failureCount++;
}
else
{
if (kDebugging)
{
}
objOut.writeObject (theObject);
objOut.flush();
if (failureCount > 0)
failureCount--;
}
// Utils.LogDebugging ("BaseObjectIOThread object sent: " +
((MS_S2SPacket) theObject).command);
}
catch (StreamCorruptedException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext
StreamCorruptedException (SendObject): ", e);
}
}
catch (IOException e)
{
failureCount++;
// Utils.LogError ("BaseObjectIOThread IOError (SendObject): ", e);
}
}
private void ReadNextObject ()
{
ObjectInputStream objIn = null;
try
{
objIn = new ObjectInputStream (socket.getInputStream());
Object thisObject = objIn.readObject();
AddObjectToQueue (thisObject);
if (failureCount > 0)
failureCount--;
}
catch (StreamCorruptedException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext
StreamCorruptedException (ReadNextObject): ", e);
}
}
catch (IOException e)
{
failureCount++;
yield();
if (failureCount == kMaxIOFailures)
{
Utils.LogError ("BaseObjectIOThreadReadNext IOError
(ReadNextObject): ", e);
}
}
catch (ClassNotFoundException e)
{
failureCount++;
yield();
Utils.LogError ("BaseObjectIOThreadReadNext
ClassNotFoundException", e);
}
if (failureCount > kMaxIOFailures)
{
if (notifyThread == null) Utils.LogSystemMsg
("BaseObjectIOThreadReadNext lost connection. failureCount: " +
failureCount);
else notifyThread.LostConnection (this);
ShutDown();
Helpful GM
<nic...@abraxis.com> wrote:
I'm game. Threads are a likely source and "syrchronize" isn't my strong
suit, either. I've little experience in either area, so screwing this
up seems a great possibility.
I synchronize when I add or remove elements from the array (add them in
ReadNextObject(), which queues them up as soon as they come in, remove
them in GetNextObject(), which returns them when the mother-thread asks
for them), and that's it.
I suppose you're going to tell me I need to synchronize... Hmmm, what?
Do I understand sychronize to say that anything that tries to enter this
method is put on hold until the previous execution of this thread.method
is finished? If so, then... hmmm... I don't know what to fix :\
Here's a quick block diagram of what I'm doing (attempt to use "std"
bracketing, so you don't have to squint ;):
public class MyTPCioThread extends Thread {
public void run () {
while (running) {
ReadNextObject()
}
// cleanup stuff
}
public void ReadNextObject() {
objIn = new ObjectInputStream (socket.getInputStream());
Object thisObject = objIn.readObject();
AddObjectToQueue (thisObject);
// Notify parent-thread that something came in.
}
sync protected void AddObjectToQueue(obj) {
queue.addElement (obj);
}
public void SendObject() {
objOut = new ObjectOutputStream (socket.getOutputStream());
objOut.writeObject (theObject);
objOut.flush();
}
sync public Object GetNextObject() { // called from parent thread
Object result = null
if (queue.size() > 0) {
result = queue.elementAt (0);
queue.removeElementAt (0);
}
return (result);
}
}
Lots of error-checking, set-up & cleanup removed -- but that's the
general idea. The parent thread does something like this:
tcpio = new MyTCPioThread();
tcpio.start();
[...]
tcpio.SendObject (MyPacketOfStuff);
[...]
// when we get a notification...
incommingPacket = tcpio.getNextObject();
[...etc.]
So -- where else would I put sync-s in this set-up? Why does your
suggestion matter -- I don't get where adding sync can improve this.
Thanks again for all your help, btw.
Marshall Spight
>
> > In article <wmZK7.38727$RG1.18...@news1.rdc1.sfba.home.com>,
> > "Marshall Spight" <msp...@dnai.com> wrote:
>
> > > One thing that could cause your problem (in fact, I'd bet this is
> > > it) is if anything, anywhere, ever, on the server side, writes any
> > > bytes to your server socket's output stream that get read by
> > > your ReadNextObject method.
>
> the socket objects that are intended to be read by ReadNextObject().
> I've been looking at this code all day, and I don't see the "if anything
> ever writes to a stream something that later gets read" part. What am I
> missing?
Perhaps I left a word out. :-(
If anything *else* writes to the socket. That is, if you write *any*
bytes to the socket using anything other than your sendObject method.
Based on the earlier symptoms, I can state with virtual certainty that
what's happening is that there are bytes at the very beginning of what
your readNextObject() is expecting to be the beginning of an OOS,
which aren't. They have to get in there somehow. Either they're introduced
in the transport layer, or you're writing extraneous bytes. (Or your reads
and writes are misaligned.) I can't think of any other possibility.
It could be the transport layer, but I'd expect that layer to be
error-corrected; this really suggests you're writingsome bytes
to the socket with something other than sendObject.
Are you certain your writes and reads are aligned? That is, each
read method on one side exactly corresponds to a write method
on the other side?
> (And thanks for your patience, here -- it's a lot of help.)
No problemo.
Marshall
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
> "Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
> news:Misc-17D489.1...@ca.news.verio.net...
> > In article <TP2L7.39520$RG1.19...@news1.rdc1.sfba.home.com>,
> > "Marshall Spight" <msp...@dnai.com> wrote:
> >
> > I follow what you're saying, I think you're overlooking a couple of
> > valuable uses of structs.
> >
> > I want to pass you 20 parameters, all at once. These parameters go
> > together (sort of like fields in an object ;) and, if you're interested
> > in one, you're probably interested in all of them.
> >
> > This is the perfect use for a public-fielded struct.
>
> As the saying goes, if you're passing 10 parameters to a method,
> you probably forgot a few. (Although I guess with 20, maybe
> you remembered them all!) The point being, if you have a method
> that takes more than ten parameters, you are likely doing something
> wrong, and you need to break the method down further.
>
> I would say this is doubly true for methods with 20 parameters!
I'm in a client-server setup. I want to send 20 things from the client
to the server (or vice versa.) 1 object. Actually, some of the items
(2s, 3s & 4 at a time) are used to create objects at the other end
without passing an entire object around.
I follow what you're saying, and it's a good rule of thumb -- I just
don't think it applies to what I'm doing.
> > The reason for data-hiding is when it would be dangerous to the object
> > to have the fields manipulated externally, without updating some
> > internal gizmo. Sure, I see that -- but "there are significant
> > disadvantages to non-private fields" seems a bit hyperbolic, and "[no
> > advantages]" seems likewise.
> Here's two disadvantages to having public fields: the class cannot
> be subclassed with a different implementation of the attribute,
> and the class cannot ever receive notification of changes to
> the attribute.
Attribute = field, right?
So, you just said the same thing I said -- when a change in the field
needs to be intercepted. Yes, this is an important reason to do what
you describe.
Now let's take a client/server thing -- the server wants to send 20 (or
10 or 40 or whatever) int-s to the client. They represent lots of
different things. Bulking up the packet-object with accessor functions,
just to waste expensive bandwidth over the wire, just so the other thing
can read the int-s at the other end through accessor functions seems
like a lot of bulk with no benefit.
See what I mean?
It's that old consistancy and hobgoblins thing ;)
> An example Chris Smith mentioned the other day
> was wanting to have a subclass of java.awt.Point that fired
> property change events; it's impossible, and the only reason
> it's impossible is because the class uses public fields instead of
> accessor methods.
It's only impossible if you USE the public fields. Granted, that means
"impossible" for a public interface -- but then you just need to invent
the SmithPoint object, or whatever.
> I do consider these disadvanges to be significant.
In the situations you describe, we agree.
> As to advantages, there is exactly one: brevity. One can type
>
> foo.x;
> foo.x = 5;
>
> instead of:
>
> foo.getX();
> foo.setX(5);
>
> This saves 5 characters in the get-case and 4 in the set case.
>
> I'd call that virtually no advantage.
That's because you don't pay by the byte to transfer data around a wire.
If you did, and if your pipe was constantly near-capacity when you found
a need to send additional data, you'd think of ways to shrink stuff
down. Keeping the object small by eliminating useless (and I mean that
in the sense of "providing no additional funcationality") accessor code.
Besides, you have variables named "x"?!?! ;) (Ok, maybe in a Point
object...)
> > What possible disadvantage is there to an object that only consists of
> > public fields, nothing else?
>
> Again, such a thing is not an object oriented construct. An object is
> data+methods: no methods, no object. Furthermore, such an struct
> cannot easily be later converted into an object, because of the
> disadvantages of public fields.
"is not an OO construct" is not a fault. That's like saying "you can't
call this a steel bridge, because it has a concrete drive surface." Who
cares?! It's a steel bridge! Concrete is allowed for certain uses on
steel bridges. In fact, using steel for the road surface would be
"stoopid" ;)
...Not that I mean to be argumentative, or anything <G> You've been a
ton of help, but I think you're suggesting that I limit myself to a rut
that serves no purpose. "Here, use this hammer, it's always worked for
me", "yeah, but I'm trying to loosen bolts", "so, use a hammer, anyway"
-- know what I mean?
> I've never seen a case where a method that supposedly needed to return
> multiple values couldn't be refactored into several methods that each
> returned one value, and were clearer and easier to understand.
Methods that return Points, Rects or Dimensions are typically used just
to get the corner-points, without care (present or possible future) for
the actual object's other properties. Here, you're wasting time (and,
if over the wire, bandwidth, which costs big dollars), wrappering those
2 (or 8) return values in objects that are un-needed.
Let's say I just needed 4 points, but they weren't a Rectangle or any
other shape, they were just 4 points. I'd make a 4-pointed object, and
pass data with them.
> Unfortunately, every time I make the point about public fields, I forget
> to say "non-static, not-final fields." (Those constants should be static,
> BTW.)
Yeah, thanks. See? I *CAN* learn! ;D
> > P.S. In case you missed it, I [sort-a] found the (original) problem:
> > smaller objects don't corrupt the stream. I thougth the stream was
> > supposed to handle breaking things into appropriately-sized packets,
> > but
> > I'll worry about that when the rest of the product is complete. So
> > now,
> > instead of sending a Vector with 50 words, I send two with 25, and
> > everything's happy. That's kM.maxWordsAtATime, btw ;)
>
> That's just freaky. But I'm glad you found the problem.
Turns out I lied. I shrank the packets and the problem went away for a
while, then came back. Sneaky little devils!
Now I'm wondering if my home-router (share a modem connection) isn't
part of the problem. It's a different-brand "Web-Ramp" like product. I
forget which one I have, and am too lazy to go look.
Someone now has me convinced I've got threading/sych problems which
seems likely, given how little I know about these things.
Miss Elaine Eos
I'm game. Threads are a likely source and "syrchronize" isn't my strong
--
Marshall Spight
> In article <n8wL7.41195$RG1.21...@news1.rdc1.sfba.home.com>,
> "Marshall Spight" <msp...@dnai.com> wrote:
>
> > "Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
> > news:Misc-17D489.1...@ca.news.verio.net...
> > > In article <TP2L7.39520$RG1.19...@news1.rdc1.sfba.home.com>,
> > > "Marshall Spight" <msp...@dnai.com> wrote:
> > >
> > > I want to pass you 20 parameters, all at once. These parameters go
> > > together (sort of like fields in an object ;) and, if you're interested
> > > in one, you're probably interested in all of them.
> > >
> > you probably forgot a few. (Although I guess with 20, maybe
> > you remembered them all!) The point being, if you have a method
> > that takes more than ten parameters, you are likely doing something
> > wrong, and you need to break the method down further.
> >
> > I would say this is doubly true for methods with 20 parameters!
>
> I'm in a client-server setup. I want to send 20 things from the client
> to the server (or vice versa.) 1 object. Actually, some of the items
> (2s, 3s & 4 at a time) are used to create objects at the other end
> without passing an entire object around.
>
> I follow what you're saying, and it's a good rule of thumb -- I just
> don't think it applies to what I'm doing.
>
> > > The reason for data-hiding is when it would be dangerous to the object
> > > to have the fields manipulated externally, without updating some
> > > internal gizmo. Sure, I see that -- but "there are significant
> > > disadvantages to non-private fields" seems a bit hyperbolic, and "[no
> > > advantages]" seems likewise.
>
> > Here's two disadvantages to having public fields: the class cannot
> > be subclassed with a different implementation of the attribute,
> > and the class cannot ever receive notification of changes to
> > the attribute.
>
> Attribute = field, right?
Yes, in this case. Note that "field" has specific meaning in Java but
"attribute" doesn't, making it the better choice for something
that might be a public field, or might be retrieved by an accessor
method, possibly by retrieving a private field, or by retrieving it
from elsewhere, or by computing it.
> So, you just said the same thing I said -- when a change in the field
> needs to be intercepted. Yes, this is an important reason to do what
> you describe.
Yes.
> Now let's take a client/server thing -- the server wants to send 20 (or
> 10 or 40 or whatever) int-s to the client. They represent lots of
> different things. Bulking up the packet-object with accessor functions,
> just to waste expensive bandwidth over the wire, just so the other thing
> can read the int-s at the other end through accessor functions seems
> like a lot of bulk with no benefit.
>
> See what I mean?
Sure. But I have one objection to your point. I have a fancy way and
a plain way of saying it; each has its value.
Plain way:
adding methods to a class doesn't increase the number of bytes
needed to send an instance of the class over the wire.
Fancy way:
Although methods appear to be associated with data (an instance,)
they are instead associated with metadata (the class.) In a client-server
setup, one passes data many times, but metadata either zero or one
times, so this isn't an issue.
Notice how the fancy way 1) is chock full of semantic goodness and
2) makes me sound pompous.
> It's that old consistancy and hobgoblins thing ;)
Did I use that phrase? I remember planning to use it in this
thread, but I thought I decided not to. Did you just bring it
up by yourself? That's spooky.
Then again, I'm more a fan of Thoreau than Emerson, anyway. :-)
> > An example Chris Smith mentioned the other day
> > was wanting to have a subclass of java.awt.Point that fired
> > property change events; it's impossible, and the only reason
> > it's impossible is because the class uses public fields instead of
> > accessor methods.
>
> It's only impossible if you USE the public fields. Granted, that means
> "impossible" for a public interface -- but then you just need to invent
> the SmithPoint object, or whatever.
I guess I don't understand you. It seems to me that if you're not using them,
you should take them out or make them private (but not both.)
> > As to advantages, there is exactly one: brevity. One can type
> > [snip]
> > This saves 5 characters in the get-case and 4 in the set case.
> >
> > I'd call that virtually no advantage.
>
> That's because you don't pay by the byte to transfer data around a wire.
> If you did, and if your pipe was constantly near-capacity when you found
> a need to send additional data, you'd think of ways to shrink stuff
> down. Keeping the object small by eliminating useless (and I mean that
> in the sense of "providing no additional funcationality") accessor code.
Again, just to be clear, adding the methods doesn't change the byte
count of the serialized object. But you have in fact come up with another
advantage: reduced class size. I did a quick test and found that removing
an accessor method reduced a .class file size by 66 bytes. I'm still going
to put that in the "virtually no advantage" category, though.
> Besides, you have variables named "x"?!?! ;) (Ok, maybe in a Point
> object...)
"X" here was meant metasyntactically; substitute the name of the attribute
for X and you get a real method name. (Although, as you Point out (heh heh)
if the class has cartesian coordinates, it may well have an attribute named
"x".)
> > > What possible disadvantage is there to an object that only consists of
> > > public fields, nothing else?
> >
> > Again, such a thing is not an object oriented construct. An object is
> > data+methods: no methods, no object. Furthermore, such an struct
> > cannot easily be later converted into an object, because of the
> > disadvantages of public fields.
>
> "is not an OO construct" is not a fault. That's like saying "you can't
> call this a steel bridge, because it has a concrete drive surface." Who
> cares?! It's a steel bridge! Concrete is allowed for certain uses on
> steel bridges. In fact, using steel for the road surface would be
> "stoopid" ;)
Well put. The first of my two points was incomplete and assumed its
conclusion, although it did make a useful point (the one about "data+methods".)
But I'm still convinced that anything that eliminates the possibility of
something that's huge (subclassing) for a benefit that's small
(saving 4-5 characters of typing, and a few dozen in class file size
(but none in instance size)) is a tradeoff that should always be
avoided.
> ...Not that I mean to be argumentative, or anything <G> You've been a
> ton of help, but I think you're suggesting that I limit myself to a rut
> that serves no purpose. "Here, use this hammer, it's always worked for
> me", "yeah, but I'm trying to loosen bolts", "so, use a hammer, anyway"
> -- know what I mean?
The subclassing and reimplementation issues are quite significant. So
use a hammer! :-)
> > I've never seen a case where a method that supposedly needed to return
> > multiple values couldn't be refactored into several methods that each
> > returned one value, and were clearer and easier to understand.
>
> Methods that return Points, Rects or Dimensions are typically used just
> to get the corner-points, without care (present or possible future) for
> the actual object's other properties. Here, you're wasting time (and,
> if over the wire, bandwidth, which costs big dollars), wrappering those
> 2 (or 8) return values in objects that are un-needed.
But wait! Now your starting to conflate remote procedure call
issues with local procedure call issues!
I'm perfectly okay with the idea of an on-the-wire protocol that
cuts things down to quite tiny. I think that's perfectly consistent
with having all non-static, non-final fields be private.
> Let's say I just needed 4 points, but they weren't a Rectangle or any
> other shape, they were just 4 points. I'd make a 4-pointed object, and
> pass data with them.
>
> > Unfortunately, every time I make the point about public fields, I forget
> > to say "non-static, not-final fields." (Those constants should be static,
> > BTW.)
>
> Yeah, thanks. See? I *CAN* learn! ;D
Well, it turns out that those constants already were static, since
fields in an interface are implicitly static. Looks like I can learn, too!
(Thanks, Kenny.)
> Turns out I lied. I shrank the packets and the problem went away for a
> while, then came back. Sneaky little devils!
>
> Now I'm wondering if my home-router (share a modem connection) isn't
> part of the problem. It's a different-brand "Web-Ramp" like product. I
> forget which one I have, and am too lazy to go look.
>
> Someone now has me convinced I've got threading/sych problems which
> seems likely, given how little I know about these things.
I'm going to vote against the idea of threading as being the cause, unless
threading is what's leading to unaligned reads and writes.
Marshall
Marshall Spight
readNextObject() on the same socket? Dingdingdingdingdingding.
Danger Will Robinson!
I'm gonna change my vote to be in favor of threading being
the problem. Can I still do that? Am I in under the deadline?
Only one thread should be allowed to call readObject() on
a given socket at a time. If one thread is interrupted before
it's finished an entire read or write of an object, you'll get:
misaligned i/o!
Synchronized isn't my strong point either, but I'd start
by doing something like this:
public void ReadNextObject()
{
synchronized(socket)
{
objIn = new ObjectInputStream (socket.getInputStream());
Object thisObject = objIn.readObject();
}
AddObjectToQueue (thisObject);
// Notify parent-thread that something came in.
}
public void SendObject()
{
synchronized(socket)
{
objOut = new ObjectOutputStream (socket.getOutputStream());
objOut.writeObject (theObject);
objOut.flush();
}
}
Marshall
Miss Elaine Eos
A big thank you to Jim Scully -- I put a sync around SendObject() and my
problems seem to have gone away. This makes sense, as 2 different
server-threads call send-object, potentially (although, MAN!, is that
obscure!) at the same time.
Then again, I thought I had it solved with shrinking my packet size --
I'm going to re-grow it, then I'll let you know it a couple of days if
it "stays fixed."
Any other words of wisdom you want to put out about sync or threads are
appreciated.
Thanks!
---
In article <Misc-BDD875.2...@ca.news.verio.net>, Miss Elaine
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
Mostly, I jumped on the idea because threading issues and sync are
things I know very little about, so could easily botch up.
The rest of it, I'm pretty comfortable with, so have a harder time
believing that's where the problem lies.
Of course, the clever problem would know to hide right in the center of
my comfort zone ;)
Babu Kalakrishnan
>In article <slrn9vshk...@ganga.sankya.com>,
>kalakr...@vsnl.com wrote:
>
>> Preferences aside, I think it is a good practice to stick to standard
>> conventions (like starting variables with lower case) when posting to
>> newsgroups because when someone else reads your code, it is that much
>> more easier for them to comprehend the problem. Making it more difficult
>> for them to understand your code can sometime cause you to not get help
>> with your problem which you might otherwise have got.
>
>I can see this is going to degenerate into a flame-fest, but I feel
>compelled to point out that your premise is sound while your conclusion
>is flawed.
Well - isn't it nice that this thread has gone without any real flames
so far ? Moral of the story - Most people who post in the c.l.j.* groups
are actually nice guys (/gals) :-)
>The idea that one should stick to standard conventions to make code
>easier to read (thus more maintainable, thus more bug-free, all good
>things) is a great one.
>
>The problem is -- while you guys are helpful in the extreme, the
>important group to make my code readable for is the other engineers in
>the shop. Hence, shop-standards, not those of a group of people who
>"write funny looking code" (to my eyes), are the ones to be followed.
>Of course, we could go on & on about the wisdom or lack thereof of
>someone setting a shop standard different from yours, but there you go.
Agreed. The only point where you misread me was that I was referring
purely to posting on the newsgroups.
As far as shop practices go - each one uses the convention they feel is
advantageous. As long as everyone agrees on something common - whether
it be an enforced practice or just by mutual agreement, I cannot see
anything wrong with it - even if it meant naming variables as
k_Yet_Another_Variable_With_A_Very_Short_Name :-)
It has been my observation that most people on this newsgroup seem to
follow the Sun convention - so it certainly would make it easier for
them if posted code follows that convention . Just regard this as a shop
where the majority prefers that convention to most other standards - and
then me and you are saying the same thing..
BK
Babu Kalakrishnan
>ka...@sankya.com (Babu Kalakrishnan) writes:
>
>> On 23 Nov 2001 10:39:29 +0000, Matt Francomb <nom...@dovecot.demon.co.uk> wrote:
>>
>> >(And please, don't anybody go on about Capitalisation Conventions to
>> >me - case-sensitivity in languages sucks anyway and shouting constants
>> >look ridiculous).
>> >
>>
>> I suspect you also prefer := as the assignment operator and = as the
>> equality check operator ?
>>
>
>You got it in one!
:-)
I also happen to have a distinct preference for languages in which the
code itself is almost self-commenting (even though I have had to program
a lot in C as well where it is sometimes very difficult to do without
horrendously unreadable constructs to achieve some things efficiently -
C lovers please excuse, this isn't a flamebait).
That's probably the reason why I took a liking to java as well.
BK
Jesper Nordenberg
I fully agree. If you really need to know where a variable is declared
(or it's type), use an IDE that supports finding the declaration.
/Jesper Nordenberg
Patricia Shanahan
Babu Kalakrishnan wrote:
...
> It has been my observation that most people on this newsgroup seem to
> follow the Sun convention - so it certainly would make it easier for
> them if posted code follows that convention . Just regard this as a shop
> where the majority prefers that convention to most other standards - and
> then me and you are saying the same thing..
I follow the Sun convention, given a choice, in my own code, but don't
care at all about the coding convention in code I'm reading, subject to
a few practical issues:
1. Indent it to represent the meaning. Use spaces for indentation, not
tabs or, worst of all, mixed tabs and spaces. Each editor that I've used
for Java has an option to use spaces. That gives the best chance of the
code showing up with clean indentation.
2. If you absolutely MUST use a news posting program with a bug that
causes it to turn "//xxx" into "file://xxx", don't use // comments in
posted code.
3. Try to keep lines short enough that they won't get wrapped by news
handling software. It doesn't know much about Java syntax.
4. Show the relevant declarations. Yes, I may guess that a name begining
with a capital letter is a class name, if I'm not shown the declaration.
I would rather be shown or told. This is especially important for code
with syntax errors, because nothing can be deduced from how a name is
used in the code. Short but complete programs are the best.
I consider these points far more important than the capitalization
convention or the placement of braces.
Patricia
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
> Oh my god, do you mean you have different threads calling
> readNextObject() on the same socket? Dingdingdingdingdingding.
> Danger Will Robinson!
>
> I'm gonna change my vote to be in favor of threading being
> the problem. Can I still do that? Am I in under the deadline?
>
> Only one thread should be allowed to call readObject() on
> a given socket at a time. If one thread is interrupted before
> it's finished an entire read or write of an object, you'll get:
> misaligned i/o!
Right, so I changed ReadNextObject to be synched. I synched the whole
routine, I see you sync just the read-object -- I'll try that, next.
I'll let you know how it goes -- as of this a.m., I still have corrupt
streams.
Of course, every time I change something, the streams stop corrupting
for 5 or 10 runs, then start being corrupt again, just to confuse me!
(@#$% streams! ;)
> Synchronized isn't my strong point either, but I'd start
> by doing something like this:
> public void ReadNextObject()
> {
> synchronized(socket)
> {
> objIn = new ObjectInputStream (socket.getInputStream());
> Object thisObject = objIn.readObject();
> }
> AddObjectToQueue (thisObject);
> // Notify parent-thread that something came in.
> }
>
>
> public void SendObject()
> {
> synchronized(socket)
> {
> objOut = new ObjectOutputStream (socket.getOutputStream());
> objOut.writeObject (theObject);
> objOut.flush();
> }
> }
Thanks!
Jim Sculley
> Aha!
>
> A big thank you to Jim Scully -- I put a sync around SendObject() and my
> problems seem to have gone away. This makes sense, as 2 different
> server-threads call send-object, potentially (although, MAN!, is that
> obscure!) at the same time.
>
> Then again, I thought I had it solved with shrinking my packet size --
> I'm going to re-grow it, then I'll let you know it a couple of days if
> it "stays fixed."
Making the packets smaller was treating the symptom. The smaller size
makes it less likely that two threads will be in the sendObject() method
at the same time, because the entire method will execute more quickly.
The core of the problem is the fact that no synchronization occurs in
your sendObject() method, or in any of the methods called by it. If you
have two threads (say ThreadA and ThreadB) it is entirely possible for
ThreadA to enter the sendObject() method, grab the output stream, send a
little bit of data, and then be blocked by the OS. Next ThreadB enters,
acquires the output stream and sends some data of its own. You
essentially have two threads writing to the same stream which is bound
to confuse whatever is on the other end of the connection.
Since this problem seems to have been solved, you should revisit
Marshall's suggestion that you *not* recreate the ObjectOutputStream
every time you call sendObject(). You really only need to make it once,
and it can exist as long as the Socket connection is alive.
Jim S.
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
> "Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
> news:Misc-56C07B.1...@ca.news.verio.net...
> >
> > > In article <wmZK7.38727$RG1.18...@news1.rdc1.sfba.home.com>,
> > > "Marshall Spight" <msp...@dnai.com> wrote:
> >
> > > > One thing that could cause your problem (in fact, I'd bet this is
> > > > it) is if anything, anywhere, ever, on the server side, writes any
> > > > bytes to your server socket's output stream that get read by
> > > > your ReadNextObject method.
> >
> > Ok, I don't understand this statement. Of course the server writes to
> > the socket objects that are intended to be read by ReadNextObject().
> > I've been looking at this code all day, and I don't see the "if
> > anything
> > ever writes to a stream something that later gets read" part. What am
> > I missing?
> Perhaps I left a word out. :-(
>
> If anything *else* writes to the socket. That is, if you write *any*
> bytes to the socket using anything other than your sendObject method.
Ah, never, never, never -- that's what SendObject() is all about. (See
other tangent re: occasional importance of data-hiding ;)
That's also, btw, why ReadObject() is protected. RO() puts the data
into a queue, and outside folks ask for GetNextObject(), which returns
the top thing on the queue (or null, if there aren't any).
PeekNextObject() does the same thing, but doesn't remove the item from
the queue.
Once I get this sucker debugged, I'll put it up on a web page. It's a
useful class (when it works! ;)
(Someone else probably already did this -- but you know the routine: but
my wheel is ROUNDER than his wheel! <G>)
Miss Elaine Eos
"Marshall Spight" <msp...@dnai.com> wrote:
> Oh my god, do you mean you have different threads calling
> readNextObject() on the same socket? Dingdingdingdingdingding.
> Danger Will Robinson!
To clarify this point:
ReadNextObject() is protected -- nothing calls it except the
BaseTCP_IOthread's run() routine, which is, in short
public void run() {
while (running) {
ReadNextObject();
}
}
However, any thread that wants to can call SendObject() to send outbound
communications. SendObject() has since been synch-ed, although I have
another post (new thread) where I ask about how to properly sync things
so they don't hang each other up.
> I'm gonna change my vote to be in favor of threading being
> the problem. Can I still do that? Am I in under the deadline?
Just in the nick of time ;)
> public void ReadNextObject()
> {
> synchronized(socket)
> {
> objIn = new ObjectInputStream (socket.getInputStream());
> Object thisObject = objIn.readObject();
> }
> AddObjectToQueue (thisObject);
> // Notify parent-thread that something came in.
> }
>
>
> public void SendObject()
> {
> synchronized(socket)
> {
> objOut = new ObjectOutputStream (socket.getOutputStream());
> objOut.writeObject (theObject);
> objOut.flush();
> }
> }
See my new thread (StreamCorruptedException-s part 2) -- the problem is
that objIn.readOject() blocks the thread util there is input. Without
input, you can't call SendObject(), because you'll sit around waiting
for a synch-ed socket which is blocked by a thread waiting for output.
Bleck.
(Please answer this issue in the other thread. Thanks.)
Miss Elaine Eos
> Miss Elaine Eos wrote:
>
> > Aha!
> >
> > A big thank you to Jim Scully -- I put a sync around SendObject() and
> > my
> > problems seem to have gone away. This makes sense, as 2 different
> > server-threads call send-object, potentially (although, MAN!, is that
> > obscure!) at the same time.
> >
> > Then again, I thought I had it solved with shrinking my packet size --
> > I'm going to re-grow it, then I'll let you know it a couple of days if
> > it "stays fixed."
> Making the packets smaller was treating the symptom. The smaller size
> makes it less likely that two threads will be in the sendObject() method
> at the same time, because the entire method will execute more quickly.
>
> The core of the problem is the fact that no synchronization occurs in
> your sendObject() method, or in any of the methods called by it. If you
> have two threads (say ThreadA and ThreadB) it is entirely possible for
> ThreadA to enter the sendObject() method, grab the output stream, send a
> little bit of data, and then be blocked by the OS. Next ThreadB enters,
> acquires the output stream and sends some data of its own. You
> essentially have two threads writing to the same stream which is bound
> to confuse whatever is on the other end of the connection.
Now fixed -- new SendObject() has a synched socket (I really should just
synch the whole rountine -- it shouldn't take THAT long to execute.)
Many fewer corruption errors, but still a few. I'm working on that.
What's your thought on 1 in/out stream vs a new one for each object?
> Since this problem seems to have been solved, you should revisit
> Marshall's suggestion that you *not* recreate the ObjectOutputStream
> every time you call sendObject(). You really only need to make it once,
> and it can exist as long as the Socket connection is alive.
Ah, yes. Well, ok then! ;)
Marshall Spight
> In article <_NFL7.41813$RG1.21...@news1.rdc1.sfba.home.com>,
> "Marshall Spight" <msp...@dnai.com> wrote:
>
> > I'm gonna change my vote to be in favor of threading being
> > the problem. Can I still do that? Am I in under the deadline?
>
> Just in the nick of time ;)
Whew!
Marshall
JavaJosh
> On 23 Nov 2001 14:29:00 GMT, Thomas Weidenfeller wrote:
>
>>Miss Elaine Eos <Misc@*NO-SPAM*PlayNaked.com> writes:
>>
>>>Misc., who'd like to shoot the person who invented
>>>open-bracket-at-the-end-of-the-line as a style ;)
>>>
>>This is 1TBS (The "One True Brace Style"). You have to shoot the
>>inventors of the C language: Kernighan and Ritchie. You will not
>>make much friends by doing so :-)
>>
>
> Have a look at the eighth commandment:
>
> http://www.lysator.liu.se/c/ten-commandments.html
>
> (applies just as well to Java as to C)
>
> /gordon
>
>
That is a great link Gordon, thanks. Verily would I like to confirm
understanding of this sacred notice that this
if (stmt)
{
stmt;
}
shall instead be inscribed as this
if (stmt) {
stmt;
}
I have tried both ways, alas, and have found the former to be more
useful, as the eye matches the braces so much easier. However, I
completely understand the call for consistency.
Josh Rehman
Gordon Beaton
> That is a great link Gordon, thanks. Verily would I like to confirm
> understanding of this sacred notice that this
>
> if (stmt)
> {
> stmt;
> }
>
> shall instead be inscribed as this
>
> if (stmt) {
> stmt;
> }
>
> I have tried both ways, alas, and have found the former to be more
> useful, as the eye matches the braces so much easier. However, I
> completely understand the call for consistency.
The style that you find easier to read, identify code structure with
etc, will always be the one that you are most used to, so I think that
there is no "absolute" here at all.
Personally I find the second easier to read. I find the additional
space between the header and the body of the block to be distracting,
since I use space to group things that belong together and separate
things that don't.
/gordon
--
[ do not send me private copies of your followups ]
g o r d o n . b e a t o n @ e r i c s s o n . c o m
Marshall Spight
> On Sun, 25 Nov 2001 21:50:52 GMT, JavaJosh wrote:
> >
> > I have tried both ways, alas, and have found the former to be more
> > useful, as the eye matches the braces so much easier. However, I
> > completely understand the call for consistency.
>
> The style that you find easier to read, identify code structure with
> etc, will always be the one that you are most used to, so I think that
> there is no "absolute" here at all.
It is true that the style one is accustomed to will be the style
one finds easiest, but that does not mean each style is
as good as the next.
I think there is an absolute here. It seems to me that one could
*measure* the comprehensibility of different brace styles,
using subjects that prefer various different styles.
Anyone care to comment?
Marshall
Dale King
news:WlAL7.41620$RG1.21...@news1.rdc1.sfba.home.com...
Actually neither one of those is actually Hungarian naming convention. They
have been incorrectly. The lpzs stuff is the awful convention known as
type-based naming that Micro$oft used and claimed was Hungarian. The other
is what I would call scope-based naming.
Joe Ottinger had a great page that explained this, but I think his pages are
now defunct, so let me see if I can explain the difference:
Consider if you had two variables, one for the height of the screen and one
for background color and both were unsigned longs. In type-base naming you
would name them something like ulScreenHeight and ulBackgroundColor. Let's
say you had a statement where you incorrectly triet to assign one to the
other:
ulScreenHeight = ulBackgroundColor;
They both have the same prefix so, they're compatible, right? No, the prefix
is just causing you to do work the compiler is supposed to do for you.
In true Hungarian, the prefix is based off what the variable means, not its
programming language type. So you might have variables like hgtScreen and
clrBackground. Then a statement like the following is obviously wrong,
because you are mixing a height with a color.
hgtScreen = clrBackground;
> PS. Prefixes are evil.
Type-based naming is certainly evil. Scope-based naming is pretty bad.
Hungarian is not recommended, but evil is going a bit too far.
--
Dale King
Dale King
news:uGT+O+50FDZW0e...@4ax.com...
> Miss Elaine Eos wrote:
>
> [...]
>
> Small note - you can drop both public and final from those constants:
>
> >public interface kM
> >{
> > int serverPort = 1232;
> ...
>
> will do. I would also recommend following the conventions and make it
> SERVER_PORT instead of serverPort etc. Identifying constants will be
> much easier for anyone studying the code.
Which brings up my long standing question, why do you need to identify
constants? What will you do with the knowledge that something is a constant
that justifies making it harder to read the name (all caps is harder to read
than mixed case).
This of course, begins with the question what is a constant? Sun never
defined it in their conventions and do not seem to have any consistent
definition for when it is applied.
--
Dale King
Marco Schmidt
>Which brings up my long standing question, why do you need to identify
>constants? What will you do with the knowledge that something is a constant
>that justifies making it harder to read the name (all caps is harder to read
>than mixed case).
Knowing that something cannot be modified should make it easier to
understand the purpose of a piece of code. If you read the source code
for a method and you find ten variables there unknown to you, it'll
probably be of some help to know which ones will not change. Of course
the extent of the improvement in readability and understanding of
semantics very much depends on the nature of the code.
Just as it helps that method calls always have parentheses after the
method's name, even if it has no arguments (that's not the case in
Pascal, as an example, so you don't know directly whether a := key;
calls a method key or simply reads the content of a variable key; in
this particular case, decent naming conventions - getKey for the
method - would help a lot). It may not be a big improvement, but it
doesn't hurt either.
I also don't think that the all caps version is that hard to read, but
that's very subjective. Maybe I'm using relatively few constants...
>This of course, begins with the question what is a constant? Sun never
>defined it in their conventions and do not seem to have any consistent
>definition for when it is applied.
With object references it's hard to tell (even if a reference is
final, a call to some method may modify the content). However, I
mostly define primitives as final, so that the problem does not arise
(often).
F'up2 comp.lang.java.programmer
Regards,
Marco
--
Please reply in the newsgroup, not by email!
Java programming tips (updated 2001-11-03):
http://jiu.sourceforge.net/javatips.html
Erki Suurjaak
> Type-based naming is certainly evil. Scope-based naming is pretty bad.
> Hungarian is not recommended, but evil is going a bit too far.
I wonder if any Hungarians have ever protested against this
specific use of the name of their language :)
Erki
Matt Francomb
[...]
>
> Just as it helps that method calls always have parentheses after the
> method's name, even if it has no arguments (that's not the case in
> Pascal, as an example, so you don't know directly whether a := key;
> calls a method key or simply reads the content of a variable key; in
> this particular case, decent naming conventions - getKey for the
> method - would help a lot). It may not be a big improvement, but it
> doesn't hurt either.
I don't agree (in the general case, rather than in the case of Java in
particular) that it's even useful to know whether a thing is a
variable or a function, except possibly in the case where someone else
might have written the function and it has side-effects that you need
to care about as well as producing a useful result. But that's just
bad code (I'm not talking about something that would be a procedure
(void function) except that it returns a status value).
Eiffel, too, hides the distinction as far as possible, to the extent
that you can override something that is a no-arguments function in one
class to be a member variable in a subclass. You don't need to know
how a function is implemented to call it, so logically, you don't need
to know that in a particular class it's implemented as a variable (or
even a constant, of course). There's certainly no good reason to have
a syntactical difference.
You can't assign to members of another class, so there's no argument
for making them private and providing accessor functions. This
wouldn't hold in Java.
--
Matt Francomb
Dale King
The point I have been making for a long time. The study would have to
measure speed of comprehension as well since most people can eventually sort
out either format, but most will probably be slower at the hidden brace
style.
Someone once said there was such a study by NASA or the military I believe,
but I could never found it. They claimed that the braces on a new line won
out. I could not get any independent confirmation of such a study.
--
Dale King
Dale King
> Dale King wrote:
>
> >Which brings up my long standing question, why do you need to identify
> >constants? What will you do with the knowledge that something is a
constant
> >that justifies making it harder to read the name (all caps is harder to
read
> >than mixed case).
>
> Knowing that something cannot be modified should make it easier to
> understand the purpose of a piece of code. If you read the source code
> for a method and you find ten variables there unknown to you, it'll
> probably be of some help to know which ones will not change. Of course
> the extent of the improvement in readability and understanding of
> semantics very much depends on the nature of the code.
Sorry, I should have anticipated this usual incorrect response. That
explanation does not work since the all caps convention is never applied to
final instance variables. So in other words, nice try, but I don't buy that
explanation.
> Just as it helps that method calls always have parentheses after the
> method's name, even if it has no arguments (that's not the case in
> Pascal, as an example, so you don't know directly whether a := key;
> calls a method key or simply reads the content of a variable key; in
> this particular case, decent naming conventions - getKey for the
> method - would help a lot). It may not be a big improvement, but it
> doesn't hurt either.
I don't disagree with this, but it has nothing to do with the question.
> I also don't think that the all caps version is that hard to read, but
> that's very subjective. Maybe I'm using relatively few constants...
IT IS EASILY PROVABLE THAT TEXT WRITTEN LIKE THIS IS MUCH HARDER TO READ
than text that is written like this.You read all caps text more slowly than
mixed case.
> >This of course, begins with the question what is a constant? Sun never
> >defined it in their conventions and do not seem to have any consistent
> >definition for when it is applied.
>
> With object references it's hard to tell (even if a reference is
> final, a call to some method may modify the content). However, I
> mostly define primitives as final, so that the problem does not arise
> (often).
The convention that Sun in general seems to apply is that static final
primitives and strings that are initialized at compile time with constants
are considered constants and the convention is applied. There are
exceptions, but I am willing to accept that these are mistakes and do not
change the rule.
One possible reasoning with primitive int is that these kind of variables
can be used as case labels, but that doesn't work for floating point or
strings, so I do not accept that as an explanation. Another possible reason
for the convention is that these static final variables can be inlined by
the compiler. But why do you need to know that.
My best explanation is that no one really thought about it. They just
continued their convention from C without actually evaluating whether it
made sense. It made sense to have a convention for #define symbols in C, but
the same reasoning does not carry over to Java.
--
Dale King
Marshall Spight
> "Marshall Spight" <msp...@dnai.com> wrote in message
> news:bQxM7.48974$RG1.25...@news1.rdc1.sfba.home.com...
> > "Gordon Beaton" <n...@for.email> wrote in message
> news:9tsui0$nkp$1...@news.du.uab.ericsson.se...
> > > On Sun, 25 Nov 2001 21:50:52 GMT, JavaJosh wrote:
> > > >
> > > > I have tried both ways, alas, and have found the former to be more
> > > > useful, as the eye matches the braces so much easier. However, I
> > > > completely understand the call for consistency.
> > >
> > > The style that you find easier to read, identify code structure with
> > > etc, will always be the one that you are most used to, so I think that
> > > there is no "absolute" here at all.
> >
> > It is true that the style one is accustomed to will be the style
> > one finds easiest, but that does not mean each style is
> > as good as the next.
> >
> > I think there is an absolute here. It seems to me that one could
> > *measure* the comprehensibility of different brace styles,
> > using subjects that prefer various different styles.
> >
> > Anyone care to comment?
>
> The point I have been making for a long time. The study would have to
> measure speed of comprehension as well since most people can eventually sort
> out either format, but most will probably be slower at the hidden brace
> style.
That's exactly what I was thinking: measure speed and accuracy.
I'm envisioning a set of code snippets, maybe whole methods, widely
varying in length. The test would be simple: do the braces nest
properly or not? 50% would, 50% wouldn't.
At the start of the test, it'd ask a few things, like age, sex, years
programming, monitor size and resolution, and which
brace style you prefer. We could see if there were any
interesting correlations.
> Someone once said there was such a study by NASA or the military I believe,
> but I could never found it. They claimed that the braces on a new line won
> out. I could not get any independent confirmation of such a study.
I haven't heard about that particular study, but I have gone searching
for studies, and haven't come up with anything. It's surprising to me
that this information isn't more available. It seems an easy enough
study to do.
Crap. I have a psych degree. I did some limited studies like this when
I was at Berkeley. Maybe I should do it myself.
Marshall "Promises the Moon, Delivers Pizza" Spight
Marshall Spight
> continued their convention from C without actually evaluating whether it
> made sense. It made sense to have a convention for #define symbols in C, but
> the same reasoning does not carry over to Java.
I've gotta believe you have come up with the explanation here.
Marshall
Marshall Spight
>
> I also don't think that the all caps version is that hard to read, but
> that's very subjective. Maybe I'm using relatively few constants...
Whether all caps is hard to read or not is not subjective. An esthetic
sensibility that dictates a preference for using all caps in a given
situation or not *is* subjective, but reading accuracy can be objectively
measure.
Marshall
Dale King
That's an easier test than the proposed test for brace comprehension. I
think it is easy to prove to yourself. Take 2 pages of text that you haven't
read. Display one in all caps and time how long it takes you to read it
versus the one in normal case. Frankly, I would quit with a headache before
finishing readinf the all caps text. I am quite certain the vast majority of
people will be faster at reading text in normal case as that is what they
are used to reading.
--
Dale King
Marshall Spight
Absolutely.
Actually, I can vaguely remember reading some fairly extensive
results on this kind of study long years ago, the conclusion
being that all caps was really quite hard to read.
Marshall
Marco Schmidt
>Sorry, I should have anticipated this usual incorrect response. That
>explanation does not work since the all caps convention is never applied to
>final instance variables. So in other words, nice try, but I don't buy that
>explanation.
I'm not sure if we are talking about the same thing. Where / by whom
is the all caps convention not applied to final instance variables? I
use it, and Sun does, e.g. in Integer.MAX_VALUE (int => primitive
type) and String.CASE_INSENSITIVE_ORDER (Comparator => non-primitive
type).
>I don't disagree with this, but it has nothing to do with the question.
Sure it has. It was supposed to emphasize that the little things -
like all caps for constants or parentheses after the name of a method
in a method call - sometimes help in understanding code. If many of
those little things add up, readability should be improved noticeably.
>IT IS EASILY PROVABLE THAT TEXT WRITTEN LIKE THIS IS MUCH HARDER TO READ
>than text that is written like this.You read all caps text more slowly than
>mixed case.
Very true in your example, but we're not talking about an article or a
novel, in the code that I write (or studied), constants do not appear
very often, and they mostly have short names, like MAX_WIDTH or
DEFAULT_PORT. In typical code, they are surrounded by a lot more
"normal" code. They are supposed to stand out from the rest of the
code. It's added information, just like syntax highlighting - you know
that if / else / while are reserved words, but having them stand out
as bold or differently-colored is nice. Not necessary, but helpful.
[...]
>My best explanation is that no one really thought about it. They just
>continued their convention from C without actually evaluating whether it
>made sense. It made sense to have a convention for #define symbols in C, but
>the same reasoning does not carry over to Java.
I'm still not really sure what the problem is. I like being able to
identify constants quickly, you obviously don't. But I fail to see why
the all caps convention does not make sense. I consider this personal
taste, just as I personally don't like opening braces at the end of a
line, like this:
if (a == 12) {
...
Marshall Spight
> Dale King wrote:
>
> >Sorry, I should have anticipated this usual incorrect response. That
> >explanation does not work since the all caps convention is never applied to
> >final instance variables. So in other words, nice try, but I don't buy that
> >explanation.
>
> I'm not sure if we are talking about the same thing. Where / by whom
> is the all caps convention not applied to final instance variables? I
> use it, and Sun does, e.g. in Integer.MAX_VALUE (int => primitive
> type) and String.CASE_INSENSITIVE_ORDER (Comparator => non-primitive
> type).
Those are final static fields, not final instance fields. The point Dale
was making is that final instance fields and final static fields have
the same attribute (unmodifiability) referenced in the argument
about making them all upper case, but do not have the same convention.
I'm with Dale on this one, and I've generally stopped using all
caps for static final fields, in part because of his arguments.
> I'm still not really sure what the problem is. I like being able to
> identify constants quickly, you obviously don't. But I fail to see why
> the all caps convention does not make sense. I consider this personal
> taste ...
I think it's fine to consider it a taste issue.
Marshall
Dale King
> Dale King wrote:
>
> >I don't disagree with this, but it has nothing to do with the question.
>
> Sure it has. It was supposed to emphasize that the little things -
> like all caps for constants or parentheses after the name of a method
> in a method call - sometimes help in understanding code. If many of
> those little things add up, readability should be improved noticeably.
And once again how does this apply to the question of all caps for
constants. All caps for constants decreases readability because all caps is
harder to read. If there were some reason for identifying constants that
offset this loss in readability it would be one thing. But after years of
searching I still have yet to find any reason to specially signal out
"constants" (it still isn't defined what a constant is) in Java.
> >IT IS EASILY PROVABLE THAT TEXT WRITTEN LIKE THIS IS MUCH HARDER TO READ
> >than text that is written like this.You read all caps text more slowly
than
> >mixed case.
>
> Very true in your example, but we're not talking about an article or a
> novel, in the code that I write (or studied), constants do not appear
> very often, and they mostly have short names, like MAX_WIDTH or
> DEFAULT_PORT. In typical code, they are surrounded by a lot more
> "normal" code.
All you have said is that the decrease in readability is very small and I
agree, but as you said these little things add up. In other words you have
argued the magnitude, not the direction of change in readability.
> They are supposed to stand out from the rest of the
> code. It's added information, just like syntax highlighting - you know
> that if / else / while are reserved words, but having them stand out
> as bold or differently-colored is nice. Not necessary, but helpful.
Why should they stand out? What information does it add? How is that
helpful? I could come up with all kinds of conventions to make things stand
out, but if they serve no purpose they do not enhance readability. For
instance what if I had a convention that I apply to all variables I create
on Mondays to make them stand out? What value is there in knowing the
variable was created on a Monday? None. What value is there in knowing
something is a "constant"? As far as I can tell, none.
The other thing I have not addressed is similar to arguments against
type-based (what M$ falsely calls Hungarian) or scope-based naming. The fact
is that things change. What if something that is now a constant becomes not
a constant in the future. Currently it is a compile time constant, but
perhaps in the future I load its value from a properties file. Its purpose
hasn't changed. But in order to stick to your convention you have to change
all code that uses it. You may not even be able to do that as customers may
write code against your interface. Note that the same cannot be said about
the other naming conventions for class vs. package vs. method. You can't
change something from one to the other tranparently.
> >My best explanation is that no one really thought about it. They just
> >continued their convention from C without actually evaluating whether it
> >made sense. It made sense to have a convention for #define symbols in C,
but
> >the same reasoning does not carry over to Java.
>
> I'm still not really sure what the problem is. I like being able to
> identify constants quickly, you obviously don't. But I fail to see why
> the all caps convention does not make sense. I consider this personal
> taste, just as I personally don't like opening braces at the end of a
> line, like this:
>
> if (a == 12) {
> ...
Fine, then it should be left as a matter of style, not mandated on high as a
coding convention. I'm not the one trying to mandate what you do, I just
want to know why others want to mandate what I do, particularly when as far
as I can tell it decreases readability.
--
Dale King
Miss Elaine Eos
wrote:
> Someone once said there was such a study by NASA or the military I
> believe,
> but I could never found it. They claimed that the braces on a new line
> won
> out. I could not get any independent confirmation of such a study.
Probably someone who worked at Nasa -- as in "yeah, we did a study (you
know, I asked 3 friends) and my way was best."
The things that pass for "science" to some people...!
Dale King
> In article <3c03...@news.tce.com>, "Dale King" <dale...@home.com>
> wrote:
>
> > Someone once said there was such a study by NASA or the military I
> > believe,
> > but I could never found it. They claimed that the braces on a new line
> > won
> > out. I could not get any independent confirmation of such a study.
>
> Probably someone who worked at Nasa -- as in "yeah, we did a study (you
> know, I asked 3 friends) and my way was best."
>
> The things that pass for "science" to some people...!
No it was supposedly a bona fide study and the results published. I cannot
verify that however as I never found it.
--
Dale King
Grant Wagner
Don't know about any survey, but I was able to find:
http://fsw.gsfc.nasa.gov/library/code_standards_c.pdf
Check section 3.3 Indentation and Visual Standards, item (8).
There is a disclaimer: "For this reason, this standard does not mandate a
particular style; programmers are free to continue using their own style.
However, the standard does give detailed style recommendations (using “should”
instead of “shall”), for programmers who wish to conform to a common style."
--
| Grant Wagner <gwa...@agricoreunited.com>
Dale King
news:3C152CAF...@agricoreunited.com...
> Dale King wrote:
>
> > "Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message
> > news:Misc-AE37A1.0...@ca.news.verio.net...
> > > In article <3c03...@news.tce.com>, "Dale King" <dale...@home.com>
> > > wrote:
> > >
> > > > Someone once said there was such a study by NASA or the military I
> > > > believe,
> > > > but I could never found it. They claimed that the braces on a new
line
> > > > won
> > > > out. I could not get any independent confirmation of such a study.
> > >
> > > Probably someone who worked at Nasa -- as in "yeah, we did a study
(you
> > > know, I asked 3 friends) and my way was best."
> > >
> > > The things that pass for "science" to some people...!
> >
> > No it was supposedly a bona fide study and the results published. I
cannot
> > verify that however as I never found it.
> > --
> > Dale King
>
> Don't know about any survey, but I was able to find:
> http://fsw.gsfc.nasa.gov/library/code_standards_c.pdf
>
> Check section 3.3 Indentation and Visual Standards, item (8).
But that is not objective evidence. That is just a command to do it one way
without any evidence of why that way is better. It is no different than
Sun's guideline to do it the other way. The idea of an objective study would
be to show that for the majority of programmers one way is superior to the
other, despite their individual preferences.
--
Dale King
Chris Smith
> Don't know about any survey, but I was able to find:
> http://fsw.gsfc.nasa.gov/library/code_standards_c.pdf
>
> Check section 3.3 Indentation and Visual Standards, item (8).
>
> There is a disclaimer: "For this reason, this standard does not mandate a
> particular style; programmers are free to continue using their own style.
> However, the standard does give detailed style recommendations (using “should”
> instead of “shall”), for programmers who wish to conform to a common style."
I don't have internet access right now, so maybe there's more in the
document... but NASA's published guidelines probably have little to do
with the existence of studies in favor of one or another brace style.
They are a large enough organization that I doubt many people in NASA
even know if Dale's remembered study ever happened. Large organizations
and communication don't mix.
Chris Smith
Raymond DeCampo
>
> Miss Elaine Eos <Misc@*NO-SPAM*PlayNaked.com> writes:
> > Misc., who'd like to shoot the person who invented
> > open-bracket-at-the-end-of-the-line as a style ;)
>
> This is 1TBS (The "One True Brace Style"). You have to shoot the
> inventors of the C language: Kernighan and Ritchie. You will not make
> much friends by doing so :-)
>
I'm convinced that that brace structure was not invented to promote
understanding and readability of code but to minimize the number of
lines the code uses. I can think of a few reasons this was desirable:
1. It made the book shorter.
2. Screen space was at a premium.
3. Employers that paid by the line insisted on it.
Mind you, I have absolutely no evidence of this whatsoever. Note that
of the three, only 1. remains a concern.
Ray
Raymond DeCampo
>
> "Miss Elaine Eos" <Misc@*NO-SPAM*PlayNaked.com> wrote in message news:Misc-17D489.1...@ca.news.verio.net...
> > Here's another use:
> >
> > Functions/methods where you want to return more than one value.
>
> I've never seen a case where a method that supposedly needed to return
> multiple values couldn't be refactored into several methods that each
> returned one value, and were clearer and easier to understand.
>
I can think of several real examples. Suppose you were writing a
mathematical parser like Maple. Now you want to implement polynomial
long division. The result should be a quotient polynomial and a
remainder polynomial. The algorithm calculates both of them at the same
time. Now, would you really have two methods like this:
public class Polynomial
{
public Polynomial divideAndGetQuotient(Polynomial divisor)
{
// code here
}
public Polynomial divideAndGetRemainder(Polynomial divisor)
{
// code here
}
}
which requires that the result be computed twice or somehow stored
indefinitely in the class on the chance that the other method is called
or would you do this:
public class Polynomial
{
public PolynomialDivisionResult divide(Polynomial divisor)
{
// code here
}
}
public class PolynomialDivisionResult
{
private Polynomial quotient;
private Polynomial remainder;
public PolynomialDivisionResult(Polynomial quotient, Polynomial
remainder)
{
this.quotient = quotient;
this.remainder = remainder;
}
public Polynomial getQuotient()
{
return quotient;
}
public Polynomial getRemainder()
{
return remainder;
}
}
Ray
Babu Kalakrishnan
I'd probably do something like :
public Polynomial[] PolynomialDivisionResult(Polynomial Divisor)
{
//calculate quotient and remainder
Polynomial[] result = new Polynomial[2];
result[0]=quotient;
result[1]=remainder;
return result;
}
BK
Chris Smith
> I'd probably do something like :
>
> public Polynomial[] PolynomialDivisionResult(Polynomial Divisor)
> {
> //calculate quotient and remainder
> Polynomial[] result = new Polynomial[2];
> result[0]=quotient;
> result[1]=remainder;
> return result;
> }
That breaks what I consider to be a very important idea in interface
design. Structured data should not be stored in non-structured types. I
prefer the DivisionResult solution.
Chris Smith
Raymond DeCampo
I'd have to agree. That's not a very OO solution at all.
Ray
Paul Murray
news:3C2390DC...@twcny.rr.com...
> I'm convinced that that brace structure was not invented to promote
> understanding and readability of code but to minimize the number of
> lines the code uses.
Or the number of keystrokes. It's nice to have such a clear visual
distinction between block delimiters and identifiers. Block delimiters are
the "punctuation" of a chunk of code, so why not use a punctuation charater?
__________________________________________________
Spot the difference!
Jer 48:10 A curse on him who is lax in doing the Lord's work! A curse on him
who keeps his sword from bloodshed!
Mk 16:16 He that believeth and is baptized shall be saved; but he that
believeth not shall be damned.
Quran 2 And kill them wherever you find them, ... if they do fight you, then
slay them; such is the recompense of the unbelievers.
http://www.users.bigpond.com/pmurray .