1. Mobile Tools for Java Platform
The goal of the Mobile Tools for Java project is to extend existing Eclipse frameworks to support mobile device Java application development.
MTJ will enable developers to develop, debug and deploy mobile Java applications to emulators and real devices.
Scope of the doc:
Focus on 1st release (+ potential future features)

2. Contents Eclipse High-Level Architecture Java Runtime Environments
MTJ Ecosystem
MTJ high-level layers
MTJ Development by Milestone
Device fragmentation
Pre-processing
Automated & manual testing
Build management
Wizards
Runtime Launch
Debugging
Code Editor
Deployment
Device Management
Signing and Obfuscation
Localization
Application Flow
GUI Editor
Backup slides

3. Eclipse High-level Architecture
Ecosystem
Vertical Industry Initiatives
Horizontal Technologies
Enterprise Domain
Internet Domain
Desktop Domain
Embedded Domain
Mobile Domain
Technology Enablers
Data Management
Modeling Tools
Embedded & Mobile Tools
Web Tools
Service Oriented Architecture
Java Dev. Tools
C/C++ Dev. Tools
Test and Performance
Business Intelligence & Reporting
System Management
Frameworks
Modeling Frameworks
Graphical Frameworks
UI Frameworks
Tools Platform
Workspace
Project Model
Update
Multi-language support
Rich Client Platform
Runtime
Workbench
SWT

4. Java Runtime Environments
Legend
Java JRE runtime dependencies
Not used Java runtime
J&C and MTJ runtime scope
Enterprise
Desktop
High-end devices
Low-end devices
Smart Cards
Optional packages
Optional packages
Optional packages
Optional packages
Personal profile
J2EE
J2SE
Foundation profile
MIDP
Java Card
CDC
CLDC
Java Virtual Machine
KVM
Card VM
Java Micro Edition (J2ME)
The MTJ projects focus in Mobile runtimes is in the J2ME area.

5. MTJ Ecosystem Eclipse MTJ context Download / Update sites
U E I
Vendor X SDK
JavaDocs
API
Different vendor products based on Eclipse MTJ
Download / Update sites
Eclipse
MTJ
API
Sun / IBM (tooling runtime
JRE 5.0 / J9 )
API
JavaDocs X
U E I
Vendor Y SDK
JavaDocs
API
A List of JVMS
Vendor X (for SDK download)
Tooling Runtimes JRE , J9
Vendor Y (for SDK download)
Operating Systems: Win32, Linux, MAC.
Real Device
Generic SDK
API
JavaDocs

6. MTJ high-level layers Mobile IDE Components Device Platform Provider
Device Description Provider
Obfuscation Provider
Packaging Provider
Signing Provider
Device Platform Provider
GUI Builder Provider
Pre-processing Provider
Build Provider
Deployment Provider
Ant Provider x
Mobile IDE Extensibility Framework Layer
Runtime Management
Build Management
Deployment Management
Device Management
GUI Builder Management
Security Management
Eclipse Tool Services
Visual Editor
Web Tools Project
GEF
Data Tools
Multimedia Tools
Multi-language support
Graphical Modeling Framework
BIRT
Testing & Profiling Tools
Workflow Toolbox
Eclipse Modeling Framework
EMF
Eclipse Platform
OSGI
SWT
Workbench
JDT
Operating Systems: Win32, Linux, MAC

7. MTJ Development by Milestone
Mobile SDK Emulator
Mobile RAD / IDE
GUI builders
Wizards
Provider Components
Game Editor
Create Application
Code Packaging
Build
Project
Build
Other
J2ME Nature
Obfuscation providers
Audio converter
Flow Editor
Create Class
Create Project
Deployment
Code Editor
Signing provider
Custom Components
Legend
1st Iteration
2nd Iteration
1st Release
Future design
LCDUI Editor
Symbian templates
Create UI
J2ME project builders
Deployment providers
Localization
eSWT Editor
Pre-processing
JAD Editor
Snippets
Runtime launch
Xx Editor
Desktop
Device
Packaging
Help
Debugging
Antenna provider
Desktop
Device
IDE Extensible Framework Layer
Device Management Framework
Build Framework
Deployment Framework
Runtime Management Framework
GUI Builder Framework
Security Management Framework
Eclipse Platform

