BlueJ Coding Help

Discussion in 'Java' started by Marcelo Rodriguez, Aug 31, 2013.

  1. 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");
    }
     
    Marcelo Rodriguez, Aug 31, 2013
    #1
    1. Advertisements

  2. 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.
    If you don't want double line breaks, either remove the \n or replace
    the pirntln method with print.
     
    Jukka Lahtinen, Aug 31, 2013
    #2
    1. Advertisements

  3. Marcelo Rodriguez

    Stefan Ram Guest

    the system's line separator
    "\n" might not be the system's line separator.
     
    Stefan Ram, Aug 31, 2013
    #3
  4. Marcelo Rodriguez

    Eric Sosman Guest

    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.
     
    Eric Sosman, Aug 31, 2013
    #4
  5. 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.
     
    Jukka Lahtinen, Aug 31, 2013
    #5
  6. Marcelo Rodriguez

    Stefan Ram Guest

    "\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.
     
    Stefan Ram, Aug 31, 2013
    #6
  7. Macintoshes, pre-OS X if I'm not mistaken, used \r (carriage return) as
    the line separator.
     
    Daniele Futtorovic, Sep 1, 2013
    #7
  8. 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?
     
    Jukka Lahtinen, Sep 1, 2013
    #8
  9. 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.
     
    Daniele Futtorovic, Sep 1, 2013
    #9
  10. Marcelo Rodriguez

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Sep 1, 2013
    #10
  11. 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. :)
     
    Daniele Futtorovic, Sep 2, 2013
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.