BlueJ Coding Help

[Marcelo Rodriguez]

I started my first day with Computer Science (Learning Java with BlueJ) and I'm not quite sure how to explain this, so here's what I am trying to end up with (the part in the middle of the dashes):

----------------------------------------
From: Bill Smith
Address: Dell Computer, Bldg 13
Date: April 12, 2005

To: Jack Jones

Message: Help! I'm trapped inside a computer!

-----------------------------------------

The order of the code that I am typing is
------------------------------------

//Author: Me
//Date created: Mar 22, 2005
public class Tester
{
public static void main(String args[])
{
System.out.println("From: Bill Smith\n");
}

 

[Jukka Lahtinen]

System.out.println("From: Bill Smith\n");

That way you'll end up with double line breaks between linies.
The method System.out.println always adds a linefeed at the end of the
output, and you add one yourself with the \n.

I am not quite sure if this is the correct format to start with or where
exactly the "\n" goes or if I need it at all or if I need the "ln" after
"print".

If you don't want double line breaks, either remove the \n or replace
the pirntln method with print.

 

[Stefan Ram]

The method System.out.println always adds a linefeed

the system's line separator

at the end of the
output, and you add one yourself with the \n.

"\n" might not be the system's line separator.

 

[Eric Sosman]

the system's line separator


"\n" might not be the system's line separator.

Is it just me, or are others also peeved that PrintStream
always ends lines with the system's line separator? IMHO, the
separator should be choosable on a stream-by-stream basis, so
(for example) one could easily write through a PrintStream to
a socket protocol requiring \r\n no matter what the local
system uses.

Ah, well. The horse and barn have been nonproximate for
a long time now.

 

[Jukka Lahtinen]

the system's line separator

"\n" might not be the system's line separator.

True, but is there a system where it doesn't cause a linefeed?
For example, in the MS systems where the normal line separator is \r\n,
a lone \n moves the cursor to the next line. And when the println method
ends the output with \r\n, the cursor ends up at the beginning of the
next line after that. It doesn't really matter that there was no
carriage return before the first linefeed.

 

[Stefan Ram]

True, but is there a system where it doesn't cause a linefeed?

"\n" is an expression.

Expression do not cause anything.

An expression can be evaluated.

The evaluation of an expression might have an effect.

But the evaluation of "\n" does not have any effect. For example,
it is well possible that no visible effect whatsoever occurs
when executing the statement

if( "\n".equals( s ))return;

. Moreover - just considering English and not Java -
a linefeed cannot be »caused« because a linefeed is not an
event. What might be caused is the /output/ of a linefeed.

For example, one does not usually say: »Will this cause a
car?« or »She has caused a book.«, but one might say: »Will
this cause an accident?« or »She has caused many to fall.«
A car or a book is not an event, but an accident or the act
of falling is.

 

[Daniele Futtorovic]

True, but is there a system where it doesn't cause a linefeed?
For example, in the MS systems where the normal line separator is \r\n,
a lone \n moves the cursor to the next line. And when the println method
ends the output with \r\n, the cursor ends up at the beginning of the
next line after that. It doesn't really matter that there was no
carriage return before the first linefeed.

Macintoshes, pre-OS X if I'm not mistaken, used \r (carriage return) as
the line separator.

 

[Jukka Lahtinen]

Macintoshes, pre-OS X if I'm not mistaken, used \r (carriage return) as
the line separator.

I thought they use LF and CR (in that order, opposite to the DOS world),
not only the CR. I never used them myself, don't they do anything with
just a LF that doesn't come with CR?

 

[Daniele Futtorovic]

I thought they use LF and CR (in that order, opposite to the DOS world),
not only the CR. I never used them myself, don't they do anything with
just a LF that doesn't come with CR?

No, just the carriage return.

I do not know what they would have done with a line feed, sorry. For my
practical purposes, MacOS has always been ancient history (as opposed to
OSX, which uses LF).

They just use the carriage return. It's one of those things you just
pick up. Because whenever the geeks ramble, like old cow-boys around the
fire, multiple parallel soliloquies, and one of them ever-so-slightly
implicitly associates the EOL sequence with a LF character, you'll
invariably have one of the thither silent ones jump up and interject:
"Tut tut tut, LF might /not be/ the line separator", in an ominous tone.
And then the one who made the association falls silent, for he knows he
has sinned; and then all the greenhorns perk up, ravished by this new
mysterious development; and they press the old hands with questions, to
pierce the mystery. A satisfied smile settles on the faces of the old
hands, and after a little pressing (etiquette obliges), they will go
into lively discussions about ye olden days (discussions which might
actually, but not necessarily, address the mystery at hand)... which I'd
personally love to do, 'cause it's fun and it's knowledge, but can't, so
I'm just giving you the meta.

 

[Arne Vajhøj]

No, just the carriage return.

I do not know what they would have done with a line feed, sorry. For my
practical purposes, MacOS has always been ancient history (as opposed to
OSX, which uses LF).

They just use the carriage return. It's one of those things you just
pick up. Because whenever the geeks ramble, like old cow-boys around the
fire, multiple parallel soliloquies, and one of them ever-so-slightly
implicitly associates the EOL sequence with a LF character, you'll
invariably have one of the thither silent ones jump up and interject:
"Tut tut tut, LF might /not be/ the line separator", in an ominous tone.
And then the one who made the association falls silent, for he knows he
has sinned; and then all the greenhorns perk up, ravished by this new
mysterious development; and they press the old hands with questions, to
pierce the mystery. A satisfied smile settles on the faces of the old
hands, and after a little pressing (etiquette obliges), they will go
into lively discussions about ye olden days (discussions which might
actually, but not necessarily, address the mystery at hand)... which I'd
personally love to do, 'cause it's fun and it's knowledge, but can't, so
I'm just giving you the meta.

I think that description is rather accurate.

But I still think that it is relevant to bring it up.

There are certain things about portability that developers
should learn at some point.

LF terminated, CRLF terminated, CR terminated, count prefix,
count prefix & suffix variable length line formats.

Little and big endian.

IEEE floating point and other floating point formats.

Unicode, UTF-8, UTF-16, ISO-8859-1, ASCII, EBCDIC for text.

Etc.

Arne

 

[Daniele Futtorovic]

I think that description is rather accurate.

But I still think that it is relevant to bring it up.

There are certain things about portability that developers
should learn at some point.

LF terminated, CRLF terminated, CR terminated, count prefix,
count prefix & suffix variable length line formats.

Little and big endian.

IEEE floating point and other floating point formats.

Unicode, UTF-8, UTF-16, ISO-8859-1, ASCII, EBCDIC for text.

Etc.

In case it wasn't clear from the above: wholeheartedly agreed, and I
love those discussions, and was just frustrated by my inability to do it
myself.