Java这套编程语言有一项重要的优点也有一项缺点，优点是「开发一次程式码能在任何平台上执行」，而其缺点则是其执行效能。让Java程式码具备极高移转性（portable）的机制也同时让Java程式码执行起来相当缓慢。
Java的应用长久以来一直局限在PC、伺服器等环境，但现在Java已逐渐跨入嵌入式方案市场，主要原因就是互动电视与手机的掘起。
为何选择Java？
互动电视的市场从来一直都没有完善整合过，不同的卫星与有线电视业者、不同的软体供应商、以及不同的视讯转换器制造商等都运用各自不同的建置技术，所以若有一家有线电视业者希望开发一个应用程式，就必须为每款计画中要支援的电视或机顶盒设备撰写不同的程式码。这让业者投入非常多的资源，却得不到相对的利润回收。
为解决这个问题，全球业界开发出两套标准。其中一套名为MHP－多媒体家庭平台，这套在欧洲制定的标准能支援全球市场。另一套是OCAP－Open Cable Application Platform是由Cable Laboratories所开发的美国有线电视标准，Cable Laboratories由有线电视业者所创立，其组织成立宗旨在制定各种开放性标准。MHP与OCAP这两套标准相当类似（见图示），事实上，OCAP大部分的规格就是引用自MHP，因此，当这些标准被推广建置后，业者就能依照标准开发互动电视应用程式，而不必担心这个应用程式将来要在那种电视或机顶盒上执行的问题。
在建置工作方面，支援OCAP标准的地区将由有线电视业者负责建置，这意谓着OCAP的建置一旦开始就会在一夕之间发生，因为当有线电视业者开始建置及要求支援OCAP时，他们所推出的每一部设备都将会支援OCAP。反观MHP就比较没有强制性。欧洲的广播业者－包括卫星与地面广播业，大多透过零售商店供应其设备，因此使用者有选择产品的权力。他们可选购支援或不支援MHP功能的产品，虽然支援MHP技术的产品会比较昂贵，但MHP产品的数量仍会持续成长。由于产品的价差及目前消费者可能感觉不到MHP的明显价值，拥有MHP功能的设备成长将是渐进式。但预估在未来5年内，这两种产品（MHP & OCAP）都会攀升至数百万部的年出货量。
Java解决方案
Java硬体加速方案约在5年前首次出现，这些方案尝试在主要处理器旁加装一个小型处理器来专责执行Java程式，希望藉此解决效能问题。值得一提的是运用了硬体加速器后，Java的执行速度确实提升了，而且它不需任何额外的记忆体－在5年前针对手机来说，这是一个很重要的优点。其缺点则是须使用额外硬体及功耗的增加。
在现今技术的发展下，即使针对手机来说，记忆体容量需求的问题已经不复存在；以往受到记忆体数量限制的系统（主要是手机）已不再有这类问题。硬体加速器的其中一项优势也就因此消失。另外一个对硬体加速器不利的就是软体加速技术经历长久的研发，已经得到了相当的进展。在效能方面已远远超越硬体加速器，且没有硬体解决方案须使用额外硬体与增加功耗的问题。
为了分析软体解决方案的效能如何超越旧型硬体方案，我们必须先回顾Java的演进历史。最早的Java建置方案是由一套转译程式（interpreter），将每个Java指令都转译成对等的微处理器指令，并根据转译后的指令先后次序依序执行，由于一个Java指令可能被转译成十几或数十几个对等的微处理器指令，这种模式执行的速度相当缓慢。
针对这个问题，业界首先开发出JIT（just in time）编译器。当Java执行runtime环境时，每遇到一个新的类别（class：类别是Java程式中的功能群组），类别是Java程式中的功能群组－JIT编译器在此时就会针对这个类别进行编译（compile）作业。经过编译后的程式，被优化成相当精简的原生型指令码（native code），这种程式的执行速度相当快。花费少许的编译时间来节省稍后相当长的执行时间，JIT这种设计的确增加不少效率，但是它并未达到最顶尖的效能，因为某些极少执行到的Java指令在编译时所额外花费的时间可能比转译器在执行时的时间还长，针对这些指令而言，整体花费的时间并没有减少。
基于对JIT的经验，业界发展出动态编译器（dynamic compiler），动态编译器仅针对较常被执行的程式码进行编译，其余部分仍使用转译程式来执行。也就是说，动态编译器会研判是否要编译每个类别。动态编译器拥有两项利器：一是转译器，另一则是JIT，它透过智慧机制针对每个类别进行分析，然后决定使用这两种利器的哪一种来达到最佳化的效果。动态编译器针对程式的特性或者是让程式执行几个循环，再根据结果决定是否编译这段程式码。这个决定不见得绝对正确，但从统计数字来看，这个判断的机制正确的机会相当高。事实上，动态编译器会根据「历史资料」做决策，所以程式执行的时间愈长，判断正确的机率就愈高。以整个结果来看，动态编译器产生的程式码执行的速度超越以前的JIT技术，平均速度可提高至50%。
但软体加速如何超越硬体加速，尤其是特别设计的「硬体加速器」？我们可以从下文了解原因：
开发Java加速器时，工程师可专注于开发硬体的小巧，也可专注于加快处理速度。为了Java的可携性（portability），让Java程式码能在所有硬体架构上执行，Sun设计的Java指令结构迥异于其他硬体架构，因此要开发一套Java加速器是相当复杂的工作。工程师不可能将硬体加速器设计得过大，因为这会使该加速器失去竞争力，工程师只好牺牲加速的功能来缩减加速器的尺寸。这类加速器在执行Java程式时的速度超过一般简易的转译器，但比不上如动态编译器的先进的软体加速器，以目前先进软体加速器的普及，拿简易的软体转译器来做比较已经没有意义。
软体方案速度较高的另一项原因是因为处理器是在原生模式下执行程式码，因此若您针对某种处理器编译Java程式码，处理器就能在最高速度的模式下执行该程式。动态编译器能提供接近原生模式的效能，并仅针对重要的程式区段来作编译。硬体加速器并未以处理器原生模式来执行程式码，而仍是以Java程式来执行。
Java指令架构在效能提升方面造成许多障碍：首先，它不允许暂存器，因此所有的运算都是在堆叠（stack）中操作。运算用的资料及结果只能放在堆叠中，运算时再从堆叠中取出使用。Java指令架构亦不允许C语言所支援的指标（pointer）。若在一个类别中有某个数值，我们希望让另一个类别使用该数值时，在C语言中仅须用一个指标指向记忆体中储存该数值的位址。因为指标若误用可能造成记忆体资料错乱，Java指令架构为维持程序执行的稳定度，因此不允许使用指标，其代价就是必须使用更多的步骤来移动资料。在传递数值时，就算该数值不会有改变，也必须从一个记忆体位址复制到另一个记忆体位址。这种方式的执行速度远低于只传递一个会指向资料所在地的指标。
上面所提的这些障碍都是硬体加速器无法解决的。因此，尽管硬体加速器出现已有4、5年的时间，却不像软体解决方案一样已经有数个世代的改进，现在其效能已经远落后软体加速器。
记忆体容量的问题不复存在
以往手机所面临记忆体容量有限的困境，因为Java编译器会耗尽所有记忆体，因此手机无法搭载任何编译器资源，在这样的环境下，当硬体加速器在当年（1999）问市时，对手机运用而言，它合理避免了对记忆体容量额外负担的问题。
但今天即使对手机而言，这种情况已不复存在。现在就算是低阶的手机也都搭载了2～3 Mbytes的记忆体。以在MIPS架构中执行的Esmertec动态编译器为例，它仅占用了235 Kbyte的记忆体空间，在所有记忆体中占用非常小的比率，因此这方面的设计限制已然消失，而记忆体充裕的状况使业界能够放手开发出各种优异的软体解决方案。
最后一点，现今的手机几乎都搭配彩色萤幕，支援富含大量绘图元素的应用。手机微控制器遇到最大的问题是绘图加速，而不是Java。若厂商所设计的产品仅搭载简单的萤幕以及少量的记忆体，那就可能需要一个Java硬体加速器，但在大多数状况下，软体解决方案都远远超过硬体解决方案！（本文作者：Noam Shendar／MIPS Technologies提供）