Picses' sky

据说核心api也不是一样的，jfc本身是一个一栈式的api库，底层基于的jni是固有的，android并不是从底层照搬这种类层次结构，但Harmony作为遵循java标准的虚拟机实现必须提供标准的api实现，所以android从api级别也不是java程序员可以容易过渡来使用的，基本上说，android只是借鉴了java的语法和一些api接口样式，本质上是完全不同的语言平台。
另外，楼主写得实在有点言过其实了，google的android面向的是手机平台，追求的是自由和创新，那它在未来必然也会因为java语法上的对底层不友好而采用和.net同样的方式——指针，然而基于Harmony的实现应该不支持这样的做法，到最后，Dalvik必然会脱出Harmony的束缚，成为彻头彻尾的另一个.net, android有点挂羊头卖狗肉，它影响不了java。

下来看看。

呵呵，支持。
有时候会顿一下，是解码器的问题还是gc调用引起的？

ruby了解下，d语言也了解下，关心一下编程未来的走势。

2歌词目录最好做成可指定的，方便很多
3标签修改可以两种做法，一种是你播放歌曲本身就是一个缓存的文件，而不是真的文件，第二种就是等到下一首歌再把当前的标签实际修改进文件，而立即生效的是播放列表的显示而已。

受教了。

高效的开发，良好的架构，KISS的哲学，也是java比其他语言更多关注的东西，毕竟你不如人家快，但语言本身的优雅和灵活使你在这方面能比其他语言更容易提升，最后才是效率考虑和优化，当然，这有一个大前提，那就是功能架构的时候你就想清楚了正确的方向，因为大的方向上是正确的，所以可以不用过早的优化。

最后的这个方法：
private static String getBB() {
return "b";
}
如果加上final应该会内联吧，说不定还是可以的哦。

佩服,用debug应该很能说明问题拉.

很有道理，设计确实不是一蹴而就的，只要遵循了好的模式和思想，体系就自然能够解离和扩展。

确实很强大，可以方便地做成电子书或导出成网页，不过一直没找到好的破解，用起来有时会在页面边角留下未注册的文字。

既然提到了代码拖拽，那我也提一下代码复制和文件复制，eclipse从3.2之前就实现了这两点，而netbeans直到6才有文件复制。
代码复制就是你剪贴板中有一份完整的java源文件的文本(注意是文本，不是文件)，点选一个包ctrl v，就可以自动生成基于此拷贝文件名的java源文件，文件拷贝类似，也就是说你可以从netbeans中拷一个java源文件的文本粘贴到eclipse中并生成一个独立的java源文件，却不能作相反的操作，因为netbeans还不支持，从网上拷代码下来运行的人就知道这个功能有多划算了。
代码拖拽只是小功能，就如同refactor尽管不是小功能，但让它在后台自己运行同样只是小功能一样。
上面还提到jfiledialog，那是基于awt的，和使用swt的filedialog有什么区别，jfiledialog不能设置多个filter，功能比起swt也太过有限，swing优势在于仿生，所以jfiledialog可以作为项目中的替代方案，但拙劣的很。
eclipse还有个功能是大范围organize import，最大是基于所有包的，netbeans rc1仍未实现，且refactor中的包重命名，尚不支持subpackage，速度也很慢，猜想还在完善中，所以，netbeans要走的路其实还很远，是好是坏还是拭目以待吧。

ria可以为bs，cs通用，可以说是将来基于mvc实现的所有项目（不论大小）的表现层，基于不同程度实现的view多数已经接近跨平台的水平了，再加上炫丽的外观确实提高了交互，尽管我也同样对目前已知的ria质疑，却不得不说只要浏览器还没有过时，ria就还在壮大，等到浏览器过时了，ria就走得更远了。

android是指手机操作系统吧，当然系统里包括了google的java vm，核心api等，独立的实现，所以应该把这里的.dex当作gphone的专有语言程序了，它不是走跨平台的路线，只想自己用把。

确实发布了，首页上都给出图片链接了。试用感觉速度又提高了点，赞。

是啊，TreeCellRenderer提供组件只用来实现节点本身的绘制，但节点所占的空间大小却不知用什么设置，我试过tree的getPathBounds()方法，好像也不是，哎。

