CompileTimeCache - Revision history

JaroslavTulach: /* Too NetBeans Specific */

2009-08-05T10:24:14Z

Too NetBeans Specific

←Older revision		Revision as of 10:24, 5 August 2009
Line 61:		Line 61:
	=== Too [[NetBeans]] Specific ===		=== Too [[NetBeans]] Specific ===

-	Parts of this article may sound a bit too [[NetBeans]] specific. Although based on our [[NetBeans]] experience, they are not specific to [[NetBeans]] at all! First of all, [[annotation processor]]s are available to every [[API]] writer targeting [[JDK]]6 (and as [[Java]] 5 is about to be end of lifed soon, this shall soon be almost everyone). Then there is the question of generating caches. One can always choose the simplest possible format - e.g. a plain text file and then there are no dependencies on [[NetBeans]] either. However even if you like our [[NetBeansLayers]] format and our ''LayerGeneratingProcessor'', don't dispair - support for this is available as two separate [[JAR]] files (''org-openide-util.jar'' and ''org-openide-filesystems.jar''), fully independent from the [[NetBeans]] [[IDE]] or even [[NetBeans Runtime Container]].	+	Parts of this article may sound a bit too [[NetBeans]] specific. Although based on our [[NetBeans]] experience, they are not specific to [[NetBeans]] at all! First of all, [[annotation processor]]s are available to every [[API]] writer targeting [[JDK]]6 (and as [[Java]] 5 is about to be end of lifed soon, this shall soon be almost everyone). Then there is the question of generating caches. One can always choose the simplest possible format - e.g. a plain text file and then there are no dependencies on [[NetBeans]] either. However even if you like our [[NetBeansLayers]] format and our ''LayerGeneratingProcessor'', don't dispair - support for this is available as two separate [[JAR]] files (''org-openide-util.jar'' and ''org-openide-filesystems.jar'' which are also available from [[NetBeansMavenRepository]]), fully independent from the [[NetBeans]] [[IDE]] or even [[NetBeans Runtime Container]].

	Anyway, regardless you use these extensions or just plain [[AnnotationProcessor]]s, do it! Generating [[CompileTimeCache]] really pays off and can simplify a lot of [[API]] as well as make it much more [[performance\|efficient]].		Anyway, regardless you use these extensions or just plain [[AnnotationProcessor]]s, do it! Generating [[CompileTimeCache]] really pays off and can simplify a lot of [[API]] as well as make it much more [[performance\|efficient]].

JaroslavTulach: /* Too NetBeans Specific */

2009-07-25T14:49:10Z

Too NetBeans Specific

←Older revision		Revision as of 14:49, 25 July 2009
Line 63:		Line 63:
	Parts of this article may sound a bit too [[NetBeans]] specific. Although based on our [[NetBeans]] experience, they are not specific to [[NetBeans]] at all! First of all, [[annotation processor]]s are available to every [[API]] writer targeting [[JDK]]6 (and as [[Java]] 5 is about to be end of lifed soon, this shall soon be almost everyone). Then there is the question of generating caches. One can always choose the simplest possible format - e.g. a plain text file and then there are no dependencies on [[NetBeans]] either. However even if you like our [[NetBeansLayers]] format and our ''LayerGeneratingProcessor'', don't dispair - support for this is available as two separate [[JAR]] files (''org-openide-util.jar'' and ''org-openide-filesystems.jar''), fully independent from the [[NetBeans]] [[IDE]] or even [[NetBeans Runtime Container]].		Parts of this article may sound a bit too [[NetBeans]] specific. Although based on our [[NetBeans]] experience, they are not specific to [[NetBeans]] at all! First of all, [[annotation processor]]s are available to every [[API]] writer targeting [[JDK]]6 (and as [[Java]] 5 is about to be end of lifed soon, this shall soon be almost everyone). Then there is the question of generating caches. One can always choose the simplest possible format - e.g. a plain text file and then there are no dependencies on [[NetBeans]] either. However even if you like our [[NetBeansLayers]] format and our ''LayerGeneratingProcessor'', don't dispair - support for this is available as two separate [[JAR]] files (''org-openide-util.jar'' and ''org-openide-filesystems.jar''), fully independent from the [[NetBeans]] [[IDE]] or even [[NetBeans Runtime Container]].

