The Object Teams Blog

Adding team spirit to your objects.

Let’s talk straight with our users

with 2 comments

Users of Eclipse trust in its quality. But what happens when they install additional plug-ins that are not part of the original download package? We tend to say that plug-ins only add to the installed system, but by saying so we’re actually spreading a myth:

“Adding plug-ins to an Eclipse install does not affect anything that is already installed.”

This simplest way to falsify this myth is by installing two plug-ins that together produce a deadlock. Each plug-in in isolation may work just perfect, but adding the other will cause Eclipse to freeze.

No zero-risk software install

Sure, in the absence of any correctness proofs, we can never be sure that adding one more plug-in to an already complex system will not break anything. Concurrency is just one of the most cumbersome issues to get right. Other reasons exist, why installing more is not always better.

Install-time risk assement

Actually, the p2 UI already distinguishes two kinds of installs: signed and unsigned artifacts, and warns the user when unsigned content is about to be installed. This is great, because now the user can decide whether s/he accepts unsigned content or not.

But this question is just the tip of the iceberg.

Behind the scenes of p2

When you tell p2 to install a given feature a number of things can happen that a normal user will not be aware of:

  • Additional required software may be pulled in, possibly from different projects / vendors / repositories
  • New features may replace existing plug-ins (patch features).
  • Installation may trigger touchpoint actions that modify central parts of the system
  • Installed plug-ins may access non-public classes and members of existing plug-ins
  • New plug-ins may hook into the Equinox framework (adaptor hooks)
  • New plug-ins can weave into the bytecode of existing plug-ins.

Is this bad?

Don’t get me wrong: I believe all these ways of influencing the installation are very useful capabilities for specific goals (and Object Teams utilizes several of those). However, we may want to acknowledge that users have different goals. If you need to be 100% sure that installing a plug-in does not delete anything on your hard disk you will not be happy to learn about the touchpoint instruction “remove”, while apparently others think this a cool feature.

Touchpoint actions have no ethical value, neither good nor bad.

Negotiation over rules

Drawing the line of how a plug-in may affect the rest of the system can be done up-front, by defining rules of conduct. Thou shalt not use internal classes; thou shalt only add, never modify etc. But that would impose a one-size-fits-all regime over all plug-ins to be published, and installations that can or cannot be created from published plug-ins. This regime would never equally suite the anxious and the daring, users with highest security constraints and users loving to play around with the newest and coolest.

Better than one size would be two sizes (conservative & bleeding edge), but then we still wouldn’t meet en par with our users, with all their shades of goals (and fears). Instead of imposing rules I suggest to enter negotiation with our users. By that I meen:

  • Really tell them what’s in the boxes
  • Let them decide which boxes to install

Proposing: Install capabilities

I could think of a concept of install capabilities at the core of a solution:

  • Each artifact may declare a set of non-standard capabilities required for installing, which could include all items from the above list (and more)
  • During install a security/risk report will be presented to the user mentioning (a summary of) all capability requests
  • Based on that report a user can select which requests to accept, possibly blocking risky plug-ins from installing
  • The runtime should enforce that no feature/plug-in uses any install capabilities which it didn’t declare

In this context I previously coined the notion of Gradual Encapsulation including a more elaborate model of negotiation.

More specifically I filed bug 316702. Where I’d love to read some comments.

Are you going to Eclipse Summit Europe? Shouldn’t we talk about this in a BoF?

I strongly feel it’s time to talk straight to our users: adding new artifacts to an existing Eclipse install is not always purely additive. Installation can indeed modify existing parts. In an open-source community, we should tell our users what modifications are requested, what potential risks are associated with a given artifact. They are grown-up and able to decide for themselves.


Written by Stephan Herrmann

October 31, 2010 at 00:07

Posted in Eclipse, Object Teams

Tagged with , ,

2 Responses

Subscribe to comments with RSS.

  1. While I agree in general, I don’t think that accessing internal or non-public classes is the problem. I almost always access internal classes and hack non-public classes, and this rarely causes any problems. What causes problems are things like the EMF model registry or GMF’s provider architecture. In both cases one plugin can accidentally break other plugins — and one can spend hours and days finding the problem. Subclassing an internal class doesn’t harm anything or anyone. That is, the problems are caused by design and not by broken encapsulation.


    (And no, I never had a problem with newer versions of plugins of which I had used internal classes. I had problems — but they were caused by changed behavior somewhere else.)

    Jens vP

    October 31, 2010 at 10:45

  2. Jens,

    I, too, have positive experience with accessing internal classes – given I read “internal” as “use at your own risk”. I mean, there’s nobody I can blame if changes to an internal class break my plug-in, if it ever happens.
    However, I respect that people have reasons to put up a rule that internal classes must not be accessed externally.

    For Object Teams I surely seek to convince everybody that our plug-ins are safe to use, e.g., by running the JDT tests against the OTDT to catch any regressions that could possibly be caused by any of our tricks.
    Yet, I prefer to let users decide whether or not they are actually convinced, and for this decision they need the information of what tricks are applied.

    Surely, also anticipated extensions (playing by all explicit rules) can break other plug-ins. I’m not sure what problems exactly you’re alluding to, but I can imagine lots of things in plug-in designs that could use more contracts and more reporting in case of (potential) interference.

    Finally, I don’t see an either-or: I personally like to work towards risk reporting and negotiation regarding encapsulation. Why don’t you initiate something similar for the registries that cause grief for you: analyze the risks and make sure they are detected and reported as early as possible. Maybe we need more rules here. Maybe new rules will again block other people from developing cool stuff. And on and on.

    My central plea is just: let’s be very open about all the rules and about when we choose to ignore a specific rule. Let’s include the user in the loop.



    October 31, 2010 at 19:59

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: