Being Eclipsed

SEED(Scala Eclipse Effort for Development) 1.0M0 Reached

2011-10-06T22:48:00.015+08:00

SEED(Scala Eclipse Effort for Development) 1.0M0 Reached

Firstly, thanks for your jumping into this entry. The SEED(Scala Eclipse Effort for Development) project is my current weekend project. The sources of SEED can be seen in the github: https://github.com/jinmingjian/seed.

table of contents

Motivation

M0: a clear architecture

Incubated in the bleeding edge

Answer to the community

What’s next

Invite to contribute

Self-introduction

Motivation

What do you really matter when taking Scala into one large software production instead of Java? the IDE tooling? Yes, the professional Scala Developers need the professional tools to hack engineering. Because Java IDE have set a high bar to the user experience of language IDE, it is hard to think the developers and especially the enterprises will be comfortable with changing into a much worse coding environment although the language itself seem better.

The basic motivation is to drive the design and implementation of SEED to match the requirements of the professional Scala Developers.

M0: a clear architecture

The basic philosophy of the SEED is :

1. stable user experiences is first

2. reflect the language characteristics and merits of Scala itself

3. do not depend on uncontrolled sources;

4. invite community to contribute

The overall architecture and concerns could be seen as follow picture:

Then, what can we see in the SEED m0? Compare two snapshots between the SEED m0 and the Scala-IDE(one version in July, 2011):

from Scala-IDE

from SEED

from the snapshots, it can been seen that:

1. the packagings are mapped usefully

it will provide the viewpoint of flattening the packaging(collapse empty packagings)

2. method member's signature only displays the type of parameter, some member's type is missing

this is by design almostly , except the main(Array) is not full displayed for the unfinished type model. It is decided that the SEED Scala model scanner will not do any inference than the simple syntax scanning. Then, how to get the type infos? The type infos will be decorated in the later when it is resovled by the nsc. The Scala model scanner is not replacement for NSC. It collaborates with NSC.

3. ':', '=' are highlighted as the keyword

these symbols are reserved words explicitly by the Scala specification[1]. As this is a little different to the Java, the SEED will provide a preferences to configure this in the future.

4. expression have been addressed

this construct is quasi-unique for Scala(but similar to the initialization block ), like the self type, early definition, class parameters, type definition... The SEED will provide the outline item for visualizing them. However, as the reason that I mentioned in one previous blog entry, it is decided that the SEED Scala Model scanner will not do any inference than the simple syntax scanning. So, the Expression, as one kind of template statement, will be displayed as {...}, FYI.

The internal thought behind the snapshot is:

1. the SEED have a lightweight Scala Model system which services for the presentation layer and kept in the memory with editor.

2. Scala NSC will provide the full semantics and AST of Scala sources as a background service;

3. Scalal NSC nuts (like AST...) considered heavyweight will be discarded by UI immediately after used.(however, it has not right to ask the NSC to do this as well)

For the time limitation, I do not deep into more aspects of design. However, heavy investigations and works have been done in the m0. I believe the architecture have given a solid basic editing exprience to the SEED, and will pave the way for cool features like reference navigation in the next.

In m0, the SEED goes beyond the editor.

Incubated in the bleeding edge

This is long topic for the SEED. I pick up some interestings for showing. The SEED adopts two techniques in e4: EMF and DI(Dependency Injection).

These two techniques are just the basestones of the coming Eclipse 4.2 release("Juno") . However, they are not very known even by Eclipse platform developers.

EMF is one effective modeling framework in fact. The big picture of the SEED Scala Model is here:

It shows a early version of model structure in that I drop the ecore graphical tooling later for the obvious sync problem. And the type subsystem is still in the changing.

EMF really makes the SEED deveoplement easier. With it, the SEED model elmenets have the capabilities of notification and navigation when it borns. And I have done the ContentProvider for thirty model elements in thirty lines by just using the EMF reflection. And I predicate that more emf based techniques would contribute to the SEED. This is just the trend shown in Eclipse Juno.

The other technique - e4 DI(Dependency Injection), is relatively new topic in the Eclipse world.

The OSGI DS spec trys to remove the boilerplate codes in the services' publishing/referencing in the form of one component model. However, the component model itself introduces some new boilerplates. One problem is, you need to reference the service in one component in the DS. Even through one component is like one POJO in appearance, its cost is far from that of POJO in the bottom. The worse thing is, the component instantiation is under the control of (DS) framework. If some components need to be instantiated by hand or by other frameworks, the own business object can not consume the service directly. It needs to design kinds of auxiliary callback structures to expose the service to the business object(or some services may be designed with "Whiteboard" pattern). (This is by my understanding to the DS spec in the early years. If some one think it is not true, please correct me. I will clear it for DS^_^) The final result is that, we pusblish the serivce in the DS-style, but return to consume it in the ServiceTracker-style in our own business object.

The e4 DI is one technique which could solve all these problem . We can use the e4 DI to inject the service directly. The contexts should/can maintain the boiledplates for service consumers.

For the Eclipse 4.2's ugly face and a little bad experiences, I still use the Eclipse 3.8 milestone. After some investigation into sources, I have successfully integrate the e4 DI in the 3.8 enviroment. There are some tricks for doing this. However, still for the time limitation, I can write another blog to address these tricks. If you want to do similar things just now, you can consult the usage of ILexingService in the com.github.seed.core here.

In a word, the SEED, as the Eclipse-based IDE, have aligned with the newest Eclipse techniques. Futhermore, the SEED will follow the rhythm of Eclipse, but not the Scala(however, the internal of SEED will depends on the svn head of Scala after bootstrap). The SEED definitely should support to choose your favorite Scala system library(I leave the Scala team to guarantee the compatibility^_^). the SEED R1.0 will come soon after the Eclipse R4.2/3.8. I will definitely consider the compatibility to the Eclipse platform. As for the clear base, the SEED may support the plaftform from R3.6 to R4.2 if it is really needed:)

There are many other internal designs and implementations in the SEED not mentioned above. such as how about the Scala Model Scanner, the source Lexer. Some of them are in the changing. The key here is that, all designs and implementations have been thought to conform to the basic philosophy mentioned above. For the limitation of both time and space, it is hoped it could be covered in the future.

What’s next

Recent milestone concerns:

M1 theme: bootstrapping

type system(index system)

nsc integration(I am planning to do a tweek for NSC to make the integration more more natively)

build system(fsc?/sbt?)

M2 theme: self-hosted

binary class viewer

preference to switch your own scala system library

classpath container support

SEED codes wiill switch to Scala(eat my own dog food)

M3-R1.0:

performance

preferences

customized CNF-based "Scala Package" view

basic mixed Java/Scala integration

basic refactoring support(rename)

my implicit highlighting work

...

any contributions

Answer to the community

I may answer one question to the community: why not contribute to the Scala-IDE project?

The answer is: Simply, I can not agree on the base architecture of the Scala-IDE. In fact, the two projects has much different architectures. SEED is a clean-room implementation, even for its icons. All of my ideas are hard to be implemented in the Scala-IDE. Workarounds may exist, but it is definitely ugly. The tooling for Scala should originally be one straight, happy, rhythmical work for developer. But now it becomes the headaches of some hardworker. However, in the future, it could be possible to collaborate if we reach an agreement on the base. I hope the SEED would become a seed for one great Scala IDE.

Invite to contribute

For the clear architecture, it is easy and fun to contribute to SEED. The informal prerequisite is the basic knowledge of Java, Scala, Eclipse and/or OSGI. But you can contribute anything even if you are not a programmer.

Let's say about the feature of "Mark Occurrences", it could be implemented by adding a new token based occurrences detection service (like IFetchOccurrencesService) by consuming the LexingService as the backend. As for the frontend(UI), you can mock my token highlighting logic firstly. Or it is better to abstract one token based rendering service for all kinds of things in the future. It may cost hours or days which depends on what you want to do and how much you are familiar with the Eclipse platform.

I will be very glad to see your name here. Or you like to fork or clone to play the codes first.

Self-introduction

This last section in this blog entry seem odd. I hope this advertisement will not disturb you. I have written a blog entry about myself and my techinical road here in July.

I have touched several startups for some Scala opportunities. It is interesting that the number of scala opportunities is much less than ruby/python/javascript in the U.S..

However, it is found that the main problem for me is that the foreign H1B sponsorship is considered heavy for the startup. So, I decide to widen the seeking range to Eclipse/OSGI(or Java?) now.

If you read here and your employer are seeking Scala/Eclipse/OSGI work and your employer supports the foreign H1B sponsorship, please help to give me a recommendation if you think I am qualified for your works. What I can promise is, if it fail to apply for the work permit, I can contribute to one project your company pointing in my two month's weekends to compensate your application cost! My current work is about the web serivce component development for an well-known application server. In fact, I have done many backend works as well. For the sake of privacy, we can talk about more privately. I gratefully thank for any opportunities on behalf of my family.

I will pause the SEED development in the following several weekends for fully seeking the new opportunities. But I think it will be finalized quickly. I will be back soon.

Finally, as a rule, the SEED 1.0 should have a codename. I decide to call the R1.0 as the "SuperDaddy"(under the umbrella of Eclipse "Juno"^_^) to acknowledge my wife and daughter's support in these weekends. I love you!

When is the SEED M0?

2011-09-06T22:34:00.009+08:00

When is the SEED M0?

As recently one Chinese developer have commented about the status of my recently blogged project about the Scala Eclipse IDE. Because this blog is published without any tags. So I used to think nobody will focus on it. This is my expectation in that I I have no habit of publishing any toys.

I'd like to first announce the name of project is SEED - Scala Eclipse Effort for Development":) This project will be hosted in the github. The recent funny thing is Linus Torvalds move the latest linux kernel tree to the github.

The biggest hard point of SEED now is the time. I basically have no time to contribute it except the weekend. I have killed two version of the implementation way. Finally, I decided that there must be one new Scala Model for eclipse-side presentation layer for putting the SEED into one stable and lightweight tooling in the daily usage(like JDT). One hand-written recursive descent parser/scanner for members of Scala top template definition is under construction(parser generators are too terrible for use).

