The persistence of e4

In Eclipse 3.x you can remember the current application state (the user’s layout and window size) between application sessions, via the setting configurer.setSaveAndRestore(true); in the initialize method of ApplicationWorkbenchAdvisor. See Eclipse RCP Tips and Tricks for details.

Eclipse e4 has no ApplicationWorkbenchAdvisor class and the application model has no property to set this. Therefore you may assume that you cannot influence the e4 behavior.

But of course this is not true. :-)

e4 has two command line options to get a similar behavior then in Eclipse 3.6. If you use the command line option “-clearPersistedState” then the user changes will be deleted.

I believe “-deltaRestore” is intended to work similar to setSaveAndRestore(true). Currently in Eclipse 4.1 M2 the state is always saved but I think that is a minor bug. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=313883 for details.

Many thanks to Remy Suen for the tip on these parameters.

Once the bug discussion has been finished I will update my Eclipse 4.0 Tutorial.

[UPDATE: The parameter is not called deltaIgnore instead of "deltaRestore".]

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, He is the primary author of vogella.com. With more than one million visitors per month this website is one of the central sources for Java, Eclipse and Android programming information.
This entry was posted in Eclipse and tagged , , . Bookmark the permalink.

2 Responses to The persistence of e4

  1. Tom Schindl says:

    This is not correct – deltaRestore only controls the type of change restoring:
    a) persit deltas and load from there
    b) persit the complete model

    The problem is that our fragment contribution story and none delta-restore don’t really work good together because your contributions get doubled!

    The replacement for setSaveAndRestore() is -persistState but there’s been a bug in 4.0 see 324841 so the only option for now is -clearPersistedState

  2. Lars Vogel says:

    @Tom thanks for the clarification. Looks like in https://bugs.eclipse.org/bugs/show_bug.cgi?id=313883 that the topic is still a little bit due to changes.

Comments are closed.