-	Anyway, regardless you use these extensions or just plain [[AnnotationProcessor]]s, do it! Generating [[CompileTimeCache]] really pays off and can simplify a lot of [[API]] as well as make it much more ~~effective~~.	+	Anyway, regardless you use these extensions or just plain [[AnnotationProcessor]]s, do it! Generating [[CompileTimeCache]] really pays off and can simplify a lot of [[API]] as well as make it much more [[performance\|efficient]].

	<comments/>		<comments/>

	[[Category:APIDesignPatterns:Performance]] [[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns:Performance]] [[Category:APIDesignPatterns]]

JaroslavTulach: /* Too NetBeans Specific */

2009-07-25T14:06:03Z

Too NetBeans Specific

←Older revision		Revision as of 14:06, 25 July 2009
Line 66:		Line 66:

	<comments/>		<comments/>
		+
		+	[[Category:APIDesignPatterns:Performance]] [[Category:APIDesignPatterns]]

JaroslavTulach: /* Namespace */

2009-07-25T14:03:00Z

Namespace

←Older revision		Revision as of 14:03, 25 July 2009
Line 43:		Line 43:
	=== Namespace ===		=== Namespace ===

-	[[NetBeans]] configuration mechanism is based on concept of [[NetBeansLayers\|layers]] of virtual filesystems written in [[XML]]. It is quite flexible, yet slightly errorprone. When one makes typo, it is quite hard to find where a problem is. And this is where [[annotations]] help quite a lot. [[Annotations]] are natural [[Java]] language elements. They have associated [[Javadoc]], code completion works when you use them in an [[IDE]], one can ~~see~~ for their usage, etc. All the [[Java]] comfort is available for free.	+	[[NetBeans]] configuration mechanism is based on concept of [[NetBeansLayers\|layers]] of virtual filesystems written in [[XML]]. It is quite flexible, yet slightly errorprone. When one makes a typo, it is quite hard to find where the problem is. And this is where [[annotations]] help quite a lot. [[Annotations]] are natural [[Java]] language elements. They have associated [[Javadoc]], code completion works when you use them in an [[IDE]], one can seek for their usage, etc. All the [[Java]] comfort is available for free.

	Then, with use of layer generating [[AnnotationProcessor]]s we can convert them into the flexible [[NetBeansLayers]] format. No typos, no inconsistencies in the [[XML]] definitions. Everything done automatically and even with compile time verification that the registration is sane (e.g. classes are public, methods are static, etc.). We have a [[builder]] like [[API]] to generate the [[XML]] quite easily:		Then, with use of layer generating [[AnnotationProcessor]]s we can convert them into the flexible [[NetBeansLayers]] format. No typos, no inconsistencies in the [[XML]] definitions. Everything done automatically and even with compile time verification that the registration is sane (e.g. classes are public, methods are static, etc.). We have a [[builder]] like [[API]] to generate the [[XML]] quite easily:

JaroslavTulach: /* Generating Caches */

2009-07-25T14:01:00Z

Generating Caches

←Older revision		Revision as of 14:01, 25 July 2009
Line 29:		Line 29:
	[[Annotations]] have gained quite a lot of popularity since [[Java]] 5. However people usually use ''RetentionPolicy.RUNTIME'' or at most ''RetentionPolicy.CLASS'' and then scan classes during execution. This is an approach used by [[Jersey]] or [[Spring]]. It is not really effective. Why? Well, imagine that the first thing your framework does is to open all [[JAR]]s on classpath, seek what classes their contain and inspect some of them. If they contain the desired annotation, do something, however as majority of the classes likely does not use your [[annotation]], just skip them (but leaving them uselessly loaded in memory). Not really effective.		[[Annotations]] have gained quite a lot of popularity since [[Java]] 5. However people usually use ''RetentionPolicy.RUNTIME'' or at most ''RetentionPolicy.CLASS'' and then scan classes during execution. This is an approach used by [[Jersey]] or [[Spring]]. It is not really effective. Why? Well, imagine that the first thing your framework does is to open all [[JAR]]s on classpath, seek what classes their contain and inspect some of them. If they contain the desired annotation, do something, however as majority of the classes likely does not use your [[annotation]], just skip them (but leaving them uselessly loaded in memory). Not really effective.

