Hi, it seems that if (cs.equals(this)) return true; should be replaced with if (cs instanceof String) return cs.equals(this); or completely left out. Does anyone agree? -- -- Cheers, Alex
Hi Alex, String.equals already performs that instanceof comparison, and is one of the first to be inlined by the hotspot. What I would do is to turn it... "this.equals(cs)" instead of "cs.equals(this)". Which would only improve performance if you have classes implementing CharSequence other than String, StringBuilder and StringBuffer... Anyway, does anyone know if the contentEquals method is actually used out there? (at least it isn't inside the JDK source code). Regards, --Jesus Alexander Veit wrote: > Hi, > > it seems that > > if (cs.equals(this)) > return true; > > should be replaced with > > if (cs instanceof String) > return cs.equals(this); > > or completely left out. > > Does anyone agree? > > --(Continue reading)
I agree, this would be a short cut in case of cs is not a String. In case of cs is a String, user likely would have used the standard equals() method to avoid the double check by instanceof. In case of HotSpot compilation AND inlining, there should be no difference. -Ulf Am 04.01.2010 16:15, Alexander Veit schrieb: > Hi, > > it seems that > > if (cs.equals(this)) > return true; > > should be replaced with > > if (cs instanceof String) > return cs.equals(this); > > or completely left out. > > Does anyone agree? > >
Am 04.01.2010 17:42, Jesús Viñuales schrieb: > Hi Alex, > > String.equals already performs that instanceof comparison, and is one of the first to be inlined by the hotspot. What I would do is to turn it... "this.equals(cs)" instead of "cs.equals(this)". > Why always waiting for HotSpot inlining to have Java fast? If not invoked so often, interpreter too should be fast as it can. -Ulf > Which would only improve performance if you have classes implementing CharSequence other than String, StringBuilder and StringBuffer... Anyway, does anyone know if the contentEquals method is actually used out there? (at least it isn't inside the JDK source code). > > Regards, > --Jesus > > > Alexander Veit wrote: > >> Hi, >> >> it seems that >> >> if (cs.equals(this)) >> return true; >> >> should be replaced with(Continue reading)
Hi Jesús, > String.equals already performs that instanceof comparison, > and is one of the first to be inlined by the hotspot. What I > would do is to turn it... "this.equals(cs)" instead of > "cs.equals(this)". That's true, but given cs is a String with length equal to this, cs.equals(this) nevertheless may return false, and if (cs.equals(this)) return true; will not return. The remaining code performs the comparison a second time in this case. > [...] > Anyway, does anyone know if the > contentEquals method is actually used out there? (at least it > isn't inside the JDK source code). I use itIt is useful to prevent from duplicate memory allocation in quite some cases. -- -- Cheers, Alex
> That's true, but given cs is a String with length equal to this, > cs.equals(this) nevertheless may return false, and > > if (cs.equals(this)) > return true; > > will not return. The remaining code performs the comparison a second > time in this case. Oh, now I see it - you are absolutely right
Changeset: d4e0ae9b4ecb Author: jjg Date: 2010-01-06 13:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d4e0ae9b4ecb 6855236: Compiler Tree API TreePath class generates NullPointerException from Iterator Reviewed-by: darcy + test/tools/javac/T6855236.java
Hi all, I asked the question on jdk6-dev list, and Joe Darcy said here's a better place to ask, so here I go. According the the JVM spec, 2nd edition, 5.3.3 Creating Array Classes, both the bootstrap class loader and user-defined class loaders can load array classes, and the corresponding class loaders involved are recorded as initiating class loaders. But starting from JDK 6, Sun's JDK by default doesn't allow array syntax in ClassLoader.loadClass()/ClassLoader.findSystemClass(); array classes couldn't be created by calling defineClass() anyway, so this effectively bans user-defined class loaders to be initiating class loaders for array classes. Calling Class.forName(className, initialize, classLoader) won't record classLoader as an initiating class loader for an array class either. Is this an intended behavior? I'm expecting a call to Class.forName() would mark the loader as an initiating one, for all classes (including array classes). That way I won't have to keep a cache of my own in my custom class loader to keep track of what's been loaded already. I read Bug 6500212 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212) and know that I shouldn't call ClassLoader.loadClass() with array syntax, so I switched to Class.forName(). But then when my class loader is asked to load the same array class again, it calls findLoadedClass() and gets a null back. That's pretty bad because I don't won't to get down to SystemDictionary::resolve_array_class_or_null() every time I load an(Continue reading)
Hello.
Please review the patch below to clarify which throwables are regarded
as checked and unchecked exceptions.
Thanks,
-Joe
--- old/src/share/classes/java/lang/Error.java 2010-01-07
18:35:40.000000000 -0800
+++ new/src/share/classes/java/lang/Error.java 2010-01-07
18:35:40.000000000 -0800
<at> <at> -26,27 +26,31 <at> <at>
package java.lang;
/**
- * An <code>Error</code> is a subclass of <code>Throwable</code>
+ * An { <at> code Error} is a subclass of { <at> code Throwable}
* that indicates serious problems that a reasonable application
* should not try to catch. Most such errors are abnormal conditions.
- * The <code>ThreadDeath</code> error, though a "normal" condition,
- * is also a subclass of <code>Error</code> because most applications
+ * The { <at> code ThreadDeath} error, though a "normal" condition,
+ * is also a subclass of { <at> code Error} because most applications
* should not try to catch it.
* <p>
- * A method is not required to declare in its <code>throws</code>
- * clause any subclasses of <code>Error</code> that might be thrown
+ * A method is not required to declare in its { <at> code throws}
(Continue reading)
Hi Joe,
This looks fine to me.
One minor consistency nit, sometimes you refer to "subclasses of" and
sometimes "subclass of" eg:
+ * <p>The class { <at> code Exception} and any subclasses that are not also
+ * subclasses of { <at> link RuntimeException} are <em>checked
+ * exceptions</em>.
+ * For the purposes of compile-time checking of exceptions, { <at> code
+ * Throwable} and any subclass of { <at> code Throwable} that is not also a
+ * subclass of either { <at> link RuntimeException} or { <at> link Error} are
+ * regarded as checked exceptions.
For consistency you could use the same wording for Exception as you do
for Throwable.
Cheers,
David
Joe Darcy said the following on 01/08/10 12:41:
> Hello.
>
> Please review the patch below to clarify which throwables are regarded
> as checked and unchecked exceptions.
>
> Thanks,
>
(Continue reading)
RSS Feed529 | |
|---|---|
820 | |
479 | |
512 | |
626 | |
594 | |
438 | |
323 | |
94 | |
279 | |
178 | |
270 | |
186 | |
265 | |
198 | |
174 | |
229 | |
242 | |
325 | |
165 | |
132 | |
235 | |
83 | |
81 | |
63 | |
309 | |
174 | |
129 | |
136 | |
152 | |
158 | |
43 | |
78 | |
81 | |
62 | |
117 | |
123 | |
123 | |
274 | |
67 | |
85 | |
81 | |
135 | |
271 | |
325 | |
228 | |
277 | |
215 | |
219 | |
167 | |
180 | |
140 | |
76 | |
67 | |
44 | |
108 | |
74 | |
77 | |
57 | |
81 | |
80 | |
68 | |
70 | |
14 | |
75 | |
23 | |
25 | |
27 | |
8 | |
9 | |
41 | |
10 | |
7 |
