harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: Google Summer of Code 2009
Date Wed, 18 Mar 2009 15:11:07 GMT
Hi Alexei,

     Thanks for suggests and comments! Your question are very helpful
to me to think more and understand the deeper requirements.

     Yes I see the other proposals have some spec already, I'll start
to write down the spec and design. As that wiki page is only for
proposal, I'll open new pages(will add link on the proposal page).
     Please correct me if I make more mistakes, thanks a lot!

2009/3/18 Alexei Fedotov <alexei.fedotov@gmail.com>:
> Jimmy,
>
> As for your questions, I have a strong belief that a mentor should
> have 90% of a proper GSoC project design before suggesting the project
> to students even if students are supposed to design the whole project.
> I think there is still place for analysis and thinking about your
> projects .
>
> Good luck.
>
>
> 2009/3/18 Jimmy,Jing Lv <firepure@gmail.com>:
>> Hi Alexier,
>>
>>     Let me explain a little more. Basically, the motivation comes
>> from the requirement of the Apache Harmony Projects.
>>
>> 1. the requirement of the localized messages
>>    Indeed we are lack of them, and we need them for customer use.
>> However we see there's no resource, no translation team for Harmony
>> Project to do this. And of course for GSoC, it is impossible for it to
>> support a project simply translate the message. But an automatic tool
>> sounds reasonable.
>>    Technically, yes we have eclipse or some other tools to extract
>> the String, but I don't see there's a full tool, automatically extract
>> the messages, analysis if necessary to translate, translate and
>> adjust, and at last inject into the source code with ResourceBundle or
>> property loading mechanism and apply the localization.
>>    This, I believe, is a Win-Win project, help the Harmony project to
>> be localized, as well as help student to train their skill, thus
>> sounds acceptable for GSoC. If some other project will use it, that'll
>> be a plus.
>>
>> 2. the new feature of Apache Harmony project
>> a. the requirement of the smallest jre,
>>     Yes I see FreeCiv - an amazing project. However as we see, not
>> all project get to know if the jre can be customized, and not all
>> customer know how to customize the jre. It may be an amazing tool for
>> Harmony than Sun, help the customers to make up his smallest jre
>> according his own project, which help them to make their program
>> download size to be smallest. Do you think it'll be a nice feature for
>> Harmony to our customers?
>>
>> b. the OSGi/updater
>>     OSGi is hot and Apache Harmony has already make its modules
>> bundle. I've heard of many java developers believe if the jdk can
>> adopt OSGi is helpful. It will help some project to be OSGi without
>> apply OSGi module on their projects. And what's more, yes I've got a
>> little investigation on this topic as well, it seems Apache Felix can
>> be applied on Harmony with a few lines changed and a few new methods
>> enhanced on vm, and then start well, And eclipse Equinox looks
>> adaptable as well. If we can go a little further, it may make the
>> Harmony Project to be the first OSGi-ed JDK on the world - cool and
>> attractive to the potential customers, isn't it? If so we can apply a
>> update mechanism for Harmony easily.
>>
>>     Yes I see the new features are beyond the Spec, I think it's OK
>> if we want to excel Sun's implementation and attract more customers.
>> Do you think the motivation is acceptable? Is there any technical
>> fault on these topics?
>>
>> 2009/3/18 Alexei Fedotov <alexei.fedotov@gmail.com>:
>>> Hello Jimmy,
>>> Being brief, I lack your motivation, not technical details.
>>>
>>> 1. I extracted minimal class sets using standard logging to enable
>>> different applications on Harmony more than once. For example, this
>>> was done for initial analysis of FreeCiv GSoC project. Why one would
>>> need a tool?
>>>
>>> 2. Eclipse and many other tools have automatic string extractors for
>>> further localization. I believe you cannot miss all these
>>> //$NON-NLS-1$ comments in the code. Your proposal lacks explanation
>>> why other open source tools do not fit.
>>>
>>> 3. I think that before one develops a Harmony updater, a research is
>>> to be conducted why existing updaters cannot be adopted. Yes, I truly
>>> believe that an updater is a separate project unless it complies with
>>> web start specification or OSGi updater specification. For OSGi, one
>>> should research if OSGi code can be simply adopted instead of
>>> rewritten.
>>>
>>> 4. I expect some words about isolation and OPEN component management
>>> as a motivation for multi-vm. IMHO, this task, if done correctly, is
>>> impossible for a student.
>>>
>>> Thanks!
>>>
>>>
>>> 2009/3/18 Jimmy,Jing Lv <firepure@gmail.com>:
>>>> Hi,
>>>>
>>>>     Thanks Alexei for your suggestion! Sorry maybe I make the
>>>> abstract on the wiki too short to be understandable, I will enrich the
>>>> information of the project motivation.
>>>>
>>>>     The translation tools as I mentioned there, was not focus on the
>>>> translation(as we know there's so many translation tools) but the
>>>> automatic fetching/injecting mechanism of the open source project
>>>> localizable messages. The first motivation was that we Harmony Project
>>>> lack those messages compared to Sun's implementation thus was not
>>>> friendly to our users. However think deeper we see many open source
>>>> projects suffer the similar problem. So the tools was planned to
>>>> automatically help Harmony the message with this tool, what's more,
>>>> may help some other open source project, especially java projects. So
>>>> I believe this is still closely related to Harmony and is a
>>>> requirement of the project(not sure if it should be titled with
>>>> "Harmony-tool-5"?)
>>>>
>>>>     The other projects are similar, comes from the requirement of
>>>> harmony project and customers requirements. Currently the Harmony
>>>> project lack a automatic updater, NSIS offer only windows installation
>>>> tool. The basic idea was simple, create a version checker/updater for
>>>> Harmony. The smallest classes selector focus on customized-harmony-jre
>>>> which may be friendly to customer usage, to find the classes with
>>>> -verbose was easy(but still may not be enough, as we don't really know
>>>> if the current set cover all classes, maybe some classes will be only
>>>> load at some special case), but the problem we want to solve is the
>>>> automatic select/build/test/packet for customer application with a
>>>> full but smallest JRE, which may be valuable to customer (e.g, eclipse
>>>> does not need to customize our jre with much effort).
>>>>
>>>>     I don't think they can be called as "new open source project",
>>>> just some tool set for harmony. What do you think?
>>>>
>>>>     There's another thought, we may enable Apache Harmony JDK with
>>>> OSGi feature. Yes it was beyond the spec, however it seems valuable if
>>>> we find out a light way, at least we see Harmony modules are already
>>>> bundled.
>>>>
>>>> 2009/3/17 Alexei Fedotov <alexei.fedotov@gmail.com>:
>>>>> I like GSoC tasks from Sean and Andrew.
>>>>>
>>>>> Jimmy,
>>>>> Can you provide a sort of analysis of your tasks? Are there any open
>>>>> source automatic translation tools? How a web updater relates to NSIS
>>>>> and Java WebStart? Is there any relation between your multi-vm and
>>>>> isolation API? What is in a smallest class set except -verbose:class?
>>>>> Please, provide more motivation.
>>>>>
>>>>> As one of Apache gurus said, "You want start a new open source project?
Don't."
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On Tue, Mar 17, 2009 at 2:44 PM, Jimmy,Jing Lv <firepure@gmail.com>
wrote:
>>>>>> Hi,
>>>>>>
>>>>>>    I've added 4 proposal there. Looking for discussions/suggestions/comments
:)
>>>>>>
>>>>>> 2009/3/16 Sian January <sianjanuary@googlemail.com>:
>>>>>>> Just wanted to encourage people to write their ideas up on the
Wiki -
>>>>>>> only Oliver has done it so far and there is a deadline.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Sian
>>>>>>>
>>>>>>>
>>>>>>> 2009/3/12 Andrew Cornwall <andrew.pack200@gmail.com>:
>>>>>>>> Is there any desire to extend VMTT?
>>>>>>>>
>>>>>>>>  - add a real assembly format (jsr :label or something like
that, instead of
>>>>>>>> jsr -11.) (Does jasm do this, and if so could we use their
format?)
>>>>>>>>  - add flexibility for bad classes
>>>>>>>>    - specifying the padding for tableswitch/lookupswitch
>>>>>>>>    - allow double/long constantpool entries without subsequent
constant
>>>>>>>> pool entry
>>>>>>>>    - mixed asm and bin in methods
>>>>>>>>    - allow insertion of binary data at other places (eg
constant pool)
>>>>>>>>  - fix bugs
>>>>>>>>
>>>>>>>> Just some thoughts...
>>>>>>>>
>>>>>>>>    Andrew Jr.
>>>>>>>>
>>>>>>>> On Wed, Mar 4, 2009 at 5:03 PM, Xiao-Feng Li <xiaofeng.li@gmail.com>
wrote:
>>>>>>>>
>>>>>>>>> On Wed, Mar 4, 2009 at 10:43 PM, Egor Pasko <egor.pasko@gmail.com>
wrote:
>>>>>>>>> > On the 0x56A day of Apache Harmony Xiao-Feng Li
wrote:
>>>>>>>>> >> On Wed, Mar 4, 2009 at 6:46 PM, Egor Pasko <egor.pasko@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >>> On the 0x56A day of Apache Harmony Xiao-Feng
Li wrote:
>>>>>>>>> >>>> This is interesting. Project ideas related
to this include:
>>>>>>>>> >>>>
>>>>>>>>> >>>> 1. Make Apache Harmony support Google
Android applications. (Android
>>>>>>>>> >>>> on Harmony should be much faster with
the much more powerful JIT and
>>>>>>>>> >>>> GC).
>>>>>>>>> >>>
>>>>>>>>> >>> Do you mean replacing Dalvik on top of the
Android stack or making a
>>>>>>>>> >>> system that works on a common desktop?
>>>>>>>>> >>
>>>>>>>>> >> Something like that... :)  At the moment I
prefer the second approach:
>>>>>>>>> >> to make Harmony ready for Android applications
on desktop. The first
>>>>>>>>> >> approach probably should be a project of Google
Android.
>>>>>>>>> >
>>>>>>>>> > sounds like a nice idea :) though I cannot imagine
how much work is
>>>>>>>>> > required to make this happen..
>>>>>>>>>
>>>>>>>>> Yes, there are lots of work in it. Well only when somebody
really
>>>>>>>>> starts thinking about it,  can we gradually get some
good solution. To
>>>>>>>>> replace Dalvik with Harmony in Android stack might be
easier. In any
>>>>>>>>> case, it requires to run Android on top of a desktop
OS, with full
>>>>>>>>> libc and utils, because that's Harmony needs. That's
why I have the
>>>>>>>>> second project idea, to reduce Harmony into a very concise
version
>>>>>>>>> that requires only minimum OS supports, as minimum as
Android
>>>>>>>>> requires. :)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> xiaofeng
>>>>>>>>>
>>>>>>>>> > --
>>>>>>>>> > Egor Pasko
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Managed Runtime Technology Center, Intel
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Unless stated otherwise above:
>>>>>>> IBM United Kingdom Limited - Registered in England and Wales
with number 741598.
>>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Best Regards!
>>>>>>
>>>>>> Jimmy, Jing Lv
>>>>>> China Software Development Lab, IBM
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> С уважением,
>>>>> Алексей Федотов,
>>>>> http://people.apache.org/~aaf/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best Regards!
>>>>
>>>> Jimmy, Jing Lv
>>>> China Software Development Lab, IBM
>>>>
>>>
>>>
>>>
>>> --
>>> С уважением,
>>> Алексей Федотов,
>>> http://people.apache.org/~aaf/
>>>
>>
>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>
>
>
> --
> С уважением,
> Алексей Федотов,
> http://people.apache.org/~aaf/
>



-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Mime
View raw message