TheYearOfAnnotations2009 - Revision history

JaroslavTulach at 04:23, 22 July 2020

JaroslavTulach — Wed, 22 Jul 2020 04:23:46 GMT

←Older revision		Revision as of 04:23, 22 July 2020
Line 9:		Line 9:
	Listen to our podcast [[Image:Apitip06-year-of-annotations.mp3]] or [[Media:Apitip06-year-of-annotations.mp3\|download it]].		Listen to our podcast [[Image:Apitip06-year-of-annotations.mp3]] or [[Media:Apitip06-year-of-annotations.mp3\|download it]].

-	~~<comments/>~~	+	[[Category:PodCast]]

JaroslavTulach at 04:43, 5 August 2009

JaroslavTulach — Wed, 05 Aug 2009 04:43:17 GMT

←Older revision		Revision as of 04:43, 5 August 2009
Line 1:		Line 1:
-	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with [[annotations]] and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can offer our [[API]] users simple looking [[annotations]] and let associated [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).	+	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use [[CompileTimeCache\|compile time]] [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with [[annotations]] and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can offer our [[API]] users simple looking [[annotations]] and let associated [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).

	The other project related to [[annotations]] that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s (more on that in [[Cooperating with Other APIs\|Chapter 10]], in section Beware of Using Other APIs). As such we are going to create our own [[annotations]] (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].		The other project related to [[annotations]] that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s (more on that in [[Cooperating with Other APIs\|Chapter 10]], in section Beware of Using Other APIs). As such we are going to create our own [[annotations]] (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].

JaroslavTulach at 13:28, 25 July 2009

JaroslavTulach — Sat, 25 Jul 2009 13:28:30 GMT

←Older revision		Revision as of 13:28, 25 July 2009
Line 7:		Line 7:
	So these are my three ''annotation related'' projects. I find them quite exciting and I cannot wait to see them being used. [[Annotations]] are here to simplify life of [[API]] users and developers. As soon as we have them, we will have full right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!		So these are my three ''annotation related'' projects. I find them quite exciting and I cannot wait to see them being used. [[Annotations]] are here to simplify life of [[API]] users and developers. As soon as we have them, we will have full right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!

		+	Listen to our podcast [[Image:Apitip06-year-of-annotations.mp3]] or [[Media:Apitip06-year-of-annotations.mp3\|download it]].

	<comments/>		<comments/>

JaroslavTulach at 09:15, 12 December 2008

JaroslavTulach — Fri, 12 Dec 2008 09:15:09 GMT

←Older revision		Revision as of 09:15, 12 December 2008
Line 1:		Line 1:
	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with [[annotations]] and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can offer our [[API]] users simple looking [[annotations]] and let associated [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).		As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with [[annotations]] and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can offer our [[API]] users simple looking [[annotations]] and let associated [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).

-	The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].	+	The other project related to [[annotations]] that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s (more on that in [[Cooperating with Other APIs\|Chapter 10]], in section Beware of Using Other APIs). As such we are going to create our own [[annotations]] (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].

-	Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! ~~Using~~ '''@Deprecated''' annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way ~~help~~ users of your [[API]] with converting their code to new, non-deprecated ~~version~~. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [[API]]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), ~~but indeed~~, my plan is to bring these ''easy to use and flexible refactorings'' to [[NetBeans]] soon, hopefully for version 7.0.	+	Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! How? Why? We have observed that using '''@Deprecated''' annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way helps users of your [[API]] with converting their code to new, non-deprecated style. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [[API]]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), lightweight and we are ready to incorporate feedback of everyone interested in the project. Indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [[NetBeans]] soon, hopefully for [[TheYearOfAnnotations2009\|version 7.0]].

-	So these are my three ''annotation related'' projects. I ~~found~~ them quite exciting and I cannot wait to see them being used. As soon as ~~they do~~, will have ~~complete~~ right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!	+	So these are my three ''annotation related'' projects. I find them quite exciting and I cannot wait to see them being used. [[Annotations]] are here to simplify life of [[API]] users and developers. As soon as we have them, we will have full right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!


	<comments/>		<comments/>

JaroslavTulach at 09:08, 12 December 2008

JaroslavTulach — Fri, 12 Dec 2008 09:08:47 GMT

←Older revision		Revision as of 09:08, 12 December 2008
Line 1:		Line 1:
-	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with ~~annotation~~ and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can ~~provide the~~ users simple looking annotations and let ~~their~~ [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).	+	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with [[annotations]] and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can offer our [[API]] users simple looking [[annotations]] and let associated [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).

	The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].		The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].

Apidesign at 21:40, 11 December 2008

Apidesign — Thu, 11 Dec 2008 21:40:41 GMT

←Older revision		Revision as of 21:40, 11 December 2008
Line 3:		Line 3:
	The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].		The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].

-	Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! Using @Deprecated annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way help users of your [[API]] with converting their code to new, non-deprecated version. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [[API]]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), but indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [[NetBeans]] soon, hopefully for version 7.0.	+	Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! Using '''@Deprecated''' annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way help users of your [[API]] with converting their code to new, non-deprecated version. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [[API]]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), but indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [[NetBeans]] soon, hopefully for version 7.0.

	So these are my three ''annotation related'' projects. I found them quite exciting and I cannot wait to see them being used. As soon as they do, will have complete right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!		So these are my three ''annotation related'' projects. I found them quite exciting and I cannot wait to see them being used. As soon as they do, will have complete right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!

