g****y
发帖数: 323 | 1 SDK 2.0
The following code:
interface A
{
}
class B
{
public A play(){
class C implements A
{
private C()
{
}
}
return new C();
}
}
when you compile it, how may class file you will get???
3??? no, 4.
A.class, B.class, B$1.class, B$1$C.class. Among those files
B$1.class infact are useless.
Why this will happen?
This is simplely because you | m******t
发帖数: 2416 | 2 Well as xt said one example would be when you want to give an event
handler which is only relevant to the current class. You have two
ways to do it nicely. One is to put it in the same class file but as
a separate class, while another one is to use inner class to
put it at where you register
your event handler. The first approach has two cons, compared with
the second one. First your event handler class will be visible to
the entire package. Second it offers less readability because a
code
【在 g****y 的大作中提到】
: SDK 2.0
: The following code:
: interface A
: {
: }
: class B
: {
:
: public A play(){
: class C implements A
| m***a
发帖数: 198 | 3 To me the most frustrating thing about inner class is like:
//-----------------------------------------------------------
class A{
protected int a=10;
}
public class B{
class C extends A{
}
C c;
public B(){
c=new C();
}
public static void main(String args[]){
System.out.println(new B().c.a);
}
}
//-----------------------------------------------------------
【在 m******t 的大作中提到】
: Well as xt said one example would be when you want to give an event
: handler which is only relevant to the current class. You have two
: ways to do it nicely. One is to put it in the same class file but as
: a separate class, while another one is to use inner class to
: put it at where you register
: your event handler. The first approach has two cons, compared with
: the second one. First your event handler class will be visible to
: the entire package. Second it offers less readability because a
: code
| xt
发帖数: 17532 | 4
Well, there is a third way, and we usually use this:
implement the event handling interfaces in the same class, then
add this as the event listener.
If the event handling is not terribly complicated, this is a good
choice, which give nice integrity of code. The implication of this
method is possible memory leak. Therefore when the object is no
longer in use, makes sure the event handler is removed.
We have built our product with about one hundred windows in the
GUI with this, and it really give
【在 m******t 的大作中提到】
: Well as xt said one example would be when you want to give an event
: handler which is only relevant to the current class. You have two
: ways to do it nicely. One is to put it in the same class file but as
: a separate class, while another one is to use inner class to
: put it at where you register
: your event handler. The first approach has two cons, compared with
: the second one. First your event handler class will be visible to
: the entire package. Second it offers less readability because a
: code
| m******t
发帖数: 2416 | 5
It certainly does! Or technically it does. 8-)
the garbage collectors in most JVM's use memory marking
instead of reference counting so that they can handle circular
referencing correctly.
Most memory leak problems in Java come from the underlying JVM
itself because JVM's are usually written in C++.
【在 xt 的大作中提到】
:
: Well, there is a third way, and we usually use this:
: implement the event handling interfaces in the same class, then
: add this as the event listener.
: If the event handling is not terribly complicated, this is a good
: choice, which give nice integrity of code. The implication of this
: method is possible memory leak. Therefore when the object is no
: longer in use, makes sure the event handler is removed.
: We have built our product with about one hundred windows in the
: GUI with this, and it really give
| xt
发帖数: 17532 | 6
Maybe in 1.3. But in 1.2 it is not happening. That's why we actually
solved the memory leaks. The only memory leak, and it is ridiculous,
we did not solve is this:
When you open a window, set focus to a JTextField, then as the cursor
blinks, it takes momory. We have observed a 12-16K/blink memory leak.
Obviously Sun is aware of this, since there are quite a few bug
reports on this. They didn't want to fix because they don't think it
is a bug - it will be gc'd in the end.
I think it is one of th
【在 m******t 的大作中提到】
:
: It certainly does! Or technically it does. 8-)
: the garbage collectors in most JVM's use memory marking
: instead of reference counting so that they can handle circular
: referencing correctly.
: Most memory leak problems in Java come from the underlying JVM
: itself because JVM's are usually written in C++.
| xt
发帖数: 17532 | 7
this is not quite true. We do have different GUI objects having
different semantics. For example, the "Back" "Next" "Cancel" "Finish"
buttons on a wizard. We do it with the same class. The way to do is
to find out the source of the event, and handle it differently.
Of course, it takes a linear time complexity to do this. But it won't
take much time, considering
the number of objects a frame is usualy very small - there is no reason
for a reasonable GUI to get that many objects in a single windo
【在 m******t 的大作中提到】
:
: It certainly does! Or technically it does. 8-)
: the garbage collectors in most JVM's use memory marking
: instead of reference counting so that they can handle circular
: referencing correctly.
: Most memory leak problems in Java come from the underlying JVM
: itself because JVM's are usually written in C++.
| m******t
发帖数: 2416 | 8
I'm not worried by performance either. 8-) You usually learn to
forget what you learned from the algorithms course one year after
you get a real job. 8-)
Your approach certainly works, and works well. However, I wouldn't
use it in my design if ever possible. The reason is simple - you are
mixing multiple functionalities in one function, and using control flags
to sort them out. It's like taking an object reference in the base
class type, and using a switch to check which exact subclass it b
【在 xt 的大作中提到】
:
: this is not quite true. We do have different GUI objects having
: different semantics. For example, the "Back" "Next" "Cancel" "Finish"
: buttons on a wizard. We do it with the same class. The way to do is
: to find out the source of the event, and handle it differently.
: Of course, it takes a linear time complexity to do this. But it won't
: take much time, considering
: the number of objects a frame is usualy very small - there is no reason
: for a reasonable GUI to get that many objects in a single windo
|
|
