[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-mtj-dev] Possible MTJ Contribution
|
Thanks,
Looks good.
I am now in San Francisco and a bit busy here, but we will come back to
you quite soon.
mho
>-----Original Message-----
>From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
>[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext
>Sebastian Sickelmann
>Sent: 14 August, 2006 21:42
>To: Mobile Tools for The Java Platform mailing list
>Subject: Re: [dsdp-mtj-dev] Possible MTJ Contribution
>
>Hi
>
>I am glad that i now can tell you some news about our possible
>MTJ-Contribution.
>We will open-source some parts of our "Annocracy"-Project.
>Annocracy uses Annotations to annotate the way of handling
>code-fragmentation. Because we are using Annotations for that,
>it is fully integrated in the Java-Language. We use
>Eclipse-Technology (JDT-AST) to process source-files and to
>create device-specific projects.
>Annocracy is not bind
>to Eclipse, it is build using an RCP-Enviroment and can so
>acutally be started using commandline and RCP-RunConfiguration
>out of Eclipse. In the next few weeks we will publish some
>ANT-Tasks to integrate it easyly in every modern IDE.
>
>I will you now show some easy examples how Annocracy feels.
>
>Here some Easy-Method-Implementation-Change (it is a mock
>example, but it shows the idea)
>
>@Implementations({
>
> @Implementation(dependsOn = "methodImplementationRule1",
>implementationOwner = "doDestroyAppImpl1"),
>
> @Implementation(dependsOn = "methodImplementationRule2",
>implementationOwner = "doDestroyAppImpl2")
>
>})
>
>private void doDestroyApp() {
>
> // TODO default implementation
>
>}
>
>@ImplementationOwner
>
>private void doDestroyAppImpl1() {
>
> System.out.println("destroying application in one way");
>
>}
>
>@ImplementationOwner
>
>private void doDestroyAppImpl2() {
>
> System.out.println("destroying application in another way");
>
>}
>
>In this example the implementation of the Method doDestroyApp
>should be change be either the implementation of
>doDestroyAppImpl1 or the impl. of doDestroyAppImpl2. It is
>exchange by the implementation of Impl1 if
>"methodImplementationRule1" is evaluated to true. The
>Evaluation can be Device/Project or Build-Specific and is
>managed by an external(plugable) Validator. The
>Defaultvalidator uses XML Configsfiles to configure the way of
>evaluation. Example:
>
>@Implementations({
>
> @Implementation(dependsOn = "CLCD1.0", implementationOwner
>= "doDestroyAppImpl1"),
>
> @Implementation(dependsOn = "CLCD1.1", implementationOwner =
>"doDestroyAppImpl2")
>
>})....
>
>If the Device that is actually building is an CLDC1.0-Device
>the implementation is exchanged by Impl1.
>If the Device that is acutally building is an CLCD1.1-Device
>the implementation is exchanged by Impl2.
>If the Device is not either an CLDC1.0 or 1.1 -Device the
>Method implementation is unchanged.
>
>What CLDC and J2SE means is defined in an external
>XML-Configuration(can be part of an set of Configurations).
>
>
> <rule-definition id = "midp1.0">
> <comparison device-property = "device.platform"
>comparator = "==" value = "midp1.0" />
> </rule-definition>
>
> <rule-definition id = "midp2.0">
> <comparison device-property = "device.platform"
>comparator = "==" value = "midp2.0" />
> </rule-definition>
>
> <!-- configuration properties -->
>
> <rule-definition id = "cldc1.0">
> <comparison device-property = "device.configuration"
>comparator = "==" value = "cldc1.0" />
> </rule-definition>
>
> <rule-definition id = "cldc1.1">
> <comparison device-property = "device.configuration"
>comparator = "==" value = "cldc1.1" />
> </rule-definition>
>..and so on
>
>
>The device-property are filled using multiple DataSources. We
>will implement an DataSource accesing our web-service of
>deviceknowledge-database. But using other
>databases(j2mepolish,wurfl,other)
>is just implementing an extension-Point in Annocracy. Is there
>an deviceknowledge-project in MTJ or DSDP that we should integrate?
>
>Annotations have one drawback to comment-based preprocessors.
>You cannot annotation some lines of code in an existing
>Method. You have to extract the code to a Method and Annotate
>your Method.
>In my eyes it is no problem, because there is no example by
>which i cannot find a name for the sourcecode -block(my new
>Method). The only problem is that method-calls are exensive an
>a method has an overhead around 100 Bytes in the resulting
>Bytecode. So we implemented an additional @Inline annotation
>that keeps track of it. @Inline is not just an code-copy. A
>Simple code copy would bring namespace problems with it.
>@Inline renames local names if it is needed.
>
>Example for @Inline:
>
>public class InlineTest {
>
> static {
> staticMethod();
> }
>
> public InlineTest() {
> }
>
> public static void main(String[] args) {
> InlineTest inlineTest = new InlineTest();
> inlineTest.voidMethod();
> inlineTest.voidMethodWithParameters(1, "void", true);
> System.out.println(inlineTest.nonVoidMethod());
> System.out.println(inlineTest.nonVoidMethodWithParameters(0,
>"nonVoid", false));
> int a;
> int b;
> int complexMethod_a;
> int result = inlineTest.complexMethod();
> int c;
> staticMethod();
> }
>
> @Inline
> private void voidMethod() {
> System.out.println("voidMethod");
> }
>
> @Inline
> private void voidMethodWithParameters(int i, String s, boolean b) {
> System.out.println("voidMethodWithParameters: '" + i +
>"', '" + s + "', '" + b + "'");
> }
>
> @Inline
> private String nonVoidMethod() {
> return "nonVoidMethod";
> }
>
> @Inline
> private String nonVoidMethodWithParameters(int i, String
>s, boolean b) {
> return "nonVoidMethodWithParameters: '" + i + "', '" +
>s + "', '" + b + "'";
> }
>
> @Inline
> private int complexMethod() {
> int a = 1;
> int b = 2;
> System.out.println("complexMethod");
> return Math.max(a, b);
> }
>
> @Inline
> private static void staticMethod() {
> int c;
> }
>}
>
>Will create this source.
>
>public class InlineTest {
>
> /**
> * Modified by Annocracy: content of the method
>'staticMethod' was inlined here
> */
> static {
> int c;
> }
>
> public InlineTest() {
> }
>
> /**
> * Modified by Annocracy: content of the method
>'voidMethod' was inlined here
> * Modified by Annocracy: content of the method
>'voidMethodWithParameters' was inlined here
> * Modified by Annocracy: content of the method
>'nonVoidMethod' was inlined here
> * Modified by Annocracy: content of the method
>'nonVoidMethodWithParameters' was inlined here
> * Modified by Annocracy: content of the method
>'complexMethod' was inlined here
> * Modified by Annocracy: content of the method
>'staticMethod' was inlined here
> */
> public static void main(String[] args) {
> InlineTest inlineTest = new InlineTest();
> System.out.println("voidMethod");
> System.out.println("voidMethodWithParameters: \'" + 1
>+ "\', \'"
>+ "void" + "\', \'" + true + "\'");
> int nonVoidMethod_return = "nonVoidMethod";
> System.out.println(nonVoidMethod_return);
> int nonVoidMethodWithParameters_return =
>"nonVoidMethodWithParameters: \'" + 0 + "\', \'" + "nonVoid" + "\', \'"
>+ false + "\'";
> System.out.println(nonVoidMethodWithParameters_return);
> int a;
> int b;
> int complexMethod_a;
> int inline_complexMethod_a = 1;
> int complexMethod_b = 2;
> System.out.println("complexMethod");
> int complexMethod_return =
>Math.max(inline_complexMethod_a, complexMethod_b);
> int result = complexMethod_return;
> int c;
> int staticMethod_c;
> }
>}
>
>Obfuscating and shrinking will delete the rest(see "int staticMethod_c"
>Deklaration)
>
>Another example. This time the very usefull @Existence
>
>@Existence(dependsOn = "mp3")
>
>private void playSound() {
>
> // TODO play sound
>
> System.out.println("La la la!");
>
>}
>
>
>private void doApplicationLogic{
>
> playSound();
>
>}
>
>
>OK. The method playSound only exists wenn the rule "mp3" is
>evalated to true. But what is with all(ok here it is only one)
>its callers? Annocracy eliminates all calls to that Method.
>Keeping track of everything you would manualy do. Example:
>
>@Existence(dependsOn = "mp3")
>
>private int calc() {
>
> return 42;
>
>}
>
>
>private void doApplicationLogic{
>
> int a = calc();
> a++;
> System.out.println(a);
>
>}
>
>
>will create an empty doApplicationLogic Method(when mp3 is not
>available), because the variable Deklarations of "a" depends
>on the result of calc. If you write:
>
>private void doApplicationLogic{
>
> int a = 0;
> a = calc();
> a++;
> System.out.println(a);
>
>}
>
>
>43 is printed by "mp3 devices" and 1 is printed by non "mp3 devices".
>
>
>Of course Annotations can be combined.
>
>This was only a small look. There is much more. But this
>should not be part of on common discussion form.
>
>Hope to get some feedback.
>
>Kind regards and sorry for the long mail Sebastian
>
>
>mika.hoikkala@xxxxxxxxx schrieb:
>> Hi,
>>
>> You get my curiosity up. When you think that you can publish
>> information what you have.
>> And if that takes time we are also interested in documentation which
>> tells how it work (end user / use case perspective) if that
>is easier
>> to deliver than code.
>>
>> Yes. Eclipse lisence is EPL and it would definitely be the best for
>> your contribution also.
>>
>> Eclipse community is quite strict that it don't have any license
>> problems in Eclipse projects.
>>
>> mho
><clear-thread />
>
>_______________________________________________
>dsdp-mtj-dev mailing list
>dsdp-mtj-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
>
