Tim Ellison wrote: > Geir Magnusson Jr wrote: >> Tim Ellison wrote: >>> Nathan Beyer wrote: >>>> I've checked in my proposal for the java.util.concurrent module at >>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/s >>>> andbox/juc-proposal. >>> You didn't just check in a proposal, you also checked in >>> Doug Lea et al's code. Nobody should commit other people's code into >>> svn this way. >> The code is under public domain license, so there should be no problem >> doing it since Doug et al produce no builds, and they suggested we do >> this. > > (not trying to be provocative, just trying to understand) > > "they" = the concurrency authors? > "do this" = produce builds or check the code into our repository? > >> it's also in our sandbox, and we're not redistributing it yet. >> >>> Was there a reason to create .../classlib/trunk/sandbox? wouldn't >>> .../classlib/sandbox make more sense? >> We already had the sandbox under /trunk > > No we didn't. > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/sandbox/?view=log&pathrev=421111 > > Perhaps it was created in the trunk by mistake.
Oh, right. Sorry - there was a sandbox in enhanced/trunk which is what I thought it was checked into... [SNIP] >>> I see copying the code as a one-way operation. We can hope to track >>> updates to the original code thoroughly, but I don't see any fixes made >>> in Harmony making it back directly into Doug's repository. >> Why not? We just offer them to Doug, and he can accept or reject. > > It strikes me as a strange model. If there is a well-run, active > project with compatible license elsewhere I'm struggling to see why we > would not just join in there, and all enjoy the fruits of the combined > work <g>. Maybe this was discussed as part of the suggestion from Doug? Doug just suggested that we'd be well served using his code since it's public domain and the definitive implementation. If there is a well-run, active project with compatible license elsewhere, please point it out. As far as I know, this is the only implementation out there, and is why it's taken and used by IBM, BEA, Apple and Sun in the same way we're proposing. Why not just "enjoy the fruits" of what's being offered as public domain by arguably the world's top expert on the subject? While we have lots of talent around here, I'd be very surprised if we could do better. > >>> Is there a reason why we want to fork this code? I'd rather we worked >>> with Doug (contributing directly to his project to make it more widely >>> usable etc). >> Tim, isn't this what we discussed? This isn't a fork in the community >> sense, it's what amounts to a "read only" copy of the code for purposes >> of building, but tracking what Doug does? We've been very clear about that. > > Do you think it is reasonable to work with that group to make the code > usable by Harmony as well as Sun? > Yes, of course, although it seems usable now... > I guess the alternative is that we replicate Sun's internal APIs if we > want to make the incoming code read-only (and presumably put it into the > depends/ directory). I don't understand the bit about the depends directory, but yes, I think that using this code as-is would require us to implement sun.misc.Unsafe, and I do think it's a reasonable thing to suggest to Doug that a neutral package is chosen for this.... like "org.apache.harmony.Unsafe" :) > >>>> org.apache.harmony.concurrent.AtomicSupport [1] - The service interface for >>>> 'java.util.concurrent.atomic' features such as CAS (compare and swap) and >>>> volatile read/writes. >>> These look like the right set of operations (without having gone through >>> the list exhaustively). >>> >>> It would be good to move the AtomicSupport type into o.a.h.luni.platform >>> so they can be used by other code (thinking reflect/objectIO etc.) >>> without having to depend on all the concurrent utils. >>> >>>> org.apache.harmony.concurrent.LocksSupport [2] - The service interface for >>>> 'java.util.concurrent.locks' support. This is similar to the >>>> java.util.concurrent.locks.LockSupport contract. >>> These are thread operations, perhaps just a misnomer. In LockSupport we >>> need MonitorEnter and MonitorExit etc. >>> >>> <sidebar> would be good to round out the set with a type to >>> invokeVirtual and friends too </sidebar> > > Note to self: I see that they already exist in ObjectAccessor, hurray! > > Just not where I would have expected to see them. > >>>> These service interfaces would need to be implemented by a VM provider and >>>> their implementations are registered using Service Provider configuration >>>> files, as defined by the JAR specification [3]. The rationale for the >>>> design >>>> of the support classes was to preserve as much of the original code as >>>> possible, >>> Do you mean by implementing the internal APIs that the concurrency code >>> has on Sun's implementation? >>> >>>> so as to facilitate future maintenance and isolate the external >>>> variability with well-defined service contracts. >>> This SPI is a runtime framework, right? Do you really think that people >>> will leave it until runtime to determine which provider they have for >>> these methods? I doubt it -- they are so closely tied to the VM that >>> they will not be pluggable at runtime. The VM/JIT will have to >>> recognize these as special methods to make it anything like usable. >> I agree - it doesn't seem right to use the SPI for this, but I haven't >> looked at the code. >> >>>> If you wan to see what source code changed, then extract the >>>> 'concurrent.tar.gz' and compare the 'concurrent' folder from there to the >>>> 'concurrent/src/main/java/java/util/concurrent' folder. >>> hmm, thanks. >>> >>>> TODOs - >>>> >>>> * Implement the service interfaces by a VM!! >>>> >>>> * Setup the build scripts (trivial) - currently there's a 'pom.xml' that's >>>> in the project, which can be used with Maven to run a build and generate >>>> documentation (mvn package site). It was just quicker for me to do this >>>> while I as hacking. >>>> >>>> * Consider and possible implement base/default service providers for win32 >>>> and linux that VMs can use if they like. >>>> >>>> * Determine the best place to integrate the TCK source, which is also >>>> available at Doug Lea's site. >>> Are you serious? Why would we copy the TCK into Harmony too?! >> Because that isn't the TCK, but simply testcases? > > I haven't checked, I took Nathan at his word. They are labeled as TCK tests, but by definition, the TCK only comes from the Spec lead. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ So from our POV, while this is code that is used in the TCK, it's not the TCK, and if we accept the public domain terms, we should be free to use them to augment our test suite. > >>>> * There are a LOT of changes, fixes and enhancements to the code at Doug >>>> Lea's site; consider what code we should additional take. >>> As I said above, I'd rather we work with Doug directly. I don't >>> understand why we have to 'take ownership' of this code. >> You keep saying that, but I keep trying to tell you that this *is* >> working with Doug directly. He's fine with this approach. We're not >> *forking* the code - we're just getting a copy for convenience, with the >> intent of working with Doug, offering changes back, and tracking what >> his tagged versions are. > > Sounds like we understand each other then <g>. > > I thought we were trying to reach a conclusion which is why I was > surprised to see the code appear. We are still trying to reach a conclusion, actually two of them - the techincal conclusion, and the process/legal one. I think having the code around to stare at will make the technical conclusion easier (and my first comment is that we shouldn't be modifying Doug' stuff, even just to change package name of atomic support). At the same time, we can resolve the legal/process issues... geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
