There is support for "look and feels," so that widgets in the GUI can imitate those from the underlying native system (unless the native system's copyright or trademark owner demands that the look be implemented in terms of the underlying native widgets, as in the case of the Aqua look and feel in Apple's Mac OS X), or a completely fictional one. |
There is support for "look and feels," so that widgets in the GUI can imitate those from the underlying native system (except when IP rights force workarounds, as noted in the Legal Issues section), or a completely fictional one. |
Legal IssuesIn the corporate programming culture, legal issues surrounding Intellectual Property often complicate technical issues. This fact of life is especially apparent with regard to the Java API. For example, the Swing API often imitates the underlying native platform's GUI, using perfectly cross-platform code. This way, users (ideally) feel comfortable and unaware they're working on a non-native platform, without Sun needing to pollute Swing with native code. However, the native system's copyright or trademark owner may demand that the look be implemented in terms of the underlying native widgets, as in the case of the Aqua look and feel in Apple's Mac OS X. Apple considers Aqua to be a competitive advantage, and desires the look and feel to be confined to their operating system. |
The libraries make it considerably easier to program in Java than in C++, according to some software development methodologists; however, other experts attribute the difference primarily to the presence of garbage collection because common libraries for other languages often have similar function to the Java API.
Sun holds complete legal control through the "Java Compatible" trademark over the APIs that all Java platforms must support. This helps insure high consistency between platforms, at the cost of decreased freedom. As of Java Development Kit v1.3, the various APIs are:
Swing is a very rich system in its own right. There is support for "look and feels," so that widgets in the GUI can imitate those from the underlying native system (except when IP rights force workarounds, as noted in the Legal Issues section), or a completely fictional one. Also, design patterns permeate the system, especially a modified model-view-controller? pattern, so programming is done cleanly, with good seperation of function from appearance. However, one inconsistency is that (as of JDK 1.3) fonts are drawn by the underlying native system, and not by Java. This makes it difficult to have utter, complete control of text size, though workarounds exist such as drawing fonts as application-supplied bitmaps. In general, layouts should be used, which keep elements within a GUI aesthetically consistent despite minor variations between platforms.
In the corporate programming culture, legal issues surrounding Intellectual Property often complicate technical issues. This fact of life is especially apparent with regard to the Java API.
For example, the Swing API often imitates the underlying native platform's GUI, using perfectly cross-platform code. This way, users (ideally) feel comfortable and unaware they're working on a non-native platform, without Sun needing to pollute Swing with native code. However, the native system's copyright or trademark owner may demand that the look be implemented in terms of the underlying native widgets, as in the case of the Aqua look and feel in Apple's Mac OS X. Apple considers Aqua to be a competitive advantage, and desires the look and feel to be confined to their operating system.