The harder work is here is the spec of Scala language is complex to fully understand. The EBNF syntax notation of Scala in spec have shown some entanglement. Like PATH is StableId, but StableId is also the PATH. This may let the notation writer more convenient, but increase the complexity of understanding and implementation. Some parts of notation is anti-intuitive. like some one pointing out in the official forum, Scala allows such definition:

val 1 = 2

from the syntax aspect, this is allowed by the fact that the pattern match style contructs can be used as one way to define variable(s). Some one think it will be kept for symmetry. But I think there is non-symmetric here in fact(like this literal pattern matching). The scope of the semantic of pattern matching is larger than that of variable definition. It is a bad smell in the language! In fact, this allowance is mainly for convenience. In almost cases, we can move the pattern match semantic just to the right of assignment, like:

val x = selector match { case ....

This kinds of design in the language much increase the freedom of language. But I think the freedom is not always the good thing for the developers. If many ways can reach one point, which way we should choose to go?

And furthermore, the wrost things for the IDE tooling designer is, for parsing such a little constructs, I even need to include almost all the syntax constructs into the parser/scanner. So heavy cost!

Some trade-offs have been made in the process. And I think everything is still under the control. It is hope by me, the SEED M0 could be published in two more weekends or so. That is the time! I am seeking some Scala related opportunities. If this can become true, I will have definitely constant daily time to contribute to the SEED. Wait for that day.

Thanks for all the followers!

From Windows to Linux

2011-07-17T16:01:00.001+08:00

The work of the whole transfer engineering has been done in this week, even I am still in a busy state. With the Linux Kernel version 3.0 coming soon, I decide to change to the Linux in honor of the 20th anniversary of Linux as well. The change is not related to which OS is better for working with. It is related to how do you think what your OS should be like. I were using one version of Red Hat Linux in 1999 or so. In that time, the drivers and applications for Linux is not very rich. I had not enough reasons to stick to the Linux as all others around me were using the Windows. However, there is 20 years from it's birth. It has one prosperous open source community already.

Note: Fedora 15 + gnome 3 + GLX-dock + kinds of extensions makes my life much easier than that in Windows 7 in fact:)

Now I am back as one professional coder, after serveral days's efforts, I am starting to enjoy the life in the world of Linux. One note to mention here, to enable the scala's gedit syntax highlighting, you need to put the scala.lang config file in to /usr/share/gtksourceview-3.0/language-specs/ if you are using the gnome 3.

And one more thing is that, I am deciding to reboot my effort of Scala Eclipse development tools in my spare time from this weekend. It is, in fact, mainly for earning one matched Scala/Java/Eclipse job in Silicon Valley(or other any possible areas^_^). But I still has full confident with that it will go beyond for other Scala development IDE tools and as the defacto tools of every Scala developer. Trust me!:)

call for job opportunities

2011-07-03T22:21:00.001+08:00

As the title of this blog suggests, I am asking for one appropriate job opporunity globally.

The biggest thing in the this year for me is the birth of my daughter. It costs almost of my free time to prepare the birth of my daughter. I hope she has a better growing environment. So I decide that it should be a change now.

In this blog I give a summary of my past technical roadmap, my current interests and my thoughts to some technical points. It will be amazing to get the matched position information. However, if not, it is hoped you can still get the useful technical informations about the related open source community and some thoughts of people in those communities.

My basic and known role in the open source community is an Eclipse enthusiast. Most of early my bloggings are about the Eclipse technology. And obviously this just explains this name of blog. I a little active in the community, but less than some famous ones(see some of these men in "Other Blogs"). One reason for this may be that, they were paid by company, but I were just a part-time phd student in that time.

The another reason is that I am also on the road to understand the framework. My very first Eclipse position is the intern of IBM CRL. In the early stage of Eclipse, not many companys adopt the Eclipse platform in all possible aspects like IBM. Yeah, the blue giant will not waste investment! The basic skill for this intern is about the EMF and the GEF. Both of them are the traditional and critical for varied tooling projects. The EMF has already became the defacto standard of modelling. I am also one fan of EMF thanks to its simplicity and power. But the most fantastic thing for the EMF community is that the project leader Ed and other committers eliminate the zero response to any question in the official forum(at least in a long run). This is a typical positive-feedback case under the whole umbrella of Eclipse. Opposed to the EMF, one bad case in the ecosystem of Eclipse is the famous Visual Editor project(vep), which has been sentenced to death just recently. The worst thing here is that the existed committers have almostly no response to the community even I shows great intensity of feeling. Maybe they are busy for their business. But is this case still qualified for being a committer? Oh, forget the answer, it has gone with the death of the project...

After the intern period, there is one greater opporunity. One private boss wants to provide a tooling product for his workflow product based on the Eclipse. The challenge of this project is that I am the sole coder and I decide to use the GMF as the base of product. The extremely hard thing is, in fact, the GMF has not released yet even with its 1.0 version in 2005. Two main reasons drive me to decide this adventure: first, the combination of EMF+GEF is boring to code the naive editor for me;second, the agility has sink into my mind. I like to embrace the change already. The final result is still nice: I implement the main features in 1.5-2 month and the code base migrate from 1.0M3 to 1.0M6(which is much closer to the formal R1.0). After four years in 2009, I have a chance to talk with that Chinese private boss. He told me that he has releasd the tool freely and there are about 10000 users using this tool(in 2009). Champagne! Now there are many workflow/BPMN editors to do such things using GMF, like the official BPMN Modeler. But I am proud to create the first one globally. It is much wise to use right tool to do right things.

NOTE: The two editors demonstrate the same basic BPM notations(But my created editor is based on the BPMN 1.0 in 2005). However, my BPMN editor add more vendor-specific functionalities behind the face.

With deeping into the framework, many Eclipse-hosted projects have been investigated by me. I have joined several commercial plugins development for coding or training in Beijing, China. And I have shared a little open source projects and knowledge from the community to the community.

NOTE: this is one of my open source projects - DOMR(Db4o Object Manager Rcp), which nominated me as one of the db4o dVPs 2010. The work done in this project is trivial actually. The great thing here is that the company behind the db40 is very community-oriented, which drives the db4o become one popular object database finally. It is also one good case for embracing community.

NOTE: This is also one my RCP spare application. The application aims to demonstrate the power of Eclipse platform. It has one unique customized shelf control, of which style is much different from that of the common Eclpse/Java desktop software. The idea is same to one topic of e4 - CSS styling, in fact.

Futhermore, I have played with the OSGI implementation in the actual Google App Engine spot firstly here. I have played with ActiveMQ + OSGI to construct a modular parallel messaging prototype system for finance(banking) transaction data monitoring. I have played with Eclipselink to integrate JPA2 to one Eclipse-based application development platform to alleviate the burden of app developers to SQL.

Eclipse has merged into the system of my business and my life.

After graspping the essences of the whole picture, the application aspect development is not my concern any more. More language and (business-)system level experiments have happened. Eclipse is not my unique working area any more as well. I have investigated several language tooling projects in the field of Eclipse: LPG, which is the effective parser generator behind the JDT/CDT, however, more people lieke to use the ANTLR;IMP, which is one wise language meta-tooling platform, however the project seems in its silent period;not mention the DLTK or other xDTs... I have studied several dynamic/functional language Javascript, Ruby, Lua and Scala more or less, with the status of IDE support definitely.

NOTE: This project trys to provide one editing enviroment for FASM. The parser is based on the LPG. The rest part is based on one Eclipse project - IMP. IMP is competive potentially to another Eclipse - DLTK. The two projects share some common ideas. However, I like IMP more for my personal taste in 2009 or so(in order to avoid another war^_^). I have another similar open source project exquery to use both LPG and IMP(I think, it is also a good demo of two projects for all learners!). Based on the framework, I complete the IDE protoype in one or two day(after the parser ready). Extreme programming! Premise is that you can handle all bugs of your dependencies:)

The final decision for me is that the Scala is the next language I will stick with. I usually select the language by the conciseness, the expressive force(powerful language constructs) and the contract-ness(Strong type). Oh, bingo! Scala reachs the best balance. In 2010, it is my great honor to be selected by GSoC(Google Summer of Code) and Scala team to participate in the development of the Scala Eclipse IDE. Unfortunately, I have not time to join the development from this year for preparing the birth of my daughter. The community is still very active. You can even see Martin Odersky throw out some new methods for the presentation compiler now and then. I love this community really and hope to come back soon.

NOTE: this is one screenshot for showing some works in my GSoC. The basic idea is to provide the corresponding to JDT for Scala. However, frankly, I do not think the dependency to AspectJ is must. The coupling working way has set a high bar for the potential contributors and have caused some wired bugs. Scala is not Java. Collaboration do not mean Coupling. If abstracting one small piece of JDT core (binary class model mainly, UI parts of JDT have many low-quality codes and designs far away from the best practice indeed) into Scala IDE as an independent base, I believe the IDE can iterate fastly and go beyond the JDT soon.

Recently, I have some interests to adopt some bleeding edge enterprise best practices to the android development. The key technologies I have done in the android system is that: DI + NoSQL. This seems not very fresh thing for the android development community. But my way is to re-invent the wheel according to my experiences of the best practices. For DI, I have constructed one JSR330-compatible DI engine, which is 1/10 of Guice in size, and has passed 80%+ JSR330-TCK tests, and beats the Guice in performance by using the Guice's mini bench test. For NoSQL, I used the stripped orientdb with unfinished query DSL. The whole thing is under the development from one weekend to another weekend if the time is allowed. And, I do not know when my first application will come out. The best practice here is that, "do not adopt the not-understanding technologies even through all others use these technologies".

