harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley1 <GHAR...@uk.ibm.com>
Subject Re: repo layout again
Date Wed, 04 Jan 2006 18:30:23 GMT
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 ?

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



Mime
View raw message