8. Device fragmentation X X =
Different characteristics of devices must be taken into account
Physical device characteristics, e.g. display resolution,-size and buttons, processing power and memory
Quirks in the OS, API and Java virtual machine implementations
Variation comes also from APIs supported by each device
Flavours of Symbian (S60, S80, S90) and other mobile OS versions
J2ME profiles and configurations CLDC 1.0/1.1 and MIDP 1.0/2.0
Optional APIs for Bluetooth, 3D, Multimedia, Web Services, etc.
Proprietary APIs from device manufacturers and operators
In addition, there are other operator and market requirements
Localisation, branding, billing, etc.
New devices and APIs are introduced frequently
Huge amount of
configurations
Varying
devices
Differing
assets
Operator
requirements X X =

9. Device fragmentation, Mobile value chain
This diagram represents the major players in the wireless industry. Application- and Content providers have partnered with Network operators to design and develop Java solutions for consumers. Content aggregators license content from it’s creators and format it to be used with specific devices and networks.
Content distributors create the revenue by providing the distribution channels.
Network operators (carriers) and Infrastructure providers control the wireless network and own the customer information. Device manufactures drive the technical innovation through the new hardware.
The application developers and content aggregators needs most tools against the device fragmentation.
Application Developers
Content aggregators and Distributor
End-user / consumer
Network operators
Retail
Infrastructure providers
Device manufactures
Legend
Information exchange
Cash flow exchange

10. Device fragmentation, pre-processing
Definition: Pre-processing changes the source code before it is compiled. It allows conditional compilation and inclusion of one source file into another and is helpful when trying to maintain a single source for several devices, each having its own bugs, add-on APIs, etc. and it enables device optimization.
The Eclipse JDT could add support for pre-processing, alternative could be e.g. J2ME Polish, which can be integrated to Eclipse (licensing must be checked) or re-implementing the similar functionality.
One key feature is the device description database, that helps to create tasks or actions against similar devices. The device description database enables that developers can identify and group devices with an keyword, that can be used e.g. in pre-processing.
Can be seen as one definition 1
Runtime Platform Definition
Device
Emulator
Real
Device Platform
1..n
Fragmentation Definition 1

11. Automated & manual testing
Tdb.

12. Build management
The build environment is heavily relying on Eclipse, but there are plans to support also Ant. One planned extension to Ant is the Antenna –project, which provides a set of Ant tasks suitable for developing wireless Java applications targeted at the J2ME and Mobile Information Device Profile (MIDP).
The build management enables that the build process can be configured to suit for the active project needs. E.g. what build providers are used as default and how the building process works.
The target device management provides data about selectable devices and J2ME platforms (SDK Emulators) and enables that the Runtime Platform Definition. The selected default target Device Platform is then activated to the projects use.

13. Wizards
Base wizards:
Create Project
Create Application
Code Packaging
Create Class
The base wizards implement the corresponding Use-Case requirements.
One optional scenario may be that Symbian has created an template mechanism (that is in use currently in C++ side in Eclipse), that the MTJ could convert to be used in the Java side.

14. Runtime Launch

15. Debugging

16. Code Editor
The MTJ code editor is based on the Eclipse JDT base functionalities.

17. Deployment and Runtime management
The MTJ provides an Deployment and DevicePlatform frameworks that supports the existing SDK Emulators and phones runtimes
The framework publishes a Device Platform -interface, that capsulate (hides) the actual runtime environments and protocols.
The framework separates the different vendors products to own plug-ins
Eclipse
Vendor X
SDK Emulator
Plug-in
SDK / Emulator (Vendor X)
MTJ
Plug-in
Vendor Y
SDK Emulator
Plug-in
SDK / Emulator (Vendor Y)
Device
Platform
Vendor Z
SDK Emulator
Plug-in
SDK / Emulator (Vendor Z)
Extension point
Vendor X
Real Device
Plug-in
Real Device (Vendor X)
Vendor Y
Real Device
Plug-in
Real Device (Vendor Y)

18. Runtime Platform Definition Fragmentation Definition
Device Management
The device management in this scope focuses to enable detecting, visually showing, identifying and visually managing the available mobile devices.
There should be ability to group devices with similar configuration based on some criteria. This grouping could be used e.g. in the packaging / building / localization / deployment / branding processes.
The device model holds each device and
Device Platform
1..n
Can be seen as one definition
Device
Emulator
Real 1
Runtime Platform Definition
Fragmentation Definition 1

