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