<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 9, 2011, at 4:48 PM, Dr Andrew John Hughes wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; "><blockquote type="cite"><br class="Apple-interchange-newline">Other ideas were considered:<br></blockquote><blockquote type="cite"> * Folding jaxp/jaxws into the root or jdk8/jdk repo<br></blockquote><br>Sounds good. jdk8/jdk would make more sense as jaxws depends on some classes that are in the jdk<br>tree (com.sun.net.httpserver) and we could then get rid of the Ant junk. It would be good to have<br>the code there too so we can once again track changes. The recent security issue was a nightmare<br>due to the unavailability of the source code.<br></span></span></blockquote><div><br></div>Humm "Ant junk" ok... I'm not in love with it either, but it does provide a very fast build of simple pure java code.</div><div>But having separated out jaxp/jaxws/corba from the rest of the jdk, we are not considering folding it all</div><div>back in. The consideration was moving the use of the drop bundle, not forking the source again.</div><div>The separation of these sources from the basic jdk has been a major benefit to the developers and was also meant</div><div>to ease the fork issues of this code, that is and has been maintained as separate open source projects and</div><div>delivered into multiple projects, licensed differently, and re-packaged in different ways.</div><div>The jdk is downstream on these sources.</div><div>There will be a separate discussion on this but it will focus on improving the source drop complications.</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; "><br><blockquote type="cite"> * Separating out the jdk demos from the jdk repo to a separate "demos" repository<br></blockquote><br>Makes sense. Having an option to disable them would be a good first step.<br></span></span></blockquote><div><br></div>A 'do not build demos' option would be a fine RFE. Maybe do some preliminary surgery to at least</div><div>isolate the sources that are strictly 'demo or sample' material. IF someone has the time. ;^)</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; "><br><blockquote type="cite"> * Separating out the client (awt/swing/etc) code from the jdk repo into a separate repo<br></blockquote><br>Why would we want to do this? IME, there are lots of interdependencies with the other code and<br>this would make the build a nightmare.<br></span></span></blockquote><div><br></div>It was suggested and talked about a little, nobody stepped forward to champion it.</div><div>I assume it would be done to categorize the sources and make the developers lives easier</div><div>when focusing on their own area.</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; "><br><blockquote type="cite"> * Updating the corba sources changing it to an ant build<br></blockquote><br>Please, no! These Ant builds are already a nightmare and an order of magniture harder to debug than<br>the Makefiles. Why you want to require a build system that requires an entire JDK setup (possibly<br>bringing another into the mix beyond the bootstrap JDK) is beyond me.<br><br></span></span></blockquote><div><br></div>Ok. I had no idea is was that bad. Well, yes, ant script logging and debugging is a bit bad, and the syntax</div><div>is a little ...ah... bizarre... don't want to insult any xml people... :^( The pains with ant scripts seemed worth</div><div>it with regards to the speed it can compile/zip/jar all in one VM process. And of course the potential NetBeans</div><div>IDE usage benefits, just ask the langtools development team.</div><div>The current corba makefile build can take 10-15 minutes on some systems, and I would estimate that an ant build could</div><div>cut that in half or maybe a quarter of that time. Especially on Windows systems which aren't exactly exec demons.</div><div><br></div><div>But regardless, this won't be happening, corba will remain 'as is' unless we decide to upgrade the entire corba</div><div>source base, in which case I would advocate using the default build mechanism recommended and used by the</div><div>Corba team. I would like to defer to the development team that has to work on this code and the upstream</div><div>project that has what is considered the master sources.</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">What would make much more sense is to just add corba into the jdk tree. It actually requires sun.tools<br>classes to compile rmic anyway so it would make much more sense there.<br></span></span></blockquote><div><br></div>No, we won't be doing that as far as I know. Unless the Corba team wants to lobby for that, and I suspect they won't.</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; "><br>Hey, I'd just make it all one repository as they all interdepend on each other, but the HotSpot folks<br>probably wouldn't like that... ;-) Moving the HotSpot servicability agent into the JDK, where the<br>interfaces it uses lives, might be a good idea though. I'm currently working on a patch which fixes<br>up a mismatch between the HotSpot SA implementation and the interfaces in the JDK which has existed<br>for who knows how long (it's certainly in OpenJDK6)...<br></span></span></blockquote><div><br></div>When we initially started the OpenJDK project, one single repository was suggested. It was quickly rejected.</div><div><br></div><div>The comments about the Serviceability Agent is puzzling, it has a very tight interface between it and the Hotspot</div><div>VM data structures, or did as I recall. What JDK interfaces are you talking about?</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; "><br><blockquote type="cite"><br></blockquote><blockquote type="cite">None of this seemed urgent to do out of the gate, or delay getting a preliminary jdk8 layout defined.<br></blockquote><blockquote type="cite"><br></blockquote><br>No, I agree with that. Splitting off OpenJDK8 already seems overdue.<br><br><blockquote type="cite">I know there is some interest in pulling the actual jaxp/jaxws sources back into their repos, that will<br></blockquote><blockquote type="cite">be discussed separately, we have multiple issues with that, but I am well aware of the pains that the<br></blockquote><blockquote type="cite">source drop zip files have created.<br></blockquote><blockquote type="cite"><br></blockquote><br>The problem is less technical and more social; there is no obvious way to interact with the JAXP and JAXWS<br>side of things. We just get these zips of code with no idea of what changes are in there or why.<br><br>Basically, they shouldn't work either like they do now or did before, but like everything else in OpenJDK<br>with visible commits. Hey, maybe we could even have some mailing list discussion if we're very lucky...<br></span></span></blockquote><div><br></div>We will try and have these discussions in the open. And try and make the source more visible, but</div><div>we do want to have the changes flowing from the master sources on these projects. Maybe we can come up</div><div>with a better way.</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; "><br><blockquote type="cite">As always, we would like to get comments, or additional ideas.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Separate topics:<br></blockquote><blockquote type="cite"> * Forest Extension and it's replacement<br></blockquote><br>Do we really need one? Current status quo (get_source.sh) works fine.<br><br><blockquote type="cite"> * Mercurial server update to 1.8 or newer<br></blockquote><br>I guess this is related to the forest issue.<br><br><blockquote type="cite"> * Build&Test system [1]<br></blockquote><blockquote type="cite"> * Open bug tracking system [2]<br></blockquote><blockquote type="cite"><br></blockquote><br>You missed off open sourcing that jcheck thing... that's the biggest problem I have with<br>the Mercurial server. :-)<br></span></span></blockquote><br></div><div>Yes. I annoy Mark about this all the time too. ;^)</div><div><br></div><div>-kto</div><div><br></div><br></body></html>