解惑

解己之惑,解人之惑

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

新成就Get:Java的bug

搞了这么多年Java,总算是让我逮住一个Java的bug,Java不能正确的处理未经压缩的大Jar包:JDK-8223811

最开始怀疑是第三方的打包库导致的,后来进一步验证确定是Java自己的bug,因为使用jar命令打出来的包也有同样的问题。

出现的异常信息是:java.util.zip.ZipException: invalid LOC header (bad signature)

那种Jar包读取metadata都没有问题,使用第三方软件解压读取也都没有问题,唯独使用Java自己的代码从JarEntry获取InputStream读取的时候会出错,另外使用jarsigner -verify去验证jar也会出问题,估计内部实现也是调用了同样的代码。

Java为什么没有SharePoint

前几天老大想知道什么是SharePoint,我就负责研究这个东西了。刚开始就认为它只不过是MS的一个产品而已,就像Office一样,但是仔细看过以后才知道,SharePoint的目标远不是这样的,SharePoint的目标是Business Buidling Framework,就像很多国内的小公司想做的快速开发框架一样,它提供很多功能,你不用写代码拖拖拽拽的就可以搞一个自己的网站,而且还在一定程度上是定制的,当然,你也可以写代码扩展系统默认的功能。
到目前为止Java业界并没有一款类似的东西,为什么?因为Java是个大的生态环境,百花齐放,某个领域有一个或者几个成功的东西,但是还没有一个完整的解决方案,当然,也有很多人在试图构建一个这样的Building Framework,只是都不够重量级,而MS,就够这个重量级,因为.NET下的那套东东,都是它自己的东东是王者,即使不是最好的,使用的人也差不多是最多的,用它的捆绑策略,也基本上慢慢做成是用得最多的,于是乎,这个诞生于若干年前的东东现在逐渐变得流行,势不可挡。

从Java转向.NET需要注意的问题

从Java转向.NET已经一个多月了,最开始的时候很轻视,因为C#和Java语法相差不多,真正开始写代码开发应用以后才发现很多的不同:

  • 开发工具几乎没得选:Visual Studio,既然用了MS的东西就得都用,否则遇到问题很难得到帮助,因为别人都是用的这一套。
  • Visual Studio给你封装了很多东西,有些开发因此变得很容易,但是也因此不能很灵活可控。而且你很难也往往不需要知道很多底层细节(例如写Web Service的客户端程序,添加一个Service ReferenceVS就会生成代码,根本不需要懂SOAP的细节)。
  • 你需要了解Windows平台的很多东西,例如安全机制,ODBC,Profile等等,而Java是跨平台的,这些配置以及安全等等都是作为jar包的方式引用和使用的,根本不应该依赖Windows内置的机制。
  • .NET有时候会使用很多遗留的东西,例如DLL,COM,而且因为版本不一样不见得好用,而Java比较简单,几乎只有jar,虽然也有版本问题,但是要知道jar里面包含那些类还是很容易的,但是DLL和COM之类的就很麻烦,似乎没有很好的工具帮助你查找哪个DLL或者COM有你需要的类。

现在还是刚刚对.NET有点感觉,没有被搞得头晕脑胀。

最后说一下,如果不是逼不得已,不要转向.NET,Java乱是乱了点,但是资源是大把大把的,而搞.NET,还是跟紧MS吧。

开始学.NET

我加入EMC本来是做Documentum的SaaS的,所以需要使用Java作为主要开发语言,但是我们的那个项目最终没有立项,现在SaaS的目标改为SourceOne了,而SourceOne是使用.net开发的,我们现在要做一个原型,最快的方法当然也是使用.net开发了,所以我们也就顺理成章的需要学习.net了。
还好我对windows平台并非一无所知,大学以及工作的前半年都在搞vc++和VB,对微软的东西还是有点基础的。
搞了8年的Java,看了两天c#的语法,最初的印象就是c#的语法太杂,虽然c#号称对c++进行了简化,但是我的感觉是完全没有简化,c#只是取消了c++的多重继承、指针以及内存管理,其他的东西并没有减少,相反还有一些新的东西出来,例如事件、对象索引器以及域和属性的分离。另外一个感觉就是c#的保留字太多了,以java的final为例,c#在不同的情况下需要使用readonly,const, sealed等关键字对应。
现在对c#还不是很清楚,需要再看看更好的书学习一下语法方面的精髓,特别是有书能够讲讲为什么那么设计就好了(也许仅仅是为了兼容性?)
最后推荐一个比较好的java和.net的对比的文章。