NOTE: the jw.di is my own DI engine. The 9 failures in JSR330TCK tests are all about uncompleted overridden behavior, which is forgot in the design phase of the egine. The original goal trys to implement one JSR330 lightweight engine run in android(or other lightweight enviroments) opposed to the relatively fat Guice. In the latter of coding phase, I introduce several CDI features like event support and binding with annotation instance literal(not like just binding with annotation class, binding with annotation instance supports specify the value of the annotation's element). That's still cool, right?:)

That's all basically. To take care of my daughter, this blogging has caused me two weekend days to finish. No time to add more! If you have the position involved above technologies, it is possible to consider me as one candidate. Contact me if you just think so by email jin.phd at gmail.com.

Heartfelt thanks!

Implicits, Scala-IDE and my mid GSOC evaluation

2010-07-18T11:08:00.002+08:00

Implicits, Scala-IDE and my mid GSOC evaluation

It is far long from my last blog entry. I even have not announced my acceptance of this year GSOC by Scala team. It is my honor! One reason is that it will be more useful if I put these time into solving practical problems.

Another big reason for the absence in June, is that several big things for me have happened in June. So most of them can not be expected or controlled. You would find helpless when the external force drived you to the different direction. After one influenza, I am back to gsoc to carry out my promise to community. The community trust that I can finish the project, so then give me the precious slot. I should show the feedback to the community and tell them the trust bear fruit. It is the spirit of community.

Now back to my mid gsoc evaluation topic. What my project do can be understanded here [1] at scala-ide wiki. If you are a new comer to Scala, you can read the official site[2]. One recent big news, we release the Scala 2.8.0 final[3]. The version is in high production-quality, and has many new features. Don't hesitate to join our party, especially if you are Java developer. Privately I were planned to write a series like "Step into Scala by Scala Eclipse IDE" at May, however, the idea now can not be picked up for the time limit.

Feature#1 in [1] is a long awaited feature in Scala IDE. It is involved with one cool Scala feature, that is the implicit conversion. This feature, as hinted by the name, can convert one object from one type to another type. The feature is similiar to the idea of Adapter pattern [4] in Java. The wonderful magic is this conversion happens implicitly(and can be controlled). So, something like follows can happen:

aVector + aInt // aInt be converted to a Vectot implicitly

Map(1->"one") // 1 or something else object will have not "->" method, we can convert any type to one type who has the "->" method

The implicit functionality "let you dress up existing libraries" [5], and make the code compact and clear. However, it will also be danger if it is abused. Because you do not know the conversion explicitly. Some potential unwanted implicit conversions may happen, but you are unaware of them. This will lead to unexpected result of your codes.

Although, the designer of Scala has given some rules to the usage of implicits(see PIS to get more detail explanation[5]). But you can not get hints when your editing sources. IDE tooling support will come to rescue you! Our feature#1 is just for this rescue!

Now, I finish the prototype of feature#1. Consider one simple source like follow:

object String2Int {

val a = "1";

val b = "2";

var c = "3";

implicit val somewords = new SomeWords("yeah!")

implicit def string2Int(s: String) = {

((s.toInt)+2)

}

def main(args:Array[String]) {

printInt("3")

printInt(a+b+c)

printIntWithSomeWords("5")(new SomeWords("..."))

printIntWithSomeWords("6")

val map = Map(1->"one",2->"two")

}

//implicit def otherwords: SomeWords = new SomeWords("Oh, yeah!")

def printInt(a:Int) {

println(a)

}

def printIntWithSomeWords(a: Int)(implicit sw: SomeWords) {

println(a)

println(sw.words)

}

class SomeWords(val words: String)

}

Can you recognize that this simple source has seven implicit conversion happened?:)

The follows sreenshot shows:

Three implicit conversion are based on the in-file implicit string2Int, but other fours are based on the implicits from the implicitly imported scala.Predef. I use the squiggle underlines to indicate them. This will be allowed to be customized after this feature being fully implemented.

So, to use our Scala-IDE, now you can see all the implicit conversion happened. I try one code exmaple vectors at official site[6], which shown like this.

One thing in UI here is that the hover has not been finished now. I am planning to use the Jface indepent annonation hover for this functionalites, not continue the current apsectJ-hooked version. As my opinion, hooking way is the double-edged sword. Hooking means you depend your works on the things out of your control. I suggest only using the AspectJ technique when the Eclipse and JDT have not left the door for your extension. However, this idea has not discussed with Miles:) I will discuss these to him in these days.

I used the Scala Eclipse IDE monthly. Frankly speaking, the current Scala Eclipse IDE is not very production-ready. I am forced to use one poor atom itx pc to power the development in one span recently. However, the performence is crazy crazy crazy...On the contrary, JDT works much fluently even on this pc. I do some profile on the current Scala Eclipse IDE, some cases shown as follows:

This screenshot shows the number of thread bump up to 59 suddenly

This screenshot shows this short lived threads are not collaborative. Almost of they are blocked.

The main thread(UI thread) are blocked in several minutes by Scala Presentation Compiler thread(this is a background thread in Scala IDE).

From the primary eye, I think, the problem may be in the abused usage of SycVar. However, I am not to much time to verify it till now. The main thread shoud be kept unblocked in most cases, because it is the UI thread. Some problems seemly exist in the compiler library. That means, other IDE using the new presentation compiler, like Netbeans, may live in the same dilemma.

In one other core-duo notebook, I give the nice feedbeek, the stop feeling only happens with short time(seconds). However, I still find many other bugs, some of my cared bugs listed on my note here:

1. perfromance

memory consumaption is huge!(this cause that the full gc acitivities are heavy in some cases?)

index/build

leak?

2. code folding only for fisrt level function

(local function def is not folded)

3. local function def/call can not be displayed correctly

4.override doese not show the override indicator in outline

5. ScalaElement extends JavaElement is not elegant

6. icons for var and private var in the outline are the same

7. F2 or hover is not always available

8. building at the unnecessary time

9. Do not hook when that extensibilities has been supported by platform(or JDT).

SDT is expensively dependent on the AOP. hookings are done by AspectsJ. This technique is advanced, complex and not elegant when the framework has left the space to be extended.

10.hover in SDT is not consistent with JDT???

abd the default type hover is a little expensive for SDT

11. compilation error in one source stop all other sources compiling and clear /bin

12. scala.tools.eclipse.javaelements -> scala.tools.eclipse.scalaelements ?

13. sdt can not compile the nsc(that is the so-called "presentation compiler" of scala)

one problem is, the package.scala(package object in 2.8?) can not be seen as a scala source file. (package is a keyword in Java?)

14. auto completion is not well-behavoired.

15. scala class file editor don't support the debug?

16. hyperlink nagivations are not always available

like:class EclipseTyperRun extends TyperRun <--

17. override method hover show usefulless things.

18. reference nagviation(concurrent marking) does not work

19. sometimes compiler has been broken without any error indication in the editor. (sometimes shows unuseful things in the error log of eclipse)

20. quick fix(ctrl+1) is broken really.

21. long time sources error at IDESettings.scala?:

error: not found: value Xwarnfatal

error: not found: value Ywarndeadcode

22. open type does not match the full qualified class Type

23. Builder does not begin to work when the modification of source has been saved soemtimes

24. coding conventions are not coherent in the sources.

25. why not Scala-IDE SDK download?(I have one home-made sdk, it is easy^_^)

Don't be scared! Some are enhancement requests. And someone may have been fixed now. I will tell you when the above problems have been solved. If you have some interesting to help us, you can reach us at [7].

Let close the this reporting first. I will be back soon. Have a good night!

References:

[1] https://www.assembla.com/wiki/show/scala-ide/Google_Summer_of_Code

[2] http://www.scala-lang.org/

[3] http://www.scala-lang.org/node/7009

[4] http://en.wikipedia.org/wiki/Adapter_pattern

[5] http://www.artima.com/shop/programming_in_scala

[6] http://www.scala-lang.org/node/60

[7] http://groups.google.com/group/scala-ide-dev

Align the Scala Development Tools with the Bleeding Edge of Eclip

2010-04-03T13:00:00.002+08:00

Align the Scala Development Tools with the Bleeding Edge of Eclipse

Too long time for me to blog anything here. In this long time, I’ve received three important offers(one small company, one big big company and one institute). Although I have not decided which to go finally, this these days are and will be impressive in my life:)

Recently, I’m beginning to prepare the defense of my Phd thesis. I accidentally found I received one email to ask whether I'd like to continue one of my 2009 GSOC[1] proposals in this year. After some browsing, I find that I am really eligible to participate in the 2010's program[2]. So, I decide to prepare this year’s GSOC for the real last time.

As an Eclipse guy, that you know, I will stick around the community. This year I raise my hands over the topic of language support using Eclipse technology, which is my best point of interest in recent years. In this year’s program, I will submit Scala Eclipse-sided enhancement proposals to promote both communities deeply into each other:)

One BIG picture! Scala is really one nice and natural language choice for one Java programmer, after I have learned some other dynamic languages like JRuby/Javascript/Lua. All the languages have their values in the appropriate places. So, in the this blogging, I don't like to fire the language WAR. I just record things about Scala and mainly SDT (Scala Development Tools, formally called Scala IDE for Eclipse[3]). This blogging could be considered as the starting point of my adventure.

Scala have three mainstream IDE supports currently. Without doubt, the enirovement of them are Eclipse, Netbeans and IntelliJ IDEA respectly. Some of Scala developers will use some of them. Among them, the SDT(I use SDT as the synonym to the "Scala IDE for Eclipse", it is my favorite name) seemly has the best integration with Java development tools(yeah, that is, JDT). I will not fire another IDE WAR...But, I predict that, the future belongs to Eclipse:)

Thanks to Miles Sabin, the SDT have one good body and have provided many nice basic functionalities, such as the wizards, highlighting, hyperlink navigation, builder, and recent code completion [4]. However, many advanced features still have not been included in the current SDT. One much inconvenient thing for me is that, the latest SDT only works with Eclipse Galileo(R3.5). The milestone of Eclipse release train has been already relatively stable for coding. Nobody will wait one year to taste the latest cool Eclipse functionalities by milestones:)

