你能够接受免部署方式访问Java程序的编程风格么

在开发Java程序时，或多或少都会用到一些Java类库程序，自己写的或其他人写的

 

我们需要将类库Jar放在开发环境的lib目录，然后使用，对于大多数企业项目来说，其实也不算太麻烦

 

不过我是做WEB开发的，自己的项目中也会部署其他组开发的jar程序，这些jar一变更，我就要全换一遍，麻烦！

 

而且有些jar的依赖关系还跟我自己的项目有潜在冲突的危险

 

我只想用，不想负责更新维护，更不想让别的jar污染我的lib目录，于是便有了这个 免部署 运行Java模块 的JIOPi编程风格。

 

在JIOPi风格中，提供功能的一组Jar包作为一个JIOPi模块发布在JIOPi模块库内(本地/远程)，每个模块有一个唯一名用于获取

JIOPi容器使用类似OSGi的模块运行机制，保证不同模块的执行不受干扰

 

HellWorld展示：

程序功能

1.实例化一个 org.jiopi.ibean.example.module.helloworld.HelloWorldImpl 对象

2.调用对象的 public void helloWorld();方法

 

//使用中央控制台，指定模块名，获得 模块控制台 对象 
ModuleConsole mc = CentralConsole.accessModuleConsole("jiopi.ibean.helloworld.m");
//通过 模块控制台 初始化 指定类 的控制面板(类对象)
ControlPanel cp = mc.accessControlPanel("org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", ControlPanel.class);
//通过 控制面板 执行 函数
cp.operate("helloWorld", void.class);

 

在这个JIOPi风格中，只需要在项目内放置一个JIOPiImpl.jar，即可透过JIOPi提供的API访问模块库中的所有程序

 

这个风格的好处是 调用 模块库 中的程序 无需在项目内放置任何额外的Jar包，但是却过多的失去了Java的代码风格，由于都是反射调用，调用效率也会有一定折扣

 

 

 

于是便出现了 接口部署 风格：

即，在项目的lib内部署要使用模块的 接口Jar包 , 对象依旧从JIOPi中获取，只不过不使用 ControlPanel 接收，而使用 对象的 接口 进行接收

HelloWorld代码如下：

 

//获取模块控制台，无差异
ModuleConsole mc = CentralConsole.accessModuleConsole("jiopi.ibean.helloworld.i");
//使用接口接收实例化后的对象
HelloWorld hw = mc.accessControlPanel("org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", HelloWorld.class);
//使用接口调用方法
hw.helloWorld();

 

在这种风格下，只有对象实例化的过程需要借助JIOPi的API

当然，我们也可以将实例化的过程交给 Spring，使用依赖注入，代码中便不会出现任何JIOPi的API程序

 

希望和大家交流一下，你是否能够接受第一种 免部署 方式的代码风格呢？

以及你 对 这种 Jar包 分离的部署方式 有些什么看法？

 

多谢各位捧场！

 

参考文章：

JIOPi v0.1规范 http://jiopi.iteye.com/admin/blogs/655032

iBean v0.1.0.1 参考实现说明  http://jiopi.iteye.com/admin/blogs/655072

第一种和第二种都不好。

我最希望的是得到OSGi的模块分离优势，同时不要加大我的代码开发难度，不要削减开发时编译器和调试器的功用。

能不能实现IoC那种松耦合的方式，不要反射，不要依赖第三方api，使用的都是pojo，然后实时组装？

第二种代码风格是可以使用 Sprint IoC 的呀，

ModuleConsole mc = CentralConsole.accessModuleConsole("jiopi.ibean.helloworld.i");  
HelloWorld hw = mc.accessControlPanel("org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", HelloWorld.class);

这两行代码在 CentralConsole中提供了快捷访问
CentralConsole.accessControlPanel("jiopi.ibean.helloworld.i",null,"org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", HelloWorld.class);

用Spring的工厂方式注入你的对象就行了，不知道跟你说的有无偏差？

呵呵，偏差估计就是你这样实现的用意了。因为你给出的HelloWorld实例只演示了反射的场景，没有给出你们期待解决的实际问题。



你这样使用反射，按理论上说，本意似乎应该是通过classloader一类的机制（恕我依靠osgi的思路去揣度了）去加载模块中的，但是你没有发觉自己没有向其他人展现模块化的情况吗？我们只看到了一个反射，其他的什么都没有了。也不知道你这里的反射是从何而来。

如果你可以提出模块划分的机制，后续的东西就好玩了，依赖如何控制，类加载如何隔离，不同模块之间的依赖如何解决。服务的暴露，接口的引用。甚至还有对原有组件库的支持和迁移难度。我觉得这些部分才是最终是否选用某个模块管理框架的依据所在，而不是使用反射还是接口的编程方式。

如果上述考虑不周，很可能大大增大系统的开发为维护量，甚至在设计阶段就会出现无法弥补的漏洞。

xyz20003，你说的不错，iBean的实现机制确实是使用类似OSGi的模块分离机制，一个JIOPi模块一个ClassLoader，从而避免依赖影响。

这一版本是POJO兼容，也就是将POJO发布成JIOPi模块，从而使用JIOPi容器来进行自动化的模块安装和升级，还没有提出模块间依赖的程序风格，当然，现在也是可以在模块中使用JIOPi的API来访问别的模块的，在一个JIOPi容器内，同名的 模块的一个版本 只会存在一个ClassLoader，所以如果 A模块使用了B1.0模块，C模块也是用了B1.0模块，那么B1.0模块中的单例模式对A C来说是1个，如果A使用了B1.1 C使用了B1.0，那么B的单例对A C而言就是两个


在部署了iBean.jar以后(就是把iBean.jar扔到lib下面就行了，还有一个jiopi.properties文件扔到classpath下面)，免部署方式的代码就可以执行了(执行过程中自动下载运行时需要用到的Jar并安装在临时文件夹)

其实JIOPi v0.1就做了这一个事情：把本应该放在lib下面的jar放在JIOPi的资源库里面，本来用是 HelloWorld hw =new org.jiopi.ibean.example.module.helloworld.HelloWorldImpl();的语句

换成使用字符串的反射机制由JIOPi容器获取，从而使用JIOPi容器对Jar文件的自动化版本管理，

JIOPi返回的类对象 可以有两种接收方式，反射方式 和 接口 方式，对于懒人（比如我），在执行对效率要求不高的代码段，直接用ControlPanel接收，不部署任何Jar就可以使用别人放在JIOPi资源库里面的所有Jar包程序，资源库的Jar更新后，我的项目用到的Jar也就自动升级了，API升级也没关系，只要我用到的API没变就行


当然这种模式就是代码中会出现JIOPi的API，而且反射效率低，那就用Spring装配吧，不过那代码中不也会出现Spring的代码么？所以。。。如果觉得失去IDE自动查错没关系，那就反射吧，省的在lib下放那么多Jar了


多谢xyz20003观点和提出的问题，让我了解应当再写一些哪方面的文档