Leandro Melo

Ranch Hand
+ Follow
since Mar 27, 2004
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Leandro Melo


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 ]
16 years ago
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).
16 years ago
Hello Kevin.

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

16 years ago

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.
16 years ago
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).
16 years ago
Hi Renu.

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

[ 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.
16 years ago
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.

[ July 02, 2007: Message edited by: Leandro Melo ]
If it was private you wouldn't be able to override it.
16 years ago
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 .
16 years ago
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.
16 years ago
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.
16 years ago