You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mike <mi...@gmail.com> on 2009/03/29 07:56:12 UTC
[GSOC] Proposals from me
Hi all,
i'm a undergraduate student from ZheJiang University and had just
submitted my proposal some of the harmony GSOC's project. I've been
focusing on harmony from last year when firepure@gmail.com gave a speech
on Apache Harmony at ZheJiang University ZJG campus.
i'm familiar with java's mechanism, how a java program runs. Know the
principle of java virtual machine. i'm also a active opensource
programmer, and currently maintain a java project called MNADemo (at
http://code.google.com/p/mnademo/ )
I have submitted 3 projects on the GSOC's website.
* harmony-class-selector
In the Harmony's wiki page it saids.
For many java desktop application, sometimes they will
offer a JRE in the installation package, which may be
big. And the project may also customize the jre to be
smallest for the application, which cost much effort. We
are looking for an automatic tool to find out all
classes for the application and build up a smallest JRE
for the customer. For many our developers, we have
EasyMock to cheat coverage tools, such as Emma. The
smallest jre can help us to find these cheats, make code
more robust.
This is a rather strange idea. Because, it will make application
code more robust, but will not make harmony-class-selector
robust. Which means, harmony-class-selector will force user to
do nearly 100% testing. This is not always good. So on my own
perspective, we need to provide 2 strategies.
1. collect the class dependency according to test generated
class file.
2. collect the class dependency according to application
jar.
One is for user to recheck the their code coverage, another is
for productivity use. But if we implement the second strategy,
the information collection algorithm will be base on .class file
parsing. There's no way for hacking a classloader when the jar
file is not fully running. So there should be an alternative.
^_^
* Harmony misc tools (harmony-tools-1 on the wiki page)
Tools that be involved are jar, javaws, jconsole.
For jar, it's not that hard. jar spec can be found at
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
For javaws, it seems that it involves the JNLP stuff, and it
shouldn't be too complicated. ^_^
But for jconsole, sun's jconsole is just too rich featured T_T.
I guess we can separate the jconsole into many other small
tools, such as heap_mon, thread_mon, vm_info. And also, we may
cast away the GUI interface, since harmony's swing/awt
implementation is not mature. CLI interface for a monitor is
convenient enough for a administrator.
* i18n tool harmony/others
The wiki page gave us a clear guideline of how to implement it
clear enough ^_^.
( http://wiki.apache.org/harmony/Harmony_i18n_tool )
So i only got some ideas on implementation:
1 i think the translation notation should be written in the
code. Programmers should know that their strings in the code
will be translated. Java5's annotation support can help us with
this. Using a annotation within a class is better than a xml
file to configure the extractor.
2 injector. how about do a hack on the classpath? when analyzer
detect that the class will be translate, use javac to compile
different a copy with different languages. then pack to
different jar files. When project code is runnning, the injector
will place the localized jar prior in the classpath.
well, this is the first idea that comes into my mind, it might be
impossible to complete, but i'm expecting your feedbacks. ^_^
Thanks all, yours
Mike
Re: [GSOC] Proposals from me
Posted by Charles Lee <li...@gmail.com>.
I agree. And Harmony-class-selector is optional. When they release a
milestone, harmony-class-selector is recommended. Any way, the main usage of
the harmony-class-selector is for a small runtime environment.
On Sun, Mar 29, 2009 at 2:30 PM, Mike <mi...@gmail.com> wrote:
> hi Charles.
> Thanks for your reply.
>
> well, do unit testing is good, but i don't think forcing other
> developers are nice enough ^_^.
>
> what if developer just want to be slick and quick without caring about
> code robust? i guess we have to leave them a choice.
>
> Yours
> Mike
>
> 在 2009-03-29日的 14:24 +0800，Charles Lee写道：
> > Hi Mike,
> >
> > Thanks for your consideration. Here is a quick reply from my mind.
> >
> > On Sun, Mar 29, 2009 at 1:56 PM, Mike <mi...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > i'm a undergraduate student from ZheJiang University and had just
> > > submitted my proposal some of the harmony GSOC's project. I've been
> > > focusing on harmony from last year when firepure@gmail.com gave a
> speech
> > > on Apache Harmony at ZheJiang University ZJG campus.
> > >
> > > i'm familiar with java's mechanism, how a java program runs. Know the
> > > principle of java virtual machine. i'm also a active opensource
> > > programmer, and currently maintain a java project called MNADemo (at
> > > http://code.google.com/p/mnademo/ )
> > >
> > > I have submitted 3 projects on the GSOC's website.
> > >
> > > * harmony-class-selector
> > > In the Harmony's wiki page it saids.
> > >
> > > For many java desktop application, sometimes they will
> > > offer a JRE in the installation package, which may be
> > > big. And the project may also customize the jre to be
> > > smallest for the application, which cost much effort. We
> > > are looking for an automatic tool to find out all
> > > classes for the application and build up a smallest JRE
> > > for the customer. For many our developers, we have
> > > EasyMock to cheat coverage tools, such as Emma. The
> > > smallest jre can help us to find these cheats, make code
> > > more robust.
> > >
> > >
> > > This is a rather strange idea. Because, it will make application
> > > code more robust, but will not make harmony-class-selector
> > > robust. Which means, harmony-class-selector will force user to
> > > do nearly 100% testing. This is not always good. So on my own
> > >
> >
> > harmony-class-selector will not force user to do nearly 100% testing, but
> > force developer to do the testing. Actually now every project will use
> unit
> > testing and code coverage to ensure their code robust, but as human
> beings,
> > we find lots of trick ways to cheat the result. Using harmony selector,
> > developer will be forced to test every code he write. Is it good or not?
> >
> >
> > > perspective, we need to provide 2 strategies.
> > >
> > > 1. collect the class dependency according to test generated
> > > class file.
> > > 2. collect the class dependency according to application
> > > jar.
> > >
> > > One is for user to recheck the their code coverage, another is
> > > for productivity use. But if we implement the second strategy,
> > > the information collection algorithm will be base on .class file
> > > parsing. There's no way for hacking a classloader when the jar
> >
> >
> > if the unit test do a really full tests on the application code, we can
> know
> > every class it use. So again, harmony-class-selector force developer to
> do
> > real full tests.
> >
> >
> > >
> > > file is not fully running. So there should be an alternative.
> > > ^_^
> > >
> > > * Harmony misc tools (harmony-tools-1 on the wiki page)
> > >
> > > Tools that be involved are jar, javaws, jconsole.
> > >
> > > For jar, it's not that hard. jar spec can be found at
> > > http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
> > >
> > > For javaws, it seems that it involves the JNLP stuff, and it
> > > shouldn't be too complicated. ^_^
> > >
> > > But for jconsole, sun's jconsole is just too rich featured T_T.
> > > I guess we can separate the jconsole into many other small
> > > tools, such as heap_mon, thread_mon, vm_info. And also, we may
> > > cast away the GUI interface, since harmony's swing/awt
> > > implementation is not mature. CLI interface for a monitor is
> > > convenient enough for a administrator.
> > >
> > > * i18n tool harmony/others
> > > The wiki page gave us a clear guideline of how to implement it
> > > clear enough ^_^.
> > > ( http://wiki.apache.org/harmony/Harmony_i18n_tool )
> > >
> > > So i only got some ideas on implementation:
> > > 1 i think the translation notation should be written in the
> > > code. Programmers should know that their strings in the code
> > > will be translated. Java5's annotation support can help us with
> > > this. Using a annotation within a class is better than a xml
> > > file to configure the extractor.
> > > 2 injector. how about do a hack on the classpath? when analyzer
> > > detect that the class will be translate, use javac to compile
> > > different a copy with different languages. then pack to
> > > different jar files. When project code is runnning, the injector
> > > will place the localized jar prior in the classpath.
> > >
> > > well, this is the first idea that comes into my mind, it might be
> > > impossible to complete, but i'm expecting your feedbacks. ^_^
> > >
> > > Thanks all, yours
> > > Mike
> > >
> > >
> > >
> > >
> >
> >
>
>
--
Yours sincerely,
Charles Lee
Re: [GSOC] Proposals from me
Posted by Mike <mi...@gmail.com>.
hi Charles.
Thanks for your reply.
well, do unit testing is good, but i don't think forcing other
developers are nice enough ^_^.
what if developer just want to be slick and quick without caring about
code robust? i guess we have to leave them a choice.
Yours
Mike
在 2009-03-29日的 14:24 +0800，Charles Lee写道：
> Hi Mike,
>
> Thanks for your consideration. Here is a quick reply from my mind.
>
> On Sun, Mar 29, 2009 at 1:56 PM, Mike <mi...@gmail.com> wrote:
>
> > Hi all,
> >
> > i'm a undergraduate student from ZheJiang University and had just
> > submitted my proposal some of the harmony GSOC's project. I've been
> > focusing on harmony from last year when firepure@gmail.com gave a speech
> > on Apache Harmony at ZheJiang University ZJG campus.
> >
> > i'm familiar with java's mechanism, how a java program runs. Know the
> > principle of java virtual machine. i'm also a active opensource
> > programmer, and currently maintain a java project called MNADemo (at
> > http://code.google.com/p/mnademo/ )
> >
> > I have submitted 3 projects on the GSOC's website.
> >
> > * harmony-class-selector
> > In the Harmony's wiki page it saids.
> >
> > For many java desktop application, sometimes they will
> > offer a JRE in the installation package, which may be
> > big. And the project may also customize the jre to be
> > smallest for the application, which cost much effort. We
> > are looking for an automatic tool to find out all
> > classes for the application and build up a smallest JRE
> > for the customer. For many our developers, we have
> > EasyMock to cheat coverage tools, such as Emma. The
> > smallest jre can help us to find these cheats, make code
> > more robust.
> >
> >
> > This is a rather strange idea. Because, it will make application
> > code more robust, but will not make harmony-class-selector
> > robust. Which means, harmony-class-selector will force user to
> > do nearly 100% testing. This is not always good. So on my own
> >
>
> harmony-class-selector will not force user to do nearly 100% testing, but
> force developer to do the testing. Actually now every project will use unit
> testing and code coverage to ensure their code robust, but as human beings,
> we find lots of trick ways to cheat the result. Using harmony selector,
> developer will be forced to test every code he write. Is it good or not?
>
>
> > perspective, we need to provide 2 strategies.
> >
> > 1. collect the class dependency according to test generated
> > class file.
> > 2. collect the class dependency according to application
> > jar.
> >
> > One is for user to recheck the their code coverage, another is
> > for productivity use. But if we implement the second strategy,
> > the information collection algorithm will be base on .class file
> > parsing. There's no way for hacking a classloader when the jar
>
>
> if the unit test do a really full tests on the application code, we can know
> every class it use. So again, harmony-class-selector force developer to do
> real full tests.
>
>
> >
> > file is not fully running. So there should be an alternative.
> > ^_^
> >
> > * Harmony misc tools (harmony-tools-1 on the wiki page)
> >
> > Tools that be involved are jar, javaws, jconsole.
> >
> > For jar, it's not that hard. jar spec can be found at
> > http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
> >
> > For javaws, it seems that it involves the JNLP stuff, and it
> > shouldn't be too complicated. ^_^
> >
> > But for jconsole, sun's jconsole is just too rich featured T_T.
> > I guess we can separate the jconsole into many other small
> > tools, such as heap_mon, thread_mon, vm_info. And also, we may
> > cast away the GUI interface, since harmony's swing/awt
> > implementation is not mature. CLI interface for a monitor is
> > convenient enough for a administrator.
> >
> > * i18n tool harmony/others
> > The wiki page gave us a clear guideline of how to implement it
> > clear enough ^_^.
> > ( http://wiki.apache.org/harmony/Harmony_i18n_tool )
> >
> > So i only got some ideas on implementation:
> > 1 i think the translation notation should be written in the
> > code. Programmers should know that their strings in the code
> > will be translated. Java5's annotation support can help us with
> > this. Using a annotation within a class is better than a xml
> > file to configure the extractor.
> > 2 injector. how about do a hack on the classpath? when analyzer
> > detect that the class will be translate, use javac to compile
> > different a copy with different languages. then pack to
> > different jar files. When project code is runnning, the injector
> > will place the localized jar prior in the classpath.
> >
> > well, this is the first idea that comes into my mind, it might be
> > impossible to complete, but i'm expecting your feedbacks. ^_^
> >
> > Thanks all, yours
> > Mike
> >
> >
> >
> >
>
>
Re: [GSOC] Proposals from me
Posted by Charles Lee <li...@gmail.com>.
Hi Mike,
Thanks for your consideration. Here is a quick reply from my mind.
On Sun, Mar 29, 2009 at 1:56 PM, Mike <mi...@gmail.com> wrote:
> Hi all,
>
> i'm a undergraduate student from ZheJiang University and had just
> submitted my proposal some of the harmony GSOC's project. I've been
> focusing on harmony from last year when firepure@gmail.com gave a speech
> on Apache Harmony at ZheJiang University ZJG campus.
>
> i'm familiar with java's mechanism, how a java program runs. Know the
> principle of java virtual machine. i'm also a active opensource
> programmer, and currently maintain a java project called MNADemo (at
> http://code.google.com/p/mnademo/ )
>
> I have submitted 3 projects on the GSOC's website.
>
> * harmony-class-selector
> In the Harmony's wiki page it saids.
>
> For many java desktop application, sometimes they will
> offer a JRE in the installation package, which may be
> big. And the project may also customize the jre to be
> smallest for the application, which cost much effort. We
> are looking for an automatic tool to find out all
> classes for the application and build up a smallest JRE
> for the customer. For many our developers, we have
> EasyMock to cheat coverage tools, such as Emma. The
> smallest jre can help us to find these cheats, make code
> more robust.
>
>
> This is a rather strange idea. Because, it will make application
> code more robust, but will not make harmony-class-selector
> robust. Which means, harmony-class-selector will force user to
> do nearly 100% testing. This is not always good. So on my own
>
harmony-class-selector will not force user to do nearly 100% testing, but
force developer to do the testing. Actually now every project will use unit
testing and code coverage to ensure their code robust, but as human beings,
we find lots of trick ways to cheat the result. Using harmony selector,
developer will be forced to test every code he write. Is it good or not?
> perspective, we need to provide 2 strategies.
>
> 1. collect the class dependency according to test generated
> class file.
> 2. collect the class dependency according to application
> jar.
>
> One is for user to recheck the their code coverage, another is
> for productivity use. But if we implement the second strategy,
> the information collection algorithm will be base on .class file
> parsing. There's no way for hacking a classloader when the jar
if the unit test do a really full tests on the application code, we can know
every class it use. So again, harmony-class-selector force developer to do
real full tests.
>
> file is not fully running. So there should be an alternative.
> ^_^
>
> * Harmony misc tools (harmony-tools-1 on the wiki page)
>
> Tools that be involved are jar, javaws, jconsole.
>
> For jar, it's not that hard. jar spec can be found at
> http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
>
> For javaws, it seems that it involves the JNLP stuff, and it
> shouldn't be too complicated. ^_^
>
> But for jconsole, sun's jconsole is just too rich featured T_T.
> I guess we can separate the jconsole into many other small
> tools, such as heap_mon, thread_mon, vm_info. And also, we may
> cast away the GUI interface, since harmony's swing/awt
> implementation is not mature. CLI interface for a monitor is
> convenient enough for a administrator.
>
> * i18n tool harmony/others
> The wiki page gave us a clear guideline of how to implement it
> clear enough ^_^.
> ( http://wiki.apache.org/harmony/Harmony_i18n_tool )
>
> So i only got some ideas on implementation:
> 1 i think the translation notation should be written in the
> code. Programmers should know that their strings in the code
> will be translated. Java5's annotation support can help us with
> this. Using a annotation within a class is better than a xml
> file to configure the extractor.
> 2 injector. how about do a hack on the classpath? when analyzer
> detect that the class will be translate, use javac to compile
> different a copy with different languages. then pack to
> different jar files. When project code is runnning, the injector
> will place the localized jar prior in the classpath.
>
> well, this is the first idea that comes into my mind, it might be
> impossible to complete, but i'm expecting your feedbacks. ^_^
>
> Thanks all, yours
> Mike
>
>
>
>
--
Yours sincerely,
Charles Lee
Re: [GSOC] Proposals from me
Posted by "Jimmy,Jing Lv" <fi...@gmail.com>.
Hi,
2009/3/30 Mike <mi...@gmail.com>
> So when shall we do our injection? compile time? Runtime seems to be
> difficult...
>
Indeed before the compilation - inject and modify into the source code. As
you know, the tool will be used by open source projects developers, help
them to automatically done the i18n.
>
> Hack on the String can be easily done under runtime. But the performance
> will slower on average, i mean without consider jar file replacement.
>
Yes, String seems too key to be hacked.
>
> Yours, Mike
>
> 在 2009-03-30一的 16:44 +0800，Jimmy,Jing Lv写道：
> > Hi,
> >
> > 2009/3/30 Mike <mi...@gmail.com>
> >
> > > 在 2009-03-30一的 15:47 +0800，Jimmy,Jing Lv写道：
> > >
> > > > Yes if the programmers does have sense to make their projects
> localizable
> > > > (like Apache Harmony) that'll be good, the only work left for the
> tool is
> > > to
> > > > translate and fulfill the property file, however many of them does
> not.
> > > The
> > > > project will help them to do that.
> > > > Yep, that's an alternative implementation, however this requires the
> > > > re-compilation thus is not flexible, and may have problems on
> > > deployment(jar
> > > > replacement is costly!). If we use a property/resource Bundle
> mechanism,
> > > no
> > > > compilation nor source code modification is need if we want to add
> one or
> > > > more languages.
> > > >
> > >
> > > well, it sounds that we needs to scan all the Strings in the source
> > > code?
> >
> >
> > Yes, possible, or at least one choice :)
> >
> >
> > >
> > >
> > > For property/resource implement, it's not easy let the program itself
> > > know. That is to say, you can't control it when displaying the String.
> > > You have to translate it out when the String is created, So if we want
> > > to all-in-one jar translation solution, we need a hack on the String
> > > class. Which i don't think is clean. ^_^
> >
> >
> > For the first thing, hack on the Harmony String is CLEAN, Apache Harmony
> has
> > fully implemented the JRE, jvm plus classlib :)
> > However, hack on the String is one of the choices. On the other hand, for
> an
> > example, we may have a line of:
> >
> > throw new RuntimeException("Love");
> >
> > and after our injection, this line will become something like
> >
> > throw new RuntimeException(Messagers.get("Love",thisLocal));
> >
> > where "Messagers.get("Love",thisLocal)" will return some translated words
> > for the local, e.g, "Amour" in the language of Franch, or "Liebe" in
> German
> > ;)
> > Further more, we may ignore some hard-to-analysis words/sentences but
> only
> > focus on the ones which are easy to apply the localization? :)
> >
> > All kinds of ideas on design is welcome at this period. Please tell me if
> > you have more questions :)
> >
> >
> > > But of course, if we implemented in that way, harmony's j2se class
> > > library implementation might be popular.^_^
> > >
> > > Thanks for you reply,
> > >
> > > Yours, Mike
> > >
> > >
> > >
> >
> >
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: [GSOC] Proposals from me
Posted by Mike <mi...@gmail.com>.
So when shall we do our injection? compile time? Runtime seems to be
difficult...
Hack on the String can be easily done under runtime. But the performance
will slower on average, i mean without consider jar file replacement.
Yours, Mike
在 2009-03-30一的 16:44 +0800，Jimmy,Jing Lv写道：
> Hi,
>
> 2009/3/30 Mike <mi...@gmail.com>
>
> > 在 2009-03-30一的 15:47 +0800，Jimmy,Jing Lv写道：
> >
> > > Yes if the programmers does have sense to make their projects localizable
> > > (like Apache Harmony) that'll be good, the only work left for the tool is
> > to
> > > translate and fulfill the property file, however many of them does not.
> > The
> > > project will help them to do that.
> > > Yep, that's an alternative implementation, however this requires the
> > > re-compilation thus is not flexible, and may have problems on
> > deployment(jar
> > > replacement is costly!). If we use a property/resource Bundle mechanism,
> > no
> > > compilation nor source code modification is need if we want to add one or
> > > more languages.
> > >
> >
> > well, it sounds that we needs to scan all the Strings in the source
> > code?
>
>
> Yes, possible, or at least one choice :)
>
>
> >
> >
> > For property/resource implement, it's not easy let the program itself
> > know. That is to say, you can't control it when displaying the String.
> > You have to translate it out when the String is created, So if we want
> > to all-in-one jar translation solution, we need a hack on the String
> > class. Which i don't think is clean. ^_^
>
>
> For the first thing, hack on the Harmony String is CLEAN, Apache Harmony has
> fully implemented the JRE, jvm plus classlib :)
> However, hack on the String is one of the choices. On the other hand, for an
> example, we may have a line of:
>
> throw new RuntimeException("Love");
>
> and after our injection, this line will become something like
>
> throw new RuntimeException(Messagers.get("Love",thisLocal));
>
> where "Messagers.get("Love",thisLocal)" will return some translated words
> for the local, e.g, "Amour" in the language of Franch, or "Liebe" in German
> ;)
> Further more, we may ignore some hard-to-analysis words/sentences but only
> focus on the ones which are easy to apply the localization? :)
>
> All kinds of ideas on design is welcome at this period. Please tell me if
> you have more questions :)
>
>
> > But of course, if we implemented in that way, harmony's j2se class
> > library implementation might be popular.^_^
> >
> > Thanks for you reply,
> >
> > Yours, Mike
> >
> >
> >
>
>
Re: [GSOC] Proposals from me
Posted by "Jimmy,Jing Lv" <fi...@gmail.com>.
Hi,
2009/3/30 Mike <mi...@gmail.com>
> 在 2009-03-30一的 15:47 +0800，Jimmy,Jing Lv写道：
>
> > Yes if the programmers does have sense to make their projects localizable
> > (like Apache Harmony) that'll be good, the only work left for the tool is
> to
> > translate and fulfill the property file, however many of them does not.
> The
> > project will help them to do that.
> > Yep, that's an alternative implementation, however this requires the
> > re-compilation thus is not flexible, and may have problems on
> deployment(jar
> > replacement is costly!). If we use a property/resource Bundle mechanism,
> no
> > compilation nor source code modification is need if we want to add one or
> > more languages.
> >
>
> well, it sounds that we needs to scan all the Strings in the source
> code?
Yes, possible, or at least one choice :)
>
>
> For property/resource implement, it's not easy let the program itself
> know. That is to say, you can't control it when displaying the String.
> You have to translate it out when the String is created, So if we want
> to all-in-one jar translation solution, we need a hack on the String
> class. Which i don't think is clean. ^_^
For the first thing, hack on the Harmony String is CLEAN, Apache Harmony has
fully implemented the JRE, jvm plus classlib :)
However, hack on the String is one of the choices. On the other hand, for an
example, we may have a line of:
throw new RuntimeException("Love");
and after our injection, this line will become something like
throw new RuntimeException(Messagers.get("Love",thisLocal));
where "Messagers.get("Love",thisLocal)" will return some translated words
for the local, e.g, "Amour" in the language of Franch, or "Liebe" in German
;)
Further more, we may ignore some hard-to-analysis words/sentences but only
focus on the ones which are easy to apply the localization? :)
All kinds of ideas on design is welcome at this period. Please tell me if
you have more questions :)
> But of course, if we implemented in that way, harmony's j2se class
> library implementation might be popular.^_^
>
> Thanks for you reply,
>
> Yours, Mike
>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: [GSOC] Proposals from me
Posted by Mike <mi...@gmail.com>.
在 2009-03-30一的 15:47 +0800，Jimmy,Jing Lv写道：
> Yes if the programmers does have sense to make their projects localizable
> (like Apache Harmony) that'll be good, the only work left for the tool is to
> translate and fulfill the property file, however many of them does not. The
> project will help them to do that.
> Yep, that's an alternative implementation, however this requires the
> re-compilation thus is not flexible, and may have problems on deployment(jar
> replacement is costly!). If we use a property/resource Bundle mechanism, no
> compilation nor source code modification is need if we want to add one or
> more languages.
>
well, it sounds that we needs to scan all the Strings in the source
code?
For property/resource implement, it's not easy let the program itself
know. That is to say, you can't control it when displaying the String.
You have to translate it out when the String is created, So if we want
to all-in-one jar translation solution, we need a hack on the String
class. Which i don't think is clean. ^_^
But of course, if we implemented in that way, harmony's j2se class
library implementation might be popular.^_^
Thanks for you reply,
Yours, Mike
Re: [GSOC] Proposals from me
Posted by "Jimmy,Jing Lv" <fi...@gmail.com>.
Hi Mike,
Welcome and sorry for late reply. :)
2009/3/29 Mike <mi...@gmail.com>
> Hi all,
>
> i'm a undergraduate student from ZheJiang University and had just
> submitted my proposal some of the harmony GSOC's project. I've been
> focusing on harmony from last year when firepure@gmail.com gave a speech
> on Apache Harmony at ZheJiang University ZJG campus.
>
:) Nice to hear that.
>
> i'm familiar with java's mechanism, how a java program runs. Know the
> principle of java virtual machine. i'm also a active opensource
> programmer, and currently maintain a java project called MNADemo (at
> http://code.google.com/p/mnademo/ )
>
> I have submitted 3 projects on the GSOC's website.
>
> * harmony-class-selector
> In the Harmony's wiki page it saids.
>
> For many java desktop application, sometimes they will
> offer a JRE in the installation package, which may be
> big. And the project may also customize the jre to be
> smallest for the application, which cost much effort. We
> are looking for an automatic tool to find out all
> classes for the application and build up a smallest JRE
> for the customer. For many our developers, we have
> EasyMock to cheat coverage tools, such as Emma. The
> smallest jre can help us to find these cheats, make code
> more robust.
>
>
> This is a rather strange idea. Because, it will make application
> code more robust, but will not make harmony-class-selector
> robust. Which means, harmony-class-selector will force user to
> do nearly 100% testing. This is not always good. So on my own
> perspective, we need to provide 2 strategies.
>
> 1. collect the class dependency according to test generated
> class file.
> 2. collect the class dependency according to application
> jar.
>
Yep, that's a good idea. The projects welcome all ideas from students.
>
> One is for user to recheck the their code coverage, another is
> for productivity use. But if we implement the second strategy,
> the information collection algorithm will be base on .class file
> parsing. There's no way for hacking a classloader when the jar
> file is not fully running. So there should be an alternative.
> ^_^
>
> * Harmony misc tools (harmony-tools-1 on the wiki page)
>
> Tools that be involved are jar, javaws, jconsole.
>
> For jar, it's not that hard. jar spec can be found at
> http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
>
> For javaws, it seems that it involves the JNLP stuff, and it
> shouldn't be too complicated. ^_^
>
> But for jconsole, sun's jconsole is just too rich featured T_T.
> I guess we can separate the jconsole into many other small
> tools, such as heap_mon, thread_mon, vm_info. And also, we may
> cast away the GUI interface, since harmony's swing/awt
> implementation is not mature. CLI interface for a monitor is
> convenient enough for a administrator.
>
I will leave Oliver and Mark to discuss with you ;)
>
> * i18n tool harmony/others
> The wiki page gave us a clear guideline of how to implement it
> clear enough ^_^.
> ( http://wiki.apache.org/harmony/Harmony_i18n_tool )
>
> So i only got some ideas on implementation:
> 1 i think the translation notation should be written in the
> code. Programmers should know that their strings in the code
> will be translated. Java5's annotation support can help us with
> this. Using a annotation within a class is better than a xml
> file to configure the extractor.
> 2 injector. how about do a hack on the classpath? when analyzer
> detect that the class will be translate, use javac to compile
> different a copy with different languages. then pack to
> different jar files. When project code is runnning, the injector
> will place the localized jar prior in the classpath.
>
Yes if the programmers does have sense to make their projects localizable
(like Apache Harmony) that'll be good, the only work left for the tool is to
translate and fulfill the property file, however many of them does not. The
project will help them to do that.
Yep, that's an alternative implementation, however this requires the
re-compilation thus is not flexible, and may have problems on deployment(jar
replacement is costly!). If we use a property/resource Bundle mechanism, no
compilation nor source code modification is need if we want to add one or
more languages.
>
> well, this is the first idea that comes into my mind, it might be
> impossible to complete, but i'm expecting your feedbacks. ^_^
>
Your ideas are cool, Mike. Please enrich your proposals to the GSoC, it is
very key to the GSoC review and final decision on choosing the students.
Please tell me if you have more questoins.
Good Luck ;)
>
> Thanks all, yours
> Mike
>
>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM