发信人: zombies()
整理人: zjxyz(2001-05-10 21:55:36), 站内信件
|
【 在 wangf (原) 的大作中提到: 】
: paint(Graphics g)这个方法在Applet和其他一些Application经常出现，
: 这个方法是否象VC中的MFC里的虚函数一样需要重载，所以我们在自己的代码
: 中经常是把绘图部分写在该方法中？那该方法所用的Graphics实例从何而来？
: 我说的是系统调用该方法时，所传入的g是用什么方法得到的？
1. paint()主要被用做handle repaint event. 如果你写的是component,你
希望它被显示在screen上,那么overried paint()是个简单的办法,你不必
去理会何时这个component需被刷新. 这个graphics从哪里来,并不重要,
你也不必去理会. 你的drawing method在那里也不重要,关键是如果你希望
system refresh你的drawing,那么最好在paint()中调用你的drawing
method. 不过注意,在swing component中,你最好用paintComponent()而
不是paint(),因为swing需要paint()来做layer.
: 2、在使用JBuiler Help和WebSphere的管理控制台时，程序运行得特别的慢，
: 从界面上看，这两个程序应该是java application，我想，java的速度还是
: 跟不上，看来applet和servlet才是java的出路了，但applet下载和初始化的
: 速度也一样的慢，所以java进一步的发展空间应该在web服务器端，如EJB等。
2. Java 作为platform,提供了各种framework做不同的开发用途, GUI是其中
的一部分,也是很重要的一部分,作为标准awt,swing,设计简洁明了.但是
在性能上它们依赖于本地机器的GUI系统,也就是说在VM上运行的Java程序
需要通过本地GUI服务来运作,哪怕是swing,它大量依靠native的drawing.
(如peer graphics). 这样GUI的性能往往取决于JVM和native os, 它们
如何提高这两者的合作性能是关键, Sun下一代的HotSpot for client VM
会这方面有所改进. 但是如果VM本身是native的话, 可想而知.....
: 3、从C的socket编程转换成java的socket编程，发现java的socket不是那么
: 好用，没有异步类，只能开线程，中文问题解决不好，还有一个老问题，在利用
: TCP传输数据过程中，如何在对端socket断开或关闭时及时得到通知？给一个样
: 例程序好吗?
3. Asynchronize Socket或Unix上的 select方法都是在Thread尚未流行时
提出的解决办法. 当时,大多数unix系统尚未支持Thread(只有process),
所以只能通过这种办法来解决异步通讯. 而java是全新的系统,从开始就
有Thread支持,所以没有必要在沿用旧的模式.如果你利用Inputstream和
OutputStream, 其本质是在一些资源上读取和写入数据, 而close的作用
是释放被占用的资源. socket符合这种情况,所以他用inputstream和
outputstream. 至于怎么read,buffered? filtered?这些都不是socket
的问题. 所以用readline在socket上和用readline在file上本质上是一
样的. 正如file的情况,如果disk突然坏了,你的read就会给你一个
IOException,在socket上, 如果对方把socket关掉了,你还在往上写,
等同与往没有的资源上写,一样IOException.
怎样编写你的protocol以保证两边同步有很多办法. 简单的说,
A: out write("END") -> socket close
B: in read -> if read content is "END" - >socket close
根据上列考虑是种状态:
1- A的lifecycle中只能在最后写END, B就能知道何时该关闭socket.
两边同步.
2- A在写的过程中突然停住处于wait状态,但它不close socket, B
的读就会block,直到 A再次写或 A close socket.
3- A在写过程中socket意外端掉, B会catch一个 IOException.
4- A写完了,但它不写"END"就把socket关掉, B没有收到"END"所以
继续读, 结果读在没有的资源上, B会catch一个 IOException.
如果你用BufferedReader,那么它可能会处理了第四种情况,而返回
给你一个null string.
由此可见,在这个Scenario中的四个结束状态中只有状态二是会引起
block的(不是很流行拒绝服务吗?)
: 4、目前java的class及容易被反编译，我所知的一个DeCafe Pro是其中的比较
: 强大的一个，有什么方法能避免开发者开发的程序给反编译出来呢？
4. 可用SourceGuard 3.0 offuscation, 这样一般的decompiler没法
反编译, 就算行了,看到的也是 a,b,c,d 等没有意义的class name和
field name. 根本没法解读.
--
Zombie
ICQ:6256854
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 203.101.49.2]
|
|