有个问题请教楼主，如何实现jtree针对不同节点的组件有不同的行高度，我现在被这个问题困扰了很久，想用拖拽来改变节点的行高，在DefaultTreeCellRenderer里处理重绘出来，但是在里面用setSize()怎么改都不行，网上没搜到这样的例子。

楼主真勤劳，赶紧去下载了。

楼上说的那本书好吗？讲哪方面的东西啊？
全局变量有时也会用到的，jvm很多借助类的静态的东西，那就是全局的了，否则很多实例引用在对象间传递起来过于复杂了。

看来大家都去看九宫格了，不错。
楼主的文章应该让搞界面的人都看看。

finalize和释放资源有关，但你说和析构有关确实容易让人想反驳，因为finalize并不是像析构函数那样让人手动调用的，功能和使用方式都没用相似的地方。
第5条没看懂什么意思，还有16说“C++ 中有运算符重载 , Java 里只有 + 号有重载的意思，不过在 JDK5 中也有其他的运算符重载，比如两个类对象可以直接相加”，还真没听说过有这回事，相加不就是用+，哪来其他的运算符。
泛型加入后可以说是充斥jfc，这是不可撤销的，所以sun很慎重，泛型真用起来完全让人摸不着头脑，我没用过模板，但c++实现一定更难于使用，我想表达的意思是，泛型让很多人觉得java难了，繁琐了，这本是选择java而非c++的理由，靠负责好面面俱到并不能让java更好用。

确实bug很多，beta2也是，升级了的swing app framework版本基本可以看得出轮廓了。但可视化界面操作是双刃剑，也可能会影响开发，我也喜欢swt，最喜欢的是eclipse的rcp，很好的框架，不知netbeans这方面做得好不好，ibm是很了不起的公司，看它提供的控件，提供的milestone的说明，感觉是很专业很为开发者负责任的在做产品。sun要多学点啊。

阿门，我这一辈子啊，还是赶紧转行得了，考公务员和考研的准备不能间断啊。当讲师需要资历和条件，一般都是干程序员干出点成绩来了才行。

老是想到有个什么东西可以，原来是Tracker，swt sample里有。还有就是swing实现透明窗格，最近才知道还有个jna，看这里：http://www.blogjava.net/ruislan/archive/2007/10/24/154689.html
只是不知是否可以跨平台了，我以前一直觉得只要能有透明窗格，swing也能有Tracker这样的东西了，现在又不确定了，因为透明ms上面的一切都变透明了，不知画出来的线还看不看得到，不然就只有用toolkit里的取capture的方法模拟桌面来实现。
还有个问题，为什么我以前装ubuntu的时候java不提供win L&F，在win下也不提供GTK L&F，如果是许可证的问题那我们以后要怎么用它的皮肤啊。

看楼主的文章，一时豁然开朗，gui原来可以是这样的，以前也下载过很多软件，最近才慢慢开始注意界面布局的特点和提供用户体验方面的东西，感觉欧美软件逐渐在界面上追求简单和易用，ComponentListener的思想有时比布局管理器容易和适合开发的需要。
楼主提到Java已经可以在桌面应用领域挑战C/C++,VB,Delphi等等，但是这类工具生成的是编译型的机器代码，具有高的执行效率和借助平台特有优势，尽管Java跨平台，又有JIT即时解释器在一定程度上提升运行速率，但是否语言级别和平台级别的一些瓶颈会成为它开发上的局限性呢，比如，我现在涉及对数据的压缩解压和即时取用，要求高响应的速度，我想可能的突破是好的算法实现，而这一层面上对数据结构的要求相对独特——针对位的操作，而Java的基本数据类型中，几乎是基于字节的，boolean在底层数据实现上也不例外（希望我没理解错），这在实现很多算法上并不理想，不知楼主的意见如何？
说到swt，我也先学了点swing再来学的，如果有说的不对的请指出，除了无法获得jdk的标准集成支持外，swt可以说在各个方面都胜过awt，之所以说awt是因为二者的实现是相似的对等体思路，swt在这方面作得很好了，那可以假设swt和awt在速度上是同一级别的东西，如果IBM现在搞基于swt基础之上的纯绘制桌面应用，就相当于在swing的同一级别之上，这方面IBM沾上边的象GEF,Draw2D可能有点联系吧，它有可能作到类似swing的程度和规模吗？就算不行差一点，但保持相同的速度级别我想还是有很大作用的，比较一下：awt是弱的，但基于其之上的swing是绘制一切无所不能的；swt是强的，而在其之上作为补充的纯绘制api也能成为其补充，在我看swt的介绍时看到这一句，对平台缺失的组件用Java绘制，这种绘制指的其实是用平台已有的swt组件进行组合获得复合控件，我看过eclipse Nebular项目，主要的自定义控件思想也是这样的，它一方面基于高效的本地控件来复合，同时也可能引入本地控件的问题。但是就现阶段来说，sun对swing的支持还未全面铺开到最关系用户切身体验的范围，举我上次评论说过的JFileChooser，速度和awt是秒和毫秒的差距，当然，这是可以通过编程手段来忽悠用户的，比如开个线程，在打开的第一时间在后台创建备用，就比如jdk demo中的swingset2的方式，但是，这比较让人难以接受，我只为了提供一个让用户选择路径的控件，用完就扔掉的东西，却不得不忍受全绘制界面带来的时间延迟，真的很不值得。
写到这里，只感觉脑袋空空，好像成不了文章了，只是还是想和大家分享，希望有人能讨论，希望想法没有浪费。