I spent about three non-fulltime days to review the SDT codes(and knowledges about the Scala and AspectJ). Finally I make the SDT avaiable under the 3.6M6[5], the latest milestone of Eclipse Helios. Cool!:) All of the basic functionalities work finely. Yeah, now the latest Scala 2.8, latest SDT(SVN) and the latest Eclipse 3.6 are in the same box now.

Some thoughts about the SDT as follows:

1. The current architecture of SDT is much nice.

This makes JDT infrastructure reusable and makes JDT integration natural. AOP/AspectJ is another cool technology. AOP/AspectJ was one of hottest topic in some days. After many new technlogies(like DI?) or frameworks appear, the people go to forgot this technology. The SDT demonstrate the power of AOP/AspectJ.

2. many codes highly depend on the Java reflection and Class.forName.

This is a little against to the OSGI best practice. And this cause one HyperlinkDetector bug when my porting. I suggest every man in the community read BJ Hargrave's "Why Class.forName sucks!" at EclipseCon 2008[6]. There are many reasons and ways to refute using the Class.forName. I rewrite the HyperlinkDetector related part in codes, and remove Class.forName statement. No problem here. (I will describe some details in my proposal.)

3. some aspects codes can be updated for new Equinox Apsects runtime.

I rewrite the aop.xml to mf.

4. the Java<->Scala collection interoperability is a little problem for newcomer.

I met some Map type checking problems when I overrided one class from one existed Java framework(Eclipse indeed). Scala has the concept of "Existential Types". I think I need more deeply lookups in this field to see what is the best practice. This is a language level problem indeed, not related to SDT. But this gives the Eclipse tooling more space to be improved as well:)

5. The build process of SDT can be simplified into small and easy pieces.

My original thought is that, bootstrapping the SDT form plain Eclipse enirvonment.That is, I can not use the SDT to build SDT at the very beginning. Miles has written one great document to show how to build the SDT[7]. But, frankly, I have not the courage to read through the document. This will be more serious for the Eclipse newcomers.

As my testing, the Eclipse PDE build tooling workflow fits the SDT as well in fact. (need a little trick:)) After some targeting and layouting, I even can run and debug the plugins in the workspace directly without any packaging, deploying or the prerequisite SDT installing step. This aslo makes SDT development's life easier.

6. naming of the version of scala-plugin-aspects is a little not consistent.

The version of bundle in the svn is 1.0.0. But the name of the scala-plugin-aspects jar is like "ch.epfl.lamp.sdt.aspects_2.8.0.r21304-b20100331125642.jar". It is the product of the ant build scripts. It is not an error strictly. However, I think it is not the best practice in Eclipse world. Just a note here:)

7. SDT in svn seem not much stable.

I meet several wired bugs, however they can not be repeatened...

Oh, here, I add one pciture to show the code completion is ready-for-use now:)

At the end of this blogging, some immediate suggestions for the current SDT, IMHO

1. re-arrange the build flow

Beside the above mentioned, SDT building artifacts can depend on the binary snapshots of latest Scala and Eclipse instance. Re-build sources of Scala is time-cost and not convenient/necessary in common cases.

2. "Release early, Release often"

align the head of SDT with the latest Eclipse and latest Scala(latest Scala is said to be used for SDT development, not SDT user)

The SDT is a tooling under the umbrella of Eclipse, so keeping its release rhythm synchronous with Eclipse(JDT) will a killing reason for the acceptance of SDT.

3. add the dist of standalone SDT installment package for downloading

The SDT needs some bootstrapping hackings in the configuration of Eclipse instance. Although it is easy for old men, it is not cheap for newcomer. I guess many people would not configure the SDT correctly. This would highly block the acceptance of the SDT and, of course, Scala itself.

I will contact Miles/scala-plugin team to see whether he/they like to accept my codes or some of it. Of course, it can be hoped that Scala will have one more bright future with the help of Eclipse:)

I have one little idea about the Scala language for e4, although I am afraid whether this will be supported by our voters. But I think I will start/push this idea some day. It will not be long...

I am planning to write more things about Scala and SDT recently. I wonder if there are some collaboration efforts about these in the community. If you are, let me know!:)

[1] http://socghop.appspot.com/

[2] http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#graduate

[3] http://www.scala-lang.org/node/94

[4] http://old.nabble.com/IntelliJ-and-Eclipse-Plugins---Scala-2.8.0.Beta1-td28035792.html

[5] http://download.eclipse.org/eclipse/downloads/drops/S-3.6M6-201003121448/index.php

[6] http://www.eclipsecon.org/2008/?page=sub/&id=377

[7] http://lampsvn.epfl.ch/trac/scala/wiki/EclipsePlugin#CreatingAndSubmittingPatches

Eclipse POLO T-Shirt Come!

2009-10-16T17:25:00.003+08:00

Eclipse POLO T-Shirt Come!

I have received my second POLO T-Shirt today. Thanks for Eclipse Foundation and Eclipse Community. Yes, this autumn is warm for me:) Great!:)

Recently, I am reading the CVM and LLVM related references. They are really both great really. And I have a plan to combine the clang with eclipse. Maybe, it could be called "ClangDT" or "CLDT" or "eclipse-clang" or "eClang"... Yes, that is a replace to CDT in current eye. Because clang has its own static analysis tools, I think this combination will be not hard. And this will introduce a windows-friendly CDT. However, I have no budget to complete it recently before I got a formal job. Hope that I can come into the work soon.

Running eRCP with Phoneme Advanced on your mobile phone

2009-10-03T12:20:00.002+08:00

Running eRCP with Phoneme Advanced on your mobile phone

Originally, I don't think this is a problem. Because I have run the eRCP with J9 VM successfullly 4 years ago. However, when I revisit this topic recently, I found that this thought was not true. You google some posts about this problem, like here or here recently, or old post here at 2007.

Now the status of JVM on mobile phone is that J9 CDC VM is not available to non-linux platform mobile users for free any more.(maybe binded with some IBM products like IBM JRE6? If I am not right, you correct me^_^). And some benchmark show that the phoneme advanced is faster thant the J9 embed.

Now, I think I should fix this problem for our community. I take out my old HP 1940, and try to find some clues. And yes, I get the crash as well. One convenient thing for Equinox(or other OSGI RI) is that you can find some logs at the %eRCP_ROOT%/configuration/ directory. I find one thing like,

...

!MESSAGE

!STACK 0

org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0,J2SE-1.3

at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Unknown Source)

at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(Unknown Source)

at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Unknown Source)

at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(Unknown

...

Yeah, "Missing Constraint: Bundle-RequiredExecutionEnvironment" error. So, we know that the Equinox OSGI framework can not recognize the phoneme advanced execution environment. After quickly sourcing, the best fixing solution appears. Using the follow .ink file to lanuch the eRCP,

37#"\phoneme\bin\cvm.exe" -Djava.specification.name="J2ME Foundation Specification" -cp \eRCP\startup.jar org.eclipse.core.launcher.Main -application org.eclipse.ercp.swt.demo.eSWTDemoApp -console

The reason is that the Equinox osgi use "java.specification.name" property to recognize the cdc execution environment, and they just accept the "J2ME Foundation Specification" as the value of property java.specification.name. However, in the Phoneme Advanced, this value is set to the "Foundation Profile Specification" in default. There are many ways to fix this problem, such as modifying the makefile of phoneme, modifying the config.ini to include this property, or modifying the source of osgi. However, the best way now is as my suggestion. I will open a bug to Equinox to see if they want to do something:)

Now you will see the exciting screen on your mobile phone.

eRCP HelloWorld

eRCP Canvas

eRCP eWorkbench

OSGI(Equinox) console

The feeling of eRCP has still been awesome from my last try several years ago. The fact eRCP can run on mobile has demonstrated the success of Eclipse RT project. (Surely, OSGi Minimum Execution Environment is JavaME Foundation).

One interesting for me is that the eSWT widgets can work with Phoneme Advanced without any modification. As I have pointed out at the previous post, the JNI application should be compiled with CVM's JNI headers. In win32/x86 platform, this re-compilation is a "must". However, direct eSWT supporting for CVM is not perfect. The screenshots, like "eRCP eWorkbench", has shown some appended unreadable characters on the menu item. That is a eSWT bug (seemly just for CVM) as I mentioned at the previous post as well. It needs times to fix this problem. Stay tuned...

Let's do a summary as follows:

1. full eRCP can be run with Phoneme Advanced

2. full OSGI 4.x RI can be run with Phoneme Advanced

3. if you run the native(JNI) codes and meet some errors, please do not forget to re-compile your JNI codes against CVM's JNI headers.

Phoneme advanced and eSWT Running Under x86 Windows

2009-09-20T20:26:00.002+08:00

Phoneme advanced and eSWT Running Under x86 Windows

Recently I still try to find interesting things to explore freely. One thing is that I mention I'd like to contribute the Eclipse in some projects, like e4 language or VE(I avoid contributing to the projects full of employees). However, the feedbacks seem not active. In my view, the reason that Eclipse is the current Eclipse is just the gigantic, passionate, dream-filled community.

Oh, come to the right topic.

There are many research JVMs under the linux. All of them are much not friendly to Windows users(the fact is that almost of them even do not consider the problem of porting to Windows). Although the linux environment is better for some programmers, it is very dangerous to think only from the programmer's perspective as a programmer. This behavior could kill your community.

"Phoneme advanced" is one CDC target Java platform(JavaME, academically. And, I will call the "Phoneme advanced" JVM as "CVM" as follow), which is opensourced from Sun's product(after the OpenJDK borning) under the GPLv2.

The attractive thing for me is that CVM could be seen as the compact version of J2SE 1.4(yes, that is, CVM fully complies with the JVM Specification, 2rd). That is, we can do many useful things on it.

It is easy to get the source of Phoneme. However, like all other research VMs, the build system of Phoneme is based on the sh/make of Linux. This is not easy to Windows users. To find , We need Cygwin, which provide a linux-like enirvonment for Windows. A little inconvenience for Cygwin is that it needs to be installed via internet connection.

