Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23381 > unrolled thread

Inserting Multiple Lines from Console

Back to article view | Back to comp.lang.java.programmer

Contents

  Inserting Multiple Lines from Console subhabangalore@gmail.com - 2013-04-08 06:59 -0700
    Re: Inserting Multiple Lines from Console Joerg Meier <joergmmeier@arcor.de> - 2013-04-08 17:04 +0200
      Re: Inserting Multiple Lines from Console Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-08 14:10 -0700
        Re: Inserting Multiple Lines from Console Lew <lewbloch@gmail.com> - 2013-04-08 15:10 -0700
          Re: Inserting Multiple Lines from Console x@x.com (znôrt) - 2013-04-09 01:08 +0200
            Re: Inserting Multiple Lines from Console Lew <lewbloch@gmail.com> - 2013-04-08 17:59 -0700
              Re: Inserting Multiple Lines from Console x@x.com (znôrt) - 2013-04-09 08:46 +0200
              Re: Inserting Multiple Lines from Console Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-09 05:39 -0300
                Re: Inserting Multiple Lines from Console Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-09 23:04 +0000
                Re: Inserting Multiple Lines from Console x@x.com (znôrt) - 2013-04-10 19:45 +0200
                  Re: Inserting Multiple Lines from Console Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-10 14:43 -0400
                    Re: Inserting Multiple Lines from Console Gene Wirchenko <genew@telus.net> - 2013-04-11 11:11 -0700
                      Re: Inserting Multiple Lines from Console Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-11 15:05 -0400
    Re: Inserting Multiple Lines from Console lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-08 16:21 +0100
    Re: Inserting Multiple Lines from Console markspace <markspace@nospam.nospam> - 2013-04-08 09:56 -0700
    Re: Inserting Multiple Lines from Console lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-09 08:28 +0100

#23381 — Inserting Multiple Lines from Console

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. 

[toc] | [next] | [standalone]

#23383

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

> subhabangalore@gmail.com 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.

[toc] | [prev] | [next] | [standalone]

#23387

On 4/8/13 8:04 AM, Joerg Meier wrote:
> On 8 Apr 2013 14:06:21 GMT, Stefan Ram wrote:
>
>> subhabangalore@gmail.com 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.

[toc] | [prev] | [next] | [standalone]

#23390

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

[toc] | [prev] | [next] | [standalone]

#23393

Lew <lewbloch@gmail.com> 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!

[toc] | [prev] | [next] | [standalone]

#23394

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.

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 simple type names.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#23395

Lew <lewbloch@gmail.com> 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. 

[toc] | [prev] | [next] | [standalone]

#23397

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

[toc] | [prev] | [next] | [standalone]

#23398

On Tue, 09 Apr 2013 05:39:49 -0300, Arved Sandstrom wrote:

> 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.
>
Can't agree more. If you're modifying a program, use the style it was 
written in unless its an impossible one.

I've seen some gross violations of this rule: a maintenance coder (who I 
never met) called Ken Eagle had changed: if he needed extra variables he 
invariably used KEN[0-9] for numeric variables and EAGLE[0-9] for 
alphanumeric variables.

It was [ahem] character-forming to maintain programs that Ken Eagle had 
made changes to.

I've not seen a Java program that has been mutilated in this fashion yet, 
but there nothing to stop this sort of idiocy being applied to Java code. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#23410

Arved Sandstrom <asandstrom2@eastlink.ca> 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.

[toc] | [prev] | [next] | [standalone]

#23413

On 4/10/2013 1:45 PM, znôrt wrote:
> Arved Sandstrom <asandstrom2@eastlink.ca> 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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23422

On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> 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

[toc] | [prev] | [next] | [standalone]

#23423

On 4/11/2013 2:11 PM, Gene Wirchenko wrote:
> On Wed, 10 Apr 2013 14:43:39 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> 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_%28programming_language%29

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23384

On 08/04/13 14:59, subhabangalore@gmail.com wrote:
> 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.

It *sounds* like what you are looking for is something like the C scanf 
function, there is an oldish component here http://www.braju.com/beta/
but you may be able to find newer and better ones on the www
Alternatively java.util.Scanner might do it for you or you could write 
your own implemention of scanf for Java using StringTokenizer

lipska


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#23385

On 4/8/2013 6:59 AM, subhabangalore@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#23396

On 08/04/13 15:06, Stefan Ram wrote:
> subhabangalore@gmail.com 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(); }}

This is surreal, if you run this code, the output is ... well 
interesting to say the least. Not sure how it meets the OP requirements 
but in fairness I'm not sure what the OP requirements are in the fist 
place so who's to say it's not 'correct'

Incidentally if you strip all the unnecessary garbage from the code and 
introduce some sanity to the formating it does make it slightly easier 
to read.

Very strange, is it mushroom season where you are?

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web