不少时候 咱们写的Java程序是分模块的,有很好的扩展机制,即咱们能够为咱们本身的java类添加插件,来运行未来某天咱们可能开发出来的类,如下称这些类为插件类。java
下边是一种简单的实现方法:c++
Class A 做为程序的主入口,其中包含了程序的执行入口(main)函数。而后在main函数中经过外部的配置文件,而后经过外部的配置文件,咱们能够得到插件类的信息(位于哪一个jar包,jar包的具体路径),而后得到jar包中某一个类的实例,来完成相应的工做。这个jar包极可能是外部的jar包,是咱们本身写好的,那么咱们放到哪里,他才能本身找到呢?我尝试过不少次,除非将其具体目录,放到class_path中才能够成功执行,不然报的异常只有一个ClassNotFoundException,就是找不到类。不过还有一种方法,就是将该jar包解压到运行jar包所在的目录,这样就能够经过class_path中的.来得到相应的类了。不过这样会显得很不专业,java写出来的东西都是jar包啊,本身感受的。放到claspath中,不能每次写出新的jar包都配置一遍吧!bootstrap
如此出现了以下的解决办法:dom
想了解解决办法的含义,首先要了解java的类加载机制。众所周知,程序若想执行,必须加载到内存当中才能成功执行。java程序并非可执行文件,由许多独立的类文件来完成。因此java中加载程序是以类为单外来完成的。这也就须要咱们来简单了解一下java的class loader加载机制。ide
java程序开始执行,遇到的第一个classloader是bootstrap classloader,这个classloader是用c++语言编写,经过他来完成加载java中的核心类。第二个classloader是extension classloader,加载的是jre/lib目录中的ext目录中的jar包。而后第三个是system classloader,也被称为应用加载器,主要负责完成加载-classpath 或者系统中的全局变量ClassPath中的类。System.out.println(System.getProperty(“java.class.path”));能够得到classpath的配置,也就是system classloader 加载的类,第四个class loader多是用户自定义的加载器,来自定义加载类。一般一个类的加载过程是这样的经过当前的类加载器的父加载器尝试查找,若是没有再找其父加载器尝试加载,直到最终的bootstrap classloader为止,若是尚未找到,那么就开始从上往下加载类。这样作的目的是防止自定义的类来覆盖系统中的类,若是没有这种机制很容易出现这种笑话,本身写了一个String类,而后new string的时候是本身写的String类,这样就比较好玩了。函数
1.本身定义URLClassLoader对象加载外部jar包,针对jar包里面再也不出现别的jar包的状况,即只解析.class文件:学习
以上的这种状况能够在别的project项目里写test方法,是平时最经常使用的,若是当.class文件里有依赖别的jar包里的对象的时候,就要把该jar包拷贝到写此测试方法的project并buildPath,否则的话运行的时候会报找不到Class对象的异常。测试
2.第二种状况是针对加载jar包里面的jar包的Class对象,还有读取某一个properties文件的方法。ui
3.第三种状况是在该项目下获取某个包的Class对象,固然了,测试方法是在该项目下写的(这样classLoader就直接能够知道对象了,不须要再自定义URLClassLoader了,用Thread.currentThread().getContextClassLoader().loadClass(.....)就能够直接得到Class对象了,回去ClassPath下找,System.out.print(System.getProperty("java.class.path"))就能够找到classPath路径)。url
下面上第二段代码
好了,大体就是这样,好好学习,每天向上!哈哈~~
补充:
4.读取jar包中的entity_pk.properties键值对到项目本地entity_pk.properties文件中
5.读写db_config.xml文件