- Portability
- Efficiency
With several OS remaining popular across different user (developers, designers, end users, etc) communities, portability has always been even Java's concern. But then, we would expect all java libraries to be portable. So, what differentiates these technologies from portability and efficiency perspective? Let's explore. There are multiple opportunities like the following:
- Develop a fully native library for each platform: This must be the fastest option. Also, we may ensure complete utilization of platform capabilities if such a library is possible. AWT is exactly this! Look and feel of widgets match perfectly with the underlying OS.
- Develop a fully java library: Something like a common denominator. We only have those options here that are available in all supported platform. There are additional layers of method calls to native OS. Hence, poor performance. Swing falls here.
- Develop a partly native and partly java library: Use native calls wherever possible and have java implementation elsewhere. This sounds like best of both worlds.
SWT is mostly native and partly java (as mentioned in the third bullet). Eclipse FAQ (http://wiki.eclipse.org/FAQ_What_is_SWT%3F) gives more details.
So, let's compile our thoughts. We need to answer the following questions to be able to make the choice:
- Is emulation of native OS widgets acceptable or do we want a perfect reproduction?
- How significant is Hardware accelaration?
- What platforms need to be supported?
- How important in cross platform similarity in look and feel?
- Ease of development
- Complexity of UI
At the end of the day, I have not seen a better source for this discussion than http://www-128.ibm.com/developerworks/opensource/library/os-swingswt/. See how many "N/A" exist for AWT. AWT is still probably the least preferred of the three. However, each technical alternative has its own merits and demerits.
No comments:
Post a Comment