{{:HeavyWeight}}

{{:HeavyWeight}}

==== Injecting UI & co. ====

==== Injecting UI & co. ====

==== More Granularity ====

==== More Granularity ====

On the other hand, there is a [[rationalistic]] solution. Your system is [[modular]], isn't it? Just some of your modules may be too ''heavyweight''. How one defines a ''weight'' of a module? In general it is a size of its [[environment]] - which is usually expressed by the outgoing dependencies the module has. If there is a module depending on [[Swing]], it is more ''heavyweight'' than a module which depends only on {{JDK|java/util|ArrayList}} - because the first one requires whole [[JDK]]8 while the latter can run on [[JDK]]8 ''compact 1'' profile (which is not just a matter of the name but also of about 30MB of download size and other resources).

On the other hand, there is a [[rationalistic]] solution. Your system is [[modular]], isn't it? Just some of your modules may be too [[HeavyWeight]].

The classic refactoring is to increase granularity of your modules - e.g. split them into (two) parts. Module A (shows a dialog, asks for a number and shows result) can be refactored into two modules: one [[library]] to compute the factorial and another [[JAR]] to show the dialogs and call into the library to get the right results. Very [[rational]] solution - however it requires thinking.

{{:HeavyWeight}}

==== Injecting UI & co. ====

