immcss的专栏

<br />http://chnic.javaeye.com/blog/236248<br /> <br /><br />自己在外面偷偷的算了下，又有将近两个月没更新过blog了。趁着今天有兴致，来更新JNI编程的第二篇文章。在第一篇里，大概介绍了JNI的特点、用途和优劣。并且做一个最简单的JNI的例子，不过说实话那个例子在实际的开发中没有太大的价值，实际开发中所需要的JNI程序要远远比那个复杂。所以这一篇就来介绍下如何通过JNI实现java和C++的相互通信，来满足实际开发的需要。<br /> <br /

<br />先给出“扶贫助手”的第一种改造，我称之为“直接型”，请看：<br /><br />package aa.bb.cc;<br />//需要import osgi的核心package<br />import org.osgi.framework.BundleActivator;<br />import org.osgi.framework.BundleContext;<br />//实现了BundleActivator<br />public class FamilyInfo implements 

先让我们来看看OSGi service platform的体系结构。另外要说明的是，我在后面的文章中，将采用framework来代替OSGi service platfrom，这样比较简便。下面这张图来自OSGi Alliance的主页（http://www.osgi.org/）层次很分明吧。放到我们假想的案例中，OS&Hardware可以对应为PDA的硬件和操作系统，您可以想象它是Intel xscacle + Microsoft window mobile，或者是Arm + embedded Linux

<br />摘要：虽然Java不允许多重继承，但是有些情况却允许其使用。本文将阐述在一个Web应用中模拟多重继承的技术。<br /><br />在一般的开发中，Java的单继承限制一般不会引起什么问题。实际上，需要使用多重继承往往意味着糟糕的设计。然而还是存在一些情况，程序员们希望能够继承多个类。虽然Java不允许继承多个类，但是有些技巧能够模拟多重继承。<br /><br />我在Swing应用程序和Web应用中都使用过这个技巧。Swing应用打包并部署服务到应用服务器上。这种情况下，因为我希望在不同组件

<br /><br /> <br /> <br /> <br />"包"机制是java中特有的，也是java中最基础的知识。一些初学java的朋友，通常象学其它语言一样从教材上copy一些程序来运行，可是却常常遇到莫名其妙的错误提示。这些问题事实上都出在对"包"的原理不够清楚。本文将就此问题进行深入阐述。<br />一、为什么java中要有"包"的概念？<br />　　以一言概之，java中"包"的引入的主要原因是java本身跨平台特性的需求。因为java中的所有的资源也是以文件方式组织，这其中主要包含大量

<br /><br />过于的一年多，在和很多it届的同学及朋友见面时，他们总会问我最近在做什么。“OSGi！”，我不加思索的回答。到目前为止，对这个单词得到的反应都没有超出“这是什么？”，“我没有听说过”，“噢，能具体点吗？”等等。而我的回答更让他们糊涂，最后，大家干脆放弃这个话题，转到买房，运动等等更能体现聚会实质的问题上。不过最近，我一直在思考这个问题，下次再遇到这种情况时，该如何去表达才能让也是it届的哥们姐们能迅速的理解这个领域的范围呢？要知道，技术人员往往不善于表达，我们已经习惯了和业内人士用行

<br />依据DDJ的C/C++专栏作家Al Steven表示：他虽然不是很懂得Java﹐但是看到这些书中对于C++的物件导向概念的阐释﹐有些地方明显错误﹐真是令人担心。本文假设读者您已熟悉一些C/C++语言的概念﹐对Java也有初步的认识。而谈论Java的interface与C++的多重继承之主要异同处。 <br /><br />interface与多重继承的观念 <br />    不管是Java的interface或是C++的多重继承﹐在物件导向的理论里﹐都算是蛮新颖的概念。所以这里我们谈的﹐是以程

<br />（四）中提到的直接型改造法实际上和一个传统的java应用程序没有区别。因此客户的需求发生变化，通常是牵一发而动全身。<br />那么我们现在就看看如果在osgi framework中，用多个bundle来实现的效果吧。我的想法是用两个bundle来配合实现“扶贫助手”的功能。一个bundle专门负责录入和显示纪录，一个bundle专门负责纪录的数据结构和对数据的处理，用时下时髦的说法就是使用了mvc，只是我的m和c放到了一起。<br />先看看mc的bundle实现代码片断：<br />pack

如何分析OSGi service platform的机制？给出几个硬生生的例子，然后分析一下代码？那还不如你自己看书看规范好了。因此，我觉得还是结合一个应用实例来分析会更容易理解，当然，是一个假想的应用实例。用怎样一个实例呢？嗯......几个月前，一个中学同学打电话给我说他们要在PDA上开发一个简单的应用程序来临时纪录工作的结果，并向我咨询，这种开发的难度和周期。这事启发我了，就以PDA的应用为背景，让我们来假想一个场景，从而来比较传统的应用模型与采用OSGi的应用模型有怎样的区别。我这样想象：小李是一个

<br /><br />1、OSGi 的体系架构是基于插件式的软件结构，包括一个 OSGi 框架和一系列插件，在 OSGi中，插件称为 Bundle，其中，OSGi 框架规范是 OSGi 规范的核心部分，它提供了一个通用的、安全可管理的 Java 框架，通过这个框架，可以支持 Bundle 服务应用的部署和扩展。Bundle 之间可以通过 Import Package 和 Require-Bundle 来共享 Java 类，在 OSGi 服务平台中，用户通过开发 Bundle 来提供需要的功能，这些 Bun

<br /><br /> <br />    GetFieldID是得到java类中的参数ID，GetMethodID得到java类中方法的ID，它们只能调用类中声明为 public的参数或方法。使用如下：<br /><br />jfieldID topicFieldId = env->GetFieldID(objectClass,"name", "Ljava/lang/String;");<br />jmethodID getcName=env->GetMethodID(objectClass,"getc

<br />在给出采用service方式实现的“扶贫助手”之前，我们稍微回顾一下上一篇的成果。<br />在（五）中，我们看到程序被分成多个bundle后，程序的模块程度得到提高，而控制模块间的耦合度由Import-Package和Export-Package来控制，相对比较灵活。另一方面程序的更新和升级的粒度变小了。谁都知道只更新部分要比全部更新强，尤其当更新发生在一些需要建立昂贵的连接时，细粒度会节省不少花销。除了这些，我们看不到其他新鲜的东西。说白了，也就是挖空心思想一些design pattern来