第一副图标签页下有横线，是viewpart没设焦点的原因。

两个功能都是依赖java5来实现吧。

java的浮点数据类型几乎毫无精度性可言，只能适应于近似计算，这倒不一定和芯片有关吧，你可以上网看看，看过之后估计对浮点数一点信心都没有了。
java线程实现是基于平台特点的没错，但同样可以保证跨平台的线程设计准确可靠地运行（前提是你设计得对），毕竟多核模拟出的是和单核相似的不确定性的线程执行情况，而确定性的编程设计才是基于这个之上的。

jvm是在底层用os实现thread的，所以线程问题在java中反而容易呈现因平台而异的现象，java能不能充分利用双核的硬件资源，是看对应的操作系统的实现的。
抢占和时间片，可以同时作为调度策略，所谓抢占，也不是优先执行，根据实现不同，可以是时间片加长，或者轮替几率加大。

我截了图
http://www.blogjava.net/Files/djsl6071/桌面.rar
第一张是正常情况，第2，3张分别显示向上、下拖动时出现的缺失。
你可以用windows自带的图片查看器打开，并放大，仔细看虚拟滑块的边缘。

进一步观察发现，lz的代码运行时虚拟滑块的边缘往往缺失，结合上一条评论谈到的，我想移动滑块时重

绘的是移动操作的上一次tempLocation指出的旧滑块的区域，而我们想要看到的新滑块的区域，并没有全部被纳入重画的范围，修改的方法：
redraw(tempLocation, 0, TEMP_H.getBounds().width,TEMP_H.getBounds().height, false);
tempLocation = valueToPels(getValue()) + movedX - TEMP_H.getBounds().width / 2;
redraw(tempLocation, 0, TEMP_H.getBounds().width,TEMP_H.getBounds().height, false);
还没想到更好的方法。

redraw(tempLocation, 0, TEMP_H.getBounds().width,TEMP_H.getBounds().height, false);
是只重绘temp thumb原来的区域，因为slider本身添加自己为PaintListener，故重画的时候paintControl被调用，那么paintControl方法作用的是整个图形区域还是temp thumb原来的区域？如果是后者，那新的temp thumb所在的区域由谁在何时绘制？ 如果是前者，重绘的不还是整体而不是thumb的区域吗？

