LowerProfile - Revision history

JaroslavTulach: /* More Granularity */

2019-03-26T12:31:03Z

More Granularity

←Older revision		Revision as of 12:31, 26 March 2019
Line 31:		Line 31:

	{{:HeavyWeight}}		{{:HeavyWeight}}
		+
		+	Very [[rational]] solution - however it requires thinking.

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

JaroslavTulach: /* More Granularity */

2019-03-26T12:29:21Z

More Granularity

←Older revision		Revision as of 12:29, 26 March 2019
Line 28:		Line 28:
	==== 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. ====

JaroslavTulach: /* Different Implementation */

2014-03-23T11:37:15Z

Different Implementation

←Older revision		Revision as of 11:37, 23 March 2014
Line 132:		Line 132:
	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.
		+
		+	== Summary ==
		+
		+	[[JDK]]8 [[profiles]] are here with us and our [[libraries]], [[framework]]s and application need to acknowledge that. Luckily there are simple patterns (demonstrated on this page) that help us adopt to smaller [[JDK]] [[profiles]] and make our code more re-usable.

JaroslavTulach: /* And When in that - Let's Also! */

2014-03-23T11:34:33Z

And When in that - Let's Also!

←Older revision		Revision as of 11:34, 23 March 2014
Line 132:		Line 132:
	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.
-
-	~~== And When in that - Let's Also! ==~~
-
-	~~==== Increase Level of [[Co-existence]] ====~~
-
-	Turning an application ready for a single user mode into a multi-user [[environment]] is a challenge. Unless you initially design for the the multi-level [[co-existence]] (e.g. use form of [[Dependency Injection]], e.g. over design at beginning), it is going to be a cross-cutting change to implement propagation of proper context throughout the system.
-
-	The only thing one can hope for is that there are existing elements in the application that are ready for [[co-existence\|mutil-co-invocation]]. For example in [[NetBeans]] we have system of actions designed around explicit context (represented by [[Lookup]]) propagation. Btw. We had to do it to fight with focus-follows mouse behavior. However now, this can be helpful when increasing [[co-existence]]. There is a {{NB\|org-openide-util\|org/openide/util\|ContextAwareAction}} which explicitly holds provided context and propagates it where necessary. We just need to make sure that whatever such system needs is being ''looked'' up in the local context, and only as a fallback we use the global one.
-
-	~~In any case enhancing APIs to explicitly propagate context where necessary is solution to any [[co-existence\|multi-co-execution]] problems.~~

JaroslavTulach: /* Different Implementation */

2014-03-23T11:34:08Z

Different Implementation

←Older revision		Revision as of 11:34, 23 March 2014
Line 130:		Line 130:
	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! ==

JaroslavTulach: /* Different Implementation */

2014-03-23T11:32:30Z

Different Implementation

←Older revision		Revision as of 11:32, 23 March 2014
Line 128:		Line 128:
	==== 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

JaroslavTulach: /* Fake Emulation Classes */

2014-03-23T11:31:57Z

Fake Emulation Classes

←Older revision		Revision as of 11:31, 23 March 2014
Line 124:		Line 124:
	</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 ====

JaroslavTulach: /* Fake Emulation Classes */

2014-03-23T11:30:56Z

Fake Emulation Classes

←Older revision		Revision as of 11:30, 23 March 2014
Line 113:		Line 113:
	==== 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">

JaroslavTulach: /* Fake Emulation Classes */

2014-03-23T11:30:10Z

Fake Emulation Classes

←Older revision		Revision as of 11:30, 23 March 2014
Line 113:		Line 113:
	==== 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">

JaroslavTulach: /* No Need to Hack */

2014-03-23T11:28:15Z

No Need to Hack

←Older revision		Revision as of 11:28, 23 March 2014
Line 89:		Line 89:

	<source lang="java">		<source lang="java">
-	EventQueue.invokeLater( -> runAction(); ); ~~// XXX fix lambda syntax~~	+	EventQueue.invokeLater(() -> runAction(); );
	</source>		</source>