tag:blogger.com,1999:blog-741750605858169835.post1547523428062661179..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: JDK 7 - Method suggestionsStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger34125tag:blogger.com,1999:blog-741750605858169835.post-13419654829178989622009-09-19T02:40:26.000+01:002009-09-19T02:40:26.000+01:00I come down in the camp of not adding many null-ha...I come down in the camp of not adding many null-handling methods. What is the single most commonly thrown exception in Java? NullPointerException, easily. Why? I would argue that null has been overloaded in Java, and is in use to mean "not initialized" "no value" "error condition" "empty object" and other things besides. <br /><br />My current practice is to try to use null *only* as an error condition, and never pass null to signify anything else. I think that many of the additions you propose would encourage using null as an object placeholder, which I think undesirable, and in fact to be one of the largest problems facing the Java programmer in practice.Frank Hardistyhttp://www.geovista.psu.edu/grants/cdcesda/software/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-88890796768864565462009-09-15T14:44:52.000+01:002009-09-15T14:44:52.000+01:00BTW i think the readInto, writeObjects, readObject...BTW i think the readInto, writeObjects, readObjects (if it can made to return multiple arguments, like a iterator that autocloses or something when its done), and xml variants are nice. Not to speak of the close method that will be adressed by ARM.paulonoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-38713235090031537382009-09-15T14:41:07.000+01:002009-09-15T14:41:07.000+01:00I wasn't trying to paste the code, just the si...I wasn't trying to paste the code, just the signatures. Soooorry.paulonoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-43070272889809659892009-09-15T14:40:42.000+01:002009-09-15T14:40:42.000+01:00I wasn't trying to paste the code, just the si...I wasn't trying to paste the code, just the signatures. Soooorry.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-62293342848630627492009-09-14T22:34:30.000+01:002009-09-14T22:34:30.000+01:00If individuals think that pasting pages of code in...If individuals think that pasting pages of code into a comment on a private blog is the way to contribute to the JDK, then I give up.Alex Buckleynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86786152116378165622009-09-14T14:11:40.000+01:002009-09-14T14:11:40.000+01:00Perhaps:
Arrays.reverse(T[]);
and its primitive ...Perhaps:<br /><br />Arrays.reverse(T[]);<br /><br />and its primitive counterparts?David Karnokhttp://darksideunderflow.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-10650249728682472172009-09-13T17:19:52.000+01:002009-09-13T17:19:52.000+01:00"No" from me to most of the null-masking..."No" from me to most of the null-masking methods. This encourages careless null propagation, which forces defensive coding, which leads to even more boilerplate.<br /><br />In my experience, educating people by requiring explicit @Nullable annotations for api parameters, backed up by automated static analylis (jsr308 checker framework) works much better. It still gives people freedom to return/pass null, but makes the conceptual cost explicit.Piotrnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-72351513367678768212009-09-11T08:27:28.000+01:002009-09-11T08:27:28.000+01:00So... much... boilerplate... ... eyes... bleeding....So... much... boilerplate... ... eyes... bleeding.<br /><br />All necessary in Java, alas.<br /><br />WBJUS.Lachlan O'Deanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-27395117239227682102009-09-11T07:49:32.000+01:002009-09-11T07:49:32.000+01:00I would like to get a java.text.Format for all box...I would like to get a java.text.Format for all boxed primitive types (not sure I want them localized), like Boolean, Integer (and not Number) etc. <br /><br />And I would like to easily get the boxed type for a primitive type and converse (boolean.class<->Boolean.class).<br />These are the most boring piece of infrastructure to write when dealing with introspection. And I think we all deal a lot with it nowadays.<br /><br />and maybe a <br />static T[] Collections.asArray(Iterable, Class) <br />based on java.lang.reflect.Array.newInstance() .Nicolas Raynaudhttp://trainoo.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-54767841328387030342009-09-11T02:47:38.000+01:002009-09-11T02:47:38.000+01:00@Stephen: Completely agree that this forum lets pe...@Stephen: Completely agree that this forum lets people get involved easily, and that some good ideas will probably come out of that.<br /><br />Just wanted to emphasize that someone with specific methods in mind already has a clear course of action if they are serious: join core-libs-dev.<br /><br />If they don't join core-libs-dev, then they're relying on someone else to read their comments here and in turn communicate them to core-libs-dev.Alex Buckleynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-15753538160353282492009-09-11T00:49:52.000+01:002009-09-11T00:49:52.000+01:00@Kieron, Not sure whether to congratulate you or c...@Kieron, Not sure whether to congratulate you or commiserate you for trying to use Option/Maybe like functionality. I'd strongly argue that beyond a few experts this kind of approach is never used in Java (Java isn't a functional language, and trying to apply functional patterns is just a bad idea IMO).<br /><br />@Casper, Any deepCopy or similar for hashcode/toString is fraught with risk due to object graph cycles and reflection. These are best avoided in the JDK lang/util area.<br /><br />@Collin, Your Each.of method is similar to Ricky's Iterables. I think some Iterable methods could be a good inclusion, although again they tend to encourage a functional style which is inappropriate for Java.<br /><br />I also agree on a direct way to create an ArrayList - however, Project Coin is providing that :-)<br /><br />@Osvaldo, I thought about including the list-like methods for arrays, but decided against. I believe that in general if you need a list then you should use a list.<br /><br />@Alex, Your point is well made, however a forum like this allows more people to get involved (as is being ably demonstrated). Whether anything happens as a result of the discussion is partly up to the individual authors.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-43324135827025533722009-09-10T23:05:40.000+01:002009-09-10T23:05:40.000+01:00Thanks to Stephen for contributing his methods bot...Thanks to Stephen for contributing his methods both here and on the OpenJDK core-libs-dev list.<br /><br />Commenters on this blog should be aware that an informed discussion is happening on the core-libs-dev list. That is where decisions are made.<br /><br />If you want to make a "submission" or give "your $0.02" in a comment on this or any other blog, that is your choice. Just know that nothing will happen as a result.Alex Buckleynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-24744699390923072282009-09-10T21:46:50.000+01:002009-09-10T21:46:50.000+01:00@efl
I think a lot of people would have liked it ...@efl<br /><br />I think a lot of people would have liked it if the for-each loop worked with more then itererabls and arrays. I think this code has been written a number of times and is a good candidate for the JDK. Our are very similar. I just used a static "factory" method to keep the typing down.Collin Faganhttp://aberrantcode.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-5029025013940244282009-09-10T20:09:34.000+01:002009-09-10T20:09:34.000+01:00@Collin
I have always wondered why the for-each co...@Collin<br />I have always wondered why the for-each construction introduced in Java 5 cannot be used directly with Iterators intead of Iterables?<br /><br />I worked around this with a solution similar to yours but more complete because my class can also convert Enumeration and Iterator in both ways anywhere an API accept one and not the other (it implements all 3 interfaces Iterable, Iterator and Enumeration).<br /><br />Iterator iterator = new EnumerationIterator(enumeration);<br /><br />Enumeration enumeration = new EnumerationIterator(iterator);<br /><br />for (String s: new EnumerationIterator(stringIterator) {}<br />or with a static factory:<br />for (String s: EnumerationIterator.iterate(stringIterator) {} //you can shorten to just iterate(stringIterator) with static import EnumerationIterator.iterateeflnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-47056251348252050462009-09-10T18:15:18.000+01:002009-09-10T18:15:18.000+01:00(Not that we should necessarily continue this disc...(Not that we should necessarily continue this discussion here, but when I want to do the sort of thing I think you are, I wrap my raw array with asList() and pass it as an arg to an ArrayList constructor to make a mutable copy...)Damon Hart-Davishttp://d.hd.org/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86390518969185985332009-09-10T18:11:21.000+01:002009-09-10T18:11:21.000+01:00@Damon Hart-Davis
Nope Arrays.asList() returns a ...@Damon Hart-Davis<br /><br />Nope Arrays.asList() returns a java.util.Arrays.ArrayList not a java.util.ArrayList. The java.tuil.Arrays.ArrayList class throws an UnsupportedOperationException if you try to add or remove anything from it.Collin Faganhttp://aberrantcode.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-33856342935135259762009-09-10T16:49:51.000+01:002009-09-10T16:49:51.000+01:00Collin: Arrays.asList()?Collin: Arrays.asList()?Damon Hart-Davishttp://d.hd.org/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-47996172620853324312009-09-10T16:32:02.000+01:002009-09-10T16:32:02.000+01:00I like most of the suggestions, even the null safe...I like most of the suggestions, even the null safe ones. Like anything I think there are places where they can be useful and places where they will cause trouble.<br /><br />I wrote a class called "Each". It converts iterators to iterables with the "of" static method.<br />Iterator stringIterator ...<br /><br />for(String item : Each.of(stringIterator)){<br /> ...<br />}<br /><br />You could also write one that takes the old Enumeration class.<br /><br />Also I was always disappointed that I can't create an ArrayList from an array. You would think that ArrayList would have a constructor that took and array.<br /><br />I'll post more as I think of them.Collin Faganhttp://aberrantcode.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-56116331688841592152009-09-10T14:39:28.000+01:002009-09-10T14:39:28.000+01:00I'm NOT against all null-masking, because some...I'm NOT against all null-masking, because some utility methods would support values that may be legally null. For one thing, when working with primitive arrays I often use (or at least support) null instead of empty arrays; I know the "best practice" of preferring empty arrays, but nulls are often more efficient and convenient.<br /><br />Now my $.02, pulled from the 'Util' class that I've been maintaining for >10 years and would love to deprecate with JDK7 :)<br /><br />- double parseDouble (String param) (and similar methods for other numeric types and also boolean): Parses param, but handles nulls (returning 0) and trims the input (ignoring spaces); API methods like Double.parseDouble() would raise exceptions in both cases.<br /><br />- String stringOf (char c, int count); String stringOf (String s, int count): Returns a string with count times some character or substring. Optimized for the common case of c/str = ' ' and small values of count (just return a substring of a static constant string with many spaces). Would ideally be new String constructors.<br /><br />- T[] subarray (T[] arr, int first, int last, boolean forceNew); T[] arrayadd (T[] arr1, T[] arr2, boolean forceNew); T[] arrayadd (T[] arr1, int first1, int last1, T[] arr2, int first2, int last2, boolean forceNew); T[] arrayadd (T[] arr, int pos, T elem); T[] arrayremove (T[] arr, int pos); T[] arrayremove (T[] arr, int first, int last, boolean forceNew): Operations on primitive arrays. Optimized for several cases like a subarray that returns the entire original array (0 .. length-1), a concatenation with at least one empty array, etc.; in these cases, the parameter forceNew==true forces to return a new array, if the caller wants to avoid aliasing (important for APIs doing defensive copying). Support smart defaults like null => [] and last* == -1 => length - 1 of the corresponding array.<br /><br />- toString (Object[] arr): Formats the array as "[a, b, c, ...]"; includes handling of subarrays and nulls.<br /><br />Another suggestion: whatever is the set of new methods, we could have automatic static-import of several important classes of this type (bundles of static utility methods), like: System, all the wrappers, Collections, Arrays, Console, and the new Objects class. Yeah, just put all that stuff in the global scope so I don't need to import such basic things as println() (that are language-level primitives in many scripting languages). Do this automatic import only for -source 1.7, to the benefit of legacy code that could have some conflict.Osvaldo Pinali Doederleinhttp://weblogs.java.net/blog/opinali/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-91005680195549083382009-09-10T14:30:56.000+01:002009-09-10T14:30:56.000+01:00Here is my submission, some additional String conv...Here is my submission, some additional String conversion methods for the String class, similar to "String.toLowerCase()" and "String.toUpperCase()"<br /><br />1. String.toTitleCase() / String.capitalize()<br /><br />This String conversion method should be and should make all first letters of the Words in a String capitalized and the rest lowercased<br /><br />2. String.toSentenceCase()<br /><br />This String conversion method should make only the first letter of group words ending with a period capitalized and the rest lowercased. The implementation can use a String.split() to split the sentence into segments based on "." (periods) and then reconstruct it with the first letters of the sentences capitalized.<br /><br />3. String.toAlternateCase() (can be renamed)<br /><br />This should make all LowerCased letters UpperCased, and vice versaFrancishttp://icewalker2g.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6630457375277942632009-09-10T14:01:46.000+01:002009-09-10T14:01:46.000+01:00With regard to null handling I certainly don't...With regard to null handling I certainly don't live in a perfect world, I simply do not agree that the null handling methods are the right response (equals excepted).Mark Thorntonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-39472114065210482532009-09-10T14:00:22.000+01:002009-09-10T14:00:22.000+01:00I'd be a lot more interested in utility classe...I'd be a lot more interested in utility classes if we had extension methods as a mechanism to bring these into proper context. <br />Apart from StringUtils and DateUtils (which JSR-310 will fix?!) all I could want is:<br /><br />T ObjectUtils.deepCopy(T t)<br />long ObjectUtils.approxSize(T t)<br />String ObjectUtils.dynamicToString(T t)<br />Number NumberUtils.round(Number value, int precision)<br />Number NumberUtils.roundUp(Number value, int precision)<br />Number NumberUtils.roundDown(Number value, int precision)<br />Number NumberUtils.random(Number min, Number max)<br /><br />...and a System.restart() but that's not exactly a utility method.Casper Bangnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16370499671037014082009-09-10T13:59:31.000+01:002009-09-10T13:59:31.000+01:00"On Character.equalsIgnoreCase, most users wo..."On Character.equalsIgnoreCase, most users would just compare upper to upper, or lower to lower, and not both. As such, the method has value."<br /><br />They should be encouraged to use String.equalsIgnoreCase or an appropriate Collator. Using a Character.equalsIgnoreCase will inevitably lead to anomalous results in some locales.Mark Thorntonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-64992919972926292702009-09-10T12:41:29.000+01:002009-09-10T12:41:29.000+01:00Nice list.
I'm also against the null-handling...Nice list.<br /><br />I'm also against the null-handling methods though. I think that my main argument would be that code using them may actually become less reliable, since if you are going to get an unwanted NPE, it is better to get it near it's source so you can fix the bug.<br /><br />We don't use null's here (at least, not exposed outside a method body, and preferably not even then). We just handle them at the bounderies. Usually this can be done with an Option-like class, e.g.<br /><br /> Option.maybe(map.get(key))<br /><br />you can then do things like (with static import):<br /><br /> maybe(map.get(key)).getOrElse(defaultValue)Kieron Wilkinsonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16459737928809646392009-09-10T11:57:19.000+01:002009-09-10T11:57:19.000+01:00I too am against most of the null-masking stuff ex...I too am against most of the null-masking stuff except for the tedious-boiler-plate-eliminating Objects.equals(). Much better to continue to educate people to THINK about null/empty return values. Almost every one of my methods and values has a comment ends with "...; not null." or " ...; never null but may be empty." etc as it's so important to generating robust and optimisable code that can avoid redundant pipeline-breaking conditionals...<br /><br />I'll take your equalsIgnoresCase() is I've just found myself rewriting a bunch of String methods to work more generically on CharSequence...<br /><br />Rgds<br /><br />DamonDamon Hart-Davishttp://d.hd.org/noreply@blogger.com