hi

Discussion in 'Java' started by kavithadayalanvit@gmail.com, Jan 31, 2007.

  1. Guest

    i want to search a particular word in the file using java.
    can u give any specific link for this

    regards
    kavitha
     
    , Jan 31, 2007
    #1
    1. Advertising

  2. <> wrote in message
    news:...
    >i want to search a particular word in the file using java.
    > can u give any specific link for this
    >
    > regards
    > kavitha
    >


    Read the file

    Check the input for the word

    If the word is found then display something

    Repeat.

    . . . .

    Maybe it would be better if you showed us what you had tried, specifically
    what is not working and we can work from there.

    --
    LTP

    :)
     
    Luc The Perverse, Jan 31, 2007
    #2
    1. Advertising

  3. Guest

    Hi kavitha,
    u can try out the following code , it allows wild cards ,but is case
    sensitive.Please tell me if u need that too??
    import java.io.BufferedReader;
    import java.io.FileNotFoundException;
    import java.io.FileReader;
    import java.io.IOException;
    import java.util.regex.Matcher;
    import java.util.regex.Pattern;

    public class RnD {

    public static void main(String[] args) {
    Pattern pattern = Pattern.compile("SAXELBY");
    BufferedReader reader = null;
    try {
    int lineNumber=0;
    reader =
    new BufferedReader(
    new FileReader("C:\\00000001.txt"));
    while (true) {
    lineNumber++;
    String curline = reader.readLine();
    if (curline == null) {
    break;
    }
    Matcher matcher = pattern.matcher(curline);
    while (matcher.find()) {
    System.out.println("at "+lineNumber+" "+
    matcher.group()
    + " start="
    + matcher.start()
    + " end= "
    + matcher.end());
    }
    }

    } catch (FileNotFoundException e) {
    e.printStackTrace();
    } catch (IOException e) {
    e.printStackTrace();
    } finally {
    if (reader != null) {
    try {
    reader.close();
    } catch (IOException e1) {
    e1.printStackTrace();
    }
    }
    }

    }
    }

    thanks
    lab
     
    , Jan 31, 2007
    #3
  4. Lew Guest

    wrote:
    > Hi kavitha,
    > u can try out the following code , it allows wild cards ,but is case
    > sensitive.Please tell me if u need that too??


    The word is "you", not "u".

    The trouble with doing someone's homework for them is that you deprive them of
    an education. That's a big waste of their tuition.

    > import java.io.BufferedReader;
    > import java.io.FileNotFoundException;
    > import java.io.FileReader;
    > import java.io.IOException;
    > import java.util.regex.Matcher;
    > import java.util.regex.Pattern;
    >
    > public class RnD {
    >
    > public static void main(String[] args) {


    Please do not embed TABs in Usenet posts.

    > Pattern pattern = Pattern.compile("SAXELBY");


    What is this regex? How did you come up with it? There was no indication in
    the OP for this.

    > BufferedReader reader = null;
    > try {
    > int lineNumber=0;
    > reader =
    > new BufferedReader(
    > new FileReader("C:\\00000001.txt"));


    Hard-coded strings. Tsk, tsk. Where did you come up with it? There was no
    indication in the OP for this.

    > while (true) {


    To depend on exceptions as flow control is a bad practice.

    > lineNumber++;
    > String curline = reader.readLine();
    > if (curline == null) {
    > break;
    > }
    > Matcher matcher = pattern.matcher(curline);
    > while (matcher.find()) {
    > System.out.println("at "+lineNumber+" "+
    > matcher.group()
    > + " start="
    > + matcher.start()
    > + " end= "
    > + matcher.end());
    > }
    > }
    >
    > } catch (FileNotFoundException e) {
    > e.printStackTrace();


    Ooh, you ignore the exception and move on. This is good for examples, bad in
    practice.

    This is also a good place to introduce logging statements.

    > } catch (IOException e) {
    > e.printStackTrace();
    > } finally {
    > if (reader != null) {
    > try {
    > reader.close();
    > } catch (IOException e1) {
    > e1.printStackTrace();


    Those darn TABs.

    > }
    > }
    > }
    >
    > }
    > }


    - Lew
     
    Lew, Jan 31, 2007
    #4
  5. Oliver Wong Guest

    Oliver Wong, Jan 31, 2007
    #5
  6. Java needs "goto" (was Re: hi)

    On Wed, 31 Jan 2007 04:55:35 -0800, Lew <> wrote:
    > wrote:

    [sNip]
    >> while (true) {

    >
    > To depend on exceptions as flow control is a bad practice.

    [sNip]

    This typically occurs because the reserved word "goto" isn't
    implemented. There are situations where "goto" would be very useful, such
    as:

    0. An alternative to "break label" since label is currently limited in
    where it can be located (such code could be easier to read)

    1. The ability to share code between methods within a class, which all
    end with the same functionality (this could be more efficient than calling
    another method; javac would need to generate errors such as attempts to
    access variables that belong to different methods, return type mismatches,
    etc.)

    I do agree with your view that infinite loops that depend on exceptions
    are a bad practice. Using conditionals to trigger a "break" would also be
    better handled by making that the focus of the loop -- and if they need to
    compare afterwards, then "do { ... } while (condition);" can certainly
    solve that problem.

    --
    Randolf Richardson -
    The Lumber Cartel, local 42 (Canadian branch)
    http://www.lumbercartel.ca/
     
    Randolf Richardson, Feb 2, 2007
    #6
  7. Guest

    On Jan 31, 5:11 pm, ""
    <> wrote:
    > Hi kavitha,
    > u can try out the following code , it allows wild cards ,but is case
    > sensitive.Please tell me if u need that too??
    > import java.io.BufferedReader;
    > import java.io.FileNotFoundException;
    > import java.io.FileReader;
    > import java.io.IOException;
    > import java.util.regex.Matcher;
    > import java.util.regex.Pattern;
    >
    > public class RnD {
    >
    > public static void main(String[] args) {
    > Pattern pattern = Pattern.compile("SAXELBY");
    > BufferedReader reader = null;
    > try {
    > int lineNumber=0;
    > reader =
    > new BufferedReader(
    > new FileReader("C:\\00000001.txt"));
    > while (true) {
    > lineNumber++;
    > String curline = reader.readLine();
    > if (curline == null) {
    > break;
    > }
    > Matcher matcher = pattern.matcher(curline);
    > while (matcher.find()) {
    > System.out.println("at "+lineNumber+" "+
    > matcher.group()
    > + " start="
    > + matcher.start()
    > + " end= "
    > + matcher.end());
    > }
    > }
    >
    > } catch (FileNotFoundException e) {
    > e.printStackTrace();
    > } catch (IOException e) {
    > e.printStackTrace();
    > } finally {
    > if (reader != null) {
    > try {
    > reader.close();
    > } catch (IOException e1) {
    > e1.printStackTrace();
    > }
    > }
    > }
    >
    > }
    >
    > }
    >
    > thanks
    > lab


    hi

    thanks for ur reply. it will also be helpful if u sent the coding
    which u have asked me .

    waiting for ur reply

    regards
    D.kavitha
     
    , Feb 2, 2007
    #7
  8. On Wed, 31 Jan 2007 07:55:35 -0500, Lew wrote:
    > wrote:
    >> while (true) {

    >
    > To depend on exceptions as flow control is a bad practice.


    That may be, but he hasn't done so in this case. The loop condition
    here is (curline != null), even though the test doesn't occur until a
    few lines further down.

    BTW exceptions *are* a form of flow control, whether you like them or
    not.

    /gordon

    --
    [ don't email me support questions or followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Feb 2, 2007
    #8
  9. Gordon Beaton schrieb:
    > On Wed, 31 Jan 2007 07:55:35 -0500, Lew wrote:
    >> wrote:
    >>> while (true) {

    >> To depend on exceptions as flow control is a bad practice.

    >

    ....
    >
    > BTW exceptions *are* a form of flow control, whether you like them or
    > not.


    That may be but he didn't tell us if they are or are not a form of
    control flow.

    To my understanding the key was not to *depend* on exceptions as flow
    control or IOW not to (mis)use the exceptional flow to control the main
    flow which is right although not always possible.

    Bye
    Michael
     
    Michael Rauscher, Feb 2, 2007
    #9
  10. Lew Guest

    wrote:
    > thanks for ur reply. it will also be helpful if u sent the coding
    > which u have asked me .


    Juat a word of friendly advice: Your posts will seem much more professional,
    and you will be in better practice for workplace communication, if you make a
    habit of using more (not completely) formal written English, in particular if
    you avoid so-called "l33t-speak" or "txt-English", comprising abbreviations
    like "u" for "you", informal or missing punctuation and capitalization, etc.

    The trouble is that the use of the abbreviated idiom conveys an impression of
    unprofessionalism and a low skill set. This may be the view of yourself that
    you wish to convey, but I fail to see how that can help you.

    You will impress more, and likely get more expert responses, if you take the
    care and trouble to follow conventional English syntax and orthography
    (barring the odd misplet word - this forum isn't completely formal).

    Just a suggestion designed to help you.

    - Lew
     
    Lew, Feb 2, 2007
    #10
  11. Re: Java needs "goto" (was Re: hi)

    "Randolf Richardson" <> writes:

    > 1. The ability to share code between methods within a class,
    > which all end with the same functionality (this could be more
    > efficient than calling another method; javac would need to generate
    > errors such as attempts to access variables that belong to different
    > methods, return type mismatches, etc.)


    That's headache-inducing and makes the code far less readable (thus it
    runs counter to your item 0). Why do you think the MINISCULE overhead
    in a local method call is worth the MAJOR hassle of having to look in
    so many places to follow the flow of a method? Not to mention that you
    still would only be able to goto code that completes with a return,
    and the label's method would need to have the same return type and
    with a compatible throws clause, and the class file spec would need to
    add a global label table...

    Refactor the shared code into a private final method and trust the
    runtime to inline the code as necessary. Or wait for closures to be
    implemented.
     
    Tor Iver Wilhelmsen, Feb 3, 2007
    #11
  12. Re: Java needs "goto" (was Re: hi)

    Randolf Richardson wrote:
    > This typically occurs because the reserved word "goto" isn't
    > implemented. There are situations where "goto" would be very useful,
    > such as:
    >

    I totally disagree. Assemblers need "goto" but no decent HLL does. That
    goes for COBOL too and before you ask, yes I've written GOTO-less COBOL.
    I have never used goto (or needed it) in C and see no need for it in Java.

    > 0. An alternative to "break label" since label is currently
    > limited in where it can be located (such code could be easier to read)
    >

    I don't use this construction in C either and, again, don't need it.

    > 1. The ability to share code between methods within a class,
    > which all end with the same functionality (this could be more efficient
    > than calling another method; javac would need to generate errors such as
    > attempts to access variables that belong to different methods, return
    > type mismatches, etc.)
    >

    Encapsulating the code in a private method makes for more readable code
    as well as eliminating code duplication.

    > I do agree with your view that infinite loops that depend on
    > exceptions are a bad practice. Using conditionals to trigger a "break"
    > would also be better handled by making that the focus of the loop -- and
    > if they need to compare afterwards, then "do { ... } while (condition);"
    > can certainly solve that problem.
    >

    Yes - but that's a result of classes that throw exceptions when their
    methods would be better off returning control values. IMO if you have to
    use exceptions to control normal logic flow in code that calls the class
    methods merely demonstrates bad class design.

    I never design classes/methods that force their user to control normal
    logic flow with exceptions: I use methods that return control
    information (e.g hasNextObject() to control loops). Similarly, my
    constructors never throw exceptions: code that may signal errors with
    exceptions is pulled out of the constructor and encapsulated as a
    separate method. This is because try...catch blocks that include class
    instance declarations screw up otherwise clean block structures by
    preventing me from grouping all object instance declarations at the
    start of a block rather than sprinkling them through the code.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Feb 3, 2007
    #12
  13. On 02.02.2007 16:14, Lew wrote:

    > Just a suggestion designed to help you.


    Adding to that: a meaningful subject also often helps. :)

    Cheers

    robert
     
    Robert Klemme, Feb 3, 2007
    #13
  14. Alex Hunsley Guest

    Re: Java needs "goto" (was Re: hi)

    Randolf Richardson wrote:
    > On Wed, 31 Jan 2007 04:55:35 -0800, Lew <> wrote:
    >> wrote:

    > [sNip]
    >>> while (true) {

    >>
    >> To depend on exceptions as flow control is a bad practice.

    > [sNip]
    >
    > This typically occurs because the reserved word "goto" isn't
    > implemented. There are situations where "goto" would be very useful,
    > such as:
    >
    > 0. An alternative to "break label" since label is currently
    > limited in where it can be located (such code could be easier to read)
    >
    > 1. The ability to share code between methods within a class,
    > which all end with the same functionality (this could be more efficient
    > than calling another method; javac would need to generate errors such as
    > attempts to access variables that belong to different methods, return
    > type mismatches, etc.)


    I disagree, I think goto was dumped for very good reasons, and
    structured programming (i.e. no gotos; use methods and refactoring
    techniques instead) makes a lot more sense.

    >
    > I do agree with your view that infinite loops that depend on
    > exceptions are a bad practice. Using conditionals to trigger a "break"
    > would also be better handled by making that the focus of the loop -- and
    > if they need to compare afterwards, then "do { ... } while (condition);"
    > can certainly solve that problem.
    >
    > --Randolf Richardson -
    > The Lumber Cartel, local 42 (Canadian branch)
    > http://www.lumbercartel.ca/
     
    Alex Hunsley, Feb 3, 2007
    #14
  15. Re: Java needs "goto" (was Re: hi)

    On 03.02.2007 13:22, Martin Gregorie wrote:
    > Randolf Richardson wrote:


    Completely agree, Martin. "Goto" is quite nonsense - it's not needed
    from a theoretical as well as from a practical point of view.

    >> 1. The ability to share code between methods within a class,
    >> which all end with the same functionality (this could be more
    >> efficient than calling another method; javac would need to generate
    >> errors such as attempts to access variables that belong to different
    >> methods, return type mismatches, etc.)
    >>

    > Encapsulating the code in a private method makes for more readable code
    > as well as eliminating code duplication.


    Plus, with modern JVM's the private method is typically inlined *if* it
    is a performance bottleneck. If not, it's not worth bothering about the
    method invocation overhead anyway.

    Side note: I am amazed that the "issue" of "goto" keeps popping up. The
    high time of Basic has long since gone but people still seem to cling to
    this ancient concept. Or do all these folks use assembler during their
    daily work?

    Regards

    robert
     
    Robert Klemme, Feb 4, 2007
    #15
  16. Lew Guest

    Re: Java needs "goto" (was Re: hi)

    Martin Gregorie wrote:
    > This is because try...catch blocks that include class
    > instance declarations screw up otherwise clean block structures by
    > preventing me from grouping all object instance declarations at the
    > start of a block rather than sprinkling them through the code.


    Personally I prefer to declare variables closest to the point of use, rather
    than all at the beginning of a block.

    - Lew
     
    Lew, Feb 4, 2007
    #16
  17. Re: Java needs "goto" (was Re: hi)

    Alex Hunsley wrote:
    > I disagree, I think goto was dumped for very good reasons, and
    > structured programming (i.e. no gotos; use methods and refactoring
    > techniques instead) makes a lot more sense.


    I suspect that Java left in "goto" as a reserved word for the same
    reason that Ada supports (with intentionally hideous syntax) "goto" --
    considerations of machine-generated code.

    But jumping from one method to another? Ye gods! Even Fortran doesn't
    allow that, except for a jump-out-to-caller mechanism that is
    essentially a poor-man's "throw".

    --
    John W. Kennedy
    "The blind rulers of Logres
    Nourished the land on a fallacy of rational virtue."
    -- Charles Williams. "Taliessin through Logres: Prelude"
     
    John W. Kennedy, Feb 4, 2007
    #17
  18. Re: Java needs "goto" (was Re: hi)

    On Sun, 04 Feb 2007 03:24:44 -0800, Robert Klemme
    <> wrote:
    > On 03.02.2007 13:22, Martin Gregorie wrote:
    >> Randolf Richardson wrote:

    >
    > Completely agree, Martin. "Goto" is quite nonsense - it's not needed
    > from a theoretical as well as from a practical point of view.
    >
    >>> 1. The ability to share code between methods within a class,
    >>> which all end with the same functionality (this could be more
    >>> efficient than calling another method; javac would need to generate
    >>> errors such as attempts to access variables that belong to different
    >>> methods, return type mismatches, etc.)

    >>
    >> Encapsulating the code in a private method makes for more readable code
    >> as well as eliminating code duplication.

    >
    > Plus, with modern JVM's the private method is typically inlined *if* it
    > is a performance bottleneck. If not, it's not worth bothering about the
    > method invocation overhead anyway.


    That's a perfectly valid alternative for one particular application of
    "goto."

    > Side note: I am amazed that the "issue" of "goto" keeps popping up. The
    > high time of Basic has long since gone but people still seem to cling to
    > this ancient concept. Or do all these folks use assembler during their
    > daily work?


    This discussion is very interesting. One of the reasons I think "goto"
    keeps coming up is that there is demand for it. Although it is commonly
    associated with BASIC, it's also available in other languages such as Perl
    (which can be written in a procedural or OO style, or as mixture of both),
    assembler (the instruction is usually called "jmp"), etc.

    I'm not convinced that "goto" is a bad thing, especially given the
    numerous "while (true) { ... }" loops that I've seen over the years
    (granted, those are usually examples of bad coding style, but many people
    use it because they don't have "goto" at their disposal).

    To me, the limit on the placement of labels at the beginning of a loop,
    followed by a partial "goto" using the "break label;" instruction is
    actually more difficult to follow because first one has to find the label
    in preceeding code, then search for the end of the loop to follow the
    program flow from there. If the label could at least be placed anywhere
    from the beginning of the loop to immediately after its end, with "goto"
    enabled for this, I do think this could actually make things a bit better.

    I definitely don't agree that removing "goto" eliminates "spaghetti code"
    and works against the OO concept (as someone pointed out in a separate
    reply), rather it's the individual developers who will continue to write
    terrible code even without "goto" (which seems to happen now). As an
    aside, a much more serious problem is the lack of source code comments
    (usually the majority of the comments in source code are a copy of the GPL
    or some other license agreement -- the slightly better programmers include
    a minor smattering of vague hints in what seem to be fewer than one or two
    dozen randomly selected lines {out of thousands}).

    I do believe that a good developer can use "goto" in an intelligent way
    that doesn't result in "spaghetti code" and doesn't detract from the OO
    concept, so perhaps if Sun ever does decide to implement it they could
    also require a "javac" command-line option like
    "-allowadvancedinstructions:goto" as a hint that alternatives are strongly
    encouraged.

    The masses seem to be convinced that "goto" is bad, but in the history of
    the world there are countless examples where the masses were wrong (e.g.,
    political elections, setting women on fire to determine if they were
    witches, removing tonsils because medical experts at the time believed
    them to be useless, mis-treatment of leppers, etc.).

    --
    Randolf Richardson -
    The Lumber Cartel, local 42 (Canadian branch)
    http://www.lumbercartel.ca/
     
    Randolf Richardson, Feb 5, 2007
    #18
  19. Re: Java needs "goto" (was Re: hi)

    Lew wrote:
    > Martin Gregorie wrote:
    >> This is because try...catch blocks that include class instance
    >> declarations screw up otherwise clean block structures by preventing
    >> me from grouping all object instance declarations at the start of a
    >> block rather than sprinkling them through the code.

    >
    > Personally I prefer to declare variables closest to the point of use,
    > rather than all at the beginning of a block.
    >

    Yes, I know your preference is normal and widely used.

    That was a personal opinion intended to show why I don't like
    constructors that throw exceptions. I've written far too much C (and
    Algol 60, Algol 68R, PL/9 and PL/1) to easily let go of the habit of
    declaring variables at the start of a block. If that makes me weird, so
    be it.

    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Feb 5, 2007
    #19
  20. Re: Java needs "goto" (was Re: hi)

    On 05.02.2007 09:34, Randolf Richardson wrote:
    > This discussion is very interesting. One of the reasons I think
    > "goto" keeps coming up is that there is demand for it.


    I'm guessing that the demand is rather low - compared with the demand
    for other things (including fixing bugs).

    > I'm not convinced that "goto" is a bad thing, especially given the
    > numerous "while (true) { ... }" loops that I've seen over the years
    > (granted, those are usually examples of bad coding style, but many
    > people use it because they don't have "goto" at their disposal).


    An endless loop with "while(true)" is at least as good as a loop with
    "goto".

    > To me, the limit on the placement of labels at the beginning of a
    > loop, followed by a partial "goto" using the "break label;" instruction
    > is actually more difficult to follow because first one has to find the
    > label in preceeding code, then search for the end of the loop to follow
    > the program flow from there. If the label could at least be placed
    > anywhere from the beginning of the loop to immediately after its end,
    > with "goto" enabled for this, I do think this could actually make things
    > a bit better.


    We must have very different coding styles. I cannot remember ever
    having used a label in Java. I simply don't need them.

    > I definitely don't agree that removing "goto" eliminates "spaghetti
    > code" and works against the OO concept (as someone pointed out in a
    > separate reply), rather it's the individual developers who will continue
    > to write terrible code even without "goto" (which seems to happen now).


    You are right. But this does not make an argument for introducing
    "goto" in Java. Only if benefits outweigh costs of this change it's
    reasonable to do it. And I don't see that.

    > The masses seem to be convinced that "goto" is bad, but in the
    > history of the world there are countless examples where the masses were
    > wrong (e.g., political elections, setting women on fire to determine if
    > they were witches, removing tonsils because medical experts at the time
    > believed them to be useless, mis-treatment of leppers, etc.).


    I won't follow this train of discussion as there are numerous things
    that could be said to this. Just this: if the majority of people do not
    care to have "goto" in Java then Sun's efforts are spent far better in
    realizing other features or fixing bugs. This alone is reason enough
    for not doing it IMHO.

    Regards

    robert
     
    Robert Klemme, Feb 5, 2007
    #20
    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.

Share This Page