19. Signing and Obfuscation
MIDP 2.0 (JSR-118) includes enhanced mobile code and application security through a well-defined security manager and provisioning process. During the provisioning the MIDP applications are signed with an certificate, which ensures their security and makes them trustworthy.
Trusted MIDlet suites can be granted access to API's without explicit user authorization, and have wider access to device API's.
Obfuscation
By using an Obfuscator tool, the source code can be made more difficult to reverse-engineer and also there can be some code optimization benefits achieved at the same time.
Obfuscation can be done e.g. through an ANT task that activates an Obfuscator tool and it performs the obfuscation against the parameterized source code location.

20. Localization
Localization (I18N/L18N) is a major issue in the wireless space, where a single app deployed to a single carrier may need to support many languages and character sets. 
Key requirements:
The Localization architecture should be capable of supporting all languages.
It should remove the need for application developers to decide which encoding the application will support.
The Localization architecture should be aware the UI differences in devices so that the developers won’t have to (e.g. the width and length of a device screen).
The localization should enable that the service providers can extend the language supports during the deployment phase.
Allow local users to select their preferred languages as provided by the application. There should be visible UI simulation that enable to verify the UI immediately when the users switch the locale.
The localization should support at leas two approaches:
By creating a resource file (.properties) and adding there the selected source files localizable keys.
By enabling such optimization to bind the localization directly to the application.

21. Application Flow
The Application Flow creates kind a action diagram, where the visible and invisible actions are drawn on a graphical editor. The AF-editor enables that developer can design e.g. mobile application UI flow.

22. GUI Editor
The Eclipse Visual Editor provides an extensible GUI framework, that can be used in the mobile IDE UI area.
Why VE: The VE’s framework provides a lot of extension points to different kind of GUI editors
Benefits: The GUI editors would have common base framework and the there is a need to implement only the delta of the different mobile GUI editors
Now existing: The base GUI framework.
What is needed: The mobile screen engines with UI widgets to LCDUI area. VE doesn’t provide any multimedia services yet.

23. More detail presentation about the top technical items
Backup slides
More detail presentation about the top technical items

24. Backup slides – Device Fragmentation

25. Device Platform Device Platform Device
1..n
Device
Emulator
Real
Target environments are seen as Device Platforms by the MTJ environment. Device Platform contains one or more Device instances.
MTJ plug-in doesn’t know if the Devices are device emulators or real devices because the plug-in extension point API hides all implementation details

26. Device Platform, Device Platform Services
getDevicePlatforms() : DevicePlatform[]
getDevices(String devicePlatformName) : Device[]
...
Device Platform Services make it possible to query available Device Platforms.
Based on Device Platform name it’s possible to get Devices or the Platform.

27. Device fragmentation Device Project
APIs
APIs
Device
Management
Project DP DP DC DC
Project can select smaller set of APIs that the targeted devices are supporting. By selecting smallest possible set of needed APIs, the number of suitable devices is bigger.
Although the Project has the default device, the Projects definitions can match to several devices.

28. Device fragmentation, Device Services
getDevices(DeviceConfiguration dc, DeviceProfile dp,
ServiceAPI[] apis) : Device[]
...
Device Services make it possible to query Devices that are possible targets to the Project’s application. Project uses it’s own definitions as parameters in the service call.

29. Backup slides - Wizards
Wizards internal architecture

30. Wizards architecture
[template management]…

31. Backup slides - Runtime Launch
Runtime Launch internal architecture

32. Runtime Launch architecture
The Runtime Launch architecture uses the Device Platform to enable selection of available Devices.

33. Runtime Platform Device Runtime Platform Definition
JVM Impl. 1 1
1..n 1
Device Configuration DC
Device Profile DP
Service API
API
Device instance defines the Runtime Platform Definitions that it’s capable to run on.
Runtime Platform consists of Device Configuration, Device Profile, Service APIs and JVM Implementation.
Device Configuration defines used configuration (i.e. CDC or CLDC) and it’s version.
Device Profile defines used profile (i.e. MIDP) and it’s version.
Service APIs are either APIs that are defined in Device Profile or API of optional Services that the Device’s OS is supporting.
Runtime Platform Definition is always based on defined Mobile SDK JVM Implementation.

