Yes, there is no "one could argue" - the previous behavior was a bug, the javadoc is crystal-clear that anything other than yyyy-mm-dd should throw an exception.
One could still argue that this kind of fix -- that changes behavior that goes as far as JDK 1.1 (introduction of java.sql) and may break some apps that rely on the bug -- should be scheduled for major releases like 1.7. But then, there's no practical advantage doing this. For client users, JRE 1.6 will eventually auto-update to 1.7 as easily as to 1.6_xx. For server users, there's no auto-update so admins can always test new updates (minor or major ones) and skip/wait to update if apps break for any reason. The remaining argument is that major updates have a beta cycle that allows app developers to test against potentially risky changes; but in this case, JDK 6u18 is a special release. Everybody who tracks JavaSE knows that 6u18 was coming as another big Update release (a la 6u10), that's why it did have a public beta cycle that was half-year long (b01 was available in august 20, 2009); so, app developers have had PLENTY time for testing and fixing apps. This particular fix was in b05 (November 11), still enough time (2+ months - even more if we count up to when Sun starts pushing u18 in java.com - moreover, this is hardly relevant as few desktop apps rely on java.sql). A+ Osvaldo On 15 jan, 00:08, "[email protected]" <[email protected]> wrote: > Looks like they're tightening the > spec...http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6898593 > > On Jan 14, 1:40 pm, "[email protected]" > > <[email protected]> wrote: > > I agree with your comments that this might actually be a fix of the > > 6u17 (and before) implementation. > > > Still, it might take many users, unhappily by surprise. > > > On Jan 14, 1:32 pm, B Smith-Mannschott <[email protected]> wrote: > > > > On Thu, Jan 14, 2010 at 19:09, [email protected] > > > > <[email protected]> wrote: > > > > This program runs without throwing an exception in 6u17 but fails in > > > > 6u18 > > > > > public class SqlDate { > > > > public static void main(String[] args) { > > > > System.out.println(java.sql.Date.valueOf > > > > ("2009-07-01")); > > > > System.out.println(java.sql.Date.valueOf > > > > ("2009-7-1")); // Crashes in 6u18 > > > > } > > > > } > > > > > I've submitted a bug to sun but can anyone else replicate this? > > > > Interesting. What you're seeing is a change in *undocumented* > > > behavior. valueOf doesn't promise to handle that syntax. Both JDK5 and > > > JDK6 are documented thus: > > > > public static Date valueOf(String s) > > > Converts a string in JDBC date escape format to a Date value. > > > Parameters: s - a String object representing a date in in the format > > > "yyyy-mm-dd" > > > Returns: a java.sql.Date object representing the given date > > > Throws: IllegalArgumentException - if the date given is not in the > > > JDBC date escape format (yyyy-mm-dd) > > > > In fact, one could argue that 6u18 brings the fixes the fact that 6u17 > > > didn't behave as documented.
-- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
