-----Original Message-----
>From: George Harley1 <[EMAIL PROTECTED]>
>Sent: Jan 4, 2006 5:45 AM
>To: harmony-dev <harmony-dev@incubator.apache.org>
>Subject: Re: repo layout again
>
>Hi Dan,
>
>By "the java.lang.*/java.io.*/etc. classes that have key native methods
>tied to the VM" you mean the set of classes labelled as "kernel classes"
>in HARMONY-14. The existing documentation for these classes (see
>http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses)
>
>states that "the VM writer is expected to entirely implement" these
>classes which suggests that your proposal to break these out independent
>of the class libraries is the way to go.
>
I think we are on the same page here.
>With the implementation of the kernel classes completely under the control
>of the VM writer it is then an internal design decision whether or not to
>realise a given method as a native or as pure Java. So long as these
>kernel classes adhere to the expected interface from the perspective of
>the classlib then there is no real issue. Meanwhile a dummy/stub
>implementation of the kernel classes would still be required in the
>classlib source tree simply to enable compilation to complete.
>
Maybe I am missing something, but why should the Java compiler care
about whether or not something is native or not? That is, why should I
care about a stub implementation? I can't connect this to my real
implementation because it would not get routed to JNI at runtime.
(Or am I still missing something?)
I guess that where I am going is that I would like to see a way to have
the 'native' declaration in the methods that need it, but what I hear you
saying is that this choice is up to me as a VM designer. Is this correct?
If so, then this "kernel" portion of the class library needs to be specific
to the VM. Right?
Thanks,
Dan Lydick
>Does that sound reasonable ?
>
>Best regards,
>George
>________________________________________
>George C. Harley
>
>
>
>
>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>04/01/2006 00:02
>Please respond to
>harmony-dev@incubator.apache.org
>
>
>To
>harmony-dev <harmony-dev@incubator.apache.org>
>cc
>
>Subject
>Re: repo layout again
>
>
>
>
>
>
>
>
>Some more platform tree names:
>
> solaris32.sparc solaris64.sparc
> linux32.sparc linux64.sparc
> darwin32.ppc (Is this correct for the new MAC boxes?)
>
>
>One of the things that has never come up in this discussion
>has been the possible breakout of the java.lang.*/java.io.*/etc.
>classes that have key native methods tied to the VM. These
>are currently set to 'method(int p1, char p2) { return(dummy_value); }'
>in the initial contribution, but will need to be converted to
>become 'native method (int p1, char p2);' in any real
>implementation. I would propose to break these out in some
>meaningful way to be independent of the rest of the class
>library, or possibly independent but absorbed into the class
>library, where the actual native code implementation is _not_
>provided there, but is found in the VM code where it naturally
>belongs. What to you think? What other suggestions do you
>have?
>
>
>Dan Lydick
>
>-----Original Message-----
>>From: George Harley1 <[EMAIL PROTECTED]>
>>Sent: Jan 3, 2006 4:57 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: Re: repo layout again
>>
>>Hi,
>>
>>How does this sound for the layout of a given module/component/thing (in
>>this case "luni") ...
>>
>>classlib/trunk
>> |
>> +--java-src
>> |
>> +--luni
>> |
>> |
>> +---src
>> | |
>> | +--main
>> | | |
>> | | +--<platform>
>> | | |
>> | | +--native
>> | | |
>> | | +--java
>> | | |
>> | | +--resources
>> | |
>> | +--test
>> | |
>> | +--java
>> | |
>> | +--resources
>> |
>> |
>> +--doc
>>
>>
>>
>>where the value of <platform> comes from the set of agreed identifiers
>for
>>all operating systems we build/run on that have platform-specific code
>>together with the "common" identifier for all platform-neutral code.
>There
>>would be multiple <platform> subdirectories under the "main" folder like
>>this ...
>>
>>
>> +---src
>> | |
>> | +--main
>> | | |
>> | | +--common
>> | | | |
>> | | | +--native
>> | | | |
>> | | | +--java
>> | | | |
>> | | | +--resources
>> |
>> |
>> +--win32.x86
>> | |
>> | +--native
>> | |
>> | +--java
>> | |
>> | +--resources
>> |
>> |
>> +--linux32.x86
>> | |
>> | +--native
>> | |
>> | +--java
>> | |
>> | +--resources
>> |
>> ...etc...
>>
>>
>>
>>I'm keeping my fingers crossed that my mail client doesn't completely
>mess
>>up the above formatting.
>>
>>Best regards,
>>George
>>________________________________________
>>George C. Harley
>>
>>
>>
>>
>>
>>Geir Magnusson Jr <[EMAIL PROTECTED]>
>>30/12/2005 16:34
>>Please respond to
>>harmony-dev@incubator.apache.org
>>
>>
>>To
>>harmony-dev@incubator.apache.org
>>cc
>>
>>Subject
>>Re: repo layout again
>>
>>
>>
>>
>>
>>
>>
>>
>>Tim Ellison wrote:
>>> Geir Magnusson Jr wrote:
>>>
>>>>does this follow from the convo re layout we had last week?
>>>
>>>
>>> yes, plus me trying to follow along with an Eclipse set-up to do
>>> development.
>>
>>Ah - that's key for you. Please help us Eclipse journeymen when you get
>>it figured out...
>>
>>>
>>>
>>>>We'd
>>>>prollie want to rename java-src to something else being it's more like
>a
>>>>module than just java...
>>>
>>>
>>> Well today it _is_ just java (and a bit of metadata) in there, but I
>>> agree that thoughts of making them a bit more than that is goodness.
>>>
>>
>>I thought we'd given some serious thought and had some kind of agreement
>>that it's worth putting the natives for a given module in that module (I
>>won't use the term 'component' there)
>>
>>That would mean :
>>
>>modules/
>> luni/
>> java-src/
>> ... your tree for luni java
>> native-src/
>> ... your tree for luni natives
>>
>>
>>geir
>>
>>> Regards,
>>> Tim
>>>
>>>
>>>>Tim Ellison wrote:
>>>>
>>>>
>>>>>beats me :-)
>>>>>
>>>>>I was following along with the Maven standard directory structure [1]
>>as
>>>>>much as possible, since we might as well do that rather than invent
>>>>>something gratuitously different. (I know nothing about maven, and
>I'm
>>>>>open to changing the structure to suit the majority.)
>>>>>
>>>>>This is where I was heading:
>>>>>
>>>>>.../classlib/trunk/
>>>>> java-src/ <- poor name, easily changed later
>>>>> <component_name>/
>>>>> make/ <- component-level build script
>>>>> src/
>>>>> main/
>>>>> java/
>>>>> org/apache/harmony/... <- impl types
>>>>> java/<whatever>/... <- Java API types
>>>>> resources/
>>>>> test/
>>>>> java/
>>>>> org/apache/harmony/... <- unit tests
>>>>> resources/
>>>>> META-INF/MANIFEST.MF <- OSGi manifest
>>>>> <component_name_2>/
>>>>> ...
>>>>> make/ <- 'bootstrap'/global build script
>>>>> target/ <- results of builds
>>>>>
>>>>> native-src/ <- I'm going to leave the natives structure
>>>>> alone for the moment
>>>>>
>>>>>I guess the main omission at the moment is a location for
>>>>>platform-specific code, I didn't see anything on the maven site about
>>>>>that.
>>>>>
>>>>>[1]
>>>>>http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>>>
>>>>>
>>>>>Regards,
>>>>>Tim
>>>>>
>>>>>Geir Magnusson Jr. wrote:
>>>>>
>>>>>
>>>>>>what does "main" mean?
>>>>>>
>>>>>>
>>>>>>On Dec 29, 2005, at 8:31 AM, [EMAIL PROTECTED] wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Author: tellison
>>>>>>>Date: Thu Dec 29 05:31:44 2005
>>>>>>>New Revision: 359782
>>>>>>>
>>>>>>>URL: http://svn.apache.org/viewcvs?rev=359782&view=rev
>>>>>>>Log:
>>>>>>>Restructuring NIO component layout to allow main and test
>co-location
>>>>>>>
>>>>>>>Added:
>>>>>>> incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/main/
>>>>>>> incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/test/
>>>>>>> incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/test/
>>>>>>>java/
>>>>>>> incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/test/
>>>>>>>resources/
>>>>>>>Removed:
>>>>>>> incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/com/
>>>>>>> incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/java/
>>>>>>>
>>>>>>
>>>
>>
>>
>
>
>
Dan Lydick