The good news is that the phoneme adv. provide make files for win32-x86 platform and VC build toolchain. The bad news is that the the default building scripts are not fully matched with your actual options. If your VC or SDK was installed into non-default directory, you need to carefully examine the output infos to find what the enirvoment variables are wrong and you should redefine those variable. Two detail clues here,

1. the path for Windows is not valid for Cygwin, modify it like c:\xxx -> /cygdrive/c/xxx

2. for the Vs8 build script, the variable "PLATFORM_SDK_DIR" can not be overrided(a bug?). You should modify it by hand.

After more or less tweaking, I get the CVM into running successfully, Cool! The coolest thing is not that the CVM could be run, but that the packed size of the runnable CVM with the foundation runtime library is just about 1.1MB.

The next big is the capability of UI application for cvm. One thing here is, you need to rebuild the native codes against with CVM' JNI headers. Don't try to use existed native library directly. Firstly, I test the SWT. But I get errors when compiling the sources under VC++2005EE and MS Platform SDK. Error logs like as follow,

...

...\MicrosoftSDK\Include\exdisp.h(39) : error C2061: syntax error : identifie

r 'IWebBrowser'

...\MicrosoftSDK\Include\exdisp.h(39) : error C2059: syntax error : ';'

...

I can not figure out how to solve this problem. If you know, please let me know:)

Then, I remember the eRCP again. In my eye, it's a lightweight RCP implementation even for desktop. The eSWT is the base of eRCP. I fetch the eSWT sources. But frankly, bugs in the eSWT win32 codes is not rare. I have some years not to touch the C/C++ codes.Otherwise, this is a good chance for me to play with JNI deeply. After a while, I get them compiled successfully again. Cong!

The above sreenshot is a sample code shipped with VE, called "SimpleSWTTextEditor". I do a little modifications to the text to test UI(JNI) and Unicode support of CVM. As you say, the basic aspect of UI is nice. However, the text of widgets has been append unreadable characters.

After intensively debugging, I find the problem exists in the #GetStringChars() method. This method return the jchar* which is called by #convertToNativeString, however this implementation in CVM seem has a non-standard behavior. (I am not sure to open this bug to eswt? or cvm?). Then after fixing this problem, I get the nearly perfect solution. The Unicode support is nice for both English and Chinese.

Cong! You can dream the next story...

e4 0.9 review - 02 - How to write a Helloworld JavaScript Bundle

2009-08-31T14:12:00.002+08:00

e4 0.9 review - 02 - How to write a Helloworld JavaScript Bundle

Go on the next e4 .9 review blogging.

The e4 has introduced the "JavaScript framework" to demonstrate the flexibility of e4 language support. In the meantime, this e4 component makes the Eclipse much similar to the internet browser(like FF,Chrome,IE...). Yeah, it can be imagined that we get a heavy but high-performance internet client. The GEF/GEF3D with Javascript should beat mainstream Javascript libraries easily. Cool...Oh, it is a little unfair to compare the C/S structure to B/S...

One thing worried by me is that, in the JS framework diagram, one flow "e4 JS->Rhino->JVM" pass by the OSGI framework. It is a smell in the aspect of security. Because the OSGI is a thin modular layer on the JVM to some extent. I can not figure out why this design is a must.(Rhino problem?)

This Javascript language support in Eclipse is a especially interesting topic for me recently. I am also doing some EPLed ecmascript 5 experiments privately. The basic idea is using the Eclipse related technologies and JDK7 MLVM to refresh the status of "JavaScript on JVM"(new Rhino?). Is there someone in the community interesting this effort? Collaboration?

Oh, a little away from the point:) In fact, one big reason for this article is that, I find no one know how to write a JavaScript Bundle and run it in the e4. Simon Kaegi said in the mail list that, they are busy doing tooling support, and "at the moment information is hard to come by other than the wiki page". As one of the most important features of e4, the missing of "Get Started" docs really blocks the passion of community. However, I think they just want to show the perfect achievement to the community when they are ready.

After quickly sources reviewing yesterday, I find that it is possible to uncover the tip of the iceberg. Maybe there are many potential contributors to take part in the evolvement of the e4 language support.

Firstly, you can read basic infos from the e4/Javascript wiki page.

I demonstrate how to code one co-located JavaScript bundles in a host OSGi bundle.(I doubt the usefulness of the semantics of the pure Javascript bundle.)

This kind of JS bundle consists of three key parts: "JavaScript-Bundle" header in manifes.mf, manifest.json(equivalent to the osgi manifes.mf), test.js(the name is arbitrary, however, you put the logic of bundle here). Some srceenshots seen as follow:

"JavaScript-Bundle" header in manifes.mf

manifest.json, note the name "Activator" should match with the constructor function in test.js(test0.js here is a bug-like script I found accidently, it seem a rhino bug. However, more dependencies cause more security problem...)

add "-console" arguments, and set the "auto-start" into true if you want to get the same screenshots below(orz, you can do it by hand)

the content of test.js(not use the rhino "print", you should borrow the "println" from Java), and we get the "Hello..." when start osgi(yeah, all wanted-to-be-started bundles will be started)

we get the "Goodbye..." when stop osgi(yeah,all started bundles will be stopped)

Congrats! You've got your first trusted Javascript bundles in e4!

Although this is a Helloworld Javascript bundle, I make sure that you can get more exciting things if you dig into the world of e4 language.

e4 0.9 review - 01 - on the road

2009-08-30T18:01:00.002+08:00

e4 0.9 review - 01 - on the road

After some recent job interviews and ecmascript 5 specification(final draft) reading, I have the breathing time in this weekend to come back to our Eclipse community. I find that there is one trend for me to do a lengthy blogging. One reason for this is that I'd like to discuss the useful, not trivial technical aspects of Eclipse evolvement in our community at least. However, this need a long time to prepare the contents usually in the span of one week or more. Maybe I can break one lengthy blog article into more short ones to make my life easier?:)

To my surprise, there are only several pieces of blogging targetted to the e4 Feedback Contest, compared to the huge number of reviews in the recent Galileo blogathon. Maybe the prize of the contest is not big? I have got one Eclipse shirt in the past. Yeah, it's great. To make me to write this review(oh, maybe a series), it is the McQ's words. This blog article is the longest one I've seen in our Planet, which address the current status of e4 and how the committer think the e4. As a healthy ecosystem, it is the responsibility for the committers to discuss the big changes before they made with the community. I really appreciate the McQ's work. So, he hope to get the feedback from the community, and I hope to give the feedback to him.

Like my Galileo review, I will not repeat the common basic informations about the e4 here. You can find enough stuffs at [1][2][3].

I review as the follow,

Compatibility:

I test the templates binding with the plugin creation wizard. For the plugin, the compatibility for 3.x plugins seem nice. Because the main existed concepts of framework have not been changed. However, all of the 3.x RCP application templates can not run on the e4 platform directly. That is a question: the 3.x application is a e4 application as well? The answer is "YES". The e4 has a provide a compatibility layer. The problem is, why we can not run the 3.x RCP application. After simply browsing the sources, I get the key to solve this problem: you can add a "applicationCSS" property to the product extension to guide the legacy workbench environment working for you. Here is the "RCPMail" product.

However, there seem a bug(or two bugs) in the plugin "org.eclipse.e4.ui.workbench.fragment". It seem odd in some aspects. So, I just mention the class "org.eclipse.e4.workbench.ui.menus.MenuHelper". If you meet some errors, you can consult this class. One thing here is, the "applicationCSS" property just serves as a dummy placeholder. This is another story. As one ongoing project, it's acceptable.

Usability

General

The default legacy workbench inherit the main face of recent Galileo platform. So, you can not see more wisdom from the a bit ugly face. In fact, there are some common but trivial unfinished parts in the e4 0.9(said by McQ's blog).

odd "Design" top menu

No toolbar for workbench
views don't support the layout
no saved last preference
clicking the current breakpointed statement in "Debug" View will not location of the sources when debugging ...
hard to close one editor if there are many opened editors
bad performance when the running time become long

Modeled UI

The Modeled UI capabilities could be played with "UI " in the top menu "e4". This is my interesting part. One reason is that I am a EMF fan. The EMF has many designs to make you happy at the Eclipse world. The dependency is one kind of responsibility. Although great Ed is still there, I hope the whole of platform with million of users dependency will not be too heavy for EMF.

Still, one obvious bug for the attribut "visible" existed.

Declarative UI

The eye-catcher of e4 is the capability of the declarative UI. There are two demo products shipped with e4. They are the standard e4 products. If you want to see how to code one new e4 powered application, see those demos. I am not a UI fan, I don't use any UI theme in my Windows desktop environment. So, I just enjoy the photos of our committers:)

Wisdom behind the e4

The most important things are the back-end ideas behind the shining or ugly face. The programming model(new?) and thus the different language support is the next milestone of Eclipse as a Utopian platform. These topics will be addressed next.

Summary

Yeah, the e4 is on the wonderful road. As a platform, I agree with the direction of e4. However, please carefully choose e4 dependencies. Hopefully, make all additions in e4 optional as possible. If one user don't like to change the skin or model something(he just want to edit his Java codes), will we force the 200+MB bulk to his disk?

[1] http://www.eclipse.org/e4/resources/e4-whitepaper.php

[2] http://download.eclipse.org/e4/downloads/drops/R-0.9-200907291930/e4-news-all.html

[3] http://wiki.eclipse.org/E4

OSGI R3 Implementation Running on Google App Engine Now

2009-08-11T19:09:00.002+08:00

OSGI R3 Implementation Running on Google App Engine Now

"OSGI on Google App Engine", this seem a little older topic now? When the first announcement of GAE/J, I just think whether it is possible to post the newest effort about this topic to the community by me. However, the poor time prohibited me from conducting more things at that time. It was ZX who posted the local test result in the community.

Time has been moving into the August, nothing new happened. I decided to revisit the little older topic.

It is known that the "sandboxed" environment of GAE/J has blocked the main OSGI running efforts. I try to rethink the real obstacle from having fun in this sandbox. For the simplicity, I do not choose the Equinox or Felix. Because they have been optimized for the full J2SE platform in a long time. I choose the framework optimized for size, that is the "Concierge". It is one of four implementations listed in the “See also” section in the OSGI wikipedia. The Concierge is a OSGi R3 framework implementation. It is still a little nice for no-trivial bundles(back to the Eclipse R3.0?).

My adventure is below...

The Filesystem

This is one main problem mentioned in the zx's blog post. However, this is just one small problem for running OSGI on GAE/J. One suggestion has been proposed by zx. That is, writing a custom storage adaptor hook. My suggestion is to take use of or consult the GaeVFS. Most of work about File-system-like GAE storage have been done in this project. I have tested some small file data storage testings. It works fine. I do no more attempt here. Because demonstrating running OSGI on the GAE/J does not need the storage. Most demands for data storage in OSGI is related to the efficiency or configuration of framework. Go ahead!

Customized Class Loading(and Reflection)

More problems will happen in this section:) In the local GAE/J, all classes are load by the IsolatedAppClassLoader. And, this class is hidden behind the API. However, in the Concierge(and other OSGI implementation), all classes in the different bundles are loaded by different bundle classloaders, which is customized from the Classloader. Definitely, the first bundle of core framework or launching core framework must be loaded by the Google runtime. If we want to cast some classes in the bundle into the class in the core system bundle, we will meet the runtime ClassNoFoundException error. The only workaround is using the launching framework to load the core framework by its customized classloader. I find that zx has found this workaround as well. The magic is in the Class FrameworkLauncher of the Equinox servletbridge.

