Leandro Melo

Hi.

You can try to find the file with a local look up (based on the package structure) using getClass().getResource(filename).
[ September 11, 2007: Message edited by: Leandro Melo ]

Hi Babu.

A naive strategy would be to open the log file using standard I/O and start looking for the requested timestamp (I suppose the log file has such information).

Hello Kevin.

From your code it looks like "matrixList" is a collection of label value benas. You should try something like:

<html:select property="strMatrix"> <html:options collection="matrixList" property="value"labelProperty="label" /> </html:select>

Hello.

Regarding the main method which is the entry point of the application, the String[] argument is required because of a design choice. It's just a standard way to pass input arguments to the application.

Hi Alexandre.

Struts does not automatically protect you against thread-safety issues. As you said it yourself, if you have an object in your application that is somehow shared by different threads, you might need to synchronize access to it. Regarding Struts (or other frameworks) you should be aware of how they work and their micro-architecture so you don't insert flaws into your design. For instance, it is not a good idea to put data members in Struts action classes (there's no guarantee about their thread-safety because Struts might use the same action instance for distinct requests).

Hi Renu.

Yes, you can use java.lang.String as the type of a bean.

<jsp:useBean id="myBean" class="java.lang.String" ... />
[ July 06, 2007: Message edited by: Leandro Melo ]

Hi Abhijith.

I'll take a shot and try make some sense out of that. The idea of implementing an interface is related to the idea of a contract that must be followed. When you choose to do that you accept its terms. Making the data members final is a way to accomplish that (you have access to the data, but you must use it how the contract dictates it). Still in this line of thought, why would you need this data to belong to your instance? You can't change it anyway... so just let it belong to the interface and be a static member. About being public, it might be about not hidding "contract clauses" (although you can make private and protected data members in nested interfaces). You either have access to the contract or not, but if you do, you should be able to see whole thing (well, at least the external "interface" of the contract ).

I hope this very general analogy is helpfull.

Hi Kumarth.

Originally posted by kumarth ravi:
It was compiled but thrown a Class cast exception.

That's what Manfred was trying to tell you. Replacing T o=new T() by java.lang.Object o=new java.lang.Object() might not be a good idea. You have just seen a situation where it wouldn't work . You might want to take a look at the tutorial I pointed in my first post, it could help you for a better understanding (if you're still confused).

Hi Markandey.

The service method is the one responsible to call doGet, doPost, doPut, depending on the request type. In this case, it is just not calling these methods (but it's handling the requests anyway). Is it clear?

Hi all.

Originally posted by Olivier Croisier:
You cannot be sure that the real type (T) will have a no-arg constructor.
So you cannot write T t = new T() !

Actually, this is not the real reason why you cannot write new T(). The problem is that generics in Java is supported by a technique called type erasure. With this technique, the generic types only exist at compile time. So, the type T is not really replaced by the real type during runtime. That's why you cannot write new T().

One thing you could do to help clear out things is to compile the following code and disamssemble it (using javap -c). Note that the disassembled code is the same.

//Class Box.java public class Box<T> { private T o; public void setObject(T o) { this.o = o; } } //Class Box2.java public class Box2 { private Object o; public void setObject(Object o) { this.o = o; } }
[ July 02, 2007: Message edited by: Leandro Melo ]

If it was private you wouldn't be able to override it.

Hi ramasri.

You cannot use this inside a static block because this relates to an instance of a class ("this instance"), while static blocks belong to the class itself. So, which one is the this instance when you're inside a block that does not belong specifically to any instance? In the case of your program, the static block is execute when the class is loaded, that's why the first output you see is "Static block started". Then, instace data is initialized. Is that clear?

Hi all!

Originally posted by Gregg Bolinger:
While I think it's excellent for any developer to have a firm grasp of memory use when programming and how all that works, from a beginner's perspective, the beauty of Java is that you don't really need to concern yourself with either.

From a more advanced perspective, that might not look so beatiful though .

Hello Bharat.

I took a look at the JLS (Java Language Specification) and I couldn't find a anything that deals directly with this particular situation. Take a look at this (section 6.6):

The Java programming language provides mechanisms for access control, to prevent the users of a package or class from depending on unnecessary details of the implementation of that package or class. If access is permitted, then the accessed entity is said to be accessible.
Note that accessibility is a static property that can be determined at compile time; it depends only on types and declaration modifiers...

The spec. also gives several examples of cases in which compile time errors occur regarding access violations. But since you recompiled only one file which is part of a larger application, I'm not sure what is defined to be the expected behaviour.

Hi Bharat.

Access control is performed at compile-time. When you compiled Use.java, bytecodes were corectly generated with a reference to the members of Provider.java you mentioned, because they were public at that time (you can use javap -c to disassemble Use.class and take a look). Afterwards, you recompiled Provider.java and made those members private, but since you did not compile Use.java again, there was no way to detect that those members are no longer public. When you run the application, both Use.class and Provider.class were technically fine. So, you need to recompile Use.java so access control is performed again.