On May 16, 2014, at 8:33 PM, Phil Race <philip.r...@oracle.com> wrote: > On 5/16/2014 5:13 AM, Paul Sandoz wrote: >> On May 14, 2014, at 11:05 AM, Alan Bateman <alan.bate...@oracle.com> wrote: >>>> : >>>> >>>> This code is under src/share/classes, so it's not clear to me what classes >>>> i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is >>>> there a list online somewhere? >>>> >>>> Out of all the classes here: >>>> >>>> >>>> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ >>>> >>>> exactly which ones should be pushed to the client forest and which ones to >>>> the jdk9-dev forest? all of them, or just a sub-set? > All of the classes in that webrev are client (awt/swing/2d) so should go to > client. > > > BTW I am behind on email but w.r.t the variable changes, then if you at least > make it consistent that > will be fine by me. >
I updated to avoid the unnecessary name change you pointed out, but i have left all others after reviewing. > > -phil. Is there a white-list of packages available to determine which > > classes should be pushed to the client jdk repo rather than the dev jdk > > repo? > > Any public API with a package prefix that begins with > java.applet, java.awt, java.beans, javax.imageio, javax.print, javax.sound, > javax.swing > and all implementation classes thereof .. > Thanks. If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue. How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo? -- It's quite clear to me this process does not scale. The amount of work that has to be done to treat the above mentioned packages separately is rapidly accelerating away from the work required to make such changes to the point at which it is extremely tempting to not bother to make such changes, which is bad because code starts ossifying. What happens if i just commit to dev/jdk instead? :-) Paul.
