Run Eclipse 3.2 SDK under Apache Harmony

Posted by eclipse @ 9:14 am, 五月 10th, 2006

Today, Apache Harmony jumped into my eye again. R.J. Lorimer, the EclipseZone editor, posted a topic about recent words from Harmony project mailing list. As a pre-investigation to my soc proposal, I’m think about the possibility of using harmony to construct a compact, effective and customizable Java(Eclipse) runtime core. After some attempts, I must to say, Harmony surprised me!

First, I downloaded the latest harmony snapshot and other pre-requisites from the Harmony project’s instruction. The size of all the Harmony JRE is about 28M, but the one of Sun’s JRE(full) seem to be 60~80M. Lots of people don’t like pack too many junks into the core of JSE, new Harmony give you another choice really. Now, harmony just released the class library which is a subset of the JSE 1.4.2. However, I find even the subset lib has arrived at a high coverage level in the 1.4.2 core API(a little for 1.5, in fact the VM of Harmony is from IBM J9 R2.3, a 1.5-compatible VM. So…)(see GreenBar in pic1).

JDK14 Harmony Snapshot

pic 1

Then, I try to start a clean Eclipse 3.2 RC3 under Harmony. I met a crash in the start-up period. That is, the latest harmony snapshot(06-Apr-2006) does not support Eclipse 3.2 without modification. After checking, this seem to be a problem caused by the uncompleted regular expression package in the lib - latest-harmony-win-x86-snapshot.zip (06-Apr-2006 07:00). I download the latest version of regex module from harmony SVN, and pack them into a new lib.

Harmony fine with Eclipse 3.2

Pic 2

Now, I could see the Harmony’s power for the first time(see pic2). Great! Harmony, now, is strong to support Eclipse Development or Application at least. Oh, Enough now! But to my upset, Eclipse seemed to be very unstable. After I opened the “Help”, SWT threw a exception and made the Eclipse crash again.(see pic3) After checking again, it was known all the crash came from “OutOfMemoryError”.

Harmony Fine with Eclipse

Pic 3

Is the default arguments of Harmony vm(from IBM) not suitable for my old and poor PC? Maybe true! Changing the vmargs to my classical command line “-vmargs -Xms256m -Xmx256m -XX:PermSize=64m -XX:MaxPermSize=64m”, I could embrace Harmony now! I played with Eclipse for tens of minutes, and test a complex GEF example(see pic4), everything is very OK. And, IMHO, the speed of Eclipse’s response under Harmony is a litter faster than that under Sun’s JRE.(After some more tests by SciMark 2.0, Harmony is a litter slower than Sun’s JDK6-b84 in my PC) Cool!^_^

GEF works well under Harmony

Pic 4

Though Harmony is far from J2SE1.5 Target, it is not far from Java Development in some extent. I hope this little note can help more people to get interested in using both great tools in the life from now^_^

ps: The most problem of Harmony may be its unstable memory management(or need some tricks for J9 VM args?). I sugguest to set a big virtual memory space if you meet “OutOfMemory” exception.

See Also:

1. Flash Demo - develop Harmony in Eclipse

Long Time to Update…

Posted by eclipse @ 12:13 pm, 五月 5th, 2006

For some awful blogging problems, I abandoned my former blog. And more, a part-time job of Eclipse plugin development and my phd experiment made me stay away from blogging.  I hope I could change this situation, I hope so.

BTW, this blog will be blogging in English, I would like maintain a Chinese blog if I have enough time

也谈OSGI与Eclipse(1)

Posted by eclipse @ 6:49 am, 二月 26th, 2006

     今天,Eclipse基金会宣布了对OSGi R4规范的支持。对于Eclipse PluginRCP的开发者来说,这一声明的发布实属意料之中。早从Eclipse3.0M6开始,OSGI已经集成到了Eclipse平台框架的核心之中,到现在的3.2 M2,已经可以在其中开发完全符合OSGI规范的Bundle了。

     OSGi规范的引入,源于Eclipse史上的第一个孵化器项目(Incubator)——Equinox Technology project,该项目试图解决2.x阶段的Eclipse运行时缺乏良好的动态性能这个问题,同时通过孵化器的形式避免在探索阶段对平台主工程产生负面影响。通过考察众多的规范,Equinox最终选择了OSGI

     OSGI的全称是“Open Service Gateway Initiative”,其最初的目的是提出一个允许将服务远程地部署到家用网关的规范,但经过几个阶段的发展(R1-R4),OSGI规范的意义和应用领域都远远超出了原来的设想。尤其是在Eclipse采用OSGI规范作为其平台框架的基础之后,OSGI已为Java开源社区所熟知。OSGI规范的核心采用了分层的框架,分为执行环境层(Execution Environment),模块层(Modules, 生命周期管理层(Life Cycle Management),服务注册表(Service Registry)和一个纠缠于各层之间的安全层(Security)。关于各层的详细描述可见于OSGi Alliance的网站。

OSGI Four Layer Framework

1    OSGi服务平台体系

     事实上OSGI和Eclipse二者的关联极为深刻。在Eclipse 3.1 Release中,已经完整地实现了OSGI R4规范的草案的核心框架。现在Eclipse平台的运行时核心,是基于OSGI服务框架(Service Framework)的org.osgi.framework和基于Eclipse扩展框架(Extension Framework)的org.eclipse.core.runtime二者的结合。这个特点,反映在运行时上就是org.osgi.framework负责plugin的生命周期(和服务注册),而org.eclipse.core.runtime负责对已存在plugin的所提供的services进行扩展;反映在工程实现上就是,(一般来说)你必须给Plugin提供2个文件,一个是OSGI服务框架要求的manifest.mf,另一个是扩展框架所要求的plugin.xml,前者描述plugin作为一般Bundle所需要的方面(服务于OSGI服务框架),后者描述plugin的扩展(Extension)和扩展点(Extension point)(服务于Eclipse扩展框架)。之所以分成了这2个部分,是由于在OSGI中并没有提供类似Eclipse扩展框架的支持,而这一框架在plugin的开发中扮演着重要作用。Eclipse已经将增加扩展机制的建议提交到了OSGI组织,相信在OSGI规范中能很快看到这一机制的体现。(注:实际上我以为会在OSGI R4中得到解决,但通过对草案的初步阅读,我没有发现对扩展机制基础性描述,但在不久的将来二者可能会统一到OSGI规范之中,Equinox项目,现在已经转为一个Platform Project,和JDT/PDE/RCP等Eclipse核心工程并列,其一个目标就是运行在Eclipse平台上的plugins可以无修改地运行在一般性的OSGI平台中)。   

     以上对OSGI和Eclipse的关系,及其发展的历史、现状和未来做了一个概述,在下一续篇中,将从具体实现的角度考察二者之间的深层联系。
By Jin
See also:
1. OSGi R4 Core DRAFT 20050714

2. The Eclipse 3.0 platform: Adopting OSGi technology

3. Eclipse Equinox project 

4. OSGi™ Alliance