However, the customized class loading infrastructure of GAE/J has another bug - GAE Issue 1503. Briefly speaking, the issue said that we can not read the bundles from the war-rooted file system although the reading action is alllowed by the GAE server(yeah, should/must be allowed). As we mentioned below, the GaeVFS can give a solution. But this workaround will make the debugging and deployment work very complex. And tobyr(from google?) said, "Unfortunately there is no workaround
for this at the moment". Interestingly, I find that ZX has found this workaround as well. That is, you give the AllPermission to the classloader. I list the compact version here,

...

static final PermissionCollection allPermissions = new PermissionCollection() {

public void add(Permission permission) {
}

public boolean implies(Permission permission) {
return true;
}

public Enumeration elements() {
return new Enumeration() {

private boolean hasMore = true;

public boolean hasMoreElements() {
return hasMore;
}

public Object nextElement() {
if (hasMore)
hasMore = false;
return new AllPermission();
}
};
}

};

...

using the allPermissions in the your classloaders like,

...

protected PermissionCollection getPermissions(CodeSource codesource) {

return allPermissions;

}

...

If you'd like to use the customzied classloaders, some reflection codes need to be written in your sources at least in the launch framework. My whole impression is that the GAE/J reflection support is much nice.

To arrive here, in fact, we can running the non blocking bundle or using the non blocking services if we can build one osgi runtime against with the GAE/J. Yeah!

Threads

The sandbox adheres to said "NO" to the thread creation till now. The Cron jobs in the GAE/J is not the substitute for the Java thread apparently. I have tried to find the lightweight thread(or called "Green Thread", "Fiber"...)for the threadless environment.

The defective solution is using the existed event-based concurrent mechanism. Some implementations are using the Actor model, like the Scala. After digging into the implementation, I found that almost of them take use of the thread pool(they need to use the scheduling algorithms in the java.util.concurrent). So, all of them failed in the GAE/J sandbox. However, I must say, I like the idea behind the lightweight thread framework. They are still very useful for the performance tunning of the common serve. If the GAE/J allow the limited thread/threadpool creation someday, I think we will be infinitely close to full full-fledged platform.

There is no workable solution here?...One (maybe only) workable and a little elegant solution which could be run on GAE/J, is the continuation based coroutine. Continuation is another big topic. There is no room to write many interesting contents of continuation here. I just show some efforts and results. I spend half a day to develop a Fiber and a simple Scheduler based on the Javaflow. I can run the 1000 simple Fibers in on the local app engine sdk server. Cong! However, the Javaflow is still in the unofficial phase. There are bugs in the bytecode weaving course for one complicate method. This badly limit the usage of whole concurrent system in one production platform like GAE. There is not actual meaningfulness for this Javaflow based Fiber system now. Fortunately, in the MLVM, the native continuation support for Java has been proposed and an initial patch is available. I hope a high performance implementation of continuation tools will appear. Unfortunately, we will not see the native continuation support in the JDK7. What's the time of JDK8?...

The basic conclusion of this section is, that no workaround for the threads.

Piece Together

Based on the above exploring, it is still possible to run the OSGI platform if the OSGI runtime and its bundles do not block the thread. I show this right! The below screenshots show my initial efforts:

Welcome page

Initialization of the modified Concierge OSGI framework

bundles command in Concierge, see the bundle 1 is just in the resolved state

start the bundle 1 (a simple bundle: simple.test-1.0.0.jar )

bundles command, to see the bundle 1 is in the active state

stop the bundle 1

bundles Command, to see the bundle 1 is back to the resolved state

headers command

The screenshots show the dynamic cycle of one dummy bundles in the OSGI platform. Cong! I hope to upload the sources to my personal project after some cleaning. However, I provide the web accessing in this appspot site.

After the successful running of the OSGI R3, is the OSGI R4 far away?

About the Google Eclispe plugin for app engine

The newest plugin for 3.5 is nice for the small project in my test(without GWT. I hope RAP could be run the GAE/J someday. yeah^_^). The size of whole plugin is a liitle large(300M+ on my disk, google plugin depends on some of WPT/WST). If some custom works can be done to GAE/J support, the plugin will be more bright.

Binding or not binding. It's a problem.

2009-07-24T22:50:00.002+08:00

Binding or not binding. It's a problem.

Recently, I'm finishing my one personal RCP project. I decide to touch the JFace data binding framework. To be exact, it now should be called the "Eclipse data binding" framework. The data binding stuffs have been one part in the core of Eclipse, and the JFace data binding is just one application of the Eclipse data binding. I have not played with the data binding since it's born. One main reason is that I don't think the listener boilerplate codes are hard to write or error-prone, however the databinding introduce many new concepts.

With the entrance of the databinding to the core of Eclipse and, of course, RCP, I should put it into my toolbox if I don't waste some functionalities and hard disk space.

Now, the target of my adventure is to customize a databinding implementation for Nebula PShelf.

Firstly, I take 2 days to read the most of materials from Eclipsepedia, EclipseCon, blogging or anything else. Frankly speaking, I don't like almost of them. Because they don't take care of the the customization of databinding which is just interesting for me. However, for newcomers, I'd like to suggest two reading - the old Eclipsepedia page, RCP Mail 2.0. And don't forget the offical databinding blog.

Then, I start to dig into the source of databinding. After my familiarity with the databinding boilerplate codes and others(how the framework works), the properties API appears. The properties API has been introduced into the Eclipse data binding framework from 3.5M5 to solve some hard coupling(then "Observables are hard to implement") in the framework. The properties API use the "Fluent Interface" which is one nice API style thought by me. Cong! With the help of the properties API, I succeed in finishing my PShelf databinding customization adventure.

Lastly, I just drop a few comments on the Eclipse Data Binding framework from my eye,

1. The framework seem a little over-designed.

In the runtime, the call stack will be much long even in the simple case compared to the traditional listener pattern.

And, many APIs are just delegates to other APIs. Like,

...

public static IObservableValue observeValue(Realm realm, Object bean,

String propertyName) {

return BeanProperties.value(bean.getClass(), propertyName).observe(

realm, bean);

}

...

public static IObservableValue detailValue(IObservableValue master,

IObservableFactory detailFactory, Object detailType) {

return new DetailObservableValue(master, detailFactory, detailType);

}

...

Thats means, many different APIs get into the same functionality. Facade? For the newcomers, this causes many confusions(schizophrenia?^_^). I just stick to use the properties API and see no side-effect. I suggest to making the old API "deprecated"(Orz, for the compatibility, they will be still live in a short or long term.)

2. org.eclipse.jface.examples.databinding.snippets are a little out of date.

Some demos use the new APIs. Some others use the old APIs or mixed ones. Even some ones are confused for newcomers. For instance, in the snippet class "Snippet002UpdateComboRetainSelection":

...

IObservableList list = MasterDetailObservables.detailList(

BeansObservables.observeValue(viewModel, "choices"),

getListDetailFactory(), String.class);

...

private static IObservableFactory getListDetailFactory() {

return new IObservableFactory() {

public IObservable createObservable(Object target) {

WritableList list = WritableList.withElementType(String.class);

list.addAll((Collection) target);

return list;

}

};

}

...

This demo seem not related to the Master-Detail pattern. This bulk codes are workable, but not elegant. I modify them like the below,

-->

...

IObservableList list = BeansObservables.observeList(viewModel,"choices", String.class);

...

Everything is still nice:)

3. Some API classes can provide more convenient APIs.

One example is the newcoming helper, ViewerSupport.bind(...), you can see the compact usage in this Matthew Hall blogging entry. For the default condition, we are happy to use this shortcut method. However, when we want to customize every providers, we are forced to use the old boilerplate codes. It's hoped that, we can add some provider accessor/mutator method in the ViewerSupport, like, get/setContentProvider, get/setLabelProvider. After that, we can live in a more concise room more happily.

4. Databinding framework has been mature to use in mainstream development(oh, some companies have done this long long ago^_^)

Although it still needs the the listeners to implement some functionalities under some complex scenarios, the databinding have covered most common UI usages. With the R3.5 properties API, we can code in a concise style from the UI application to the databinding customization. However, the databinding framework has a relatively high learning curve, in comparison to the traditional listener pattern. The listener pattern is more straight and debuggable. You can stay in the traditional listener codes if you think it is enough. Indeed, the Eclipse Databinding seemly provide more advanced features such as the before/after validation, which need a careful design if you try to code from scratch. The learning time is the price of any framework. The only thing is whether we choose a right framework. The Eclipse data binding framework is just the right framework.

Next, I'm considering to taste the EMF Data binding API (with the new properties API) some time.

When the PDE(JDT) met the Jar-in-Jar bundle

2009-07-15T10:25:00.002+08:00

When the PDE(JDT) met the Jar-in-Jar bundle

"Jar-in-Jar" is a word using in the 3.5M5 new and noteworthy page. A Jar-in-Jar bundle is just the jarred bundle which contains other jars. (sometimes, called "nested Jar".)

Recently, when I use the db4o osgi bundle, I met a compilation problem. It said,

"the type com.db4o.ObjectContainer cannot be resolved. It is indirectly referenced from required .class files".

From one entry in its forum, I know that, it is an old problem after the db4o get into the world of osgi.

After a simple inspection, I find the reason. That is, the PDE can not resolve the Jar-in-Jar bundle. The old Bug157375(and Bug 111238 as well) addressed this problem. As Jeff suggested in the comments, the best practice for this is "packaging each JAR as a bundle and not nesting JARs at all".

However, as Jeff said as well, "Equionx(and other OSGi implementation?) will run JAR'd bundles with nested bundles just fine". So, this just causes a compilation error, but not a runtime problem. I think this bug is still a bug.

As Thomas Watson said, this bug "well actually is JDT" bug. Jeff simply suggested a bug-fixing idea: "basically if the bundle has JARs on the classpath then unzip in a temp spot and us the temp location for classpath computations". But the Bug 111238 seemly said more problems with extraction method. I have one idea, like using some detecting codes just to check the correct dependency of the jar-in-jar on the fly and to avoid the compilation blocking. In the other aspects, we can still use the original bundle.

Lastly, two workaround for this bug: 1. using the best practice pointed by Jeff; 2. unzipping the jar, then using the directory-style bundle.

Warning: If you are the man responsible for building your osgi bundle, please keep the best practice. "nested jars are evil"(zx^_^).

My Eclipse Galileo Review: from one eye in the community

2009-07-14T13:15:00.002+08:00

My Eclipse Galileo Review: from one eye in the community

p.s.: Galileo is has a special position in my heart for his cool scientific contribution to our human being.

The annual simultaneous release Galileo has grown to 33 projects. There are many articles about the tips and tricks of Galileo in the planet of Eclipse. So, in this article, I will not review the common tips in the Galileo, however, I will try to review some tracks of development and community process from my eye when the Galileo train are being developed. And, so, I will not cover everything in Galileo, and just show some interesting things in my eye.

1. Eclipse platform

Not mention the R3.5 News and Northwory:)

"p2 is great", the words often appear in the planet of Eclipse. As a common provisioning platform in the osgi, the p2 introduce many new concepts and designs than old old "Update Manager". And P2 is the successor of old update manager. In fact, I much like the idea behind the p2.

However, as an old Eclipse guy, I am not very satisfied with the current state of p2. P2 seem not cover all the functionality of old update manager. One bug, we fight for, is the Bug 224145. As an active Eclipse developer, we often have many different projects. For instance, one project is based on EMF, one other project based on CDT, one other project based on BIRT, still one other project based on WTP...As all we known, the startup time difference between booting from 50 plugins and booting from 500 plugins is very very obvious. Does anybody want to wait 30s to get one Eclipse instance to just writte an simple ant script or xml config file?. In the world of "old update manager", we are easy to use different configurations to achieve it. Here is a useful tip by Michael Scharf. I guess p2 could do this as well, however, who knows how to?

Here, I do a unexact small statistics about the p2 problem(and update problem) in the recent equinox group(eclipse.technology.equinox, from 2009/06/01 to 2009/07/10): 27(p2 related)/77(equinox all) =35%. Now is the age of R3.5, and the p2 is just the one small component of the whole Equinox. Even now, I often hear the complaint from newcomers in my BBS, such as, "the auto-upgrade does not work", "updating crash my Eclipse"... So, p2 is great, but there is a (long or short?) way to make most people in the community to accept it.

git

Git is coming into Eclipse. Yes, CVS, SVN and GIT are in parallel use in the development process of Eclipse projects. you can find the hot discussion here, and more here. Git, as one kind of DVCSs, provides many new improvements and features. I guess more and more projects will transfer to the git when the next iteration. However, if some projects have played finely with the current svn/cvs server, they may stay with it in a long period.

bugzilla search engine

Bugs searching in bugzilla is not much cleverer as we expected. It is a little pain for our developers or users. Hence, Gunnar Wagenknecht fire a bug, i.e. Bug 214067. Yes, we wanna let Google index the Eclipse.org Bugzilla. Google engine can rank the search result in a better relevancy. However, it is reported that the direct google indexing will cause some potential spamming problem. So, this enhancement has not resolved. Now, we can taste one experimental indexing bugzilla search engine provided by Gunnar Wagenknecht(seemly does not work recently). Nice work, Gunnar!

Eclipse weather

Eclipse Weather Forecast, is a new column in the Eclipse.org site during the period of Galileo. I like it! For instance, you can know the next release of Eclipse train is called "Helios"(Yep, not e4). Funny^_^ This column really make Eclipse community more interactive, especially between the committers and the end users. I hope that this forecast could be updated more actively:) If you like it, you can add it to your favorites. One problem is, the address of its RSS seem re-directed to another news Eclipse rss...

2. Modeling

The EMF seem already the defacto standard of modeling. Many new and kinds of projects, such as EMF Index, EEF, EGF, Edapt, has poured into the EMF ecosystem during the period of Galileo train. Some is cool. For instance, for EMF index, we can dream a modeling object database will appear in some day. Other new projects, I am not much familiar with those. I Hope they can pay attention to the collaboration in the whole modeling ecosystem. However, EMF is a must for an Eclipse guy! Even the coolest e4 has been depended on the EMF:) You can image that, in some day, you can't survive in the Eclipse world without modeling things!

3. Graphical

In the field of graphical editing, there are not many news. The GMF and the GEF still control the world. Zest in GEF get some funds at this summer. Cong! One project, I like to mention, is GEF3D, which could be considered as the 3D version of GEF. GEF3D is not listed in the Galileo packages and is considered as an incubation project. However, I like the idea of GEF+OpenGL behind it. There is a old bug, Bug 68724, in the Bugzilla addressed this requirement. In fact, the GMF team(yep, they are also maintenancing the GEF) have introduced some animation effects into the field of graphical editing. However, as we know, OpenGL (or like things) is more professional in all kinds of graphical effects. It can be seen that, Thomas Crockett, a NASA guy, has given the wonderful experience in the Mars rovers the with the GEF+OpenGL. Do you like do a overhauling to your graphical editor? Ask the GEF3D now!

(P.S.: I have an idea about GEF3D + Zest, maybe this can be a next years' gsoc topic^_^)

4. Web

(p.s.:I am not a web side guy now. )

RAP

This project provides a web presentation layer on RWT API + a runtime server layer on Equinox. Cool! After that, a plugin developer can easily develop a web site(Yep, that's called "Single Sourcing"). I much like this kinds of technologies. Yes, you can dream doing everything using Eclipse. This is just an eclipsed life, advocated by me.

XML Tools

On the planet, we has one diligent blogger, David Carver. He is just responsible for the XML related tooling development in WTP. If you want to grasp the main progress of XML related things in the Eclipse/WTP, you can rss his blog:)

The WTP has provided many mainstream XML tools although there are many XML plugins provided by other commercial companies. Frankly, the user experience of WTP/XML editor is not very good in my limited tests. One main problem is the bad memory consumption. Several old is or new bugs(Bug 156564, Bug 136935, Bug 142692) addressed this problem. It is quite a relief when I heard some work have been done when the Galileo although I have not tested the effect of improvement.

I had involved with XQuery work in the near past several months. This is the one of some unfinished works in WTP/XML. For some reasons, I have not finished my effort. In my personal opinion, it seems the best choice to follow the way of XQDT 2.0(http://www.xqdt.org/) or to collaborate with it. However, there are still some problems existed.

5. Others

I just mention one hot topic DSL(language) IDE support in Eclipse. The Xtext and DLTK has joint the Galileo train. And the Xtext has shown its face at the planet of Eclipse. I've written down a funny entry:

IMP V.S. DLTK. V.S. SSE V.S. Xtext V.S. JTF V.S. LTK(in Eclipse) V.S. ...

There is a highly overlapped area in the language IDE support, and nobody intend to do some collaboration work:) So, here, I don't comment on the pros or cons of each ones. I just recommend one newborn project:

IMP

IMP is based on the idea of "meta-tooling"(Yeah, you may associate it with meta-model in your brain...). That is, based on some meta descriptive languages (such as English?) or components, we can get(generate) our wanted tooling(IDE). Some awesome abstractions have been done in IMP. IMP can provide many IDE-level supports, such as outline view, content assistant, preference construction... IMP is general tooling support platform. IMP supports general language(reinvent the JDT using IMP have been domonstrated in IMP. Cooling! ). IMP supports debug functionility construction. IMP supports refactoring functionility construction. And IMP supports "embedded language"(thinking, JavaDoc in Java done by JDT).

Although the IMP is in the incubation phase, as my recent tests, the basic runtime is stable relatively. One thing, I love, the IMP with LPG(LALR Parser Generator) could provide a full-EPLed solution to language IDE support. Cool! If you plan to develop a language IDE support, you can considered to take use of the IMP. You will get a clear framework, little-size dependency, grammar development tooling and advanced analysis features supports. And I am also planning to write some articles about the IMP and LPG:)(to compete with the current Xtext series?) Oh, come on!

6. Future