Swing是Java平台的标准桌面实现，awt的早期的成型为Java技术在桌面的发展奠定了坚实的基础，最底层的实现显然是对等体来铺垫的，往上走产生了两种不同的思路，Swing和SWT，他们生来都是为了一个目的，让Java更好用，更多人用，Swing是了不起的框架，经典的设计，复杂而灵活，SWT晚出生一点，它是看着Swing的不足在发展自己的，它一出生并没有想过和Swing争，所以只是从实际的产品除非，满足实际的需要，只是eclipse用得好了自然而然的想到借鉴它成功的因素，才想着复用自己的那一套，所以它一出生，就烙着便利软件产品的特点，即便是到了如今，JFace出来了，RCP出来了，哪一个不都是走在Swing前面，Swing开源的api也是有不少的，Application级的全栈式框架也不是没人做过，为什么sun从来都没有加入过JFC中，直到今天，Netbeans来了，带来了这一些，但还是没赶上SWT的，用过JFace的人都知道，IBM在其中开发了多少成熟的组件，Preference，Wizard，一个个很简单，却是现代软件产品中已经上升到了经典范畴的概念，Swing的api中有吗？还要复用多少次才会被加进去呢？
SWT的gc，它同样可以绘制一切，那它的速度不会比Swing快多少吧？Swing中有象SWT中的FileDialog那样借助操作系统实现的组件吗？我用过JFileChooser，速度比FileDialog起码慢5倍，创建完了不能释放，以便下次打开保持较快的速度，这期间占用了多少内存？跨越的基本是整个产品的生命周期，实际项目中，一个JFileChooser，足够否决Swing的理由了，何况象JFileChooser一样慢的，有多少个。SWT的一大弊端是jni，本地方法调用的时间消耗和内存管理成本会在运行时和编程上产生不利的影响，特别涉及纯Java对象在本地组件上的呈现，会是很大的问题，暂时并没有好的解决方法，主要是绕过，缺失某些极具表现力的界面效果，而一板一眼，中规中矩。
Swing没有错，错的是它身后的SUN，SWT并不是最好的，但它得益于IBM。从今天开始追来得及吗？除非你让我在Swing中用FileDialog，既然我已经可以多少用些SWT_AWT了。

从诞生以来，Java一直被认为是一个拥有面向对象的高级语言特性并拥有健壮稳定运行平台的技术，它作为语言和平台的双重身份而被程序员所接受，编写富于编程思想和设计模式体系的软件产品。
它的优点是虚拟机，使其轻易实现了跨平台，强大的垃圾回收和相当纯粹的面向对象编程法则，这些都是上层建筑，而在底层支持的，是一个仿真的机器，字节码的解读是以jvm的指令序列的方式，在底层，抛开了所有高级语言的特性，那就是接近汇编级别的指令。这样的层次结构，不仅有利于跨平台的实现，更有利于语言技术的自适应发展，随时调整自身的语法和结构，与时俱进。

你可以使用接口作为一种行为的协议，它可以实现自继承层次中的任何类（也就是它可以是任何派系）。
1.在没有关联的类之间保留相似性而不依赖类的(继承)关系。
2.声明多个类(它们多半是平行的，没有继承关系)中期望实现的方法。
3.展现一个对象的编程接口而不是它的类。(面向接口编程，ruby中的duck type的思想解释得很形象)
3.建立多继承模型，一种在一些oo语言中允许的一个类有多个父类的特性。

报告一个问题，本人用的是jre1.6.0_0.3，exe4j有个功能是搜索指定目录的jre，这个功能有个bug，如果你用刚重装windows的还没有装任何软件的操作系统测试，尽管目录中包含的jre的版本，exe仍会报错，提示缺少msvcr71.dll(这个文件其实在jre\bin下)，解决办法是把它放在exe的同一目录下，或者用exe4j中可以指定本地库的功能，在其中指定jre\bin为一个本地库，那个dll并非jvm所特有，所以可能有些人装了visual studio之类的默认会装一个到系统中去，所以看不出问题，希望lz验证一下，如果没问题的话补在你的文章的后面提醒大家。

lz很强啊，难道swing和swt通吃？

我最早是用textpad，eclipse的语法解析和内容助手是相当强大的，据说只有idea更强一点，netbeans和它同属开源产品，java世界里一般都能找到2个以上竞争性的且都不错的产品，有福了大家。

个人觉得如果从头学起，特别是jvm指令基础，可以配合学一下ant(moven则是ant将来可能的替代，好比svn和cvs)。类名方法名的记忆并不是必须的，可以“懒加载”。

@Raylong
不是的，java的数组就是对象，对象任何时候都是在堆中存储，像你说的“如果没有引用能到达{1,2,3}它会销毁的，如果int[] a = {1,2,3}; 包含在方法中，你说的没错。”前半句是没错，如果没有任何引用确实会销毁，a引用如果再赋值给其他变量(可能是全局的)，那么这个数组不会被销毁，让它在栈中存放是没有意义，如果这种情况大量出现明显影响jvm的使用，sun不会留下让程序员犯错误的机会。

