Aditya Jha

Winston Gutkowski wrote:I think all programmers should be required to write at least one divide-and-conquer sort in their lives and create a few different types of hashtable from scratch; what I don't expect (and would probably mark them down for) is for them to do it when they're writing a project.

This is what I believe.

@Rameshwar

I firmly believe, it is NOT the problem which is of relevance here, it is the concept that they are trying to teach.

If I'm teaching Stacks to students, I would not give them "Guessing next move on a Chess board" as the first problem. I would give something similar to palindrome, so they don't have to spend time in actually figuring out the business-logic, and can focus on the technical solution using a Stack, for the time-being. A bit later, I can always introduce some worthwhile problems, which also test their analytical abilities.

There is a reason why when you give interviews to the likes of Google, Amazon etc., they want you to be able to come out with Dijkstra's Algorithm on a graph, or even Depth-first traversal on a Tree without recursion, right there in the interview on a white-board. They always wrap the problem in a nice problem-statement, which will not give you an idea about what they actually want to check. Again, it's not the solution they look for (which could arguably be achieved with some brilliant libraries) but the approach.

It's all very good that students should be taught about real world problems. However, I don't think presenting them with a real-world project on the day they learnt arrays is a good idea. You would rather take baby steps with them, make sure they understand the nuances of the data-structure in question, and in the process, prepare them for the eventual "big" real-world problems.

As for real-world problems, if I were to check palindrome for a million strings in a limited-resources context, I would find another way than instantiating a StringBuilder for each string. It's always good to have practised programming concepts in their most basic forms.

I have a slightly different point of view.

When programming is learnt as part of an academic course, it is required that the concepts (say, data structures) are explained and are covered by a series of programming questions which help in demonstrating whether a student has indeed grasped the fundamentals or not.

Testing a string for palindrome in real world should definitely be achieved by using library functions, because there are bigger problems to solve. However, an academic exercise of the same problem must have been presented to students so they can demonstrate their grasp on a related concept (for example, using arrays or Stack). Here, the concept being explained takes precedence, and not the problem itself. And it's always good to wrap the concepts in a puzzle of sorts which (a) you can relate to, in a layman's way (without necessarily being reminded about the concept in question), and (b) can test whether for an apt problem, if you can figure out how to use the concept or not.

For example, how would you solve the same problem using (a) arrays (b) Stack or (c) None of these. All 3 are valid questions and simply testing the approach you would take to solve this puzzle. It's the approach which is relevant in such an academic exercise, not the puzzle itself. In fact, another perfectly valid question would be how would you solve this same problem by using a library function, IF the topic being taught is "Common classes and methods in Java".

It wouldn't be wrong to say that you will get more marks if you have the correct approach, even if for some small reason you're still not able to solve the given problem, as opposed to you solving the given problem with a wrong approach, which does not use the concept being taught.

Please note that if this question is part of an academic exercise, they probably want you to check palindrome without using an API like StringBuffer.reverse().

Aditya Jha wrote:You can receive all 4 inputs from user, and then create an Item object and populate its fields. Thereafter, you can add this new Item object to the list.

Does this sound feasible to you? If you have any doubts on any of these steps, do let us know.

I know of companies ill-treating employees... but selling them outright! God help us all.

[EDIT] Trying to be more politically correct.

duhit Choudhary wrote:public void UpdateStatus(Object obj) { try { String command = "?012" + "\r"; System.out.println(command); out.write(command.getBytes()); System.out.println("-----------------------Current Status-------------------------"); } catch ( IOException e ) { e.printStackTrace(); } }

What is the argument Object obj in this method used for? In the method, you are creating a String, printing it to System.out and writing it to yet another out. None of these operations use the argument obj anywhere.

What's the output you are getting, and what were you expecting?

The easiest option for you would be to instantiate the singleton instance eagerly (on class load).

So, the line private static ClassicSingleton instance = null; can be changed to private static ClassicSingleton instance = new ClassicSingleton();
Also, you can then remove the if(instance == null) check from getInstance method, as it would be redundant (instance will never be null).

This is, of course, assuming, your design can afford to have this class eagerly instantiated. There are genuine cases where this is not a possibility.

Another option is to do away with hand-coded singleton completely, and rely on a container mechanism to ensure singularity. An example could be a singleton bean using Spring framework.

You can receive all 4 inputs from user, and then create an Item object and populate its fields. Thereafter, you can add this new Item object to the list.

Winston Gutkowski wrote:Actually, if Nakataa wants to return a List with a generic runtime type, it is. The problem as I see it, is how to determine what that is. Specifically:
context.getBean(beanName)
needs to be runtime castable to a List<T>, and the only way I can see of ensuring that is to pass the Class, as was mentioned above.

Winston

Matthew Brown wrote:But with the class argument, you don't need to cast. It's compile-time type safe.

The class argument is there simply to specify T because it can't be derived from other arguments.

My confusion is because the following code compiles and runs fine. It does generate a warning, and correctly so, but if the list is indeed of the correct type, it works well.
public static void main(String[] args) { List<String> list = getList(); System.out.println(list); } public static <T> List<T> getList() { return (List<T>) getBean(); } private static Object getBean() { return new ArrayList<String>(); }
I didn't have to pass a generic class parameter here. I'm sure context.getBean() will also work fine.

I think we need a generic class parameter only when we need to perform something like typeParam.isInstance(obj) or similar with the generic class parameter.

@Winston

Pardon my understanding. Could you please explain what difference a class parameter brings in? More specifically, what do we do with that parameter in the method? As for casting, IMHO even without the argument, we can cast a member of a non-generic list into T, or the whole non-generic list into List<T>. Am I missing something?

Steve Luke wrote:But there is still a problem here - the run time has to be able to deduce the type of T at run-time, and must be able to do so from something in the method signature. One way of doing this might be to pass in the Class Object for the type you want.

That's not necessarily a problem per se.

You are right that one way to do this is to include a Class<T> parameter. However, it's not strictly needed. One can have the method without the Class<T> argument, and still be able to call like: List<String> list = MyBeanFactory.<String>doReturnResourceBean(beanName, configFileName); or even List<String> list = doReturnResourceBean(beanName, configFileName);.

Seetharaman Venkatasamy wrote:perhaps, main method's argument?

I believe JVM arguments (such as -Xms) are not part of the main method arguments.

As for the original question, the behaviour of RuntimeMXBean.getInputArguments() is JVM-implementation specific. So, I would not recommend relying on it too much. Usually, application code does not need (or care) about what JVM arguments were supplied to the runtime, and for good reason. However, if you do want to have the application behave differently in say, different memory conditions etc., there are ways to get those settings from Runtime, instead of getting JVM arguments (and parsing them etc.).

IMHO, try to get what you want directly from Runtime, instead of worrying too much about the exact JVM arguments supplied via command-line.

Winston Gutkowski wrote:

Aditya Jha wrote:I'm not sure I'm getting you here. What I proposed was a (possible) solution to point 3 (the rest of my post).

I was referring to your "blindly replace each URL" statement. I don't think that's what Leo had in mind at all.

Winston

Right. So, the 2 string replacements after the "blind replace" (as mentioned in my post) will help him negate the bad effect of the blind replace.

Winston Gutkowski wrote:

Aditya Jha wrote:So, let's say you blindly replace each URL with <a href="{0}">{0}</a>.

Actually, I think Leo covered that with his "outside of any tags" statement, but that's what's going to be difficult.

Winston

I'm not sure I'm getting you here. What I proposed was a (possible) solution to point 3 (the rest of my post).