harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bootjvm@earthlink.net" <boot...@earthlink.net>
Subject Re: repo layout again
Date Wed, 04 Jan 2006 20:22:30 GMT


-----Original Message-----
>From: George Harley1 <GHARLEY@uk.ibm.com>
>Sent: Jan 4, 2006 12:30 PM
>To: harmony-dev <harmony-dev@incubator.apache.org>
>Subject: Re: repo layout again
>
>Hi Dan,
>
>>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?)
>
>Apologies, I think I should have made myself clearer. You are correct that 
>you (in your role as a VM provider) would not care about the stub 
>implementations. These stubs would be required in the classlib source tree 
>(not in the VM provider's source tree) to enable the Java compilation of 
>the classlib code to succeed. That is, the stub versions of these kernel 
>classes are present simply as a compile-time aid to the development of the 
>classlib code. At runtime the built classlib classes would need the "real" 
>implementation of these kernel types which would be supplied by the VM 
>provider. 
>
>
>> 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?
>
>Yes, correct. AFAIK if a VM designer makes one or more of the kernel API 
>methods native then that will not break the API for the classlib at 
>runtime even though that classlib will have been built against the stub 
>implementation of the kernel classes in which the API method(s) were not 
>declared to be native. Or, in other words, changing a method 
>implementation from non-native to native preserves binary compatibility 
>with client code. 
>
>> If so, then this "kernel" portion of the class library needs to be 
>specific
>> to the VM.  Right?
>
>Absolutely right. The *real* "kernel" portion of the class library is 
>developed and shipped with a VM. The *stub* version of the "kernel" 
>classes are just a development aid for classlib developers. 
>
>Sound reasonable ?
>

Works for me.


Dan Lydick


>Best regards,
>George
>________________________________________
>George C. Harley
>
>
>
>
>
>"bootjvm@earthlink.net" <bootjvm@earthlink.net> 
>04/01/2006 17:22
>Please respond to
>harmony-dev@incubator.apache.org
>
>
>To
>harmony-dev <harmony-dev@incubator.apache.org>
>cc
>Dan Lydick <dlydick@earthlink.net>
>Subject
>Re: repo layout again
>
>
>
>
>
>
>
>
>-----Original Message-----
>>From: George Harley1 <GHARLEY@uk.ibm.com>
>>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
>>
>>
>>
>>
>>"bootjvm@earthlink.net" <bootjvm@earthlink.net> 
>>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 <GHARLEY@uk.ibm.com>
>>>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 <geir@pobox.com> 
>>>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, tellison@apache.org 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
>
>




Dan Lydick

Mime
View raw message