-	Is there a better way? Indeed: Generate caches during compilation and use them to effectively load just the needed classes instead of scanning whole classpath. All that is needed is to register an [[AnnotationProcessor]] for important annotations and ~~after~~ compilation generate ''META-INF/jersey.classes'' or ''META-INF/spring.classes'' with list of class names to inspect. Then	+	Is there a better way? Indeed: Generate caches during compilation and use them to effectively load just the needed classes instead of scanning whole classpath. All that is needed is to register an [[AnnotationProcessor]] for important annotations and during compilation generate ''META-INF/jersey.classes'' or ''META-INF/spring.classes'' with list of class names to inspect. Then
	just use		just use

JaroslavTulach: /* Generating Caches */

2009-07-25T14:00:21Z

Generating Caches

←Older revision		Revision as of 14:00, 25 July 2009
Line 27:		Line 27:
	=== Generating Caches ===		=== Generating Caches ===

-	[[Annotations]] have gained quite a lot of popularity since [[Java]] 5. However people usually use ''RetentionPolicy.RUNTIME'' or at most ''RetentionPolicy.CLASS'' and then scan classes during execution. This is an approach used by [[Jersey]] or [[Spring]]. It is not really effective. Why? Well, imagine that the first thing your framework does is to open all [[JAR]]s on classpath, seek what classes their contain and inspect some of them. If they contain the desired annotation, do something, however as majority of the does not use your annotation, just skip them (but leaving them uselessly loaded in memory). Not really effective.	+	[[Annotations]] have gained quite a lot of popularity since [[Java]] 5. However people usually use ''RetentionPolicy.RUNTIME'' or at most ''RetentionPolicy.CLASS'' and then scan classes during execution. This is an approach used by [[Jersey]] or [[Spring]]. It is not really effective. Why? Well, imagine that the first thing your framework does is to open all [[JAR]]s on classpath, seek what classes their contain and inspect some of them. If they contain the desired annotation, do something, however as majority of the classes likely does not use your [[annotation]], just skip them (but leaving them uselessly loaded in memory). Not really effective.

	Is there a better way? Indeed: Generate caches during compilation and use them to effectively load just the needed classes instead of scanning whole classpath. All that is needed is to register an [[AnnotationProcessor]] for important annotations and after compilation generate ''META-INF/jersey.classes'' or ''META-INF/spring.classes'' with list of class names to inspect. Then		Is there a better way? Indeed: Generate caches during compilation and use them to effectively load just the needed classes instead of scanning whole classpath. All that is needed is to register an [[AnnotationProcessor]] for important annotations and after compilation generate ''META-INF/jersey.classes'' or ''META-INF/spring.classes'' with list of class names to inspect. Then

JaroslavTulach: /* Define the Annotation */

2009-07-25T13:57:44Z

Define the Annotation

←Older revision		Revision as of 13:57, 25 July 2009
Line 9:		Line 9:
	<source lang="java" snippet="anagram.api.Words"/>		<source lang="java" snippet="anagram.api.Words"/>

-	Any user will be allowed to ~~annotation~~ its own static method with this [[annotation]] instructing the [[API]] to call this method whenever somebody needs a list of words to play the anagram game. Here is a sample use:	+	Any user will be allowed to annotate its own static method with this [[annotation]] instructing the [[API]] to call this method whenever somebody needs a list of words to play the anagram game. Here is a sample use:

	<source lang="java" snippet="anagram.words.annotation.usage"/>		<source lang="java" snippet="anagram.words.annotation.usage"/>

JaroslavTulach: /* Define the Annotation */

2009-07-25T13:57:07Z

Define the Annotation

←Older revision		Revision as of 13:57, 25 July 2009
Line 5:		Line 5:
	=== Define the Annotation ===		=== Define the Annotation ===

