Matthew Cox

Memory is allocated for all the necessary items of any given class. So when your super class is declared, it will do the same, reserve whatever memory is necessary. With inheritence, this same thing occurs in addition to reserving memory for the sub class's components. It is not about copies or variables.

In addition, let us look at an example:

public class Base { String foo; public Base() { foo = "base"; } } public class SubBase { String bar; public SubBase() { super(); bar = "SubClass"; System.out.println(super.foo); } }


In this example the memory location for the variable foo in Base, is accessible in SubBase. They point to the same memory location, it is not a copy but rather a reference to the base.foo field.

abalfazl hossein wrote:

This looks more like a blog post

No!
I want to be sure, I asked a Generic class and I write an example, But after I post here one friend told me using of generic is pointless in your example!

If that is the case then no harm no foul. It helps if you are more specific with the wording of your question IMO. As to whether or not it is pointless .... interfaces are used to provide a unified type and define behavior. If you don't intend to use this interface anywhere else other than a specific class, then it could be deemed as pointless.

If we are assessing whether it is pointless to include a generic type in your interface ... then your friend is incorrect. You are creating a definition of behavior that can be enforced and checked at compile-time while allowing the flexibility of passing in generic types .. I don't see how that functionality is pointless.

To elaborate, I may want to utilize your interface to add people to my Classroom class, or maybe Teachers to my Faculty class and maintain the Classroom and Faculty instances referenced by the interface you defined. A bit contrived but a very common place theme as the problem size scales.

This looks more like a blog post (look at what I did) masked as a question.

Adam Preston wrote:ohhhhhhhhhhh i get it now... so if (i) was equal to 124 you would put 'case 124'??

I am assuming in that situation it would probs be easier to use if else if ladder???

A switch statement is best to use when there are many cases .. but it is all based upon a singular variable.

If you have multiple variables invovled, that is the time to use an if branch.

chaitanya karthikk wrote:Hi Henry I dint understand what you said. And please tell me what I quoted about multiple inheritance is correct or wrong.

Thank you in advance.

What he is saying is that in your second example, the compiler/run-time will make no differentiation between interface A.a() and B.a(). Since they have the same signature, return type, and name ... they are handled in the same fashion ... invoke a()

here is an example
public interface A { void a(); } public interface B { void a(); } public class Concrete extends A, B { public void a() { System.out.println("No other implementation, other than me!"); } } public static void main(String[] args) { Concrete c = new Concrete(); A a = c; B b = c; c.a(); a.a(); b.a(); }

OUTPUT:
No other implementation, other than me!
No other implementation, other than me!
No other implementation, other than me!


The only method that could be invoked is a() ... A,B will both refer to a().

You mention that the code will never stop ... almost sounded like unexpected behavior by the way you phrased it. This indeed, will never stop because you have no exit condition for the while loop, or alternatively, a method for breaking out of the loop. Fix this to allow you to terminate the app gracefully.

package socketserver; while (true) { line = is.readLine(); os.println(line); }



As for the code. I think the problem might simply be that you are setting your server app to listen on port 9999, while you are connecting with your client app on 25. Change it so that the two port numbers match.

There has to be a server app running for it to connect to, otherwise there would be no I/O connection. Since your list of details surrounding the problem are vague and sparse, need to ask whether you have a server app even running.

