KVM本身只带有cldc1.1的类库，功能十分简单，不能满足用户的需求，本篇介绍如何对KVM进行扩展。
对KVM进行扩展，在java层十分简单，只要向在编译Java代码时多加一个文件就可以，没什么要说的，麻烦的是假如在加入的Java类中有本地操作该怎么办？本地的C语言代码放在哪里编译才能够供KVM调用？
答案是KNI.下面就以KNI为主要内容介绍如何对KVM加以扩展，在最后附加一个具体的实现例子。
1. KNI的特点：
KNI（K Native Interface）是SUN的KVM（K Virtual Machine）所使用的本地方法调用机制。
JNI（Java Native Interface）是已经为我们所熟悉的Java本地方法调用机制，JNI一般使用在J2SE或J2EE平台上，本地方法被编进动态链接库，在运行时由Java虚拟机载入。
KVM中也需要本地调用，但JNI是“重量级”的本地调用方式，在使用时消耗的资源较多，所以针对KVM设计出了KNI，KNI被称为是JNI的一个简化版，是“轻量级”的本地调用方式。KVM不能加载动态链接库，所以在KNI机制下，本地方法不是写在库中，而是编入虚拟机内部。
以下是KNI与JNI最重要的一些区别：
KNI是“实现层”的API，即它是虚拟机实现的一部分，修改KNI的API就要重新编译虚拟机，这些API的细节对于Java程序员来说是不可见的；而JNI的API是在运行时动态加载进来的，它的修改与虚拟机无关，JNI的API对于Java程序员来说是可见的。
KNI的函数建在虚拟机内部，只能为此虚拟机所独享；而JNI的函数放在动态链接库中，可以为多个虚拟机共用。
由于在虚拟机内部，KNI的很多操作方式与虚拟机有关，在传递参数和控制对象的时候都要先经过一些非凡的处理；JNI的调用方式比较直接，但可能会增加安全隐患。
KNI是JNI的简化版，功能也会弱一些，它不能创建对象，也不能调用Java层的方法。
总之，“在虚拟机内部”是KNI所有特点的根源，记得这一点，KNI的所有内容都非常轻易理解。
下文各节对KNI的各个方面做一下介绍，只详述那些KNI所特有的内容，更全面的内容可以参考KVM附带的KNI specification.
2. 数据类型：
2.1 原始类型：
上表中间一列是KNI所提供的8种原始类型，它们的长度与所对应的Java原始类型的长度相同。
2.2 对象类型：
上图是KNI所支持的对象类型，其实所有对象都可作为jobject，只是对图中所示的这些object类的子类有非凡的支持，比如为数组类提供了操作数组元素的方法。
2.3 返回类型：
“返回类型”也就是本地方法的返回值的类型，KNI对它们有专门的定义。
上表右边一列即本地方法的返回类型。
进入讨论组讨论。
2.4 字符串类型、类描述符、字段描述符：
