http://permalink.gmane.org/gmane.comp.java.classpath.patches hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.classpath.patches/13246 <pre> As far as I understood the documentation (in my case http://docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#enable-disable as a reference) it is true that '-ea' (no argument) only applies to normal classes. The flag '-ea:*' does apply all classes: "The above switches apply to all class loaders. With one exception, they also apply to system classes (which do not have an explicit class loader). The exception concerns the switches with no arguments, which (as indicated above) do not apply to system classes." Did I miss anything? </pre> Josef Eisl 2012-04-25T06:44:37 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13245 <pre>----- Original Message ----- I'm confused about something in this patch which perhaps you can explain. I was under the impression that all system classes had assertions enabled and disabled as 'system assertions' (-esa/-dsa). So I was expecting the patch to just return this value if the classloader was null. Why does it instead retrieve a system classloader and probe that on a per-package/class basis? How would these values be set? As quoted before, the Oracle documentation explicitly states that -ea does not turn on system assertions. This patch would imply that e.g. assertions for java.lang could be turned on by -ea:java.lang. Is this intentional? On the administrative side, AFAICS you haven't contributed before. Do you have a copyright assignment with the FSF? Thanks, </pre> Andrew Hughes 2012-04-25T00:07:04 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13244 <pre> Oh, yeah. That's true. If the reference implementation is used everything should be fine ;). </pre> Josef Eisl 2012-04-24T19:07:22 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13243 <pre>On Tue, Apr 24, 2012 at 9:40 PM, Josef Eisl &lt;zapster&lt; at &gt;complang.tuwien.ac.at&gt; wrote: Acked-by: Pekka Enberg &lt;penberg&lt; at &gt;kernel.org&gt; On Tue, Apr 24, 2012 at 9:40 PM, Josef Eisl &lt;zapster&lt; at &gt;complang.tuwien.ac.at&gt; wrote: Sure, but only for VMs that override GNU Classpath VM native classes. Jato, for example, doesn't. </pre> Pekka Enberg 2012-04-24T18:52:27 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13242 <pre>Hi. Attached is a patch that enables GNU Classpath to distinguish between normal assertions and assertions for system classes (i.e. null classloader) as discussed on the Classpath mailing list [1]. Note that the new method 'java/lang/VMClassLoader.getSystemAssertionStatus()' must be implemented otherwise an exception will occur. josef [1]: http://developer.classpath.org/pipermail/classpath/2012-April/003195.html On 04/24/2012 02:29 AM, Andrew Hughes wrote: </pre> Josef Eisl 2012-04-24T18:40:46 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13241 <pre>As discussed on the gcj mailing list recently: http://gcc.gnu.org/ml/java/2012-03/msg00048.html I've added an implementation of java.util.regex.Matcher.usePattern(Pattern). It was pretty simple, not more than a five minute job. ChangeLog: 2012-03-22 Andrew John Hughes &lt;ahughes&lt; at &gt;redhat.com&gt; * java/util/regex/Matcher.java: (usePattern(Pattern)): Implemented. I've also synced in a number of fixes which were only committed to gcj and not GNU Classpath that I found during the merge: http://gcc.gnu.org/ml/java-patches/2012-q1/msg00063.html 2012-01-01 Jakub Jelinek &lt;jakub&lt; at &gt;redhat.com&gt; * gnu/java/rmi/registry/RegistryImpl.java (version): Update copyright notice dates. * tools/gnu/classpath/tools/orbd/Main.java (run): Likewise. 2007-02-26 Jakub Jelinek &lt;jakub&lt; at &gt;redhat.com&gt; * java/util/TimeZone.java (getDefaultDisplayName): Don't check if TimeZone is instanceof SimpleTimeZone. 2006-09-13 Andrew Haley &lt;aph&lt; at &gt;redhat.com&gt; * java/util/PriorityQueue.java: Throw IllegalArgumentException for capacity </pre> Dr Andrew John Hughes 2012-04-03T14:11:07 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13240 <pre> One thing I forgot to mention: tooling is critical. I don't have to create properly-formatted ChangeLog entries by myself because there are tools to do it. Any change to policies requires complete tooling support or people will waste time having to generate entries by hand. Andrew. </pre> Andrew Haley 2012-03-30T09:08:39 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13239 <pre> I don't understand this comment. The plugin makes git handle ChangeLogs correctly; there are plugins to make it handle other formats correctly, too. Because the ChangeLog is useful to have, independently of any particular VCS. As long as there is a ChangeLog, it doesn't matter at all how it is created, as long as it's correct, complete, and properly formatted. But I don't think there is a choice. It's too late, so all this discussion is moot. Andrew. </pre> Andrew Haley 2012-03-30T08:17:43 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13238 <pre>----- Original Message ----- Yes, let's not. I'll just say that from my side, working with individual changesets makes it a lot easier to dig out individual patches, etc. Doing the recent gcj merge with SVN was horrendous compared with the OpenJDK merges I do (though gcc is a much bigger repo) and I think things would be a lot harder if OpenJDK used it. git and mercurial seem pretty much the same to me, the main difference being that mercurial seems to trail git in terms of feature development and git has a usable branch system, rather than the fakery we have to do with mercurial. </pre> Andrew Hughes 2012-03-29T23:01:29 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13237 <pre>Hi Andrew, Thank you for the explanation. Thu, 29 Mar 2012 18:33:45 +0100 Andrew Haley &lt;aph&lt; at &gt;redhat.com&gt;: The plugin is merely a workaround. You say "GNU projects have X" Why? ("because" is missing) You you put ChangeLog to ignored list and regenerate on tarball release via git log would it be possible to say the project has ChangeLog or not? VCS could keep everything you put - e.g. auto-generated files and binaries - it's up to you decide what's suitable for you when doing basic tasks. E.g., Classpath repo has .svnignore files - if moved to git we could create .gitignore by "ln -s" for each one (putting .svningore to .git exclude file) - a working solution while keeping compatibility with SVN but will it be as convenient as "native" .gitignore (e.g., in case of cloning)? (I guess there probably exists some driver that emulates .gitignore based on .svn/cvsignore present but I'm not sure.) If you could be here more verbose or give a link - would be appreciated. Thanks. Agree but if there is a choice -</pre> Ivan Maidanski 2012-03-29T20:54:59 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13236 <pre> But that's what the git ChangeLog plugin is for. GNU projects have ChangeLogs; it's up to the VCS to keep up. So was I. Who said that Java developers prefer SVN to Git? Well, I vastly prefer SVN to anything I've seen recently because of its branch handling, but maybe that's only me. In any case, let's not have this mailing list degenerate into "my VCS versus yours" flame wars, just like every other list. Andrew. </pre> Andrew Haley 2012-03-29T17:33:45 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13235 <pre>Hi Andrew, Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley &lt;aph&lt; at &gt;redhat.com&gt;: Sorry for not explaining you how does git merge work. if you don't have a special ChangeLog-aware merge driver installed (like git-merge-changelog) you would almost always get merge conflicts when pulling public modifications into a privately modified ChangeLog file (same for rebasing). Every merge conflict requires manual handling. If it is decided to move to VCS that simplifies parallel development and branch merging, staying with old commit policy (relying on ChangeLog) neutralizes that benefits. PS. I was surprised to hear that free Java developers prefer SVN to Git. How many free Java developers have been contributing to Classpath over the passed 3-4 years? And which of them prefer to stay with CVS and SVN? Regards. </pre> Ivan Maidanski 2012-03-29T17:19:33 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13234 <pre> Why? I think this sentence is missing a "because ..." clause. Andrew. </pre> Andrew Haley 2012-03-29T16:42:17 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13233 <pre> FWIW, I voted for git because that's what I know. I have never used Mercurial for real work. Pekka </pre> Pekka Enberg 2012-03-29T16:06:22 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13232 <pre>Hi Andrew, It would be good to deprecate ChangeLog (used as commit log) as well. Regards. Thu, 29 Mar 2012 10:52:26 -0400 (EDT) Andrew Hughes &lt;ahughes&lt; at &gt;redhat.com&gt;: &gt; </pre> Ivan Maidanski 2012-03-29T15:58:34 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13231 <pre> Yes, I'm sure that's the meta-reason, and I should have been paying more attention. :-( Andrew. </pre> Andrew Haley 2012-03-29T15:17:51 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13230 <pre> Because nobody spoke up during the review period, so the first suggestion was accepted. </pre> Chris Burdess 2012-03-29T15:12:33 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13229 <pre> I missed that. OK, I'll push the patch to git. We need at least to make the CVS read-only. Why are we using yet another VCS, anyway? We can pretty much guarantee that free Java devs are used to Mercural and maybe Subversion, but git? Andrew. </pre> Andrew Haley 2012-03-29T15:07:42 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13221 <pre>OpenJDK throws StringIndexOutOfBoundsException and so should we. Signed-off-by: Pekka Enberg &lt;penberg&lt; at &gt;kernel.org&gt; --- ChangeLog | 6 ++++++ java/lang/String.java | 4 ++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index cce9803..0a867cc 100644 --- a/ChangeLog +++ b/ChangeLog &lt; at &gt;&lt; at &gt; -1,5 +1,11 &lt; at &gt;&lt; at &gt; 2012-03-15 Pekka Enberg &lt;penberg&lt; at &gt;kernel.org&gt; +* java/lang/String.java: +(codePointAt): Fix exception type. +(codePointBefore): Fix exception type. + +2012-03-15 Pekka Enberg &lt;penberg&lt; at &gt;kernel.org&gt; + * java/util/Formatter.java: (format): Fix NPE errors. diff --git a/java/lang/String.java b/java/lang/String.java index 45c0daf..eb713ce 100644 --- a/java/lang/String.java +++ b/java/lang/String.java &lt; at &gt;&lt; at &gt; -705,6 +705,8 &lt; at &gt;&lt; at &gt; public final class String */ public synchronized int codePointAt(int index) { + if (index &lt; 0 || index &gt;= count) + throw new StringIndexOutOfBoundsException(index); // Use the CharSequence overload as we get bet</pre> Pekka Enberg 2012-03-15T20:20:32 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13220 <pre>This patch fixes NPE for the following Malva test cases: assertEquals("false", String.format("%b", (Object[])null)); assertEquals("null", String.format("%h", (Object[])null)); assertEquals("null", String.format("%s", (Object[])null)); assertEquals("null", String.format("%c", (Object[])null)); assertEquals("null", String.format("%d", (Object[])null)); assertEquals("null", String.format("%o", (Object[])null)); assertEquals("null", String.format("%x", (Object[])null)); Signed-off-by: Pekka Enberg &lt;penberg&lt; at &gt;kernel.org&gt; --- ChangeLog | 5 +++++ java/util/Formatter.java | 21 ++++++++++++++++++--- 2 files changed, 23 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 48af956..cce9803 100644 --- a/ChangeLog +++ b/ChangeLog &lt; at &gt;&lt; at &gt; -1,3 +1,8 &lt; at &gt;&lt; at &gt; +2012-03-15 Pekka Enberg &lt;penberg&lt; at &gt;kernel.org&gt; + +* java/util/Formatter.java: +(format): Fix NPE errors. + 2012-03-12 Pekka Enberg &lt;penberg&lt; at &gt;kernel.org&gt; * gnu/java/nio/FileLockImpl.java, diff --git a/java/util/Forma</pre> Pekka Enberg 2012-03-15T19:38:31 http://permalink.gmane.org/gmane.comp.java.classpath.patches/13219 <pre> ----- Original Message ----- Well they at least need to be documented and the lack of implementation noted therein. </pre> Andrew Hughes 2012-03-15T10:06:56 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.classpath.patches