34. Runtime Platform (cont.)
JVM Impl
Service API
API
Library Jar
Library Jar 1 1
Service API –object contains the standardize service name and it’s version, i.e. WMA 1.1, MMAPI 1.1 or Location API 1.0 .
Service API has also reference to JAR Library that implements the API.
Also Mobile SDK JVM Impl –object contains the JVM name and it’s version and reference to JAR Library that implements the JVM specification that is defined by the Runtime Platform’s Device Configuration Specification.

35. Runtime Platform, Device Services
getRuntimePlatforms(String devicePlatformName,
String deviceName) : RuntimePlatformDefinition[]
...
Device Services make it possible to query Runtime Platforms of a Device.

36. Backup slides - Debugging
Debugging internal architecture

37. Debugging architecture…

38. Backup slides - Device Management
Device Management internal architecture

39. Device Management architecture
Device Platform
Device Management architecture
Mobile Project
1..n
1..n
Extended device definition
Device
Emulator
Real 1
Runtime Platform Definition
Fragmentation Definition 1
Each Mobile project may select the targeted devices, that the project is supporting. Mobile Project contains one or more Device Platforms, thus there is only one default mobile SDK active.
The Device Platform and Device instances definition is stored inside the EMF based Device model and the with extendable persistence component the definition is shared with in several projects.
The Runtime Platform Definition data is also stored and shared among projects and the Fragmentation Definition can enhance the task to find compatible device groups.
Also the pre-processing can use this to provide and define the device grouping inside the JDT.

40. Device Management
Device Description Provider
Device Platform Provider
Device Management
<< extension point >>
<< extension point >>
<< extension point >>
Device Management Implementation
Device Platform
Device Description Implementation
<< extends> >
<< extends> >
<< extends> >
Device Platform
Device Description Implementation
Device Platform
Target environments are seen as Device Platforms by the MTJ environment. Device Platform contains one or more Device instances.
MTJ plug-in doesn’t know if the Devices are device emulators or real devices because the plug-in extension point API hides all implementation details
Device instance defines the Runtime Platform that it’s capable to run on.
The Device Management uses Device Platform and Device Description information.
The deeper interaction and dependency is described in the following two slides

41. Device Management control flow
Device Management Implementation
MTJ Core Plug-in
3: getImplementations(“Device Platform”)
return: DevicePlatformProvider [ ]
Out
2: getDevices(devicePlatformName)
1: getImplementations(“Device Management”)
return: DeviceManagement [ ]
Device Platform
4: getDevices()
return: Device [ ]
5: getImplementations(“Device Description”)
return: DeviceDescriptionProvider [ ]
Device Description Impl.
6: getDeviceDescription( String vendor, String model)
return: DeviceDescription

42. Device Platform, Device Platform Services
getDevicePlatforms() : DevicePlatform[]
getDevices(String devicePlatformName) : Device[]
...
Device Platform Services make it possible to query available Device Platforms.
Based on Device Platform name it’s possible to get Devices or the Platform.

43. Device Platform

44. Device

45. Runtime Platform

46. Project

47. Code Editor internal architecture

48. Code Editor architecture
tbd

49. Project Project Device
LEGEND:
Device
Project
APIs
APIs
Project’s defined Device Configuration
Project’s defined Device Profile
Service APIs that are selected to the Project
Device’s Device Configuration
Device’s Device Profile
Service APIs that are supported by the Device DC DP DP DP
Library Jar
Library Jar DC DC
APIs 1
1..n DC DP 1 1
APIs
Mobile SDK Emulator
Mobile Project development is targeted to devices that have certain Device Configuration and Device Profile. Therefore MTJ’s Project has also Device Configuration and Device Profile defined.
It’s possible to select a set of Service APIs to the Project. Based on the selected set of APIs corresponding Jar –libraries are added to the project.
Project always has default device that matches to the Projects definitions. That default device also gives the needed Jar –libraries to the Project.

50. Backup slides - Deployment
Deployment Framework internal architecture

