Prashant Shiralkar

Pedro Kowalski wrote: I've tested it and it doesn't follow the DD order, so - watch out for this guys :-)

I can't think of a situation where you'd keep same values for <load-on-startup> yet bother about the order. How does it matter?

Probably, from maintainability viewpoint, they kept <url-pattern> tag separate from <servlet>. If its a part of <servlet>, imagine what you'd need to do if you later want a url path to be handled by a different servlet (existing or a new one). You'd have to delete the <url-pattern> from the current <servlet> and make a new entry in the other <servlet>. Instead, keeping this tag in a separate <servlet-mapping> tag gives you the ease of maintenance by being able to change just the name of the servlet without touching other parts in the descriptor.

Probably, you missed it: start() only gives you the starting position of a match. To actually have the matching string, you'd need to use group() method of Matcher class

Nancy Antony wrote: when I donot write any constructor in my class Java provides one, which we usually say that intializes the instance variables to their default values

This no-arg constructor provided by Java does not initialize the instance variables to default values. The initialization happens even before this constructor is called.

but I think default construtor doesn't do anything as any variable screated on heap is automatically initialized, am I right?

Yes, that's correct.

What does constructor returns ? Current Object i.e this that means object reference as this is a reference to the current object. So I understand the process as such. new allocates memry and constructor is called by passing this to the constructor and the only code which is present in default constructor is return this and in paramterized constructor , return this statement is automatically added?

It's the new operator that calls the constructor and finally returns the reference to the new object. A constructor has no return type hence doesn't ever return anything.

If you are trying to synchronize access to x, which is common to all instances of TestClass, you need to obtain lock at the class level.
public void m1(){ synchronized(TestClass.class) { x++; System.out.println( "bla bla ..."); } } orpublic void m1(){ synchronized(this.getClass()) { x++; System.out.println( "bla bla ..."); } }

Adolfo Eloy wrote:..is there any kind of software to query on the pool? any JVM tool or kind of debugger? ... But, does anybody knows about a way to inspect the String pool efficiently?

Interesting questions! What's your motivation to know this?

why string is immutable and why all wrapper class are immutable i know these are valued object but i don't get this