Apidesign at 21:40, 11 December 2008

Apidesign — Thu, 11 Dec 2008 21:40:17 GMT

←Older revision		Revision as of 21:40, 11 December 2008
Line 1:		Line 1:
	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with annotation and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can provide the users simple looking annotations and let their [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).		As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with annotation and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can provide the users simple looking annotations and let their [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).

-	The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[~~APIs~~]]. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].	+	The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[API]]s. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].

-	Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! Using @Deprecated annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way help users of your [[API]] with converting their code to new, non-deprecated version. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [API]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), but indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [NetBeans] soon, hopefully for version 7.0.	+	Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! Using @Deprecated annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way help users of your [[API]] with converting their code to new, non-deprecated version. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [[API]]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), but indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [[NetBeans]] soon, hopefully for version 7.0.

	So these are my three ''annotation related'' projects. I found them quite exciting and I cannot wait to see them being used. As soon as they do, will have complete right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!		So these are my three ''annotation related'' projects. I found them quite exciting and I cannot wait to see them being used. As soon as they do, will have complete right to call the year 2009 the [[TheYearOfAnnotations2009\|year of annotations]]!

Apidesign at 21:39, 11 December 2008

Apidesign — Thu, 11 Dec 2008 21:39:35 GMT

←Older revision		Revision as of 21:39, 11 December 2008
Line 1:		Line 1:
-	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with annotation and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can provide the users simple looking annotations and let their [[AnnotationProcessor\|annotation processors] do more advanced and more effective processing. As a result the developers have simple API to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to ~~end~~ users).	+	As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009\|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor\|annotation processors]]. As a result we can replace our [[NetBeansLayers\|layer based registrations]] with annotation and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can provide the users simple looking annotations and let their [[AnnotationProcessor\|annotation processors]] do more advanced and more effective processing. As a result the developers have simple [[API]] to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to [[API]] users).

-	The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [~~Annotations for Software Defect Detection~~ JSR 305], yet until it is stable we do not want to expose ~~that~~ API to ~~our~~ users. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].	+	The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [http://jcp.org/en/jsr/detail?id=305 JSR 305], yet until it is stable we do not want to expose such unstable API to users of our stable [[APIs]]. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). The hope is that our annotation will stay compatible even if the underlaying [http://jcp.org/en/jsr/detail?id=305 JSR 305] slightly changes. Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].

	Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! Using @Deprecated annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way help users of your [[API]] with converting their code to new, non-deprecated version. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [API]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), but indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [NetBeans] soon, hopefully for version 7.0.		Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! Using @Deprecated annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way help users of your [[API]] with converting their code to new, non-deprecated version. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [API]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), but indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [NetBeans] soon, hopefully for version 7.0.

Apidesign: New page: As I noted recently, I see the year 2009 as the year of annotations. The NetBeans project is about to rely on them more heavily. Finally! We've been waitin...

Apidesign — Thu, 11 Dec 2008 21:32:25 GMT

New page: As I noted recently, I see the year 2009 as the year of annotations. The NetBeans project is about to rely on them more heavily. Finally! We've been waitin...

New page

As I noted recently, I see the year 2009 as [[TheYearOfAnnotations2009|the year of annotations]]. The [[NetBeans]] project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with [[JDK]] 1.6 [[JavaC]] and we can use compile time [[AnnotationProcessor|annotation processors]. As a result we can replace our [[NetBeansLayers|layer based registrations]] with annotation and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can provide the users simple looking annotations and let their [[AnnotationProcessor|annotation processors] do more advanced and more effective processing. As a result the developers have simple API to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to end users).

The other project related to annotations that we are likely to incorporate during 2009 is our extended use of [http://jcp.org/en/jsr/detail?id=305 Annotations for Software Defect Detection]. This is heavily based on the [Annotations for Software Defect Detection JSR 305], yet until it is stable we do not want to expose that API to our users. As such we are going to create our own annotations (still recognizable by [[FindBugs]] and co.). Please find our [http://www.netbeans.org/nonav/issues/showattachment.cgi/73321/annotations_tmp.patch current patch] and comment here or in the [http://www.netbeans.org/issues/show_bug.cgi?id=137437 issue 137437].

Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to ''bring complex refactoring to masses''! Using @Deprecated annotation is good hint to help your API users recognize that some part of your [[API]] is obsolete and shall no longer be used, however that in no way help users of your [[API]] with converting their code to new, non-deprecated version. We have a solution: Use [https://lang.dev.java.net/ Code Transformation Annotations]! Dear [API] writers, let's adopt these annotations and use them in your [API]! They are completely standalone ([http://hudson.apidesign.org/job/net.java.lang/javadoc/ read more]), but indeed, my plan is to bring these ''easy to use and flexible refactorings'' to [NetBeans] soon, hopefully for version 7.0.

So these are my three ''annotation related'' projects. I found them quite exciting and I cannot wait to see them being used. As soon as they do, will have complete right to call the year 2009 the [[TheYearOfAnnotations2009|year of annotations]]!

<comments/>