The e4 is the coolest thing in the platform evolvement. The e4 has released the 0.9M5 recently and is moving into the 0.9RC1. As I mentioned above, the next train release of Eclipse is called Helios, not e4. However, the e4 is our future(Eclipse 4.0?). I don't repeat anything. If you like to try, you can get more infos from the e4 web site. I just say that, the e4 is worth a try!

We should thank all Eclipse committers to push the Eclipse into a higher-level milestone when the Galileo. We are living in a technically dreaming community...

Db4o Object Manager Rcp 1.0.0 released

2009-07-11T14:20:00.002+08:00

Db4o Object Manager RCP version 1.0.0 released

Today I have released the first DOMR(Db4o Object Manager RCP) release at the project site. I include two platform version in the release: win32.win32.x86 and linux.gtk.x86. I have tested the win32 version, but not the linux version. If there is some bug, please fire a bug issue here.. In fact, it is easy to export 16 platform versions under eclipse. If some bodies like to provide some tests work, please also fire a bug issue here. I'd like to provide new platform version.

The current DOMR is based on the OMJ svn codes. I just mainly fixed a little irrational UI flow(I think^_^). Some codes I've seen are not written in a good style. So my modification is not very elegant as well. But, it works:)

As the project page said, It will be a lightweight, standalone db4o object management tool. For the time-limiting, I may foucs on the bug-fixing work. If you have found bugs, don't hesitate to submit issue here. It is my pleasure to fix it for you:)

However, I hope this project will go into its own way in the future. I'm considering to do more clean work to the current code base. And there are some potential directions in the DOMR, such as more professional Eclipse-integrated UI, db4o-java code generation. graphical db4o visualization, db4o DSL. If some ones in the community have interesting in this project, you can drop a email to me. I will add your account to the project member list, then you can contribute to the code base:)

Da Vinci Machine(MLVM) Ready for Hacking

2009-06-08T21:01:00.004+08:00

Da Vinci Machine/MLVM, as said in the website , is a multi-language renaissance for the JVM, which is under the umbrella of JSR 292. Some dynamic languages on JVM like JRuby(and Groovy?) have played with those cool MLVM functionalities some times ago in some limited scope. Because the MLVM need to be built from the source, and because on some platforms OpenJDK could not be built easily.
In recent days, the OpenJDK/JDK milestone 3 released, and the MLVM is one of the coolest features targeted in the milestone 3. So, I think it is the time to try how the MLVM tastes in the midst of my busy schedule:)
I download the JDK binary snapshot b59 for my windows. Install and re-setup my path. Then, copy below helloworld codes(shameless got from the repo of MLVM, thanks for John Rose, leader of MLVM/JSR292):

import java.dyn.*;
public class Hello {
public static void main(String... av) {
if (av.length == 0) av = new String[] { "world" };
greeter(av[0] + " (from a statically linked call site)");
for (String whom : av) {
greeter.invoke(whom); // strongly typed direct call
// previous line generates invokevirtual MethodHandle.invoke(String)void
Object x = whom;
InvokeDynamic.hail(x); // weakly typed invokedynamic
// previous line generates invokedynamic MethodHandle.invoke(Dynamic)Dynamic
}
}
static void greeter(String x) { System.out.println("Hello, "+x); }
// intentionally pun between the method and its reified handle:
static MethodHandle greeter
= MethodHandles.lookup().findStatic(Hello.class, "greeter",
MethodType.make(void.class, String.class));
// Set up a class-local bootstrap method.
static { Linkage.registerBootstrapMethod("bootstrapDynamic"); }
private static CallSite bootstrapDynamic(Class caller, String name, MethodType type) {
assert(type.parameterCount() == 1 && (Object)name == "hail"); // in lieu of MOP
System.out.println("set target to adapt "+greeter);
MethodHandle target = MethodHandles.convertArguments(greeter, type);
CallSite site = new CallSite(caller, name, type);
site.setTarget(target);
return site;
}
}

>>javac Hello.java

Oh, Error! Yes., that seem "a bug in the 1.7 compiler " discussed here.
try again,

>>javac -source 1.7 Hello.java

Cong!

>>java -XX:+EnableInvokeDynamic Hello
Hello, world (from a statically linked call site)
Hello, world
set target to adapt greeter(java.lang.String)void
Exception in thread "main" java.lang.UnsupportedOperationException: NYI
at sun.dyn.FromGeneric.buildAdapterFromBytecodes(FromGeneric.java:238)
at sun.dyn.FromGeneric.(FromGeneric.java:98)
at sun.dyn.FromGeneric.of(FromGeneric.java:185)
at sun.dyn.FromGeneric.make(FromGeneric.java:177)
at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:247)
at java.dyn.MethodHandles.convertArguments(MethodHandles.java:764)
at Hello.bootstrapDynamic(Hello.java:58)
at sun.dyn.CallSiteImpl.makeSite(CallSiteImpl.java:64)
at Hello.main(Hello.java:42)

Cong too! Although the weakly typed invokedynamic entry seem throw the UnsupportedOperationException. (although it is odd why the helloworld example can not pass the test^_^)
It is super-cool! I guess some concepts such as MethodHandle will affect the implementation of the proposal of "closure" in Java.

One natural question is, how do our Eclipse get ready to work with MLVM?

Can ECJ emit the invokedynamic bytecode?
Can Equinox(OSGI) benifit from from the new dynamic behavior?
...

Come on!

db4o OME into RCP easily

2009-04-16T16:36:00.007+08:00

Recently I pick up my old idea about the code snippets management tool. For a personal project, I would like to use a lightweight and easily-used db for store my codes. Db4o is a nice candidate for me. After making db4o work for me, I try to see what and how the db4o store it . One good news is that, db4o has provide an Object Manager(OM) to explore the local/remote db storages. One bad news is that, the OM now is only available to a little big Eclipse and very very much big MSVS. No reason I need to install an IDE if I just want to see or query one little db.

"Ample food and clothing by working with our own hands":) I quickly add an RCP cloth to the db4o OME(OM for Eclipse plugin) in a non-invasive way. It seem delicious!

After converting ICU plugin into a "base mode", the size of packed OME RCP have been reduced to about 15.4M. Cong!

I wonder whether the db4o has QA for its product? Because the current OME shipped with db4o-7.9-java has obvious critical bugs when connecting with local db files! But, a little is better than none... Hope they can fix these bugs soon.

ps: From limited eye, db4o seem an enhanced version of Java object serialization mechanism. So, Is it easy to implement a db for oject? No. There are too many considerations for storing objects(object graph indeed) in the db style. Using db4o will make your life much easy:)

Eclipsed Sun?

2009-04-03T17:23:00.005+08:00

There are some interesting news.

If IBM acquire Sun?

Some interesting brainstorming,

Netbeans will fuse into Eclipse?

SWT will take place with Swing in Java?

JDK will be under some APL-friendly license?

Java will be osgized?

Java will be faster?

...

Proposal is out too

2009-03-28T16:53:00.005+08:00

After the business of writing and some modification, I release my one proposal. Some bodies may read it, if you like to know some current XQuery and related tooling knowledge, and even if you do not use eclipse. I think it is a good reading(shamelessly)^_^

The blogspot's blog page is difficult to use. I try to blog and post by the google docs. Hope it will give me a better user experience.

For next M0a, I will do some bug-fixing jobs, and push the parser to 90-95% satisfaction. I re-examine the disambiguity condition mentioned in my former post. And I find the precedence of my expression is in reverse. It is interesting work to try to fix the problem in next days.

eXQuery M0 is out! Cheers for EclipseCon 2009!

2009-03-26T12:17:00.015+08:00

After 5-day rush, I release the eXQuery M0 today. Cheers for EclipseCon 2009!

M0 - Snapshot

The snapshot demonstrates two features, simple token coloring, and multiple errors reporting.

The man behind the nice face of IDE is the nice parser.

The shown snapshot is one script that comes form the w3c XQuery test suite. We can see the errors such as "item_tuple", is not really a error. In fact, the reason is that the "item" is a keyword in the XQuery spec, but the parser treat the keywords and the general variable-style words differently. This will be fixed in M0a recently:)(as done

in OCL^_^) The other hard problem is the XQuery grammar is not the full LALR(k) grammar(?). there are some ambiguities when using the '+' and '*' operators mentioned in w3c recommendation. One solution is to use the backtracking parser, which has been done in the eXQuery and CDT.(the w3c recommendation use a disambiguity rule to solve this problem. It could be considered how to add or we need this rule?)

Frankly, I have underestimated the complexity of the XQuery grammar. I said to Dave the words like "the grammar seem simple" in some communicating email shamelessly^_^. In fact, there are many many tricks in the grammar. To seek the reason, you can see the Martin Probst blog. I've read more and more...

The eXQuery project is a pre-exploring project for my last gsoc effect. The basic goal has been achieved. Now I'm a veteran with XQuery:) Cong! I feels 70% pleased with the semi-ugly XQuery parser. But I feels 95% pleased with the working combination of LPG and IMP. Isn't it cool if you can get one simple IDE for a working language(not toy language!) in one week?!

Being Eclipsed

SEED(Scala Eclipse Effort for Development) 1.0M0 Reached

When is the SEED M0?

​From Windows to Linux

call for job opportunities

Implicits, Scala-IDE and my mid GSOC evaluation

Align the Scala Development Tools with the Bleeding Edge of Eclip

Eclipse POLO T-Shirt Come!

Running eRCP with Phoneme Advanced on your mobile phone

Phoneme advanced and eSWT Running Under x86 Windows

e4 0.9 review - 02 - How to write a Helloworld JavaScript Bundle

e4 0.9 review - 01 - on the road

OSGI R3 Implementation Running on Google App Engine Now

Binding or not binding. It's a problem.

When the PDE(JDT) met the Jar-in-Jar bundle

My Eclipse Galileo Review: from one eye in the community

Db4o Object Manager Rcp 1.0.0 released

Da Vinci Machine(MLVM) Ready for Hacking

db4o OME into RCP easily

Eclipsed Sun?

Proposal is out too

eXQuery M0 is out! Cheers for EclipseCon 2009!

From Windows to Linux