Inserting Multiple Lines from Console

Discussion in 'Java' started by subhabangalore@gmail.com, Apr 8, 2013.

  1. Guest

    Dear Group,

    I was trying to get input of different nature of string, int etc.

    To insert multiple lines I can do sort of standard coding like,

    public class BRReadLines {
    public static void main(String args[]) throws IOException
    {
    // Create a BufferedReader using System.in
    BufferedReader br = new BufferedReader(new
    InputStreamReader(System.in));
    String str;
    System.out.println("Enter lines of text.");
    System.out.println("Enter 'end' to quit.");
    do {
    str = br.readLine();
    System.out.println(str);
    } while(!str.equals("end"));
    }
    }

    I may assign string and int also. But I was looking to assign different variable names like,
    String str;
    int In;
    .....
    and read from console.

    Initially I did
    str=br.readLine()
    and
    In=br.read()

    but did not help much,
    then I am trying like,

    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    BufferedReader br1 = new BufferedReader(new InputStreamReader(System.in));

    str=br.readLine();
    In=br1.read();

    It is generally going okay but when the output is being generated I am getting arbitrary output.

    If anyone can kindly suggest how may I improve it?

    Regards,
    Subhabrata.
    , Apr 8, 2013
    #1
    1. Advertising

  2. Stefan Ram Guest

    writes:
    >If anyone can kindly suggest how may I improve it?


    public class Main
    {
    public void quit(){ java.lang.System.exit( 0 ); }

    public void main() throws java.lang.Throwable
    { final javax.script.ScriptEngine scriptEngine
    = new javax.script.ScriptEngineManager().getEngineByName( "JavaScript" );
    scriptEngine.put( "main", this );
    final java.lang.StringBuilder text = new java.lang.StringBuilder();
    scriptEngine.put( "text", text );
    scriptEngine.eval( "print('');" ); // loads engine for faster reaction
    java.lang.System.out.printf
    ( "*** Texteditor 2000, V1.0 ***%n%n %d Bytes Free%n%n Enter%n%ntext." +
    "append('example');%n%n or other StringBuilder calls in JavaScript " +
    "syntax to edit,%n%n or enter%n%nmain.quit();%n%n to quit.%n%n",
    java.lang.Runtime.getRuntime().freeMemory() );
    while( true )try
    { java.lang.System.out.printf( "%n> ", text );
    java.lang.System.out.println
    ( scriptEngine.eval( System.console().readLine() ));
    java.lang.System.out.printf( "%s%n", text ); }
    catch( final java.lang.Throwable throwable )
    { java.lang.System.err.println( throwable ); }}

    public static void main( final java.lang.String[] args )
    throws java.lang.Throwable { new Main().main(); }}
    Stefan Ram, Apr 8, 2013
    #2
    1. Advertising

  3. Joerg Meier Guest

    On 8 Apr 2013 14:06:21 GMT, Stefan Ram wrote:

    > writes:
    >>If anyone can kindly suggest how may I improve it?

    > public void quit(){ java.lang.System.exit( 0 ); }


    Aside from the horrible, horrible JavaScript advice that I honestly pray
    you posted as a joke, why are you qualifying java.lang things ?

    Liebe Gruesse,
    Joerg

    --
    Ich lese meine Emails nicht, replies to Email bleiben also leider
    ungelesen.
    Joerg Meier, Apr 8, 2013
    #3
  4. markspace Guest

    On 4/8/2013 6:59 AM, wrote:

    > I was trying to get input of different nature of string, int etc.


    > It is generally going okay but when the output is being generated I
    > am getting arbitrary output.


    I think first your main problem is trying to define the problem. You
    need to define what "nature" you want to read in what circumstances.
    Nobody just reads lines and turns them into strings or ints on a whim.

    If you need some definition because your just doing this on your own,
    consider writing a simple parser for algebraic input. Parsers are
    common in computer science, so they're good to know about, look it up.

    The next step is to define some test cases. Here's some lines you
    should be able to read in and parser correctly. Note that I'm assuming
    you'll do this "algebraically" and that * and / get evaluated before +
    and -.

    1 + 1
    -10
    1243 + 678 * 5
    1 / 3
    45 - 34 + 12 - 90 + 78 * 3 / 2
    markspace, Apr 8, 2013
    #4
  5. Daniel Pitts Guest

    On 4/8/13 8:04 AM, Joerg Meier wrote:
    > On 8 Apr 2013 14:06:21 GMT, Stefan Ram wrote:
    >
    >> writes:
    >>> If anyone can kindly suggest how may I improve it?

    >> public void quit(){ java.lang.System.exit( 0 ); }

    >
    > Aside from the horrible, horrible JavaScript advice that I honestly pray
    > you posted as a joke, why are you qualifying java.lang things ?

    The fully qualifying of classes, as well as the strange indentation, is
    typical of Stefan. I usually ignore his code snippets, but do try to
    comprehend his non-code.
    Daniel Pitts, Apr 8, 2013
    #5
  6. Lew Guest

    Daniel Pitts wrote:
    > Joerg Meier wrote:
    >> Stefan Ram wrote:
    >>> subhabangalore@... writes:
    >>>> If anyone can kindly suggest how may I improve it?

    >
    >>> public void quit(){ java.lang.System.exit( 0 ); }

    >
    >> Aside from the horrible, horrible JavaScript advice that I honestly pray


    Yes, that is the really strange thing there.

    >> you posted as a joke, why are you qualifying java.lang things ?


    He's pretty aggressive about refusing to comply with community standards.

    > The fully qualifying of classes, as well as the strange indentation, is
    > typical of Stefan. I usually ignore his code snippets, but do try to
    > comprehend his non-code.


    In this case it's a bizarre answer.

    The suggestion to use Scanner or a string tokenizer was better.

    --
    Lew
    Lew, Apr 8, 2013
    #6
  7. znôrt Guest

    Lew <> writes:

    > In this case it's a bizarre answer.


    i found it amusing, and quite brilliant.

    > The suggestion to use Scanner or a string tokenizer was better.


    instead of pointing to some basic building blocks with which to build a
    rudimentary parser, he presented a working solution using a complete
    parser already available to java. i would definitely hire this guy! xD

    and his code style isn't that bad. anyway if your eyes start to bleed
    just paste into eclipse and hit ctrl-shift-f!
    znôrt, Apr 9, 2013
    #7
  8. Lew Guest

    znôrt wrote:
    > Lew writes:
    >> In this case it's a bizarre answer.

    >
    > i [sic] found it amusing, and quite brilliant.


    This is a Java newsgroup, and the OP clearly was trying to learn Java.

    >> The suggestion to use Scanner or a string tokenizer was better.

    >
    > instead of pointing to some basic building blocks with which to build a
    > rudimentary parser, he presented a working solution using a complete
    > parser already available to java [sic]. i [sic] would definitely hire this guy! xD


    Not appropriate for the question, though.

    > and his code style isn't that bad. anyway if your eyes start to bleed
    > just paste into eclipse [sic] and hit ctrl-shift-f!


    You don't work in a professional programming environment with source control and
    code reviews, do you?

    Formatting changes introduce more to review and get wrong. They are frownedupon.

    Everywhere I've worked has insisted on a house style before checkin is permitted.

    Also, I program on a Mac a lot of the time, so Ctrl-Shift-F doesn't work, and when at
    home I usually use NetBeans, which has a different key chord.

    Not everyone uses Eclipse or NetBeans, either.

    Stefan is notable for his attitude about conventional formatting and simpletype names.

    --
    Lew
    Lew, Apr 9, 2013
    #8
  9. znôrt Guest

    Lew <> writes:

    >> he presented a working solution using a complete

    > Not appropriate for the question, though.


    he did show some functionality that java has out of the box, and how to
    use it in a smart and effective way.

    > You don't work in a professional programming environment with source
    > control and code reviews, do you?


    i do. hell i do! and standups and retrospectives and breakfasts and
    coding dojos and checkstyles and freaking sonar pedantic warnings are my
    everyday's cross to bear. and let's not forget common criteria! that's
    why i can appreciate some fresh air sometimes. and some bizarre-ness for
    a change, why not :)

    > Formatting changes introduce more to review and get wrong. They are
    > frowned upon.


    indeed. i didn't suggest raping any house rules either.

    > Everywhere I've worked has insisted on a house style before checkin is
    > permitted.


    i have to assume you wouldn't work in a shop run by stefan xDDD

    > This is a Java newsgroup, and the OP clearly was trying to learn Java.


    you have a point there. and it's nice that someone pointed out that
    stefan's contribution is unconventional, but then there is still some
    value to it i wouldn't dismiss just because it is unconventional or is
    something ... well, that would be most probably frowned upon in a
    conventional sw engineering dept.
    znôrt, Apr 9, 2013
    #9
  10. On 04/08/2013 09:59 PM, Lew wrote:
    > znôrt wrote:
    >> Lew writes:
    >>> In this case it's a bizarre answer.

    >>
    >> i [sic] found it amusing, and quite brilliant.

    >
    > This is a Java newsgroup, and the OP clearly was trying to learn Java.
    >
    >>> The suggestion to use Scanner or a string tokenizer was better.

    >>
    >> instead of pointing to some basic building blocks with which to build a
    >> rudimentary parser, he presented a working solution using a complete
    >> parser already available to java [sic]. i [sic] would definitely hire this guy! xD

    >
    > Not appropriate for the question, though.
    >
    >> and his code style isn't that bad. anyway if your eyes start to bleed
    >> just paste into eclipse [sic] and hit ctrl-shift-f!

    >
    > You don't work in a professional programming environment with source control and
    > code reviews, do you?
    >
    > Formatting changes introduce more to review and get wrong. They are frowned upon.


    The problem there sounds more like unclear ownership of source code. The
    move away from formal checkout-checkin in source control systems
    (although oddly enough not in many other systems, like CMS or ECM)
    doesn't mean that there shouldn't be _informal_ checkout-checkin, i.e.
    at any given time only certain individuals should have "ownership" of a
    file, optimally one person per file per branch.

    If this informal policy is observed, formatting changes accompany real
    changes, and sometimes the formatting changes *are* the real changes.
    Basically this kind of "known ownership" goes a long way to eliminate
    dabbling, including casual formatting tweaks.

    > Everywhere I've worked has insisted on a house style before checkin is permitted.


    I've worked in places that had a "house style" and enforced it, places
    that said they had one but didn't enforce it, and on projects that
    didn't have one at all. I've found that the need for a house style
    diminishes if coders know not to dabble and nitpick, they know only to
    do a format if it's an intentional _refactoring_ of sorts to improve
    maintainability, and the individual styles of people are good (IOW, good
    coders).

    To the latter point, I have no problem working with another programmer's
    style if it's clear and makes sense. If I have been called upon to make
    minor mods, I adopt the style.

    > Also, I program on a Mac a lot of the time, so Ctrl-Shift-F doesn't work, and when at
    > home I usually use NetBeans, which has a different key chord.
    >
    > Not everyone uses Eclipse or NetBeans, either.
    >
    > Stefan is notable for his attitude about conventional formatting and simple type names.
    >

    AHS
    Arved Sandstrom, Apr 9, 2013
    #10
  11. znôrt Guest

    Arved Sandstrom <> writes:

    >> Formatting changes introduce more to review and get wrong. They are
    >> frowned upon.

    >
    > The problem there sounds more like unclear ownership


    if there is a problem at all with formatting you can use a centralized
    mandatory style configuration shared by all developers, and automatic
    formatting on save. voilà.

    of course this only applies to "professional programming environment
    with source control and code reviews" (which is the current context),
    where you have control over the tools.

    once you do that you never bother again on formatting or styling issues,
    not for a second, and bytheway realize that poor code quality has
    absolutely nothing to do with formatting or style at all.
    znôrt, Apr 10, 2013
    #11
  12. Eric Sosman Guest

    On 4/10/2013 1:45 PM, znôrt wrote:
    > Arved Sandstrom <> writes:
    >
    >>> Formatting changes introduce more to review and get wrong. They are
    >>> frowned upon.

    >>
    >> The problem there sounds more like unclear ownership

    >
    > if there is a problem at all with formatting you can use a centralized
    > mandatory style configuration shared by all developers, and automatic
    > formatting on save. voilà.
    >
    > of course this only applies to "professional programming environment
    > with source control and code reviews" (which is the current context),
    > where you have control over the tools.
    >
    > once you do that you never bother again on formatting or styling issues,
    > not for a second, and bytheway realize that poor code quality has
    > absolutely nothing to do with formatting or style at all.


    Why do so many programming languages -- including Java --
    allow the programmer the freedom to use arbitrary amounts of
    white space between tokens? Perhaps it's to give petty tyrants
    something to obsess about: As long as they're busy insisting on
    their own rigidly-defined white space allocation rules, they'll
    perhaps lack the energy to do something more troublesome.

    Meanwhile, mechanically allocated white space is occasionally
    a bad thing. Case in point: I recently wrote a bit of code to
    solve a small system of linear equations using Cramer's Rule. You
    may recall that this involves calculating matrix determinants --
    that's one reason it's not especially good for large equation sets,
    but this one was only three-by-four. So I wrote myself a method
    of nine arguments, and called it like this:

    double d = determ(sumXX, sumXY, sumX,
    sumXY, sumYY, sumY,
    sumX, sumY, n );

    double a = determ(sumXC, sumXY, sumX,
    sumYC, sumYY, sumY,
    sumC, sumY, n ) / d;

    double b = determ(sumXX, sumXC, sumX,
    sumXY, sumYC, sumY,
    sumX, sumC, n ) / d;

    double c = determ(sumXX, sumXY, sumXC,
    sumXY, sumYY, sumYC,
    sumX, sumY, sumC ) / d;

    See the nice, neat three-by-three matrices? See how the column
    of right-hand sides (the ...C terms) marches neatly across the
    tableau? See Cramer's Rule exactly as your high-school algebra
    textbook pictured it?

    Along came the ever-helpful mechanical formatter:

    double d = determ(sumXX, sumXY, sumX,
    sumXY, sumYY, sumY,
    sumX, sumY, N);

    double a = determ(sumXC, sumXY, sumX,
    sumYC, sumYY, sumY,
    sumC, sumY, N) / d;

    double b = determ(sumXX, sumXC, sumX,
    sumXY, sumYC, sumY,
    sumX, sumC, N) / d;

    double c = determ(sumXX, sumXY, sumXC,
    sumXY, sumYY, sumYC,
    sumX, sumY, sumC) / d;

    See the matrices? They're still there, if you sort of tilt your
    head to the side and squint a little; it may help if you're slightly
    astigmatic. See the right-hand sides in their systematic little
    dance? Not I, not with all the head-tilting my vertebrae can manage.
    Somebody's insistence on his own notions of formatting (as embodied
    in the mechanical formatter) transformed my code from crystal-clear
    to opaque and ugly.

    Perhaps I should just be thankful it left the line breaks
    in place. It doesn't always, you know! About a month ago I used
    this well-known pattern:

    Quotation quo = new Quotation.Builder()
    .setDate(elt.getAttribute(DATE))
    .setPrice(elt.getAttribute(PRICE))
    .setSize(elt.getAttribute(SIZE))
    .setSource(elt.getAttribute(SOURCE))
    .build();

    .... which the friendly formatter turned into:

    Quotation quo = new
    Quotation.Builder().setDate(elt.getAttribute(DATE)).setPrice(elt.getAttribute(PRICE)).setSize(elt.getAttribute(SIZE)).setSource(elt.getAttribute(SOURCE)).build();

    .... after which the check-in system dinged me for line length.

    --
    Eric Sosman
    d
    Eric Sosman, Apr 10, 2013
    #12
  13. On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman
    <> wrote:

    [snip]

    >See the matrices? They're still there, if you sort of tilt your
    >head to the side and squint a little; it may help if you're slightly
    >astigmatic. See the right-hand sides in their systematic little
    >dance? Not I, not with all the head-tilting my vertebrae can manage.
    >Somebody's insistence on his own notions of formatting (as embodied
    >in the mechanical formatter) transformed my code from crystal-clear
    >to opaque and ugly.


    Of course, it can go the other way around, too. Sometimes,
    formatters do help clean up code. One reason that I have avoided
    using code formatters though is because sometimes, aesthetics is
    important. Your code is an example of this. Another would be a
    function/method call with some parameters that are important. How
    would you split (typed all on one line):


    retval=functionname(importantparm1,importantparm2,option1,option2,option3,option4,option5);

    I would probably use
    retval=functionname(importantparm1,importantparm2,
    option1,option2,option3,option4,option5);
    or
    retval=functionname(

    importantparm1,importantparm2,option1,option2,option3,option4,option5);
    It is extremely unlikely that I would use
    retval=functionname(importantparm1,importantparm2,option1,option2,
    option3,option4,option5);
    but how do I specify what the aesthetics are?

    > Perhaps I should just be thankful it left the line breaks
    >in place. It doesn't always, you know! About a month ago I used
    >this well-known pattern:
    >
    > Quotation quo = new Quotation.Builder()
    > .setDate(elt.getAttribute(DATE))
    > .setPrice(elt.getAttribute(PRICE))
    > .setSize(elt.getAttribute(SIZE))
    > .setSource(elt.getAttribute(SOURCE))
    > .build();
    >
    >... which the friendly formatter turned into:
    >
    > Quotation quo = new
    >Quotation.Builder().setDate(elt.getAttribute(DATE)).setPrice(elt.getAttribute(PRICE)).setSize(elt.getAttribute(SIZE)).setSource(elt.getAttribute(SOURCE)).build();
    >
    >... after which the check-in system dinged me for line length.


    Are you coming? We got you.
    Are you going? We got you.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Apr 11, 2013
    #13
  14. Eric Sosman Guest

    On 4/11/2013 2:11 PM, Gene Wirchenko wrote:
    > On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman
    > <> wrote:
    >
    > [snip]
    >
    >> See the matrices? They're still there, if you sort of tilt your
    >> head to the side and squint a little; it may help if you're slightly
    >> astigmatic. See the right-hand sides in their systematic little
    >> dance? Not I, not with all the head-tilting my vertebrae can manage.
    >> Somebody's insistence on his own notions of formatting (as embodied
    >> in the mechanical formatter) transformed my code from crystal-clear
    >> to opaque and ugly.

    >
    > Of course, it can go the other way around, too. Sometimes,
    > formatters do help clean up code. [...]


    That, I think, should be their main purpose and use case.
    Refactor a bunch of deeply-nested code into a method of its
    own, and a mechanical reformatter is a great convenience in
    re-adjusting the nesting levels. Throw a loop or an if() around
    something, ditto. And, of course, every so often you encounter
    some wretched piece of code where twenty different programmers
    have used thirty different styles -- the mechanical cleaner-
    upper can be as helpful as forty maids with forty mops.

    But I truly think casual use of reformatters is a bad idea.
    Some folks require them at check-in ("Unless thy code pass
    unchanged through the reformatter, Lo! I say unto thee that it
    shall not enter the Kingdom of Checkin"), and some apply them
    routinely at check-out ("Nobody should care what the code in the
    repository looks like, because everyone reformats it to his own
    style when working on it anyhow"). Both practices, it seems to
    me, are capable of destroying or at least obscuring information.[*]

    [*] For an extreme example of code that would be damaged by
    mechanical reformatters, note that Whitespace code embedded in
    Java code (perhaps for steganographic purposes) would be quite
    unlikely to survive Java-oriented reformatting. :)
    http://en.wikipedia.org/wiki/Whitespace_(programming_language)

    --
    Eric Sosman
    d
    Eric Sosman, Apr 11, 2013
    #14
  15. Stefan Ram Guest

    Eric Sosman <> writes:
    > double d = determ(sumXX, sumXY, sumX,
    > sumXY, sumYY, sumY,
    > sumX, sumY, n );
    > Along came the ever-helpful mechanical formatter:
    > double d = determ(sumXX, sumXY, sumX,
    > sumXY, sumYY, sumY,
    > sumX, sumY, N);


    That is a rather half-hearted reformatter! A real
    reformatter should be able to strip the information
    about the line breaks, too, giving something like

    double d = determ(sumXX, sumXY, sumX, sumXY, sumYY, sumY, sumX,
    sumY, N);

    . Especially for this purpose I used a special reformatter,
    called »Jacobe«, that one could call with a maximum line
    width of »1« to obtain an output with one token per line!
    Next, I passed it through the Eclipse formatter to get what
    many people declared to prefer. It was thus stripped of all
    formatting information of the original source to the maximum
    extend possible.

    Sadly, Jacobe was not updated for Java 1.7, so I had to
    refrain from using it.

    A thorough reformatter should parse the source into an AST
    and then build a new source from that AST. (The line breaks
    are not part of the AST.)
    Stefan Ram, Apr 11, 2013
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roy Schestowitz

    Inserting Lines into HTML Header

    Roy Schestowitz, Jun 12, 2005, in forum: HTML
    Replies:
    10
    Views:
    992
    Andy Dingley
    Jun 13, 2005
  2. Ben Finney
    Replies:
    2
    Views:
    986
    Egor Bolonev
    Jun 30, 2003
  3. Replies:
    7
    Views:
    176
    Ben Morrow
    Jun 7, 2006
  4. PG

    inserting lines

    PG, Sep 20, 2006, in forum: Perl Misc
    Replies:
    13
    Views:
    204
    David Oswald
    Oct 3, 2006
  5. Cah Sableng
    Replies:
    0
    Views:
    236
    Cah Sableng
    Apr 23, 2007
Loading...

Share This Page