Modular Java SE
From APIDesign
(→java.applet and java.beans) |
|||
| Line 3: | Line 3: | ||
There can be many reasons for having [[module system|modular]] [[JDK]], but to simplify things, let's stick with one: we want to reach a point in future, when it will be enough to download just a limited set of [[JDK]] to execute an applet/application/server, etc. | There can be many reasons for having [[module system|modular]] [[JDK]], but to simplify things, let's stick with one: we want to reach a point in future, when it will be enough to download just a limited set of [[JDK]] to execute an applet/application/server, etc. | ||
| - | + | ||
== java.applet and java.beans == | == java.applet and java.beans == | ||
| + | |||
| + | The biggest obstacle preventing creation of limited parts of [[JDK]] that really work is to define such limited ''pieces'', make them independent and yet keep binary compatibility for the whole '''Java SE'''. Let's look at one such problem and seek a solution. | ||
Obviously you may be interested in using [[JavaBean]]s specification and you may not want to know anything about applets. Also you may want to use applets and don't care about introspection and BeanInfos provided by [[JavaBean]]s. Is this possible? | Obviously you may be interested in using [[JavaBean]]s specification and you may not want to know anything about applets. Also you may want to use applets and don't care about introspection and BeanInfos provided by [[JavaBean]]s. Is this possible? | ||
Revision as of 14:33, 16 June 2009
I like puzzles that tease my mind (a bit). Last week I've been introduced to one. Modularize JDK (a described at Mark Reinhold's blog). This page will capture my thoughts on this topic.
There can be many reasons for having modular JDK, but to simplify things, let's stick with one: we want to reach a point in future, when it will be enough to download just a limited set of JDK to execute an applet/application/server, etc.
java.applet and java.beans
The biggest obstacle preventing creation of limited parts of JDK that really work is to define such limited pieces, make them independent and yet keep binary compatibility for the whole Java SE. Let's look at one such problem and seek a solution.
Obviously you may be interested in using JavaBeans specification and you may not want to know anything about applets. Also you may want to use applets and don't care about introspection and BeanInfos provided by JavaBeans. Is this possible?
Well, there is a problem. The java.beans.AppletInitializer interface. It resides in beans, yet its signature contains java.applet.Applet. This means that the java.beans package has compile time dependency on java.applet. Does that mean whoever uses JavaBeans module in future, needs to install applet module as well?
I hope no. Anybody knows how to do it?
<comments/>
Follow