51. Deployment framework architecture
LEGEND:
MTJ Editor context
Deployment context
Existing SDK / Emulators
Existing emulator integrations
Deployment Interface
Eclipse Plug-in Extension point
New, open deployment plug-in, OBEX based
Mobile Devices
Existing native deployment
SDK / Emulator (Vendor X)
MTJ IDE environment
U E I
U E I X X
SDK / Emulator context (Nokia, Win32 OS)
Deployment Framework Z
U E I
Interface
S40
Interface
O T A
Extension point X
S60
O B E X
Real Device
The MTJ provides an Deployment framework that supports the existing SDK Emulators and phones runtimes.
The framework publishes an deployment interface, that capsulate (hides) the actual runtime environments and protocols.
The framework separates the different deployment low-level services to own components (like UEI, OTA, etc.) with supporting existing proprietary emulator and phone access (marked as X and Z).
It also provides a new development branch to the OBEX based deployment, which can be used e.g. towards to MAC OS environment. Thus this requires that the needed protocols / protocol wrappers are available.

52. Mobile Vendor specific view
Eclipse
Vendor X
SDK Emulator
Plug-in
SDK / Emulator (Vendor X)
MTJ
Plug-in
Vendor Y
SDK Emulator
Plug-in
SDK / Emulator (Vendor Y)
Device
Platform
Vendor Z
SDK Emulator
Plug-in
SDK / Emulator (Vendor Z)
Extension point
Vendor X
Real Device
Plug-in
Real Device (Vendor X)
Vendor Y
Real Device
Plug-in
Real Device (Vendor Y)
The MTJ provides an Deployment framework that supports the existing SDK Emulators and phones runtimes
The framework publishes a Device Platform -interface, that capsulate (hides) the actual runtime environments and protocols.
The framework separates the different vendors products to own plug-ins

53. Mobile vendor specific view details
Different mobile vendors can use their existing emulators and add the deployment (emulator) specific plug-in to the MTJ environment. The emulator specific plug-in may be even in binary format, if it needs to protect some internal implementation or specification.
The emulator specific plug-in uses the MTJ generic API and also contributes to the MTJ’s deployment frameworks extension point.
The deployment framework could provide an template from such plug-in that helps to other vendors to tie up their specific solutions.
The deployment framework supports also that the emulator is discovered by manual entering the location. There could be a dynamic plug-in, that ‘ties’ the discovered emulator to the deployment framework.
The deployment framework can provide also other extension points, that enables others to extend e.g. the emulator specific properties, UI’s etc.
The deployment framework provides a plug-in template for existing emulators, which can dynamically be attached to wrap the specific emulator.

54. Deployment framework plug-ins
MTJ plug-in wrapper
Mobile vendors devices
Device Platform plug-ins have several different implementations
Device Platform plug-ins are responsible of the communication protocols between MTJ environment and Emulators / Real Devices
The plug-ins also store all config data. F. ex. Emulator plug-in stores the Emulator SDK root directory itself
UEI = Unified Emulator Interface
XEI = Extended Emulator Interface (Nokia proprietary)
X = Proprietary Emulator Interface
Vendor X SDK Emulator
Plug-in
U E I
U E I
SDK / Emulator (Vendor X)
Vendor Y SDK Emulator
Plug-in
X E I
X E I
SDK / Emulator (Vendor Y)
Vendor Z SDK Emulator
Plug-in X X
SDK / Emulator (Vendor Z)
Vendor X Real Device
Plug-in
O B E X
Real Device (Vendor X)
Vendor Y Real Device Plug-in
HTTP/FTP service
Real Device (Vendor Y)
O T A
Vendor Z Real Device Plug-in
Real Device (Vendor Z)
FTP
HTTP/FTP service
O T A
FTP

55. Deployment framework design
Integrating to the existing SDK Emulators:
Deployment framework
Enables adding a new SDK Emulator by manually entering the location or by local hard drive browsing (typical case for existing emulators).
Hides the used targeted runtime environments behind a few deployment interfaces
Simplifies the deployment process against the device / emulator variation
Generalizes the deployment management by encapsulating the SDK Emulator dependencies to a separate plug-ins, thus enabling it to publish it’s own specific functionality.
Integrating to new SDK Emulators, which do have a specific plug-in:
If the SDK Emulator has own deployment plug-in and the plug-in does follow the Deployment framework extension rules, it’s automatically instantiated
Deployment framework instantiates Deployment component and calls its methods via deployment interface
Deployment component plug-in
Implements the Deployment frameworks interface
Contributes to the Deployment frameworks extension point
May also extend some SDK Emulator specific services to the Deployment framework

