1. The application model is stored in the e4xmi file, and provides a way of representing the entire state of the application's UI. It is also persisted on save and then reloaded at startup, so positions of parts and their visibility are persisted. The model is also accessible at runtime via the various M* classes such as MApplication and MPart, and can be queried and mutated at runtime.
2. Parts are a more generic form of views and editors. Unlike Eclipse 3.x, not everything needs to fit into a View or Editor category; they are all just parts that contain UI components underneath, and can be organized appropriately.
3. Although extension points aren't used for things like commands, keybindings or views, they are still used to define other extensions to Eclipse such as builders, marker types, and language parsers. The only thing that the Eclipse 4 model moves out of the extension points are the UI-related concepts. Even then, in the Eclipse 4 IDE the backward compatibility mode ensures that all the UI-related extension points are still rendered. For developing IDE plug-ins, the Eclipse 3.x APIs will likely be around for the next couple of Eclipse releases.
4. The Eclipse 4 contexts are essentially a series of HashMap objects that contain values (objects) associated with keys. Parts can dynamically obtain content from their context, which includes all the injectable services as well as dynamically changing content such as the current selection. A context is implicit in every part, and inherits up the containment chain, terminating with the OSGi runtime.
5. There are several annotations used by Eclipse 4, including @Inject (used to provide a general 'insert value here' instruction to Eclipse), @Optional (meaning it can be null), @Named (to pull out a specific named value from the context), @PostConstruct (called just after the object is created), @PreDestroy (called just before the object is destroyed), @Preference (to pull out a specific preference value or the preference store), @EventTopic and @UIEventTopic (for receiving events via the event admin service and on the UI thread respectively), @Persist and @PersistState (for saving data and view data), @Execute and @CanExecute (for showing what method to execute, and a Boolean conditional which has a Boolean return to indicate if it can run), @Creatable (to indicate that the object can be instantiated), and @GroupUpdate (to indicate that updates can be deferred).
6. Messages are sent via the EventBroker, which is accessible from the injection context. This can use sendEvent or postEvent to send data. On the receiving side, using the @UIEventTopic or @EventTopic annotations is the easiest way to receive values. As with preferences, if it's set up as a method parameter then the changes will be notified.
7. Selection can be accessed using the value from the context with a method injection or value injection using @Named(IServiceConstants.ACTIVE_SELECTION).