swt就是jni实现的，所以它dispose的时候一定就释放了系统的资源(除非swt可能有的bug)，留下纯java的对象却是gc管理的，所以你确定dispose了的话问题就还在jvm内部，大的数据量一般会有缓冲机制，说到这里，不知你的程序是否依托于容器了，提供了对象缓冲池的实现，需要时获得对象，释放时直接归到池中，不作销毁，而是供下一次类似的请求直接修改并做二次使用，通过动态调整对象数量来适应不同需求。(但也可能内存占用增加就时由这部分的不合理使用产生的，看看容器有没有全局变量的使用，例如session之类的)

你上一篇中提到任务管理器显示占用增加，我觉得并不是程序在占用，而是虚拟机根据你程序使用内存的趋势不断要求系统提供更大的内存以保证程序的运行。

还有swt占用的系统资源不会由jvm管理，所以你对swt资源的释放对jvm内存占用没有影响。

给我一份吧
djsl6073@126.com

我也要一个，谢谢了先
djsl6073@126.com

@千里冰封
其实无论jdic，还是java6里采用的方式，抑或swt，本质都是jni的方式去解决这一问题，然后跨平台实现了。比起swt，swing才是真正的庞大，当然这也体现了它功能的强大以及速度的相对延迟，说道gui开发的首选，如果项目设计了和本地操作系统相关的，就好比这个浏览器，完全可以用swt了，毕竟它多少还是有跨平台支持的。

楼上说的在理，原帖是4年前的吧，那时java方兴未艾，完全oo的想法正流行，大家对oo也都还带有不同程度的误解，而今再回首，也许都看得开了。

以前也用相似的方法写过一些其它的东西，比如可以自由拖动并显示背景的半透明窗口啦，放大镜啦，结果都以失败告终了，主要是无法随背景的更新而更新，能够更新的又无法保证效率，楼主有没有兴趣尝试一下。

看冰封说的，swt还是不错的，老实说觉得用swt和用vb之类的差不多，简单点，追求速度，用户满意度，但由于并非由jvm控制资源，很难获得稳定性。swing的架构那是经典mvc，在配以jvm的呵护，自然是优秀的，简直是媲美j2ee的架构啊。

听说java中时间的操作有一些不是很精确，不清楚具体指哪一块，楼主有没有研究呢，感觉用calander会好点.

UI delegate 是swing在mvc基础上加的一些提高灵活性的扩展，外观同样是随操作系统本地的外观呈现的，awt只是swing最底层的基础，老实说这个基础薄弱而且过于依赖平台对等体，swing就好像借awt这只鸡生的蛋，用的只是那个壳，而绘制了其他的一切来确保了几乎没有平台差异，可能用惯了swt的对awt不会怎么反感，但是用惯了swing的却不会想去用awt。
觉得setUI的方法确实比在button上编码修改好，起码可以动态装卸。其实swing只对平台共有的个性化组件使用了UI delegate，自然是认为这些组件才被用户视为理当呈现为平台上的样子，而如楼主的这个例子，使得任何平台和任何laf下按钮都会是同一个样子，谈不上有什么问题，这个看项目的需要。
swing是个不错的平台差异化下桌面解决方法。

个人也觉得oo中会出现一些问题,这些问题随着技术和思想的进步日渐凸现.

但就本文的观点,其实谈不上是oo的封装和继承带来的,很多往往是我们设计人员的疏忽.

比如第一个stack的例子,ArrayList是明显的jfc,继承自它是完全没有必要的,除非你的类在抽象空间中能够真正代表ArrayList类的一个特殊子类集合,面向对象优先考虑抽象空间的完美而不是效率和实现空间的简便,这是规则,也是出于ood的要求,在这个实例中,明显应该用聚合而不是继承.

抛出异常的问题,对不支持的方法抛出异常过于拙劣了,完全可以在继承树的层次上加上抽象类,很好地分叉,而不是依赖有限的异常处理机制,异常处理在面向对象构架中算得上相当游离的一个功能了,尽管看似也有类的继承关系,但独立的捕获和处理,并不适合作为业务逻辑的相关环节实现.

oo的问题个人觉得很多在继承层次的复杂性，jfc库继承层次过多，导致无法查知当前方法的具体调用栈位置——也就是具体方法的实现方式往往被复杂和繁冗的继承和封装掩盖，让人摸不找头脑，不知道过程逻辑究竟在何处实现，也就无法最大限度地学习已有的类库（当然，只是学习和修改，因为使用是不需要知道了，毕竟封装就是为了屏蔽实现细节。）