harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoli...@apache.org
Subject Re: [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model
Date Fri, 30 Sep 2005 12:41:20 GMT
Oh gosh, it is way too early to reject things for such reasons.  Instead 
of being a roadblock, contribute patches.  That is the affirmative thing 
to do rather than starting out with the hammer.  It is really hard to 
start a project in the fashion of harmony (w/o initial codebase) because 
so many initial decisions in any project must favor "the least thing 
that could possibly work" -- beyond this you take into concern "other 

For instance, I'm quite interested in a VM that sucks less than IBM's 
for the AIX P5 platform, but I'm not going to "-1 this won't work on 
AIX".  I guarantee no code submitted will be perfect and some won't even 
be immediately portable especially in the early stages.  PLLLLEEEAAASE 
take an affirmative view rather than a "code by committee" negative view.


David Tanzer wrote:
> On Fri, 2005-09-30 at 02:58 -0400, Geir Magnusson Jr. wrote:
>>On Sep 30, 2005, at 2:51 AM, Mladen Turk wrote:
>>>Geir Magnusson Jr. wrote:
>>>>David Tanzer has offered his proof-of-concept component model to  
>>>>the  project.  It can be found here :
>>>>[ ] +1 Accept the code into the project
>>>>[X] -1 Don't accept the code.  Reason :
>>>The code itself is posix only.
>>It's a proof of concept for the sandbox!  This isn't a commitment to  
>>the idea or the implementation, but just getting it in so people can  
> Right, that's what my intention was, nothing more.
>>>If we continue this way, porting to the other platforms will
>>>become impossible.
>>>Even the simple posix itself is incompatible between various
>>>flavors. For example on AIX there is 'archive.a(dso.so)' and
>>>dlopen needs 'RTLD_NOW | RTLD_GLOBAL | RTDL_MEMBER' flags.
>>>Some platforms like HPUX use the shl_load, not to mention the
>>>Windows or Netware.
>>>The actual code itself exists, and is very much mature within
>>>Apache2, and module dependencies are implemented within apr-iconv
>>>project, so perhaps this would be a way to go.
>>APR?  I think that we'll leverage APR heavily.  Whether or not the  
>>APR API is the one we use as the standard porting layer API remains  
>>to be seen. If not, I'm certain will used it for platform  
>>implementations of the porting layer...
> There are several places in the code where I've added comments about
> things that have to be changed if we really use this component model.
> Note that there are also serious concerns about performance in a
> runtime-configurable component model and Robin Garner suggested to aim
> for compile time configurability (See [1]). APR would definitely be a
> better choice than posix, but AFAICS the decision about what our 
> portability layer will be has not been made yet.
>>>Also, what about coding style guide?
>>That's a good question, and something I assume we'll converge around  
>>as we get moving.
> I totally agree with that. I discussed earlier with Weldon Washburn 
> and Geir about using the Java Coding Conventions where possible (See 
> [2] and follow-ups), but this still doesn't cover things like directory
> structure, some aspects of documentation policy, etc., and there was no
> decision yet.
> Regards, 
> David.
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c43326A25.40409@anu.edu.au%3e
> [2]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/%3c4dd1f3f0050827071543279cac@mail.gmail.com%3e

Andrew C. Oliver
SuperLink Software, Inc.

Java to Excel using POI
Commercial support including features added/implemented, bugs fixed.

View raw message