-----Original Message----- >From: George Harley1 <[EMAIL PROTECTED]> >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 > > > > > >"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> >04/01/2006 17:22 >Please respond to >harmony-dev@incubator.apache.org > > >To >harmony-dev <harmony-dev@incubator.apache.org> >cc >Dan Lydick <[EMAIL PROTECTED]> >Subject >Re: repo layout again > > > > > > > > >-----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 > > Dan Lydick