==== Injecting UI & co. ====

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]] (see [http://bits.netbeans.org/html4j/0.7.6/net/java/html/json/doc-files/websockets.html the javadoc]).

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]] (see [http://bits.netbeans.org/html4j/0.7.6/net/java/html/json/doc-files/websockets.html the javadoc]).

Then it was easy to provide one implementation using classical ''Tyrus'' library and one, really slim using in browser ''WebSocket'' object and make sure the best suitable is always plugged in.

Then it was easy to provide one implementation using classical ''Tyrus'' library and one, really slim using in browser ''WebSocket'' object and make sure the best suitable is always plugged in.

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]] (see [http://bits.netbeans.org/html4j/0.7.6/net/java/html/json/doc-files/websockets.html the javadoc]).

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]] (see [http://bits.netbeans.org/html4j/0.7.6/net/java/html/json/doc-files/websockets.html the javadoc]).

Then it was easy to provide one implementation using classical ''Tyrus'' library and one, really slim using in browser ''WebSocket'' object and make sure the best suitable is always plugged in.

Then it was easy to provide one implementation using classical ''Tyrus'' library and one, really slim using in browser ''WebSocket'' object and make sure the best suitable is always plugged in.

What if our restricted profile requires different implementation than the original one? Then one has to make the implementation pluggable (for example by creating an [[Injectable Singleton]]) and implement it twice. Sometimes it is possible to keep the original [[API]] and have just two different implementations. Sometimes the original [[API]] richness cannot be achieved in the restricted [[environment]] - in such case one may consider to abstract the shared functionality into new module with [[API]] and rewrite modules ready for using the restricted version to use it instead.

What if our restricted profile requires different implementation than the original one? Then one has to make the implementation pluggable (for example by creating an [[Injectable Singleton]]) and implement it twice. Sometimes it is possible to keep the original [[API]] and have just two different implementations. Sometimes the original [[API]] richness cannot be achieved in the restricted [[environment]] - in such case one may consider to abstract the shared functionality into new module with [[API]] and rewrite modules ready for using the restricted version to use it instead.

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]]. See http://bits.netbeans.org/html4j/0.7.5/net/java/html/json/doc-files/websockets.html

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]] (see [http://bits.netbeans.org/html4j/0.7.6/net/java/html/json/doc-files/websockets.html the javadoc]).

Then it was easy to provide one implementation using classical ''Tyrus'' library and one, really slim using in browser ''WebSocket'' object.

Then it was easy to provide one implementation using classical ''Tyrus'' library and one, really slim using in browser ''WebSocket'' object and make sure the best suitable is always plugged in.

== And When in that - Let's Also! ==

== And When in that - Let's Also! ==

==== Different Implementation ====

==== Different Implementation ====

What if our restricted profile requires different implementation than the original one? Then one has to make the implementation pluggable (for example by creating an [[Injectable Singleton]]) and implement it twice. Sometimes it is possible to keep the original [[API]] and have just two different implementations. Sometimes the original [[API] richness cannot be achieved in the restricted [[environment]] - in such case one may consider to abstract the shared functionality into new module with [[API]] and rewrite modules ready for using the restricted version to use it instead.

What if our restricted profile requires different implementation than the original one? Then one has to make the implementation pluggable (for example by creating an [[Injectable Singleton]]) and implement it twice. Sometimes it is possible to keep the original [[API]] and have just two different implementations. Sometimes the original [[API]] richness cannot be achieved in the restricted [[environment]] - in such case one may consider to abstract the shared functionality into new module with [[API]] and rewrite modules ready for using the restricted version to use it instead.

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]]. See http://bits.netbeans.org/html4j/0.7.5/net/java/html/json/doc-files/websockets.html

Recently I had a lot of fun with restricted [[environment]] called [[Bck2Brwsr]] and for example to encapsulate [[WebSocket]] communication I rather invented new [[API]] than tried to use one already existing in [[Java]]. See http://bits.netbeans.org/html4j/0.7.5/net/java/html/json/doc-files/websockets.html

</source>

</source>

which is exactly the workaround [[I]] used to get [[Grizzly]] working on [[JDK]]8 compact 2 profile, before it got fixed. One can use this trick whenever it comes to ''javax'' packages - those can be loaded by any classloader. The trick does not work for ''java'' packages, as those are sealed and can only be loaded by system classloader.

which is exactly the workaround [[I]] used to get [[Grizzly]] working on [[JDK]]8 compact 2 profile, before it got fixed. One can use this trick whenever it comes to ''javax'' packages - those can be loaded by any classloader. The trick does not work for ''java'' packages, as those are sealed and can only be loaded by the system classloader.

==== Different Implementation ====

==== Different Implementation ====

==== Fake Emulation Classes ====

==== Fake Emulation Classes ====

Sometimes (especially when it comes to [[API]]) it is harder to eliminate classes from richer [[profiles]] easily. In such case, there may be brutal force, think no more solution: Emulate such classes. This is particularly easy in case of simple interfaces or classes that can throw exceptions. For example get your [[API]] compact 1 profile ready and still reference {{JDK|javax/swing|Action}}, just copy the class and everything will work. Or to eliminate need of [[JNDI]] without changing a line on the call site, one can create a fake:

Sometimes (especially when it comes to [[API]]) it is harder to eliminate classes from richer [[profiles]] easily. In such case one can try the ''brutal force, think no more'' solution: Emulate such classes. This is particularly easy in case of simple interfaces or classes that can throw exceptions. For example get your [[API]] compact 1 profile ready and still reference {{JDK|javax/swing|Action}}, just copy the class and everything will work. Or to eliminate need of [[JNDI]] without changing a line on the call site, one can create a fake:

<source lang="java">

<source lang="java">

==== Fake Emulation Classes ====

==== Fake Emulation Classes ====

Sometimes (especially when it comes to [[API]]) it is harder to eliminate classes from richer [[profiles]] easily. In such case, there may be brutal force, think no more solution: Emulate such classes. This is particularly easy in case of simple interfaces or classes that can throw exceptions. For example get your [[API]] compact 1 profile ready and still reference {{JDK|javax/swing/Action}}, just copy the class and everything will work. Or to eliminate need of [[JNDI]] without changing a line on the call site, one can create a fake:

Sometimes (especially when it comes to [[API]]) it is harder to eliminate classes from richer [[profiles]] easily. In such case, there may be brutal force, think no more solution: Emulate such classes. This is particularly easy in case of simple interfaces or classes that can throw exceptions. For example get your [[API]] compact 1 profile ready and still reference {{JDK|javax/swing|Action}}, just copy the class and everything will work. Or to eliminate need of [[JNDI]] without changing a line on the call site, one can create a fake:

<source lang="java">

<source lang="java">

<source lang="java">

<source lang="java">

EventQueue.invokeLater( -> runAction(); ); // XXX fix lambda syntax

EventQueue.invokeLater(() -> runAction(); );

</source>

</source>