一个通用的面向对象的查询接口

现在做持久化基本上都会用到ORM,现在最通用的解决方案当然就是Hibernate以及由之引申出来的EJB3的持久化方案,我们在做DAO层的时候经常是直接写HQL,并不是说它不好,而是不够通用。例如本来有个功能是查询某种类型的User,但是需要额外的过滤和排序,那么就需要拼HQL的,不太好维护,所以有一个面向对象的查询接口还是比较好。
下面就是这个雏形,是我现在的项目中用到的,抛砖引玉吧。
下面是全部的类和主要的方法,其他的方法都忽略了,可以到Google Code下载全部的源代码。
阅读全文

GAE支持Java了

今天同事发的邮件知道了这件事情,确信不是愚人节节目了。
http://code.google.com/intl/zh-CN/appengine/docs/java/gettingstarted/
http://code.google.com/intl/zh-CN/appengine/docs/java/overview.html
http://code.google.com/appengine/docs/java/tools/eclipse.html

看来我的my-scrum得迁移语言了,虽然Python是很好的尝试,但是还是更加熟悉Java一些。

搭建自己的云:Hadoop

呵呵,原来自己也可以搭云玩了,而且是Java的云,这是apache下的开源项目,是根据google发布的一些论文构建的,虽然根据这位老兄的实验,在集群环境下的性能并不是特别理想,但是还是值得一试的,毕竟代表了最先进的IT技术之一嘛。最后提一下这个Hadoop中文研究院,有兴趣不想看因为的可以看看这个网站。

性能测试

上周基于JUnit写了个简单的性能测试框架,其实就是用了下Annotation,发现还是很好用的。

/**
 * Performance test annotation.
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface PerformanceTest
{
    public String name() default "";
    public int times();
    public boolean stopOnError() default false;
}

阅读全文

查看Class文件的版本

呵呵,同事的类编译出来以后在Tomcat里面运行一直报错,说类版本不对,他已经把JDK1.6卸载了,上网查了下,一个简单的类就可以读出class文件的版本:

import java.io.*;

public class ClassVersionChecker {
    public static void main(String[] args) throws IOException {
        for (int i = 0; i < args.length; i++)
            checkClassVersion(args[i]);
    }

    private static void checkClassVersion(String filename)
        throws IOException
    {
        DataInputStream in = new DataInputStream
         (new FileInputStream(filename));

        int magic = in.readInt();
        if(magic != 0xcafebabe) {
          System.out.println(filename + " is not a valid class!");;
        }
        int minor = in.readUnsignedShort();
        int major = in.readUnsignedShort();
        System.out.println(filename + ": " + major + " . " + minor);
        in.close();
    }
}

major  minor Java platform version
45       3           1.0
45       3           1.1
46       0           1.2
47       0           1.3
48       0           1.4
49       0           1.5
50       0           1.6

原文在这里

Java的一些不易碰到的限制

这段时间在公司听到的,我想大部分的人都不会遇到,有次可见糟糕的代码风格会导致什么问题。

第一个是JSP太复杂了,包含了很多的JSP,最后为了修改一个BUG,增加了另外一个小JSP,结果发现JSP编译出错,出错原因是方法体超过64K,不可思意吧。

第二个是方法参数太多,也是一个人为了修正一个BUG,需要增加两个参数,结果加了以后发现编译不过,原因是JAVA只能允许255个参数,而那个方法原来就定义了254个参数,后来的方法是把要增加的两个方法丢到一个Collection。

呵呵,天下之大,无奇不有。

更早的文章

© 2019 解惑

本主题由Anders Noren提供向上 ↑