6486887: (prefs) Preferences sync fails if jaxp transform provider doesn't support indent-number

[bha@worldnet.att.net]

-------------- Original message ----------------------
From: "Joseph D. Darcy" <Joe.Darcy at Sun.COM>
>
> bha at worldnet.att.net wrote:
> > -------------- Original message ----------------------
> > From: "Joseph D. Darcy" <Joe.Darcy at Sun.COM>
> >> bha at worldnet.att.net wrote:
> >>> I'm planning to look into providing a back-port patch for this bug. It is 
> >> marked as fixed in jdk 7, but a bunch of us really need it fixed in jdk 6 
> too. 
> >> This Preferences Impl bug is a regression, as it hworks fine in jdk 5.
> >>> That said, is anybody else already working on this, and/or any words of 
> >> warning/wisdom/advice?
> >>>   
> >> Hello.
> >>
> >> The issue in question was fixed under
> >>
> >> 6396599 (prefs) Preferences sync fails if jaxp transform provider 
> >> doesn't support indent-number
> >>
> >> early in JDK 7 and the fix should also be in the OpenJDK 6 sources.  The 
> >> OpenJDK 6 sources branched off from JDK 7 around build 20, circa late 
> >> August 2007 to early September 2007.  If a fix was in JDK 7 before then, 
> >> it should also be in OpenJDK 6.
> >>
> >> Regards,
> >>
> >> -Joe
> > 
> > 
> > Hi Joe,
> > 
> > Judging from the source in the newly published jdk6 bundle (b05-12_feb_2008), 
> it appears the fix for this bug is included:
> > 
> > file: java/util/prefs/XmlSupport
> > 
> >     /**
> >      * Write XML document to the specified output stream.
> >      */
> >     private static final void writeDoc(Document doc, OutputStream out)
> >         throws IOException
> >     {
> >         try {
> >             TransformerFactory tf = TransformerFactory.newInstance();
> >             try {
> >                 tf.setAttribute("indent-number", new Integer(2));
> >             } catch (IllegalArgumentException iae) {
> >                 //Ignore the IAE. Should not fail the writeout even the
> >                 //transformer provider does not support "indent-number".
> >             }
> > ...
> > 
> > Cool. Now how do I figure out when/if this code will make it into a release of 
> jdk/jre 1.6? Dare I infer the "b05" might translate to jdk6 update 5?
> 
> Hello.
> 
> That is a separate question.  OpenJDK 6 and Sun's 6 updates are 
> different, but related, release trains.  The "b05" in this case is 
> build 5 of OpenJDK 6, which has no direct relation to 6 update 5.  I'll 
> be posting some thoughts on criteria for getting bug fixes into OpenJDK 
> 6 versus JDK 7 versus a 6 update release in the near future.  However, 
> to get 6396599 fixed in a 6 update release, I suggest you and others 
> interested in a fix add votes for the bug on bugs.sun.com; I'll also 
> forward this issue to those who run the 6 update releases.
> 
> Cheers,
> 
> -Joe

Hi Joe,

I see, and I appreciate you forwarding this to the Sun JDK 6 update team very much. One problem with this sort of back port regarding voting: As is often the case, all the bug reports are closed, marked as "fixed" in a newer release, while still being broken in the currently most common real world release. That is the case here as well. The bugs are all closed as duplicates and/or closed as fixed in JDK 7. 

6396599  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6396599
6486887  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486887
6568540  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6568540

The problem is we can't vote for closed bugs (and even if we could, I doubt the votes would be considered as important...)
Though the bugs are closed, there are a bunch of user comments asking about a JDK 6 back port. Would you suggest I open a brand new bug report specific to JDK 6 for this, or does that just add noise?

Thanks,
Dan