Home » Archived » DSDP - Mobile Tools for Java (MTJ) » Preprocessing Discussion
| Preprocessing Discussion [message #17430] |
Mon, 30 October 2006 17:49  |
 Sebastian Sickelmann
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Hi MTJ
Let me introduce myself in first place. My Name ist Sebastian Sickelmann
and i am CTO of Four2B GmbH in Germany. We(mainly Artjom Bitor)
developed a preprocessing solution that is able to manage Code
Fragmentation without comment based proprosessing derectives.
I have a meeting with Mika, Rauno and Arto at Eclipse Summit(thanks for
good discussion at Summit). The result of our discussion was that it is
best to discuss our solution at MTJ Newsgroup or Mailing List. I decided
it is best in Newsgroups(for Thread-Tracking).
And the best way presenting a solution for discussion purpose is to show
a small "real" world example. For that we packaged a Update-Site
(http://www.annocracy.four2b.de/update/) (Sorry that we only bring in
source-code for the Annotation Implementation, but at this time i don't
get the complete clearance for using the EPL for the complete source).
And we know that is not easy to see how a solution works without any
example Project. (http://www.annocracy.four2b.de/GameOfLife.zip)
In the GameOfLife Zip is a project and an additional Plugin
(de.four2b.annocracy.mockDeviceDataSource_1.0.0.jar) that is not really
useful for a real project, but is capable for the GameOfLife Example
Project. Annocracy is extendable at several points, and this plugin is a
simple DeviceInformation Datasource for Annocracy. The
DeviceDataSources, BuildSystem etc. are not the Main-Parts of Annocracy.
But we packed this example with a very simple Build-Cycle and
DeviceData-Source, to show its functionality.
Our main goal is to enable MTJ to use Annocracy Preprocessing, so that
it is embeded in all those nice MTJ-Features.
If you want to discuss with us about preprocessing with Annotations it
is time to create a fresh Eclipse 3.2-Testing Installation and workspace
for testing purpose and extract the GameOfLife-Zip and add the prepared
project to this workspace. Please don't forgot to install the additional
MockDeviceDataSource-Plugin into your plugin-directory.
Annocracy is an RCP so you can use it via RCP-Launch-Configuration. We
prepared a small ANT-Task(not fully integrated all features yet). With
this use can use Annocracy outside of Eclipse(just a RCP-Installation
with the used plugins are needed). There is no UI-Plugins in Annocracy,
but we want to integrate it into MTJ-Build-Process (posible there will
be a need for using Wizards and Preference-Pages for Annocracy, but now
let please discuss the preprocession terms in General).
In GameOfLife Project we tried to help setup your first Annocracy Build.
Please read readme.txt and follow the instructions. Be carefull the
temporary-workspace(WORK in build.xml and "Workspace Data" in
RCP-Launch-Configuration) used by Annocracy will be deleted before
processing.
Hope to get some review reports, proposals or maybe just ideas of want
we can do better.
We try to translate our internal architecture document to english and
bring it in an presentable form in the next days.
Hope to hear from you
Kind regards
Sebastian
|
|
|
| Re: Preprocessing Discussion [message #17439 is a reply to message #17430] |
Wed, 01 November 2006 09:00  |
Eclipse User |
|
|
|
Originally posted by: rauno.seppala.removeme.nokia.com
Sebastian,
have you checked a short news track earlier "Preprocessing is having some
patents"? What is your understanding of them? Are they something that should
be checked against your solution by Eclipse legal?
Rauno
"Sebastian Sickelmann" <sebastian.sickelmann@four2b.de> wrote in message
news:45463B36.3010806@four2b.de...
> Hi MTJ
>
> Let me introduce myself in first place. My Name ist Sebastian Sickelmann
> and i am CTO of Four2B GmbH in Germany. We(mainly Artjom Bitor)
> developed a preprocessing solution that is able to manage Code
> Fragmentation without comment based proprosessing derectives.
>
> I have a meeting with Mika, Rauno and Arto at Eclipse Summit(thanks for
> good discussion at Summit). The result of our discussion was that it is
> best to discuss our solution at MTJ Newsgroup or Mailing List. I decided
> it is best in Newsgroups(for Thread-Tracking).
>
> And the best way presenting a solution for discussion purpose is to show
> a small "real" world example. For that we packaged a Update-Site
> (http://www.annocracy.four2b.de/update/) (Sorry that we only bring in
> source-code for the Annotation Implementation, but at this time i don't
> get the complete clearance for using the EPL for the complete source).
>
> And we know that is not easy to see how a solution works without any
> example Project. (http://www.annocracy.four2b.de/GameOfLife.zip)
>
> In the GameOfLife Zip is a project and an additional Plugin
> (de.four2b.annocracy.mockDeviceDataSource_1.0.0.jar) that is not really
> useful for a real project, but is capable for the GameOfLife Example
> Project. Annocracy is extendable at several points, and this plugin is a
> simple DeviceInformation Datasource for Annocracy. The
> DeviceDataSources, BuildSystem etc. are not the Main-Parts of Annocracy.
> But we packed this example with a very simple Build-Cycle and
> DeviceData-Source, to show its functionality.
>
> Our main goal is to enable MTJ to use Annocracy Preprocessing, so that
> it is embeded in all those nice MTJ-Features.
>
> If you want to discuss with us about preprocessing with Annotations it
> is time to create a fresh Eclipse 3.2-Testing Installation and workspace
> for testing purpose and extract the GameOfLife-Zip and add the prepared
> project to this workspace. Please don't forgot to install the additional
> MockDeviceDataSource-Plugin into your plugin-directory.
>
> Annocracy is an RCP so you can use it via RCP-Launch-Configuration. We
> prepared a small ANT-Task(not fully integrated all features yet). With
> this use can use Annocracy outside of Eclipse(just a RCP-Installation
> with the used plugins are needed). There is no UI-Plugins in Annocracy,
> but we want to integrate it into MTJ-Build-Process (posible there will
> be a need for using Wizards and Preference-Pages for Annocracy, but now
> let please discuss the preprocession terms in General).
>
> In GameOfLife Project we tried to help setup your first Annocracy Build.
> Please read readme.txt and follow the instructions. Be carefull the
> temporary-workspace(WORK in build.xml and "Workspace Data" in
> RCP-Launch-Configuration) used by Annocracy will be deleted before
> processing.
>
> Hope to get some review reports, proposals or maybe just ideas of want
> we can do better.
>
> We try to translate our internal architecture document to english and
> bring it in an presentable form in the next days.
>
> Hope to hear from you
>
> Kind regards
> Sebastian
|
|
|
| Re: Preprocessing Discussion [message #17444 is a reply to message #17439] |
Wed, 01 November 2006 19:30 |
Sebastian Sickelmann
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Rauno,
yes, i have checked it after eclipse summit but not have written any
post on this issue because i am not a legal expert.
I think, like that 6,839,712 from IBM is very special to
internationalization and searching for hardcoded strings. From my point
of view this has no point of contact with Annocracy or other
preprocessing technologies.
The same with patent 6,986,129 from SUN. I dont think that there will be
any problem with Annocracy, but it is much closer to what we need in MTJ
for preprocessing.
In this patent there is a template used for processing, i don't find any
information if this template is compileable of is just a template file
in any format. The line orientation discribed in this patent is realy
close to microcode, antenna, polish. These technologies use line based
meta code for preprocessing. Annocracy is using a java language element
and some external informations for steering of preprocessing. The Patent
is written in August 2001 before Annotations are inside Java Language,
so it is not clear if Annotations and processing of them are in scope ot
the patent.
When there is a legal checking i think it should check if:
-The Sun Patent hits comment(line) based preprocessing
-The Sun Patent hits the processing of Annotations.
-The Sun Patent hits changing of sorcecode(whats with refactorings)
I don't think the Annocracy is in scope of these patents. I'am not a
legal, but i think when this 3 points are checked we can say that all
preprocessing solutions we need for MTJ are applicable without legal
drawbacks.
Sebastian
Rauno Seppala schrieb:
> Sebastian,
> have you checked a short news track earlier "Preprocessing is having some
> patents"? What is your understanding of them? Are they something that should
> be checked against your solution by Eclipse legal?
>
> Rauno
>
> "Sebastian Sickelmann" <sebastian.sickelmann@four2b.de> wrote in message
> news:45463B36.3010806@four2b.de...
>> Hi MTJ
>>
>> Let me introduce myself in first place. My Name ist Sebastian Sickelmann
>> and i am CTO of Four2B GmbH in Germany. We(mainly Artjom Bitor)
>> developed a preprocessing solution that is able to manage Code
>> Fragmentation without comment based proprosessing derectives.
>>
>> I have a meeting with Mika, Rauno and Arto at Eclipse Summit(thanks for
>> good discussion at Summit). The result of our discussion was that it is
>> best to discuss our solution at MTJ Newsgroup or Mailing List. I decided
>> it is best in Newsgroups(for Thread-Tracking).
>>
>> And the best way presenting a solution for discussion purpose is to show
>> a small "real" world example. For that we packaged a Update-Site
>> (http://www.annocracy.four2b.de/update/) (Sorry that we only bring in
>> source-code for the Annotation Implementation, but at this time i don't
>> get the complete clearance for using the EPL for the complete source).
>>
>> And we know that is not easy to see how a solution works without any
>> example Project. (http://www.annocracy.four2b.de/GameOfLife.zip)
>>
>> In the GameOfLife Zip is a project and an additional Plugin
>> (de.four2b.annocracy.mockDeviceDataSource_1.0.0.jar) that is not really
>> useful for a real project, but is capable for the GameOfLife Example
>> Project. Annocracy is extendable at several points, and this plugin is a
>> simple DeviceInformation Datasource for Annocracy. The
>> DeviceDataSources, BuildSystem etc. are not the Main-Parts of Annocracy.
>> But we packed this example with a very simple Build-Cycle and
>> DeviceData-Source, to show its functionality.
>>
>> Our main goal is to enable MTJ to use Annocracy Preprocessing, so that
>> it is embeded in all those nice MTJ-Features.
>>
>> If you want to discuss with us about preprocessing with Annotations it
>> is time to create a fresh Eclipse 3.2-Testing Installation and workspace
>> for testing purpose and extract the GameOfLife-Zip and add the prepared
>> project to this workspace. Please don't forgot to install the additional
>> MockDeviceDataSource-Plugin into your plugin-directory.
>>
>> Annocracy is an RCP so you can use it via RCP-Launch-Configuration. We
>> prepared a small ANT-Task(not fully integrated all features yet). With
>> this use can use Annocracy outside of Eclipse(just a RCP-Installation
>> with the used plugins are needed). There is no UI-Plugins in Annocracy,
>> but we want to integrate it into MTJ-Build-Process (posible there will
>> be a need for using Wizards and Preference-Pages for Annocracy, but now
>> let please discuss the preprocession terms in General).
>>
>> In GameOfLife Project we tried to help setup your first Annocracy Build.
>> Please read readme.txt and follow the instructions. Be carefull the
>> temporary-workspace(WORK in build.xml and "Workspace Data" in
>> RCP-Launch-Configuration) used by Annocracy will be deleted before
>> processing.
>>
>> Hope to get some review reports, proposals or maybe just ideas of want
>> we can do better.
>>
>> We try to translate our internal architecture document to english and
>> bring it in an presentable form in the next days.
>>
>> Hope to hear from you
>>
>> Kind regards
>> Sebastian
>
>
|
|
| | |
| Re: Preprocessing Discussion [message #18626 is a reply to message #17485] |
Thu, 09 November 2006 12:34 |
Ricky
Messages: 204
Registered: July 2009 |
Senior Member |
|
|
Hello Everybody,
using annotations is an interesting approach, although I see some major =
=
problems with it.
- Annotations work only on the field and method level. On the other hand=
, =
a lot of decisions are done within methods and it whould be annoying to =
=
refactor this into several methods to dispatch to the right ones. This =
would break up the unit of work from one method to severals just to =
reflect device fragmentation.
Even in simple examples this can become quite complex, like the provided=
=
example:
@Implementations(implementations =3D { @Implementation(dependsO=
n =3D =
"midp1.0", implementationOwner =3D "randomIntForMidp1") })
public static int randomInt(int range) {
// default implementation
return random.nextInt(range);
}
@ImplementationOwner
private static int randomIntForMidp1(int range) {
// implementation for MIDP-1.0
int randomInt =3D randomInt();
if (randomInt < 0) {
// allow only positive numbers
randomInt *=3D -1;
}
return randomInt % range;
}
Note: the availability of random.nextInt(range) is not dependent on the =
=
MIDP version, by the way. This is part of the CLDC specification.
A comment-based preprocessing equivalent is much simpler in comparison:
public static int randomInt(int range) {
int randomInt ;
//#if polish.cldc1.0
randomInt =3D Math.abs(this.random.nextInt()) % range;
//#else
randomInt =3D this.random.nextInt(range);
//#endif
return randomInt;
}
In more complex examples where there are many branches necessary within =
=
one method, this yields up quite a lot. Expressing complex statements li=
ke =
/#if polish.hasCommandKeyEvents || (polish.key.LeftSoftKey.defined && =
polish.key.RightSoftKey.defined) could be quite verbose in an annotation=
..
- Imports cant be handled by annotations. E.g. if you want to draw a hal=
f =
transparent rectangle you need the nokia ui api (i.e. a platform specifi=
c =
import). With comment-based preprocessing this is quite simple:
//#if polish.api.nokia-ui
import com.nokia.mid.ui.*;
//#endif
- The plugin processing the annotated classes need to run in a Java5 VM.=
=
This is in contrast to the claim eclipse runs on 1.4. On a sidenote if t=
he =
developer has installed a Java5 VM he can not use Java 5 features like =
autoboxing, enums and foreach as the target version for midp is 1.2. J2M=
E =
Polish converts Java5 class files on the fly to 1.2 compatible ones.
A good thing about the annotation approach is, that the editor doesnt ne=
ed =
to be changed at all for the preprocessing stuff. But full tooling suppo=
rt =
for preprocessing also includes things like occurrence marking or choosi=
ng =
of target platform (target device) so we have to go into the editor =
nevertheless. The Mepose plugin of J2ME Polish is a good showcase that =
this can be done and is ready for inclusion.
Regards,
Richard
|
|
|
| Re: Preprocessing Discussion [message #18643 is a reply to message #18626] |
Thu, 09 November 2006 21:22 |
Artjom Bitor
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
Hello!
First of all, thanks to Richard for his opinion. It is good to have a
discussion.
Well, that's true that using annotations for code fragmentation is quite
different approach than some established solutions based on preprocessing
with directives, e.g. J2ME Polish. This does not only mean that a
developer has to change his way of programming. This also means that using
annotations provides such capabilitys like syntax cheking or the ability
to be processed by refactoring operations like any other Java element -
"out of the box" and not only through extra tools.
The scope of annotations is not only a field or a method, as mentioned by
Richard. They can be used along with much more elements:
- Type
- Field
- Method
- Constructor
- Parameter
- Local variable
- Pakage declaration
- Annotation
On the one hand it can be seen as not enough in a comparison to the
omnipresence of Java comments wich are used to bring a preprocessing
directive into the code. But on the other hand this can be seen as
reasonable limitations. Fragmenting the code should go along with taking
the structure of this code into account. This strategy provides also a
limitation of mistakes - like setting some //#endif on the wrong line or
forgetting to set it at all. Or managing all occurencies of an element
that should exist only in some case. According to a method this means to
manage all its invocations by surrounding them with appropriate
directives. In a complex structure this could easily be forgotten. If you
use an Existence-Annotation in Annocracy, than the system takes care of
all occurencies, invocations, etc. All you need is probably add a comment
for yourself to see the dependency or use some visual decoration provided
by a tool - yet to come but not impemented at the moment because Annocracy
is quite "young".
Richard also demurs about the handling of complex statements like /#if
polish.hasCommandKeyEvents || (polish.key.LeftSoftKey.defined &&
polish.key.RightSoftKey.defined). Maybe it is a misunderstanding of
concept which Annocracy follows. In the most annotations there is an
element that is called "dependsOn". It's used to represent a case, e.g.
that a device has some capability. In our small example application there
are not many of such cases used, e.g. "midp1.0". This is not always, as it
could seem to be, equivalent to some atomar case like
polish.hasCommandKeyEvents. It is only a placeholder or a label for a rule
which contains all the logic for a comparison of device properties with
some values you expect. You could specify a rule that handles cases of any
complexity - using the usual operators like AND, OR, NOT -, give it a name
and reference it by this name in the annotations. Annocracy provides a way
of this specification in an external file that easily can be modified or
completed. I would say, it is even less verbose in an annotation, than in
a comment based directive. Besides you have to specify such a rule - as it
is called in the context of Annocracy - only once - in the mentioned file.
If you prefer to use it other way, it's quite easy to provide an
appropriate RuleValidator by yourself that can handle the same input like
polish.hasCommandKeyEvents || (polish.key.LeftSoftKey.defined &&
polish.key.RightSoftKey.defined). Annocracy alows you to extend its
functionality at various points.
Concerning imports - you have no need to handle them in Annocracy in the
way you would if you were using J2ME Polish. Let us analyse what the cases
are for handling imports. The simple one can be that you are using some
functionality in your application that should exist only in some special
case. Importing the needed classes that comes along with it should also be
handled in the same way. In J2ME Polish you can achieve this by
surrounding such an import declaration with directives, as shown in the
example provided by Richard:
//#if polish.api.nokia-ui
import com.nokia.mid.ui.*;
//#endif
Annocracy handles such a case in a different way. The functionality is
removed from code if the corresponding condition is not fulfiled - e.g.
using @Existence. The import which of cource is not touched by any
annotation and is not needed in the enclosing compilation unit will be
removed by Annocracy at the end of the processing. It's just the same if
you were using Eclipse as IDE and invoking "organize imports" action.
The second case for handling imports could be that you have to "toggle" an
import of a functionality that is provided by an advanced API but is not
included in the old one, e.g. GameCanvas in MIDP-2.0. In such a case you
would provide an own implementation - with the same name - and just want
to "link" the import to yours one. In J2ME Polish this could by something
like this:
//#if polish.midp2
import javax.microedition.lcdui.game.GameCanvas;
//#else
import my.own.GameCanvas;
//#endif
In Annocracy you could use @Types instead to change the type of your
element containing the declaration of your GameCanvas (because changing
the type is what you want in such a case, isn't it?) :
@Types(types = { @Type(dependsOn = "midp1.0" typeOwner =
"canvasTypeOwner") })
private javax.microedition.lcdui.game.GameCanvas canvas;
@TypeOwner
private my.own.GameCanvas canvasTypeOwner;
Although this annotation was not used in our example application this does
not mean that there is no such functionality provided by the annotations
of Annocracy. Just look at the annotations in the package
de.four2b.annocracy.annotations.core. By the way, you are not limited by
using only this annotations. You can easily specify your own if there is a
need. This comes along with providing of the appropriate processing
component, but it's also nothing complex according to the simple API and
using utilities included in Annocracy for such purposes.
If you are working with annotations you need Java 5 - there is nothing to
appeal against. You should have this installed on your computer if you
want to use Annocracy. But I don't really understand the problem mentioned
by Richard: "... The plugin processing the annotated classes need to run
in a Java5 VM. This is in contrast to the claim eclipse runs on 1.4..."
I'm currenlty using Eclipse with Java 5 VM and being still able to develop
J2ME applications. As mentioned in the readme file, that is shipped with
our example application, you have to include the rt.jar from Java 5 JRE in
the classpath of your project if you want to use all of the core
annotations. It's also mentioned how you can limit the access to this JAR
by adding some restrictions. This is e.g. one way if you do not want to
have functionality from Java 5 in your project, besides the annotations.
This way you could not use autoboxing e.g. by mistake. The code is
absolutely valid for the platform you're targeting, e.g. 1.2. By the way,
it's planned to provide a processing component for transforming the other
features of Java 5 in the code to the needed code version, e.g. 1.2. This
way you'll be able to write your code as if you would develop for Java 5
platform. So, J2ME Polish would be not the only one tool with such
abilities.
At the moment Annocracy dose not provide a GUI tool for assisting the
developement process. But, as mentioned above, it's planned to do one in
the near future. So it's just a matter of time. The advantage of J2ME
Polish in this case is of course unchallenged - at the moment. Annocracy
does not exist as long as other tools and has no big crew behind it.
That's why there are not all features integrated yet. But it's going to
change.
Kind regards,
Artjom
|
|
|
| Re: Preprocessing Discussion [message #18666 is a reply to message #18643] |
Fri, 10 November 2006 10:10 |
Sebastian Sickelmann
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Hi
Thanks to Artjom for the good post. I think the mean problem is that
we(the founders/developers of Annocracy) had not yet posted enought
information to Newsgroup/Mailinglist/Wiki about Annocracy-Features. I
think that we should change this as soon as possible. Whats the best way?
We have a bugzilla account, i think with this we can edit MTJ-Wiki.
Should be build up a knowledge-base for Annocracy in MTJ-Wiki? There we
can explain the core Annotations the processing and a "How can i
translate this polish-notation efficently to Annocracy".
@Rauno: Can you place a starting-page for this, if this wiki-part is
wanted? Or should we start a new wiki for that at four2b? We are using
MediaWiki, so there is a good change to transfer is easialy later.
Artjom Bitor schrieb:
> Hello!
>
<schnipp/>
>
> If you are working with annotations you need Java 5 - there is nothing
> to appeal against. You should have this installed on your computer if
> you want to use Annocracy. But I don't really understand the problem
> mentioned by Richard: "... The plugin processing the annotated classes
> need to run in a Java5 VM. This is in contrast to the claim eclipse runs
> on 1.4..."
I think i found what Ricky means:
http://www.eclipse.org/eclipse/development/readme_eclipse_3. 2.1.html
*With the exception of a small set of features that actually require
*Java SE 5 APIs (in particular, the support for Annotation Processing
*and JUnit 4), the 3.2 release of the Eclipse Project runs against
*version 1.4 of the Java 2 Platform. As such, the Eclipse Project SDK as
*a whole is targeted at both 1.4 and Java5 VMs, with full functionality
*available for 1.4 level development everywhere, and new Java5 specific
*capabilities available when running on a Java5 VM. Appendix 1 contains
*a table that indicates the class library level required for each
*plug-in.
But i think that there is no problem with it. Users who wanted to use
Annocracy as preprocessing solution must use a Java5-VM as Eclipse
Runtime. Annocracy should not be the one and only preprocessing-solution
in MTJ. If i reminder me correct, Arto had designed an extension-Point
for MTJ-Buildprocessing and Preprocessing.
<schnipp/>
|
|
|
| Re: Preprocessing Discussion [message #565402 is a reply to message #17430] |
Wed, 01 November 2006 09:00 |
Rauno Seppala
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
Sebastian,
have you checked a short news track earlier "Preprocessing is having some
patents"? What is your understanding of them? Are they something that should
be checked against your solution by Eclipse legal?
Rauno
"Sebastian Sickelmann" <sebastian.sickelmann@four2b.de> wrote in message
news:45463B36.3010806@four2b.de...
> Hi MTJ
>
> Let me introduce myself in first place. My Name ist Sebastian Sickelmann
> and i am CTO of Four2B GmbH in Germany. We(mainly Artjom Bitor)
> developed a preprocessing solution that is able to manage Code
> Fragmentation without comment based proprosessing derectives.
>
> I have a meeting with Mika, Rauno and Arto at Eclipse Summit(thanks for
> good discussion at Summit). The result of our discussion was that it is
> best to discuss our solution at MTJ Newsgroup or Mailing List. I decided
> it is best in Newsgroups(for Thread-Tracking).
>
> And the best way presenting a solution for discussion purpose is to show
> a small "real" world example. For that we packaged a Update-Site
> (http://www.annocracy.four2b.de/update/) (Sorry that we only bring in
> source-code for the Annotation Implementation, but at this time i don't
> get the complete clearance for using the EPL for the complete source).
>
> And we know that is not easy to see how a solution works without any
> example Project. (http://www.annocracy.four2b.de/GameOfLife.zip)
>
> In the GameOfLife Zip is a project and an additional Plugin
> (de.four2b.annocracy.mockDeviceDataSource_1.0.0.jar) that is not really
> useful for a real project, but is capable for the GameOfLife Example
> Project. Annocracy is extendable at several points, and this plugin is a
> simple DeviceInformation Datasource for Annocracy. The
> DeviceDataSources, BuildSystem etc. are not the Main-Parts of Annocracy.
> But we packed this example with a very simple Build-Cycle and
> DeviceData-Source, to show its functionality.
>
> Our main goal is to enable MTJ to use Annocracy Preprocessing, so that
> it is embeded in all those nice MTJ-Features.
>
> If you want to discuss with us about preprocessing with Annotations it
> is time to create a fresh Eclipse 3.2-Testing Installation and workspace
> for testing purpose and extract the GameOfLife-Zip and add the prepared
> project to this workspace. Please don't forgot to install the additional
> MockDeviceDataSource-Plugin into your plugin-directory.
>
> Annocracy is an RCP so you can use it via RCP-Launch-Configuration. We
> prepared a small ANT-Task(not fully integrated all features yet). With
> this use can use Annocracy outside of Eclipse(just a RCP-Installation
> with the used plugins are needed). There is no UI-Plugins in Annocracy,
> but we want to integrate it into MTJ-Build-Process (posible there will
> be a need for using Wizards and Preference-Pages for Annocracy, but now
> let please discuss the preprocession terms in General).
>
> In GameOfLife Project we tried to help setup your first Annocracy Build.
> Please read readme.txt and follow the instructions. Be carefull the
> temporary-workspace(WORK in build.xml and "Workspace Data" in
> RCP-Launch-Configuration) used by Annocracy will be deleted before
> processing.
>
> Hope to get some review reports, proposals or maybe just ideas of want
> we can do better.
>
> We try to translate our internal architecture document to english and
> bring it in an presentable form in the next days.
>
> Hope to hear from you
>
> Kind regards
> Sebastian
|
|
|
| Re: Preprocessing Discussion [message #565429 is a reply to message #17439] |
Wed, 01 November 2006 19:30 |
Sebastian Sickelmann
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Rauno,
yes, i have checked it after eclipse summit but not have written any
post on this issue because i am not a legal expert.
I think, like that 6,839,712 from IBM is very special to
internationalization and searching for hardcoded strings. From my point
of view this has no point of contact with Annocracy or other
preprocessing technologies.
The same with patent 6,986,129 from SUN. I dont think that there will be
any problem with Annocracy, but it is much closer to what we need in MTJ
for preprocessing.
In this patent there is a template used for processing, i don't find any
information if this template is compileable of is just a template file
in any format. The line orientation discribed in this patent is realy
close to microcode, antenna, polish. These technologies use line based
meta code for preprocessing. Annocracy is using a java language element
and some external informations for steering of preprocessing. The Patent
is written in August 2001 before Annotations are inside Java Language,
so it is not clear if Annotations and processing of them are in scope ot
the patent.
When there is a legal checking i think it should check if:
-The Sun Patent hits comment(line) based preprocessing
-The Sun Patent hits the processing of Annotations.
-The Sun Patent hits changing of sorcecode(whats with refactorings)
I don't think the Annocracy is in scope of these patents. I'am not a
legal, but i think when this 3 points are checked we can say that all
preprocessing solutions we need for MTJ are applicable without legal
drawbacks.
Sebastian
Rauno Seppala schrieb:
> Sebastian,
> have you checked a short news track earlier "Preprocessing is having some
> patents"? What is your understanding of them? Are they something that should
> be checked against your solution by Eclipse legal?
>
> Rauno
>
> "Sebastian Sickelmann" <sebastian.sickelmann@four2b.de> wrote in message
> news:45463B36.3010806@four2b.de...
>> Hi MTJ
>>
>> Let me introduce myself in first place. My Name ist Sebastian Sickelmann
>> and i am CTO of Four2B GmbH in Germany. We(mainly Artjom Bitor)
>> developed a preprocessing solution that is able to manage Code
>> Fragmentation without comment based proprosessing derectives.
>>
>> I have a meeting with Mika, Rauno and Arto at Eclipse Summit(thanks for
>> good discussion at Summit). The result of our discussion was that it is
>> best to discuss our solution at MTJ Newsgroup or Mailing List. I decided
>> it is best in Newsgroups(for Thread-Tracking).
>>
>> And the best way presenting a solution for discussion purpose is to show
>> a small "real" world example. For that we packaged a Update-Site
>> (http://www.annocracy.four2b.de/update/) (Sorry that we only bring in
>> source-code for the Annotation Implementation, but at this time i don't
>> get the complete clearance for using the EPL for the complete source).
>>
>> And we know that is not easy to see how a solution works without any
>> example Project. (http://www.annocracy.four2b.de/GameOfLife.zip)
>>
>> In the GameOfLife Zip is a project and an additional Plugin
>> (de.four2b.annocracy.mockDeviceDataSource_1.0.0.jar) that is not really
>> useful for a real project, but is capable for the GameOfLife Example
>> Project. Annocracy is extendable at several points, and this plugin is a
>> simple DeviceInformation Datasource for Annocracy. The
>> DeviceDataSources, BuildSystem etc. are not the Main-Parts of Annocracy.
>> But we packed this example with a very simple Build-Cycle and
>> DeviceData-Source, to show its functionality.
>>
>> Our main goal is to enable MTJ to use Annocracy Preprocessing, so that
>> it is embeded in all those nice MTJ-Features.
>>
>> If you want to discuss with us about preprocessing with Annotations it
>> is time to create a fresh Eclipse 3.2-Testing Installation and workspace
>> for testing purpose and extract the GameOfLife-Zip and add the prepared
>> project to this workspace. Please don't forgot to install the additional
>> MockDeviceDataSource-Plugin into your plugin-directory.
>>
>> Annocracy is an RCP so you can use it via RCP-Launch-Configuration. We
>> prepared a small ANT-Task(not fully integrated all features yet). With
>> this use can use Annocracy outside of Eclipse(just a RCP-Installation
>> with the used plugins are needed). There is no UI-Plugins in Annocracy,
>> but we want to integrate it into MTJ-Build-Process (posible there will
>> be a need for using Wizards and Preference-Pages for Annocracy, but now
>> let please discuss the preprocession terms in General).
>>
>> In GameOfLife Project we tried to help setup your first Annocracy Build.
>> Please read readme.txt and follow the instructions. Be carefull the
>> temporary-workspace(WORK in build.xml and "Workspace Data" in
>> RCP-Launch-Configuration) used by Annocracy will be deleted before
>> processing.
>>
>> Hope to get some review reports, proposals or maybe just ideas of want
>> we can do better.
>>
>> We try to translate our internal architecture document to english and
>> bring it in an presentable form in the next days.
>>
>> Hope to hear from you
>>
>> Kind regards
>> Sebastian
>
>
|
|
| | |
| Re: Preprocessing Discussion [message #565659 is a reply to message #17485] |
Thu, 09 November 2006 12:34 |
Ricky
Messages: 204
Registered: July 2009 |
Senior Member |
|
|
Hello Everybody,
using annotations is an interesting approach, although I see some major =
=
problems with it.
- Annotations work only on the field and method level. On the other hand=
, =
a lot of decisions are done within methods and it whould be annoying to =
=
refactor this into several methods to dispatch to the right ones. This =
would break up the unit of work from one method to severals just to =
reflect device fragmentation.
Even in simple examples this can become quite complex, like the provided=
=
example:
@Implementations(implementations =3D { @Implementation(dependsO=
n =3D =
"midp1.0", implementationOwner =3D "randomIntForMidp1") })
public static int randomInt(int range) {
// default implementation
return random.nextInt(range);
}
@ImplementationOwner
private static int randomIntForMidp1(int range) {
// implementation for MIDP-1.0
int randomInt =3D randomInt();
if (randomInt < 0) {
// allow only positive numbers
randomInt *=3D -1;
}
return randomInt % range;
}
Note: the availability of random.nextInt(range) is not dependent on the =
=
MIDP version, by the way. This is part of the CLDC specification.
A comment-based preprocessing equivalent is much simpler in comparison:
public static int randomInt(int range) {
int randomInt ;
//#if polish.cldc1.0
randomInt =3D Math.abs(this.random.nextInt()) % range;
//#else
randomInt =3D this.random.nextInt(range);
//#endif
return randomInt;
}
In more complex examples where there are many branches necessary within =
=
one method, this yields up quite a lot. Expressing complex statements li=
ke =
/#if polish.hasCommandKeyEvents || (polish.key.LeftSoftKey.defined && =
polish.key.RightSoftKey.defined) could be quite verbose in an annotation=
..
- Imports cant be handled by annotations. E.g. if you want to draw a hal=
f =
transparent rectangle you need the nokia ui api (i.e. a platform specifi=
c =
import). With comment-based preprocessing this is quite simple:
//#if polish.api.nokia-ui
import com.nokia.mid.ui.*;
//#endif
- The plugin processing the annotated classes need to run in a Java5 VM.=
=
This is in contrast to the claim eclipse runs on 1.4. On a sidenote if t=
he =
developer has installed a Java5 VM he can not use Java 5 features like =
autoboxing, enums and foreach as the target version for midp is 1.2. J2M=
E =
Polish converts Java5 class files on the fly to 1.2 compatible ones.
A good thing about the annotation approach is, that the editor doesnt ne=
ed =
to be changed at all for the preprocessing stuff. But full tooling suppo=
rt =
for preprocessing also includes things like occurrence marking or choosi=
ng =
of target platform (target device) so we have to go into the editor =
nevertheless. The Mepose plugin of J2ME Polish is a good showcase that =
this can be done and is ready for inclusion.
Regards,
Richard
|
|
|
| Re: Preprocessing Discussion [message #565676 is a reply to message #18626] |
Thu, 09 November 2006 21:22 |
Artjom Bitor
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
Hello!
First of all, thanks to Richard for his opinion. It is good to have a
discussion.
Well, that's true that using annotations for code fragmentation is quite
different approach than some established solutions based on preprocessing
with directives, e.g. J2ME Polish. This does not only mean that a
developer has to change his way of programming. This also means that using
annotations provides such capabilitys like syntax cheking or the ability
to be processed by refactoring operations like any other Java element -
"out of the box" and not only through extra tools.
The scope of annotations is not only a field or a method, as mentioned by
Richard. They can be used along with much more elements:
- Type
- Field
- Method
- Constructor
- Parameter
- Local variable
- Pakage declaration
- Annotation
On the one hand it can be seen as not enough in a comparison to the
omnipresence of Java comments wich are used to bring a preprocessing
directive into the code. But on the other hand this can be seen as
reasonable limitations. Fragmenting the code should go along with taking
the structure of this code into account. This strategy provides also a
limitation of mistakes - like setting some //#endif on the wrong line or
forgetting to set it at all. Or managing all occurencies of an element
that should exist only in some case. According to a method this means to
manage all its invocations by surrounding them with appropriate
directives. In a complex structure this could easily be forgotten. If you
use an Existence-Annotation in Annocracy, than the system takes care of
all occurencies, invocations, etc. All you need is probably add a comment
for yourself to see the dependency or use some visual decoration provided
by a tool - yet to come but not impemented at the moment because Annocracy
is quite "young".
Richard also demurs about the handling of complex statements like /#if
polish.hasCommandKeyEvents || (polish.key.LeftSoftKey.defined &&
polish.key.RightSoftKey.defined). Maybe it is a misunderstanding of
concept which Annocracy follows. In the most annotations there is an
element that is called "dependsOn". It's used to represent a case, e.g.
that a device has some capability. In our small example application there
are not many of such cases used, e.g. "midp1.0". This is not always, as it
could seem to be, equivalent to some atomar case like
polish.hasCommandKeyEvents. It is only a placeholder or a label for a rule
which contains all the logic for a comparison of device properties with
some values you expect. You could specify a rule that handles cases of any
complexity - using the usual operators like AND, OR, NOT -, give it a name
and reference it by this name in the annotations. Annocracy provides a way
of this specification in an external file that easily can be modified or
completed. I would say, it is even less verbose in an annotation, than in
a comment based directive. Besides you have to specify such a rule - as it
is called in the context of Annocracy - only once - in the mentioned file.
If you prefer to use it other way, it's quite easy to provide an
appropriate RuleValidator by yourself that can handle the same input like
polish.hasCommandKeyEvents || (polish.key.LeftSoftKey.defined &&
polish.key.RightSoftKey.defined). Annocracy alows you to extend its
functionality at various points.
Concerning imports - you have no need to handle them in Annocracy in the
way you would if you were using J2ME Polish. Let us analyse what the cases
are for handling imports. The simple one can be that you are using some
functionality in your application that should exist only in some special
case. Importing the needed classes that comes along with it should also be
handled in the same way. In J2ME Polish you can achieve this by
surrounding such an import declaration with directives, as shown in the
example provided by Richard:
//#if polish.api.nokia-ui
import com.nokia.mid.ui.*;
//#endif
Annocracy handles such a case in a different way. The functionality is
removed from code if the corresponding condition is not fulfiled - e.g.
using @Existence. The import which of cource is not touched by any
annotation and is not needed in the enclosing compilation unit will be
removed by Annocracy at the end of the processing. It's just the same if
you were using Eclipse as IDE and invoking "organize imports" action.
The second case for handling imports could be that you have to "toggle" an
import of a functionality that is provided by an advanced API but is not
included in the old one, e.g. GameCanvas in MIDP-2.0. In such a case you
would provide an own implementation - with the same name - and just want
to "link" the import to yours one. In J2ME Polish this could by something
like this:
//#if polish.midp2
import javax.microedition.lcdui.game.GameCanvas;
//#else
import my.own.GameCanvas;
//#endif
In Annocracy you could use @Types instead to change the type of your
element containing the declaration of your GameCanvas (because changing
the type is what you want in such a case, isn't it?) :
@Types(types = { @Type(dependsOn = "midp1.0" typeOwner =
"canvasTypeOwner") })
private javax.microedition.lcdui.game.GameCanvas canvas;
@TypeOwner
private my.own.GameCanvas canvasTypeOwner;
Although this annotation was not used in our example application this does
not mean that there is no such functionality provided by the annotations
of Annocracy. Just look at the annotations in the package
de.four2b.annocracy.annotations.core. By the way, you are not limited by
using only this annotations. You can easily specify your own if there is a
need. This comes along with providing of the appropriate processing
component, but it's also nothing complex according to the simple API and
using utilities included in Annocracy for such purposes.
If you are working with annotations you need Java 5 - there is nothing to
appeal against. You should have this installed on your computer if you
want to use Annocracy. But I don't really understand the problem mentioned
by Richard: "... The plugin processing the annotated classes need to run
in a Java5 VM. This is in contrast to the claim eclipse runs on 1.4..."
I'm currenlty using Eclipse with Java 5 VM and being still able to develop
J2ME applications. As mentioned in the readme file, that is shipped with
our example application, you have to include the rt.jar from Java 5 JRE in
the classpath of your project if you want to use all of the core
annotations. It's also mentioned how you can limit the access to this JAR
by adding some restrictions. This is e.g. one way if you do not want to
have functionality from Java 5 in your project, besides the annotations.
This way you could not use autoboxing e.g. by mistake. The code is
absolutely valid for the platform you're targeting, e.g. 1.2. By the way,
it's planned to provide a processing component for transforming the other
features of Java 5 in the code to the needed code version, e.g. 1.2. This
way you'll be able to write your code as if you would develop for Java 5
platform. So, J2ME Polish would be not the only one tool with such
abilities.
At the moment Annocracy dose not provide a GUI tool for assisting the
developement process. But, as mentioned above, it's planned to do one in
the near future. So it's just a matter of time. The advantage of J2ME
Polish in this case is of course unchallenged - at the moment. Annocracy
does not exist as long as other tools and has no big crew behind it.
That's why there are not all features integrated yet. But it's going to
change.
Kind regards,
Artjom
|
|
|
| Re: Preprocessing Discussion [message #565694 is a reply to message #18643] |
Fri, 10 November 2006 10:10 |
Sebastian Sickelmann
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Hi
Thanks to Artjom for the good post. I think the mean problem is that
we(the founders/developers of Annocracy) had not yet posted enought
information to Newsgroup/Mailinglist/Wiki about Annocracy-Features. I
think that we should change this as soon as possible. Whats the best way?
We have a bugzilla account, i think with this we can edit MTJ-Wiki.
Should be build up a knowledge-base for Annocracy in MTJ-Wiki? There we
can explain the core Annotations the processing and a "How can i
translate this polish-notation efficently to Annocracy".
@Rauno: Can you place a starting-page for this, if this wiki-part is
wanted? Or should we start a new wiki for that at four2b? We are using
MediaWiki, so there is a good change to transfer is easialy later.
Artjom Bitor schrieb:
> Hello!
>
<schnipp/>
>
> If you are working with annotations you need Java 5 - there is nothing
> to appeal against. You should have this installed on your computer if
> you want to use Annocracy. But I don't really understand the problem
> mentioned by Richard: "... The plugin processing the annotated classes
> need to run in a Java5 VM. This is in contrast to the claim eclipse runs
> on 1.4..."
I think i found what Ricky means:
http://www.eclipse.org/eclipse/development/readme_eclipse_3. 2.1.html
*With the exception of a small set of features that actually require
*Java SE 5 APIs (in particular, the support for Annotation Processing
*and JUnit 4), the 3.2 release of the Eclipse Project runs against
*version 1.4 of the Java 2 Platform. As such, the Eclipse Project SDK as
*a whole is targeted at both 1.4 and Java5 VMs, with full functionality
*available for 1.4 level development everywhere, and new Java5 specific
*capabilities available when running on a Java5 VM. Appendix 1 contains
*a table that indicates the class library level required for each
*plug-in.
But i think that there is no problem with it. Users who wanted to use
Annocracy as preprocessing solution must use a Java5-VM as Eclipse
Runtime. Annocracy should not be the one and only preprocessing-solution
in MTJ. If i reminder me correct, Arto had designed an extension-Point
for MTJ-Buildprocessing and Preprocessing.
<schnipp/>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 19:50:30 GMT 2024
Powered by FUDForum. Page generated in 0.03444 seconds |
] 
Search
Help
Register
Login
Home
