Re: JDBC question...

    Hi Joe,

> IOW:  It's the same thing underneath the covers.

    Nope.  The book to look at is the Java Language Specification.   See the
discussion "3.10.5 String Literals" under "Lexical Structure"

http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#44591

    Some quotes:

"Each string literal is a reference (§4.3) to an instance (§4.3.1, §12.5) of
class String (§4.3.3). String objects have a constant value. String
literals-or, more generally, strings that are the values of constant
expressions (§15.28)-are "interned" so as to share unique instances, using
the method String.intern."

    The above is handled through the compiler and start up, that is, pre-run
time.

"Strings computed at run time are newly created and therefore distinct.

 The result of explicitly interning a computed string is the same string
as any pre-existing literal string with the same contents."

    You can easily write a code test using == against a literal and a new
String created from that literal to see they are not the same.  Since String
literals are effectively objectized, you can do odd things like

System.out,println( "What is my length?".length() );


    BTW, for those not aware,  there's now a PDF of the JLS 3rd edition
available at:

http://java.sun.com/docs/books/jls/


                                                         Joe Sam

Joe Sam Shirah -        http://www.conceptgo.com
conceptGO       -        Consulting/Development/Outsourcing
Java Filter Forum:       http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International?    http://www.jguru.com/faq/I18N
Que Java400?            http://www.jguru.com/faq/Java400


----- Original Message ----- 
From: "Hayes, Joe" <Joe.Hayes@xxxxxxxxxx>
To: "'Java Programming on and around the iSeries / AS400'"
<java400-l@xxxxxxxxxxxx>
Sent: Thursday, June 16, 2005 1:12 PM
Subject: RE: JDBC question...


> I thought that a statement like:
> String s = "foo";
>
> was an implicit call to String s = new String ("foo");
>
> IOW:  It's the same thing underneath the covers.
>
> Read that in a book once, was the author wrong?  (not going to mention it
my
> name because it would ruin my already shaky credibility :) )
>
>
> -----Original Message-----
> From: java400-l-bounces@xxxxxxxxxxxx
> [mailto:java400-l-bounces@xxxxxxxxxxxx]On Behalf Of Joe Sam Shirah
> Sent: Thursday, June 16, 2005 11:58 AM
> To: Java Programming on and around the iSeries / AS400
> Subject: Re: JDBC question...
>
>
>
>     Hi Shane,
>
>     Paul's answer should have resolved your immediate problem.
>
>     Since you were in on a newbie/rookie thread earlier, I have some
general
> comments on your code:
>
>         Generally, don't use the form
>
>                 String s = new String( "some literal" );
>
>     Literals *are* Strings and you're just creating a new object for
nothing
> ( that isn't ==, BTW. )  There's another thread on the cost of
> instantiation.  A real concern is what happens while initializing in the
> constructor.  Since String uses a backing character array and does some
> calculations, duplicating strings like this can be costly.
>
>     I think you already know this, see the difference between:
>
>                             String timeQuery = new String("...
>
> and
>
>                             workCodeQuery = "select...
>
>         Another response said "No need to use prepared statements in this
> case, all the statements are fixed."  The rationale for PreparedStatements
> is normally "Is the statement executed multiple times?"  If so, the answer
> is almost always yes, regardless of whether parameters are needed or not.
> Sometimes other concerns, such as protecting from SQL injection attacks
and
> auto-handling escaping suggest using PreparedStatements even when it will
> only be executed once.
>
>     BUT, in your code for queryCKWORKCD, you are causing a lot of
> unnecessary work.  In the loop:
>
> >    for (x = 0; x <= 9; x++) {
> >       workCodeQuery =
>
> you create and execute a new PreparedStatement on each iteration, when the
> only difference is pc[x].trim().  That should be a parameter, with the
> same PreparedStatement used throughout the loop.  For more info, see "
JDBC
> Technology Guide: Getting Started" in the JDK documentation for JDBC.  You
> may also find my JDBC 2.0 Short Course helpful.  It's at:
>
> <
>
http://developer.java.sun.com/developer/onlineTraining/Database/JDBC20Intro/
> >
>
> The examples were tested on DB2 Universal, DB2/400 and Cloudscape.
>
>     HTH,
>
>                                                          Joe Sam
>
> Joe Sam Shirah -        http://www.conceptgo.com
> conceptGO       -        Consulting/Development/Outsourcing
> Java Filter Forum:       http://www.ibm.com/developerworks/java/
> Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
> Going International?    http://www.jguru.com/faq/I18N
> Que Java400?            http://www.jguru.com/faq/Java400
>
>