You could also easily test if you are even getting a connection because right now, your checks before attempting to read or write to the streams are insufficient. Checking for null won't cut it. You also need to see if it is connected with the following:
Socket s = new Socket("127.0.0.1", 5000); try { if (s.isConnected()) { //perform read/write } } catch (IOException e) { //catch any connection or stream errors }

Ernest Friedman-Hill wrote:It's a fundamentally flawed question, as standard JVMs have half-a-dozen or more threads running on startup, and that's not even counting the GUI event thread. Depending on which GC implementation is running, garbage collection can take as few as one or as many as three or more threads all by itself. There's also a Finalizer thread, a "Reference Handler" thread, a "Signal Dispatcher" thread, a "Low Memory Detector" thread, and the main thread, of course. There may also be Hotspot compiler threads!

I would imagine that the simple-minded "the main thread and the GC thread" is what the interviewer was looking for.

I definitely agree with this statement. I just found this tidbit.

Every application has at least one thread — or several, if you count "system" threads that do things like memory management and signal handling.

Alex Hurtt wrote:Assuming the application has no GUI, could the other answer be the main thread and the garbage collector? I would assume you'd have at least one garbage collector for each JVM process. (In other words, using Windows as an example, for each instance of the java.exe/javaw.exe process, one garbage collector).

Hmmmm I definitely would not be willing to repudiate your suggestion since I have spent a lot more of my time in the recent years working with C#. However, my intuition tells me that GC may be a part of the main thread. Garbage Collection isn't a process that is going on at all times. Objects are marked for GC but could take a long amount of time to actually be GCed (relative to processing speed). Therefore, I would not be inclined to suggest that GC would need it's own thread by default (that isn't to say that GC isn't executed on a asynchrnous thread started by the main thread). Many possibilities here.

I did a little reading on the Thread class in the Java 5.0 API

When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class). The Java Virtual Machine continues to execute threads until either of the following occurs:

This is interesting considering the question. However, it doesn't prove that there isn't a second thread of a daemon type.

Exerpt from Oracle's Threading Tutoria: http://download.oracle.com/javase/tutorial/essential/concurrency/procthread.html

But from the application programmer's point of view, you start with just one thread, called the main thread. This thread has the ability to create additional threads, as we'll demonstrate in the next section.

What you need to do is discern a way to separate your View (the drawing process) from the Model (the game state and logic). Make classes that perform all the logic you want to implement. Then create some shared set of classes where it stores the results of your Model logic.

Then just simply rewrite you View (drawing classes) to access the shared ones. Now you have decoupled the View from the Model. A classic example of this is using a Design Pattern called The Mediator. If you google Mediator Pattern you will find plenty of tutorials on how to adapt your code to this concept. It's fairly straightforward.

A word of caution. After you have had a chance to study the mediator concept ... you'll find it tempting to stuff all your "middle-man" code into ONE class. If you do, you might as well title the class as public class GodClass {} =P

Make every attempt to divide the in-between logic into multiple mediator classes so that it will be easier for you to debug and make changes that won't cascade (i.e changes that require you to make more changes to existing code that is already working)

The Main thread (I don't know the given name for it, if any) and the Event Dispatch thread. As the name implies, all Event Driven callbacks occur on this thread. It's a big one used in GUI development (for example).

You can't cast to it at Compile time if I am understanding your question correctly. When using Reflection, you are essentially giving up compile-time type checking and all the conveniences that come with it in order to gain the ability to "dynamically cast" as people seem to always describe it. Read up on Reflection and examine some coding examples. Reflection is tedious, run-time error prone (if not carefully coded), and if I remember correctly ... has a lot of overhead associated with it (not sure on this one). So be careful about how and when you decide to use it.

Someone in an earlier post mentioned a much simplier design ... it won't scale well but if you are only handling 4 or 5 classes and interfaces tops ... then creating a switch block of if block and using instanceof would be the best (meaning easiest) route. =D

GL

Let's not waste forum space on posts like this. It's inappropriate and every CS/IS major, dev, tech etc.... has enough braggarts to deal with as is and no one is interested in having you report on an inaccurate detail in some book you forgot to mention the title of. To top it all off, it is not very stimulating as a topic as is ... not even open-ended.

regards,

Cox

Answer to my own question. revalidate() was on the right track ... I knew it was a method similar in appearance to this one.

The class Container has a validate() method which forcing the container to lay its elements on the screen again.

1.5 API

public void validate()Validates this container and all of its subcomponents.
The validate method is used to cause a container to lay out its subcomponents again. It should be invoked when this container's subcomponents are modified (added to or removed from the container, or layout-related information changed) after the container has been displayed.


Overrides:
validate in class Component
See Also:
add(java.awt.Component), Component.invalidate(), JComponent.revalidate()

So I simply called validate() after dynamically modifying th component

When the item is added it is not visible within the container until I resize the container. I tried calling repaint() on both the added component and the container but still doesn't update the visibility.

I am rusty with swing right now.
I know this is something silly, can anyone point me in the right direction?

Thanks