Tool to externalize strings

Discussion in 'Java' started by Anonymous user, Jan 27, 2006.

  1. Hello,

    i've watched a little bit the existing tools to help externalize
    strings but none of them is really great. Does anybody know if the
    described tool below exists?
    - in IDE:
    * warns about badness of complex string constructs like "at position
    " + pos + "."
    - juste before compilation (on the fly):
    * replace all strings literals ("*") by xxx.yyy.Resources.get(id)
    * create a default properties file with { id="*" }
    - in a separate tool
    * GUI like:
    | lang1 | lang2 |
    ----------------------
    | str1 | str2 |

    pros:
    - you don't need to assign an id for each string (like in Eclipse tool)
    - you don't see the ugly call to the resources in you IDE

    cons:
    - it surely slow down compilation, but it worth it

    Does that exists? If no have you any idea why? If you think it's not a
    good tool, plz explain why.

    TIA
    Anonymous user, Jan 27, 2006
    #1
    1. Advertising

  2. Anonymous user

    Oliver Wong Guest

    "Anonymous user" <> wrote in message
    news:...
    > Hello,
    >
    > i've watched a little bit the existing tools to help externalize
    > strings but none of them is really great. Does anybody know if the
    > described tool below exists?
    > - in IDE:
    > * warns about badness of complex string constructs like "at position
    > " + pos + "."
    > - juste before compilation (on the fly):
    > * replace all strings literals ("*") by xxx.yyy.Resources.get(id)
    > * create a default properties file with { id="*" }
    > - in a separate tool
    > * GUI like:
    > | lang1 | lang2 |
    > ----------------------
    > | str1 | str2 |
    >
    > pros:
    > - you don't need to assign an id for each string (like in Eclipse tool)
    > - you don't see the ugly call to the resources in you IDE
    >
    > cons:
    > - it surely slow down compilation, but it worth it
    >
    > Does that exists? If no have you any idea why? If you think it's not a
    > good tool, plz explain why.


    The first downside I could think of off the top of my head is that you
    don't want to externalize ALL Strings, especially when doing stuff with
    Reflection, or specifying hardcoded filenames, URLs, etc.

    The second one that comes to mind is that is detecting the "badness of
    complex string constructs" could be difficult, for example, if a string is
    constructed through a deeply recursive calls. It sort of implies the machine
    understanding the intent of the programmer.

    The third one is that when two strings are semantically identical, they
    should have the same id, but the tool would probably not be able to
    determine when two strings are semantically identical (note that just
    because two strings are identical in one language doesn't mean that they are
    semantically identical in all languages).

    But for some common "small" applications, it does seem like it would
    save time over Eclipse's method.

    Rather than "Just before compilation, on the fly", how about a GUI tool
    that goes through all your Java files and asks you which ones you want to
    externalize, and which ones you want to keep as is?

    - Oliver
    Oliver Wong, Jan 27, 2006
    #2
    1. Advertising

  3. > The first downside I could think of off the top of my head is that you
    > don't want to externalize ALL Strings, especially when doing stuff with
    > Reflection, or specifying hardcoded filenames, URLs, etc.


    Yeah but it could be configured, at the first run, you externalize
    everything. To get the strings. And you "unselect" some of them in a
    GUI tool for next run.


    > The second one that comes to mind is that is detecting the "badness of
    > complex string constructs" could be difficult, for example, if a string is
    > constructed through a deeply recursive calls. It sort of implies the machine
    > understanding the intent of the programmer.


    no handling a complex case. A computer is dumb and will always be. The
    aim is just to handle 90% of dumb case it can understand. The aim is to
    avoid losing time on dumb things.

    It would requires a way to take over control of the tool for complex
    cases.


    > The third one is that when two strings are semantically identical, they
    > should have the same id, but the tool would probably not be able to
    > determine when two strings are semantically identical (note that just
    > because two strings are identical in one language doesn't mean that they are
    > semantically identical in all languages).


    it seems like the exception not the rule to me, but i might be wrong.
    One again you could forbig the coalescing (good word?) of all the
    similar strings by looking at their filename/linenumber for example.


    > But for some common "small" applications, it does seem like it would
    > save time over Eclipse's method.


    thx :)


    > Rather than "Just before compilation, on the fly", how about a GUI tool
    > that goes through all your Java files and asks you which ones you want to
    > externalize, and which ones you want to keep as is?


    It would be great! But more complicated to do i think.



    > - Oliver


    thx for your comments.
    Anonymous user, Jan 30, 2006
    #3
    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. Gokula Krishnan

    Externalize and Internalize

    Gokula Krishnan, Jul 18, 2003, in forum: Java
    Replies:
    1
    Views:
    3,084
    Jayaram
    Jul 18, 2003
  2. Kurt Krueckeberg
    Replies:
    2
    Views:
    705
    =?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=
    Nov 17, 2004
  3. Rick

    Comparing strings from within strings

    Rick, Oct 21, 2003, in forum: C Programming
    Replies:
    3
    Views:
    375
    Irrwahn Grausewitz
    Oct 21, 2003
  4. Klaus Neuner
    Replies:
    7
    Views:
    486
    Klaus Neuner
    Jul 26, 2004
  5. Ben

    Strings, Strings and Damned Strings

    Ben, Jun 22, 2006, in forum: C Programming
    Replies:
    14
    Views:
    754
    Malcolm
    Jun 24, 2006
Loading...

Share This Page