-	Although not necessary, it is good to start with definition of an annotation in your [[API]]. At the end [[AnnotationProcessor]]s are optimized to process annotations. To allow [[API]] users to easily define list of words to feed into the Anagram game, let's introduce '''@Words''' annotation:	+	Although not necessary, it is good to start with definition of an [[annotation]] in your [[API]]. At the end [[AnnotationProcessor]]s are optimized to process annotations. To allow [[API]] users to easily define list of words to feed into the Anagram game, let's introduce '''@Words''' annotation:

	<source lang="java" snippet="anagram.api.Words"/>		<source lang="java" snippet="anagram.api.Words"/>

-	Any user will be allowed to annotation its own static method with this annotation instructing the [[API]] to call this method whenever somebody needs a list of words to play the anagram game. Here is a sample use:	+	Any user will be allowed to annotation its own static method with this [[annotation]] instructing the [[API]] to call this method whenever somebody needs a list of words to play the anagram game. Here is a sample use:

	<source lang="java" snippet="anagram.words.annotation.usage"/>		<source lang="java" snippet="anagram.words.annotation.usage"/>

JaroslavTulach: /* Define the Annotation */

2009-07-25T13:56:40Z

Define the Annotation

←Older revision		Revision as of 13:56, 25 July 2009
Line 5:		Line 5:
	=== Define the Annotation ===		=== Define the Annotation ===

-	Although not necessary, it is good to ~~define~~ an annotation in your [[API]]. At the end [[AnnotationProcessor]]s are optimized to process annotations. To allow [[API]] users to easily define list of words to feed into the Anagram game, let's introduce '''@Words''' annotation:	+	Although not necessary, it is good to start with definition of an annotation in your [[API]]. At the end [[AnnotationProcessor]]s are optimized to process annotations. To allow [[API]] users to easily define list of words to feed into the Anagram game, let's introduce '''@Words''' annotation:

	<source lang="java" snippet="anagram.api.Words"/>		<source lang="java" snippet="anagram.api.Words"/>

JaroslavTulach: /* Too NetBeans Specific */

2009-07-25T13:54:07Z

Too NetBeans Specific

←Older revision		Revision as of 13:54, 25 July 2009
Line 61:		Line 61:
	=== Too [[NetBeans]] Specific ===		=== Too [[NetBeans]] Specific ===

-	Parts of this article may sound a bit too [[NetBeans]] specific. Although based on our [[NetBeans]] experience, they are not specific to [[NetBeans]] at all! First of all, [[annotation processor]]s are available to every [[API]] writer targeting [[JDK]]6 (and as [[Java]] 5 is about to be end of lifed soon, this shall soon be almost everyone). Then there is the question of generating caches. One can always choose the simplest possible format - e.g. a plain text file and then there are no dependencies on [[NetBeans]] either. However even if you like our [[NetBeansLayers]] format and our ''LayerGeneratingProcessor'', don't dispair - support for this is available as two separate [[JAR]] files (''org-openide-util.jar'' and ''org-openide-filesystems.jar''), fully independent from the [[NetBeans]] IDE or even [[NetBeans Runtime Container]].	+	Parts of this article may sound a bit too [[NetBeans]] specific. Although based on our [[NetBeans]] experience, they are not specific to [[NetBeans]] at all! First of all, [[annotation processor]]s are available to every [[API]] writer targeting [[JDK]]6 (and as [[Java]] 5 is about to be end of lifed soon, this shall soon be almost everyone). Then there is the question of generating caches. One can always choose the simplest possible format - e.g. a plain text file and then there are no dependencies on [[NetBeans]] either. However even if you like our [[NetBeansLayers]] format and our ''LayerGeneratingProcessor'', don't dispair - support for this is available as two separate [[JAR]] files (''org-openide-util.jar'' and ''org-openide-filesystems.jar''), fully independent from the [[NetBeans]] [[IDE]] or even [[NetBeans Runtime Container]].

	Anyway, regardless you use these extensions or just plain [[AnnotationProcessor]]s, do it! Generating [[CompileTimeCache]] really pays off and can simplify a lot of [[API]] as well as make it much more effective.		Anyway, regardless you use these extensions or just plain [[AnnotationProcessor]]s, do it! Generating [[CompileTimeCache]] really pays off and can simplify a lot of [[API]] as well as make it much more effective.

	<comments/>		<comments/>