Q: Why using introspection and reflection inside a compiled JSP?
** sorry people for reposting - i got no answer so far. maybe the e-mail got lost. can someone comment on this, please? thx! ** hi all, this might be regarded as a user question but i think this is so much internal that this is the right list to post to. if not, please excuse me. i will then repost on the users list. ok, here's what i'd like to know: looking at the java code generated from a JSP i found this: in the JSP (the details of the tag are irrelevant. the important thing is the property): my:tag foo="false" in the generated .java file: JspRuntimeLibrary.introspecthelper(_jspx_th_my_tag_0, "foo","false",null,null, false); since the type of the attribute can be determined at compile time i wonder why introspection / reflection is used inspite of the performance drawback. did i overlook something? can anyone anser this? thank you! robert -- Robert Klemme Software Engineer - myview technologies GmbH Co. KG Riemekestrae 160 ~ D-33106 Paderborn ~ Germany E-Mail: mailto:[EMAIL PROTECTED] Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
hi all, Among the alternatives we've kicked around: comp.lang.java.html+template comp.lang.java.template+tag comp.lang.java.servlet+template comp.lang.java.template-tech comp.lang.java.web-tech Again, any suggestions welcome either here or in private e-mail. how about comp.lang.java.web-apps comp.lang.java.web-applications comp.lang.java.tagged comp.lang.java.tag-html comp.lang.java.tagged-text comp.lang.java.embedded comp.lang.java.embedded-programming comp.lang.java.dynamic-html comp.lang.java.in-ascii-formats no real blockbusters... maybe someone else gets inspired. :-) robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Thread-safety
hi again! -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 7:11 PM To: [EMAIL PROTECTED] Subject: Re: Thread-safety on 1/29/01 3:52 AM, "Klemme, Robert, myview" [EMAIL PROTECTED] wrote: i cannot believe that people at sun would risk these consequences, do they? LOL! That is the funniest thing I have read in a long time! :-) you're not saying i'm naive, are you? :-)) well, at least you had fun. :- People are not perfect and they make human errors. This is clearly one of them and is also in an area that is *very* difficult to get right. surely they are. but since everybody knows that optimizations are a difficult topic one should be cautious and evolve slowly. apart from that, even i - who had only a single lecture about compiler construction - did know this. so i would have expected people at sun to know it, too... well, but maybe again naive... regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Thread-safety
hi! -Original Message- From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 10:26 AM To: [EMAIL PROTECTED] Subject: Re: Thread-safety There are IMHO two reasons why these statements may be 'executed' out of order: [...] tis is all very reasonable. To summarize: The designers of the JVM spec relaxed the requirements on order of execution to allow as much performance as possible while still guaranteeing the outcome of a program *if it is run in a single thread* what irritates me here is the point that they should not have taken into consideration what happens to multithreaded programs. this is because as far as i understand support for multithreaded applications is one of the core features of the java language. (I believe the word is 'deterministic'). Whenever there's communication between threads, the programmer must be *very* careful to ensure that the state seen by one thread corresponds to the one written by another. AFAIK the only mechanism the Java language provides to ensure this is the use of synchronized blocks. ironically the optimization which was implemented for performance improvement does lead to a performance loss (because the locking of objects is costly) in another place. of course, overall this could still be an improvement - especially if most of the code executes "single threaded"... regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Thread-safety
hi all!
-Original Message-
From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 26, 2001 6:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Thread-safety
Does this mean that the following code would be thread safe?
NO, it's not!
sorry to intervene here. i think you are wrong. look at it again:
[...]
Does this mean that the following code would be thread safe?
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
synchronized(new Object()) {_jspx_init();}
_jspx_inited = true;
}
}
}
this double check is a usual technique to improve performance. the inner
check is necessary for proper operation. the outer check improves
performance since it does not require a lock on the object to be acquired
which is relatively costly.
and, btw. why did they not code this:
if ( ! _jspx_inited ) {
synchronized (this) {
if ( ! _jspx_inited ) {
// other initialization stuff
_jspx_inited = true;
}
}
}
i think it is quite superfluous to compare a boolean with true or false
(apart from the fact that in other programming languages this might even be
dangerous, just think of C...)
regards
robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: FW: Thread-safety
hi all! -Original Message- From: Brian Goetz [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 27, 2001 3:15 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FW: Thread-safety [...] Assuming jspx_init() might create an object (what else would an init() routine do?), the problem is that your initial reference of jspx_inited is unsynchronized. Supposed thread A is inside the synchronized block. Thread B is about to execute "if (_jspx_inited == false). The compiler/cache/memory CAN make it appear to thread B that jspx_inited has been set to true before all the instructions corresponding to jspx_init() have executed. but as far as i can see this is not a problem: 1. the inner block does not get executed, which is exactly what i want. if thread a is initializing then we do not want to have other threads doing the same stuff again. (in fact - not considering exceptions which might let the initialization fail - the earlier the flag gets switched the better. but, clearly, keeping exceptions in mind the flag should be set only if the initialization succeeds. although i doubt whether a second try will succeed...) 2. the "real" check is done inside the synchronized block and by the time the lock is aquired by the second thread this real check should work on the real data. i am not too deep into JVM mechanics but one general rule for optimizations is that they are not allowed to change the execution semantics of a piece of software. so if there are some reorderings then they must not change the semantics - otherwise i would seriously question them. regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Thread-safety
thank you paul to point me at an omission. -Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED]] Sent: Monday, January 29, 2001 11:54 AM To: [EMAIL PROTECTED] Subject: Re: Thread-safety [...] The problem is that the point of the code block is to be sure that the _jspx_init() method has been completed before proceeding. The problem is that _jspx_inited might appear to other threads to be set to true before the original thread has completed executing the _jspx_init() method (or at least before its changes are available to other threads). This means that the second thread would come through, see that _jspx_inited is true, and skip the synchronization block. That threads execution would then proceed thinking that everything has been initialized when it hasn't. ok, i see. thank you again for clarifying. do i now fully understand the issue: the problem at hand cannot easily be solved by assigning the flag from the return value of the init() method because of a combination of inlining and reordering which might again lead to a prior assignment. is that so? normally i would say that a code like "_jspx_inited = do_init();" may not be rearranged in a way that the assignment occurs prior to finishing of the method body (especially since there can be exceptions). i would guess that - by allowing this - a whole bunch of programs would run berserk or simply break... i cannot believe that people at sun would risk these consequences, do they? Check out the article that is referenced in other mail in this thread or hit JavaWorld and see the references section on the article about singletons. this one? http://www.javaworld.com/javaworld/jw-04-1999/jw-04-toolbox.html regards robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Session url rewriting
hi there! the original e-mail of craig dates some months back. When a session is first created, Tomcat has no way to know whether session cookies are supported by the browser. Therefore, to be safe, it sends the session ID both ways (by cookie and by modifying URLs that you submit to response.encodeURL calls). On subsequent requests that are part of this session, Tomcat will notice that it received the session ID via a cookie, so it will stop doing the rewriting. i wonder whether anything has changed here, especially whether there is a configuration option (possibly in server.xml) that switches cookies for session tracking of. thanks a lot robert -- Robert Klemme Software Engineer - myview technologies GmbH Co. KG Riemekestrae 160 ~ D-33106 Paderborn ~ Germany E-Mail: mailto:[EMAIL PROTECTED] Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
