Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
JDK 7: What Frequently Rewritten Methods Should be Included in java.util.Objects?
Posted by Ryan Slobojan on Sep 11, 2009
In preparation for the arrival of a new class in JDK7 called java.util.Objects which will contain frequently-written utility methods, Joe Darcy of Sun has put out a request to the OpenJDK core-libs-dev group for ideas on what methods should be contained in this class. InfoQ would like to pass this request along to the wider Java community.
In his initial post, Darcy highlighted a couple of potential methods which could be useful in this class:
- A null-safe
equals(arg1, arg2)method which returns true if both arguments are null, false if only one is null, andarg1.equals(arg2)otherwise - A set of
compareTo(arg1, arg2)methods for all primitive types (int, long, etc)
Some other suggestions came from Andrew John Hughes, including:
toString(arg), which would write out via reflection all of the fields inside the object to the returned output string- A utility implementation of the
clone()method
Martin Buchholz also proposed a null-safe hashCode() implementation, which would return 0 for a null object.
Stephen Colebourne created a long list of proposed methods for this class, primarily by choosing existing methods from the Apache Commons Lang utility classes. Some of those proposed include:
min(comparable1, comparable2)andmax(comparable1, comparable2), which would be null-safe and which would return the smallest/largest non-null object (or null if both arguments were null)defaultNull(obj, defaultValue)which would return the defaultValue object if obj was null
What are your thoughts? What methods should be added to java.util.Objects?
- This article is part of a featured topic series on Java
- See more Java content at: http://www.infoq.com/java
- Other recent content items in this topic
RelatedVendorContent
Introducing SQLFire: a memory-optimized, high performance SQL database
Tutorial: Integrating SQLFire with tc Server and Spring Data
The WebSphere Liberty Profile for Developers: An Introduction
Related Sponsor
VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface
int, long? java.util.Primitives?
by
Ronald Miura
Posted
More methods
by
Thomas Mueller
Posted
Re: More methods
by
Thomas Mueller
Posted
stupid idea
by
Stephan Oudmaijer
Posted
Copy Apache Commons
by
Dyego Carmo
Posted
Re: Copy Apache Commons
by
Eirik Maus
Posted
Re: Copy Apache Commons
by
Thomas Mueller
Posted
Re: Copy Apache Commons
by
James Richardson
Posted
Re: Copy Apache Commons
by
Luis Espinal
Posted
Re: Copy Apache Commons
by
George Petrov
Posted
Re: Copy Apache Commons
by
Luis Espinal
Posted
A proxy could be far more useful than a clone
by
Mario Fusco
Posted
My 3 thoughts
by
William H
Posted
...
by
Martin Krüger
Posted
Format of output in "toString(arg)" call
by
Blue Diamond
Posted
Bad idea
by
Andriy Tsykholyas
Posted
Re: Bad idea
by
Luis Espinal
Posted
Re: Bad idea
by
Andriy Tsykholyas
Posted
Re: Bad idea
by
Rodrigo Lopes
Posted
Re: Bad idea
by
Andriy Tsykholyas
Posted
Re: Bad idea
by
William H
Posted
Re: Bad idea
by
adrian collheart
Posted
Re: Bad idea
by
Andriy Tsykholyas
Posted
A safe cast method might be useful
by
Gregg Saffell
Posted
Objects
by
Jonathan Locke
Posted
Objects
by
Nikolay Tsankov
Posted
toJSON()
by
Pedro Fracarolli
Posted
Dealing with nulls
by
Eric Francis
Posted
-
I don't think that java.util.Objects is the right place to put methods to manipulate primitives... maybe java.util.Primitives?
-
boolean isNullOrEmpty(String s)
Those here should be in String, non-regexp versions:
String[] String.splitAt(char separatorChar, boolean trim)
String String.replaceAllExact(String before, String after)
byte[] String.convertHexToBytes()
String String.convertBytesToHex(byte[] value)
byte[] serialize(Object obj)
Object deserialize(byte[] data) -
boolean isNullOrEqual(Object a, Object b)
so instead of
Objects.isNullOrEmpty(s) use Objects.isNullOrEqual(s, "") -
Why should a new set of utility classses be included in Java 7? Just use jakarta commons, leave the JDK alone please!!!!
Just another bad idea IMHO, include stuff that does matter! -
Please... copy all thinks of Apache Commons...
This collection is very usefull !!!! -
The possibility to proxy any kind of object could allow to natively implement some pattern typical of aspect oriented programming.
Moreover I believe that projects like lambdaj ( code.google.com/p/lambdaj/ ) demonstrate very well how a smart use of proxy and reflection allows to easily enrich the language and make it more readable through DSL. -
+1 (if that's the max allowed plusses in one post)
-
-1 to copy all of Apache Commons. That would be bloat, delay releasing JDK 7, and add many bugs.
-
What's the point of copying Apache Commons if it already exists?
-
1) Might be asking a lot but my wish would be a diff engine for Java beans similar to windiff. Basically something that given a pair of beans can spit something out that showed me what all the differences were. I've written something like this before (sally for a proprietary company so I can't share the code) and it isn't that hard to do but a properly maintained one would be really handy. It’s the sort of thing that when writing auditing for an app can save you a ton of time.
2) Rather less interesting every project I've ever done seems to need an isNullOrEmptry check for strings – i.e:
public static boolean isNullOrEmpty(String text) {
if(text == null || "".equals(text.trim())) {
return true;
}
return false;
}
Hardly rocket science I know…
3) Most of the other suggestions on the original post seem quite sensible to me apart from all the null masking stuff that Colebourne wants to introduce. I don't see much in adding everything from the commons collection. -
Please don't - most of apache software is horribly implemented and has that horrible horrible log4j everywhere. (actually i don't blame log4j - it works fine! - but libraries shouldn't use it!!! send events round the place please)
More than this: why bloat with stuff thats already in existence?
this just strikes me as more fiddling while the real important stuff goes ignored. see "project coin" for more twiddling... -
A null-safe equals(), a clone() method and an hashCode() implementation are worth a discussion, but the other suggestions belongs to other (utility) classes then java.lang.Object.
-
The idea of toString(arg) returning all of the fields inside the object 'arg' is a good idea. I am assuming that it is recursive i.e., toString() will be called on the nested/contained objects if any.
Question is, what will be the format of the output string?
Adding a capability to specify a format viz., XML, YAML/JSON etc. can prove the toString(x) be very helpful. Is this thought about?
If being able to print object on console is the only goal, then YAML/JSON can be a default choice and being able to support XML can also provide a handy solution in serialization of objects for the users. -
This is a bad idea. It would just increase the bloat in JDK. And those methods won't be used by majority of developers. I'm developing for years and need for such methods is so rare that it does not worth to put them into Object.
This also violates KISS principle. -
I occasionally find myself writing
if (obj instanceof MyClass)
{
MyClass mc = (MyClass)obj;
mc.mcMethod();
}
I wonder if Object could be enhanced to allow for something like:
obj.as(MyClass.class).mcMethod();
This of course begs the question, what if obj is not an instance of MyClass? In that case the statemtent would be ignored. Now I suppose if the statement were a declaration (e.g., int y = obj.as(MyClass.class)...) then the statement couldn't be ignored, in that case, it would have to be treated as if it had been written just "int y;". -
It's not an OO thing to do. If you're going to add Object related functionality, it belongs in Object (and if you really want to make me happy, implement mix-ins so we can add our own functionality to any object). The only really useful additions I can think of to Object would be:
boolean Object.safeEquals(Object)
Bytes Object.size() (see wicket for Bytes object and implement as deep sizeof using instrumentation API)
Since Java doesn't have mix-ins (particularly dynamic ones), it might be interesting to allow meta-data object associations:
Object.set(MetaData.Key<T> value)
T Object.get(MetaData.Key<T>)
(this would be implemented with a MetaData object map (ala com.locke.library.utilities.metadata in twenty-six-wicket-tricks on google code) on the side (adding no instance fields to Object, obviously)).
Also, I think a MutableObject<T> would be a nice thing to have in the java core. I implement that one almost every project.
And, BTW, I think making Package work 100% of the time in Class would be of some benefit. We have a workaround in Wicket called PackageName, but that code is undesirable.
There are a number of missing methods in String and List (the obvious first() and last() methods are missing, for example), which could be added. I especially would like to have easy String path-like parsing with:
String String.afterFirst(char)
String String.afterLast(char)
String String.beforeFirst(char)
String String.beforeLast(char)
could also use:
String String.capitalize(String)
String String.decapitalize(String)
and a more efficient replace (that doesn't use regexps), and I'd like this one too:
String String.stripEnding(String ending)
oh, and while you're at it, i'd like member reflection constants like xyz.field and xyz.method.</t></t></t> -
What's the point of copying Apache Commons if it already exists?
In some orgs, you are not allowed to add 3rd party jars - as stupid as it might sound, that's reality. Having some or all of the great functionality from apache commons will greatly help. Plus it would consolidate that functionality into one place.
Consider Swing's threadWorker - IIRC it started as a 3rd party lib, and it is now part of the JDK. Good stuff that is more or less a de-facto stardard should be moved into the JDK. -
Please don't - most of apache software is horribly implemented and has that horrible horrible log4j everywhere. (actually i don't blame log4j - it works fine! - but libraries shouldn't use it!!! send events round the place please)
More than this: why bloat with stuff thats already in existence?
this just strikes me as more fiddling while the real important stuff goes ignored. see "project coin" for more twiddling...
Uh, did you configure log4j so that it doesn't send events everywhere? The only time "I" see the commons stuff sending log4j messages is when "I" EXPLICITILY configure it to do so, for debugging purposes. -
This is a bad idea. It would just increase the bloat in JDK. And those methods won't be used by majority of developers. I'm developing for years and need for such methods is so rare that it does not worth to put them into Object.
This also violates KISS principle.
What, you have never had a need for implementing null-safe comparators, formatters, bean property copiers, predicated/filtering collections? Never had a need to reduce re-inventing some or all of the wheels when doing those? -
This is a bad idea. It would just increase the bloat in JDK. And those methods won't be used by majority of developers. I'm developing for years and need for such methods is so rare that it does not worth to put them into Object..
Luckily for you that also isn't the case here. The mentioned utility methods will end up in java.util.Objects, which is distinct from java.lang.Object. But you knew that, didn't you? -
Luckily for you that also isn't the case here. The mentioned utility methods will end up in java.util.Objects, which is distinct from java.lang.Object. But you knew that, didn't you?
No, I missed the package. My bad :) -
What, you have never had a need for implementing null-safe comparators, formatters, bean property copiers, predicated/filtering collections? Never had a need to reduce re-inventing some or all of the wheels when doing those?
Yes, never had a need for all of them. Still I had need for some of them, but those were really rare cases. In such cases either own code or existing non-JDK libraries can be easily used. -
+1 for:
byte[] serialize(Object obj)
Object deserialize(byte[] data)
Also:
String dump(Object o)
Making a best effort to present the object in human readable form, similar to Eclipse's debug view, useful for logging at debug level. -
It'd be nice to have a String toJSON(Object) method. It'd get all the members' values by calling the getters via reflection and using the getter name - the "get" prefix to name the output JSON attributes.
-
If they wer already in the JDK, you would not need to include other libs to your project
-
If they wer already in the JDK, you would not need to include other libs to your project
Sure. But you can't put everything into JDK. Libs are exactly for this purpose. JDK should include only the most commonly needed functionality, the rest should be in libs. In my opinion this is not the most commonly needed functionality. And I believe JDK already contains too much functionality which can reside in external/additional libs well.
At the same time there are areas where Java is weak (like closures or multimedia). So, I think JDK guys should concentrate on those areas (because only they can do this). And not implement in JDK functionality which is already available in external libs. -
At the same time there are areas where Java is weak (like closures or multimedia). So, I think JDK guys should concentrate on those areas (because only they can do this). And not implement in JDK functionality which is already available in external libs.
Taking your point about JDK containing too much functionality which can reside in external libs multimedia seems to me to be an example of something better residing outside the JDK since it wouldn't be well served by the long release cycles of the full JDK. JavaFX, whilst it still has a way to go, is doing a pretty good job in this area in my view. With closures Sun obviously wanted to add them in but didn't feel it has enough support from Java devs as a whole to risk it so really we only have ourselves to blame here. -
Two suggestions:
First would be compile-time null-safety checking. There are already code analysis tools which can do analysis on the code to and determine code which could be not null-safe. Perhaps if the compiler would be able to include similar analysis and raise at least a warning if it finds any code which isn't null-safe. Eiffel's latest version includes similar checking (they use void reference in place of null reference), and the whitepaper on the subject at: docs.eiffel.com/sites/default/files/void-safe-e....
Second would be to have null be the ultimate object which implements all classes and does nothing and returns null in all cases (with certain exceptions if dealing with multiple null objects). While this would remove the NullPointerException (all cases would just do nothing and return null), I wouldn't recommend this without at least the compile-time warnings as described in my first suggestion, as this would be so prone to errors in unchecked code. Another difficulty of this would be determining (in a semi-general way) in what cases operations on the null object would return null and in what cases operations would return some other value (for instance null+1 -> null, while null==1 -> false, or sum(1,2,3,null,5) -> 11).
Of course I do like the other suggestions for making more methods null-safe by handling null inside the core code rather than expecting developers to have to include all-too-redundant null checks throughout their code. Null shouldn't be considered something to be avoided resulting in catastrophes when it is accidentally used, but as a valid representation of nothing or no value to be handled gracefully whenever it is present. It's kind of like 0 in that way - 0 being a representation of how many apples you have after someone takes your last apple.
28 comments
Watch Thread Reply