56. Deployment framework Model
Device Platform
Deployment framework Model
Device
Runtime Platform
Definition
1..n
Emulator
Device
Real
Device 1
Target environments are seen as Device Platforms by the MTJ environment. Device Platform contains one or more Device instances.
MTJ plug-in doesn’t know if the Devices are device emulators or real devices because the plug-in extension point API hides all implementation details.
Device instance defines the Runtime Platform that it’s capable to run on.

57. Deployment framework Model (cont.)
i/f
MIDlet
Deployment
CDC
Deployment
MEGlet
Deployment
Resource
Deployment
Deployment interface is generic representation of a entity that is send from MTJ environment to Device Platform instances.
Realization of a deployment can be MIDlet, CDC, MEGlet or Resource deployment (or something else). So the realization is created from source application definitions and f. ex. MIDlet project deployment consists of Application JAR and JAD files.
Target Device Platform knows, what’s inside the received deployment and how to handle it.

58. Signing and Obfuscation
Signing and Obfuscating internal architecture

59. Signing architecture
There is a SecurityManager, that manages the keys and certificates in the IDE environment globally.
Each project can configure the signing options and parameters against the actual needs.
The Signing Provider implements the actual signing and it can be used through e.g. the Ant scripts.

60. Obfuscating architecture
It is a well known fact that Java Class (bytecode) files can be easily reverse-engineered because Java compiler leaves a lot of such information into bytecode that helps the reverse-engineering task. Code obfuscation is one protection tool for Java code to prevent reverse engineering. Code obfuscation makes programs more difficult to understand, so that it is more resistant to reverse engineering.
Obfuscation techniques fall into three groups:
Layout Obfuscations
Layout Obfuscations modify the layout structure of the program by two basic methods: renaming identifiers and removing debugging information. Almost all Java obfuscators contain this technique.
Control Obfuscations
Control Obfuscations change the control flow of the program.
Data Obfuscations
Data Obfuscations break the data structures used in the program and encrypt literal.
The MTJ enables to use existing Obfuscator -products through an wrapper plug-in (Obfuscation Provider), that can be further tailored.

61. Mobile Visual Editor architecture
Backup slides - GUI
Mobile Visual Editor architecture

62. Visual IDE environment in general
The RAD IDE environment is having some clear elements, like the core IDE graphical and code editor, property sheet and outline viewer for IDE environment objects.
Also the graphical editor uses the screen engine for creating the actual graphical UI presentation (like WYSIWYG).
Also the mobile emulators / SDKs’ are providing the ability to launch the applications.
Eclipse Platform
IDE
Screen Engine
Graphical Editor
Code / Resource Editor
UI, WYSIWYG
Property Sheet
Outline Viewer
Launcher / Emulator
Source code, resource files, etc.
Trace, profile, debug
Source files

63. VE Internal Component Architecture
Eclipse Platform
The Eclipse Visual Editor framework provides a flexible GUI framework, which can be quite easily extended to e.g. mobile domain.
The current desktop version supports JFC and SWT GUI editors with full set of UI widgets. The actual screen rendering is done in separate rendering engine.
Internally VE uses EMF in CDE and models the Java source in JEM.
Eclipse Visual Editor Framework
JFC Editor
SWT Editor
Local or Remote Java VM
Target VM
BeanInfo VM
Java core
Java Element Model (JEM)
Common Diagram Model (CDE)
Java Code Generation Adapter
GEF
EMF
Java source files

64. Mobile Visual Editor GUI Components
Legend
Existing in Eclipse
MTJ project scope
Eclipse MTJ IDE
MTJ Screen Engine
Mobile CLDC proxy components
Mobile eSWT proxy components
Custom Mobile proxy components
MTJ CDLC UI components
CDLC UI base Look & Feel
Custom UI Components
Custom UI Look & Feel
MTJ eSWT UI components
MTJ eSWT UI components
Custom UI Components
Custom UI Look & Feel
Custom UI components
Custom UI Look & Feel
Eclipse VE
MTJ Mobile Extension
GEF EditorPart
UI VE Model
CLDC Screen Rendering Engine
eSWT Screen Rendering Engine
Custom Screen Rendering Engine
Screen Rendering API
BeanProxy Adapter
Common Screen Rendering Engine
Screen Rendering Context
Screen Rendering API
BeanInfo Adapter
Eclipse Platform

65. Backup slides – Milestone Plan

66. MTJ Milestone Plan
tbd