By default, all Java classes are mutable i.e contents of their instances can be modified. But there are few advantages that immutability offers (http://download.oracle.com/javase/tutorial/essential/concurrency/immutable.html), and that's why some classes are made immutable by marking them as final. The classes in question are String and Wrapper classes, and if you think logically about them (any immutable class), then the description in the link provided would start making sense. Let us address each of the two separately:

String class:
As mentioned in SCJP page 433 by Kathy Siera and Bert Bates, as applications grow, its very common to have a lot of redundancy in the String literals for a program. Hence, in order to address this issue, the designers of Java came up with the concept of String pool which improves performance by making efficient use of available memory. But now, as you might imagine, if several reference variables refer to the same String without even knowing it, it would be bad if any of them could change the String's value. Hence, there arose the need of making this String class immutable.

Wrapper classes:
One of the objectives of making wrapper classes is to provide a mechanism to treat primitives with activities reserved for objects, like being added to Collections, or returned from a method with an object return value. If you think about a collection, it would often be the case that it is accessed by multiple threads. If the wrapper classes weren't mutable, it would run into the risk of concurrent modification and thus lead to inconsistent states. Thus, in order to avoid conflicts, wrapper classes are made immutable.

So, in general, whenever you come across an immutable class, it would be logical to think of its instances being used in a concurrent manner. Also, if you do not want your object contents to be modified (one of the reasons being concurrent access), then make the class immutable.

Henry Wong wrote: Because of type erasure, both methods come out to the same signature.

Here, do you imply: add(E e) and add(Object o)? If so, does that mean, after "type erasure", add(E e) of HashSet<E> looks like add(Object o)?

A related discussion: https://coderanch.com/t/233142/threads/java/synchronized-keywords-static-methods may help

From your comment on Line 21, S and Y extends X, but S doesn't seem to be a subtype of Y. So on line 23, it would give a compile time error as object 's' cannot be returned where an instance of Y or its subtype is expected.

The only reason I can think of is because C is apart of the same inheritance tree as B and B implements m

is a reason why the compiler doesn't complain when the downcast is made.

Whereas the reason for not having a run-time error is that the "Run Time Type Identification (RTTI)" or runtime type checking succeeds (It doesn't harm to cast null to C). Even though it looks like you are just performing an ordinary parenthesized cast [b = (C)m], at run time this cast is checked to ensure that it is in fact the type you think it is. If it weren't, you'd have got a ClassCastException. Try using b = (C)a and you will get a runtime error.

So, JVM only checks if the runtime object has the same type or is a subtype of the cast. This act of checking types at runtime is called RTTI.

I did go through the spec, and I am convinced why that answer is what it is, but I don't see, from a design viewpoint, why a "new" session object is automatically available to all JSP pages with no existing session AND default value of "true" for the session attribute in the page directive.

Does it mean the JSP page which encounters this kind of code for the first time from a new user is the initiator of a new session for the user? or rather put another way - Is this session available to other resources for further requests from the same user?

If not, what use is a new session meant just for a JSP page, if its really not involved in any state maintenance and which ultimately is going to get destroyed at the end of _jspService method?

The following is a question from Enthuware Mock Exam:
Consider the following JSP code: <html><body> <% Integer count = (Integer) request.getSession(false).getAttribute("count"); if(count != null ) { out.println(count); } else request.getSession(false).setAttribute("count", new Integer(1)); %> Hello! </body></html> What will it print for the very first request to this page as well as the web application that contains this page?
The correct answer is "It will print Hello and will set the count attribute in the session."
I answered: "It will throw a NullPointerException at request time."

The explanation the tool gives for the correct answer is:
Explanation:
---------------------------
Had this code been in a regular servlet like this:
public void doGet(...) { Integer count = (Integer) request.getSession(false).getAttribute("count"); if(count != null ) { out.println(count); } else request.getSession(false).setAttribute("count", new Integer(1)); }
It would have thrown an NullPointerException as request.getSession(false) would have returned null (since this is a first ever request to the servlet container.)

However, in case of JSP pages, the session is automatically created by default. I.e. <%@ page session="true" %>
---------------------------

I wasn't convinced with the explanation and hence I tried creating a JSP and it worked as per the given comments. I also observed the servlet code resulting from translating the JSP (which said HttpSession session = pageCotext.getSession()). For the session attribute of page directive, the spec says:

If true then the implicit script language variable named session of type javax.servlet.http.HttpSession references the current/new session for the page.

But I fail to understand why a JSP is given a session object when it has not been explicitly "requested" by a developer; and what does it mean to have a new session just for the page? And given that, does a request to any JSP automatically associate a session with the client, even when there is no need to have a notion of "state"?

Regards,
Prashant

Hi Saima,

Your understanding

The jsp:getProperty and jsp:setProperty in either page operate on the bean in the most restricted scope, starting with page,request,sesssion and application.

is correct. The basic reason for this behavior can be known if you observe how the container translates both .jsp files into their correspoding servlet (.java) files. You may find them in:

yourTomcatHomeDir/work/Catalina/yourServerName/yourWebAppName/org/apache/jsp

It replaces the <jsp:setProperty/> or <jsp:getProperty/> by findAttribute() method, and as you might be aware findAttribute() starts looking from most restricted to least restricted scope, & thus the above behavior makes sense.

Moral:
1) To distinguish between the beans in different scopes, make the "id" attribute distinct in the <jsp:useBean/> standard action. OR
2) Use getAttribute(String, int) method to explicitly specify the scope in which you want the container to look for the bean (this is not a good approach though as this takes you away from using standard actions)

Hope this helps.

Prashant

Thanks Keith, I misinterpret the body-content type. A related problem I faced while implementing this was that, at request time, it gave a compilation error for the generated servlet file corresponding to the JSP page. To get around this, I placed the TagHandler.class file in the same directory as the servlet java file. Ideally, tomcat should be able to find the class file in /WEB-INF/classes directory, but looks like it didn't. Do you see any reason for this?