SEED(Scala Eclipse Effort for Development) 1.0M0 Reached

NOTE: the project has been stopped in that no enough time and my reflection to the language.

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!