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 17:22:02 GMT


-----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