解惑

解己之惑,解人之惑

标签:Java (第2页共6页)

JConsole

这个好像是JDK1.6里面新推出的,和JBoss的JMX-Console的功能类似,只是这个是GUI的,而且需要远程的服务器启动一些服务,在应用服务器的启动中修改以下配置(就是修改JAVA_OPTS):

-Djboss.platform.mbeanserver -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl -Dcom.sun.management.jmxremote  -Dcom.sun.management.jmxremote.port=9998 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

The method getXxx() is undefined for the type Yyy

今天遇到这个问题都快崩溃了,那个方法明明定义了,在JSP中用反射拿到类声明的全部方法并打印出来都可以看到的,但是修改回来后就是编译不过。
Google了下,也是很多人遇到,但是没有人解决,有人说是tomcat的问题,不太相信。
突然想到我的工程是hot deploy的,那个class有两份,一份新的一份旧的,jboss的tomcat在编译那个JSP时用的是旧的类,运行时用的是我Hot deploy的新的类定义。
重新编译发布整个工程,问题解决。

List的问题

今天遇到一个奇怪的问题,从一个List取一个SubList,然后对从SubList删除某些元素,然后再从List里面删除SubList里面剩余的元素,但是所有的删除都没有找到匹配的东西,并没有删除成功,但是原来的List出问题了,它的内容出现不规则的变化,有时候变成0,但是有时候不重新取数据的话还能恢复成原来的状态。
呵呵,怀疑这个是JDK的bug,但是没有时间验证了,做个记号。
现在的解决方法是拿到subList后再创建一个新的List,把SubList的内容加进去,这样就没有问题了。
从JDK的API看,从List得到SubList只是得到了原来的List的一个view,所以进行这些操作的时候原来的List和View之间在进行处理的时候可能有问题。

JDK5中没被重视的重要特性:instrumentation

我们的产品中使用到这个特性了,主要是加载Jboss的AOP,另外Oneal的单元测试使用到了这个特性,使用的是jmockit,然后在Javaeye看到一个文章谈到性能优化,使用的是jamon,developerworks上也有两篇文章( Java 5 特性 Instrumentation 实践Java SE 6 新特性: Instrumentation 新功能 ),需要好好关注下。

Java远程调试

其实就是使用了JDK的JPDA,在启动服务器(Jboss或者Tomcat等)的命令行参数里面加上:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n

以Eclipse作为调试工具的话,创建一个Remote Java Application,连接参数填写正确的IP和端口(就是上面的8787)就行了

得到当前方法

在写代码的时候我们可能会需要当前的方法名,特别是在输出一些调试信息的时候,但是如果使用字符串硬写的话不太好,API好像也不带对应的功能,如果细心的话,异常信息里面是带出错的方法名的,我们可以dump stack trace并分析得到当前方法的方法名,实际上有更好的方法,和dump stack trace类似:
public static String getCurrentMethodName() {
    StackTraceElement element=Thread.currentThread().getStackTrace()[3];
    return element.getClassName()+"."+element.getMethodName();
}
为什么是3呢?从0到2分别是:
java.lang.Thread.dumpThreads
java.lang.Thread.getStackTrace
xxx.Xxxx.getCurrentMethodName:也就是你定义这个工具方法的类

文件删除不成功

Java的功能在某些地方确实很有缺陷,File的delete方法就是一个很大的问题,如果文件被使用而不能删除,那么这个方法调用是不会抛出异常的,也不会返回任何信息,就像方法调用根本没有发生一样。由于是临时产生的文件,如果不能删除,那么文件越来越多就可能撑爆硬盘。
方法当然可以有一些,例如可以加一个线程不停的试,,删除不成功就等待一段时间,直到删除成功,这个方法应该是比较有效的,因为大部分情况下,文件只是临时被占用,可能前后就差那么几百毫秒,当然,这个方法不完美,还是可能有漏网之鱼,明天再好好想想方法了。

保持开放的思想

今天突然发现自己原来对Ruby和RoR的抵触是完全没有道理的,因为自己理想中的Java开发框架和RoR的很多思想其实是相同的,可能是太喜欢Java,使用的时间也太长,任何对它可能构成威胁的东西都会有本能的反应了?
其实Java语言本来也是吸取其他语言的精华而创建出来的,每当有一种新的语言诞生的时候,也同时意味着它必定有什么优势,否则是很难被人接受并被广泛使用的,如果本着学习的精神,我们其实可以从这些新兴的语言身上学习和借鉴这些优点,并努力借用到Java的开发中,除了语言本身的限制,我们应该是可以借鉴很多。
我想如果一个掌握OO设计的高手去使用汇编或者C语言做开发,那么他在OO中学习到的一些东西肯定可以借用到这些语言中。

PS:Java世界一直没有出现我期望的框架,我自己也在尝试做一个,需要研究研究RoR了,很多规则或者思想可以借鉴过来

Java序列化确实很慢啊

我们的系统还使用古老的Ant1.5作为构建工具,而且做了一些定制(可能修改了部分源代码),我们就不能随便升级到高版本,而Ant1.5的那个Junit的task比较旧,运行每个TestCase的时候都是重新开一个新的VM,而我们的单元测试框架要读取很多EJB配置文件完成初始化,如果每个TestCase都去解析那些文件就太慢了,每个TestCase至少需要10秒,所以没有办法,我就把所有的Case都手工加到一个TestSuite,然后运行那个Suite,这样就不会重复解析那些文件了。但是手工把那些Case加到Suite里面也是很痛苦的事情,就想到把那些解析的结果缓存下来,最先想到的当然是序列化了,结果让我大跌眼镜,序列化的三个文件一共1.33M,而原来需要解析的XML文件有4.5M,有十几个文件,相互之间还有关联,结果解析那些XML文件只需要不到6秒钟,而反序列化需要7秒多!

Java磁砖

今天早上到新房子看了下,没有什么进度,但是看到了Java磁砖。
磁砖的中文名好像是乔意达,在旁边有个英文:Java,没有带相机,改天拍个照片贴上来。
上周六在九百买的时候没有注意,因为主要是老婆在挑,我们只看到超市的价格标签,没有看到包装盒,而那个英文名称是在包装盒上的。
也许这个只对我们做Java开发的人有点意思

更新:照片如下
Java磁砖
PS:我们买的时候这个磁砖挺便宜的,2.48元一块(原价是4.5元好像),300X450,在九百里面买的,而且九百搞活动,买1000减120,给我们装修的工头说质量不错,不过式样比较少,只有三种花色

更早的文章 更新的文章

© 2020 解惑

本主题由Anders Noren提供向上 ↑