String/StringBuffer (was Re: An alternative to JSP)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
From: Paul Speed [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: An alternative to JSP
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
Mel Martinez wrote:
Without getting into the larger issue, one problem
that jumped out at me from your article is (at least
in your examples) the MLS precompile looks at the
expression inside the digraphs and replaces line
terminations in the *.j source with linefeed
characters ('\n'). That presumes the line termination
character of choice for the output is a linefeed
character. It may be a '\n' is fine for most cases,
but the truth is that it depends on the platform upon
which the output is to be used. In generall, it is
always best to use the line.separator property instead
or use a PrintWriter's println() method to insert the
correct line termination.
Another issue is that the example creates catenated
String literals. I would hope that the actual code
produced would use appropriately initialized
StringBuffers or performance could be a problem.
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer ("My").append("dog").append("has").append("fleas").toString();
It is also possible to write a statement like:
"My" + "dog" + '.'
The ability to concatenate a char points at an underlying StringBuffer
implementation, which supports append(String) and append(char) methods.
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string concatentation operator
( + ), and for conversion of other objects to strings. String concatenation is
implemented through the StringBuffer class and its append method. String
conversions are implemented through the method toString, defined by Object and
inherited by all classes in Java. For additional information on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java Language Specification.
Arieh
of literals it can be more efficient than StringBuffer as long as
they are grouped together as above. Since I haven't looked at the
code directly, I don't know how or if this affects your point.
-Paul Speed
Just some thoughts on the implementation. On the
larger issue of this thread, I don't really see the
benefit of something like MLS over JSP, which
potentially allows you to completely remove all Java
code from the html (by using jsp tags and taglibs),
but take that as an imho.
Dr. Mel Martinez
Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- Brad Cox [EMAIL PROTECTED] wrote:
At 11:30 AM -0500 01/11/2001, Shawn McMurdo wrote:
I agree with most of your discussion of the
disadvantages of JSP/ASP/etc,
but I believe your solution does not address a
fundamental problem, which
is the complete separation of presentation
resources from presentation logic.
That is correct. My goal at this point is to get
free of JSP so the
goal was only to duplicate what JSP does in a way I
can live with.
Having the HTML embedded in a java class may be
suitable for small
applications
built by engineers but does not address the vast
majority of applications
where designers work on HTML using many different
HTML editing tools
while developers work on the application logic in
Java using various IDEs and
editors.
Perhaps I miscommunicated. The private methods that
contain the
{{html}} need not be private methods in the
controller class,
although that is the style I demonstrated in the
paper and that I use
in my own I-do-it-all work.
Also there is nothing that requires these view
methods to contain
hardcoded strings, other than the crude measurements
in the
Conclusion section that makes me doubt that the
space issue is a
primary concern. Each method could aim MLS at an
html file at runtime
(using the doStream() method that it provides for
this purpose but
which I didn't mention in the article) and let it do
the executable
inclusion at runtime. But good point; I'll make this
explicit in the
article.
This would also eliminate the need for the outermost
enclosing {{...}}, but
the executable inclusion brackets would remain. Do
you object to my
belief that html experts and their tools couldn't be
trained to
ignore the {{...}} wrappers around the html? I'd be
interested in
hearing more about this. After all, JSP has the same
problem
RE: String/StringBuffer (was Re: An alternative to JSP)
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer
("My").append("dog").append("has").append("fleas").toString();
It is also possible to write a statement like:
"My" + "dog" + '.'
The ability to concatenate a char points at an underlying StringBuffer
implementation, which supports append(String) and
append(char) methods.
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string
concatentation operator
( + ), and for conversion of other objects to strings. String
concatenation is
implemented through the StringBuffer class and its append
method. String
conversions are implemented through the method toString,
defined by Object and
inherited by all classes in Java. For additional information
on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java
Language Specification.
On a performance note, doesn't it strike anybody the methods
on StringBuffer are declared 'synchronized' is a bad thing?
Object creation and synchronization are 2 of the most costly operations in
Java.
- Chris.
Brainbench MVP Java2.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: String/StringBuffer (was Re: An alternative to JSP)
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string
concatentation operator
( + ), and for conversion of other objects to strings. String
concatenation is
implemented through the StringBuffer class and its append
method. String
conversions are implemented through the method toString,
defined by Object and
inherited by all classes in Java. For additional information
on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java
Language Specification.
And the Java Language Specification (Section 3.10.5: String Literals) says
this:
"Strings computed by constant expressions (15.27) are computed at compile
time and then treated as if they were literals"
http://java.sun.com/docs/books/jls/html/3.doc.html#101083
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer
("My").append("dog").append("has").append("fleas").toString();
If this is actually the case, Sun's JDK is not in compliance with the spec.
However, in my tests, this is not the case.
From this class:
public class StringTest {
static String blah = "My " + "dog " + "has " + "fleas.";
}
The following is the result from "javap -c StringTest" after compiling:
Compiled from StringTest.java
public class StringTest extends java.lang.Object {
static java.lang.String blah;
static {};
public StringTest();
}
Method static {}
0 ldc #1 String "My dog has fleas."
2 putstatic #5 Field java.lang.String blah
5 return
Method StringTest()
0 aload_0
1 invokespecial #4 Method java.lang.Object()
4 return
regards,
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: String/StringBuffer (was Re: An alternative to JSP)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: String/StringBuffer (was Re: An alternative to JSP)
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
X-MIME-Autoconverted: from quoted-printable to 8bit by amon.Central.Sun.COM id
KAA15483
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string
concatentation operator
( + ), and for conversion of other objects to strings. String
concatenation is
implemented through the StringBuffer class and its append
method. String
conversions are implemented through the method toString,
defined by Object and
inherited by all classes in Java. For additional information
on string concatenation
and conversion, see Gosling, Joy, and Steele, The Java
Language Specification.
And the Java Language Specification (Section 3.10.5: String Literals) says
this:
"Strings computed by constant expressions (15.27) are computed at compile
time and then treated as if they were literals"
http://java.sun.com/docs/books/jls/html/3.doc.html#101083
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
Paul,
Actually, my investigations in the past have shown that (at least in
Sun's JDK 1.2) this is implemented as:
new StringBuffer
("My").append("dog").append("has").append("fleas").toString();
If this is actually the case, Sun's JDK is not in compliance with the spec.
However, in my tests, this is not the case.
From this class:
public class StringTest {
static String blah = "My " + "dog " + "has " + "fleas.";
}
The following is the result from "javap -c StringTest" after compiling:
Compiled from StringTest.java
public class StringTest extends java.lang.Object {
static java.lang.String blah;
static {};
public StringTest();
}
Method static {}
0 ldc #1 String "My dog has fleas."
2 putstatic #5 Field java.lang.String blah
5 return
Method StringTest()
0 aload_0
1 invokespecial #4 Method java.lang.Object()
4 return
Michael,
thanks. I stand corrected.
Arieh
regards,
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Arieh Markel Sun Microsystems Inc.
Network Storage500 Eldorado Blvd. MS UBRM11-194
e-mail: [EMAIL PROTECTED] Broomfield, CO 80021
Let's go Panthers Phone: (303) 272-8547 x78547
(e-mail me with subject SEND PUBLIC KEY to get public key)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
