Java's Properties object hasn't changed much since pre-Java 5, and it hasn't got Generics support, or very useful helper methods (defined pattern to plug in classes to process properties or help to load all properties files in a directory, for example).
Has development of Properties stopped? If so, what's the current best practice for this kind of properties saving/loading?
Or have I completely missed something?
A lot of the concepts around Properties are definitely ancient and questionable. It has very poor internationalization, it adds methods that today would just be accomplished via a Generic type, it extends Hashtable, which is itself generally out of use, since its synchronization is of limited value and it has methods which are not in harmony with the Collections classes introduced in 1.2, and many of the methods added to the Properties class essentially provide the kind of type safety that is replaced by Generics.
If implemented today it would probably be a special implementation of a Map<String, String>, and certainly support better encoding in the properties file.
That being said, there isn't really a replacement that doesn't add complexity. Sure the java.util.prefs.Preferences api is the "new and improved" but it adds a layer of complexity that is well beyond what is needed for many use cases. Just using XML is also an option (which at least fixes the internationalization issues) but a properties object often fits the needs just fine, at which point use it.
It's still a viable solution for simple configuration requirements. They don't need generics support because Property keys and values are inherently Strings, that is, they are stored in flat, ascii files. If you need un/marshaling/serialization of objects, Properties aren't the right approach. The preferred method is now java.util.prefs.Preferences for anything beyond even moderately sophisticated configuration needs.
It does what it needs to do. It's not that hard to write support for reading in all the properties files in a directory. I would say that's not a common use-case, so I don't see that as something that needs to be in the JDK.
Also, it has changed slightly since pre-Java 5, as the Javadoc says that extends Hashtable<Object, Object> and implements Map<Object, Object>.
"it hasn't got Generics support,"
why does it need generics support; it deals with string key and string values
I would not consider Java properties deprecated. It is a mature library - that's all
The dictionary structure is one of the oldest most used structures in most programming languages http://en.wikipedia.org/wiki/Associative_array, I doubt it would be deprecated.
Even if were to be removed there would soon be new implementations outside of the core.
There already are external extensions, apache commons are great resources that I think have helped to shape java over the years, see http://commons.apache.org/configuration/howto_properties.html.
Related
Why NavigableMap interface was created with additional method definitions and extended with SortedMap, while they could have added it in SortedMap interface and as usual implemented them in TreeMap?
The internet is filled with answers that it was included to navigate across the map. Here what does navigate mean?
SortedMap interface is already published (since 1.2). That means that there are maybe hundreds or thousands classes somewhere out there that rely on SortedMap. If you would add new methods to SortedMap in 1.6, without providing default method implementations, this would break all those classes that implement SortedMap. Given that so much stuff relies on Java, this would break literally everything on the planet. I hope that it is obvious that "not breaking everything on the entire planet" is a good enough reason for not adding some obscure methods willy-nilly (It's obviously an overly dramatic and tongue-in-cheek description of what would actually happen. If the maintainers of the Java standard library did that, then nobody would use the new version, and someone would probably file a bug report, that's it).
The documentation states quite clearly what "to navigate" means:
Methods lowerEntry, floorEntry, ceilingEntry, and higherEntry
https://docs.oracle.com/javase/7/docs/api/java/util/NavigableMap.html
It means that you can not only lookup and traverse, but also find entries which are "close" to the requested key.
I won't speak to what uses NavigateMap has but in terms of why the SortedMap interface was not modified instead of adding a new interface; that was because it would break existing implementations. As you point out TreeMap etc. could be updated to implement the new methods but what about custom implementations of SortedMap? So any legacy code out there that upgrades to JRE 1.6+ would need to search the code base and implement these new methods, but Java advertises itself as being backwards compatible (for Java 6 at least when NavigateMap was added)
arraylists, buffered reader, scanner, etc.. all "Default" classes that "already exist" in the language..
unlike, say, public class widthOfTable which would be a "made up" class , that " did not already exist in language"..
why is there no term to distinguish these ideas when teaching? I barely discovered this difference in college , despite being here 3 years.
Actually, there is a pretty strong distinction between what you called "default" and "made-up" classes, which has to do with their package names.
All "default" classes are in some java.* package (java.lang, java.util, etc.), and no "made up" class could use a package name that starts with java..
As for the fact that this distinction is blurred "when teaching", my feeling is that it's intentional. Java as a language is pretty much a set of keywords and syntax rules plus a java.lang.Object class that nobody could avoid extending (and which uses a few other built-in types like String, Integer and some exceptions).
The JDK is a Java library to help you with the most common use-cases, but in some cases there are better alternatives.
In my opinion, it would be a mistake to teach someone that java.util.Calendar or the java.util.logging stuff have any advantage over JodaTime or SLF4J just because they're in the classpath by default.
I had the same question in my mind before and i had a different term for your word default and I called them built-in classes.
why is there no term to distinguish these ideas when teaching?
there is already but taught indirectly using the terms packages and namespaces
if there is a time that you will design a programminng language you can tell any developer what are those default or built classes by putting them in right packages and namespaces for example
mydefaultclasses.io.print
mydefaultclasses.io.read
in java its really understandable that any classes under java namespace is a default or built-in class. it really depends upon what will came up on the documentation of the language you are trying to learn.
Not sue if I totally understand your question, but you can find all the predefined classes in Java under the Java Class Library: Java Class Library.
Actually it is more powerful to have packages or namespaces. Your way of thinking is like an implementation that only supports two namespaces. The standard library (in this case the java.*, in c++ std) is one, the other is all your other stuff. After a while, you probably end up with a new set of "default" classes anyway and you put those in a package to avoid clutter your global namespace.
I was frustrated recently in this question where OP wanted to change the format of the output depending on a feature of the number being formatted.
The natural mechanism would be to construct the format dynamically but because PrintStream.format takes a String instead of a CharSequence the construction must end in the construction of a String.
It would have been so much more natural and efficient to build a class that implemented CharSequence that provided the dynamic format on the fly without having to create yet another String.
This seems to be a common theme in the Java libraries where the default seems to be to require a String even though immutability is not a requirement. I am aware that keys in Maps and Sets should generally be immutable for obvious reasons but as far as I can see String is used far too often where a CharSequence would suffice.
There are a few reasons.
In a lot of cases, immutability is a functional requirement. For example, you've identified that a lot of collections / collection types will "break" if an element or key is mutated.
In a lot of cases, immutability is a security requirement. For instance, in an environment where you are running untrusted code in a sandbox, any case where untrusted code could pass a StringBuilder instead of a String to trusted code is a potential security problem1.
In a lot of cases, the reason is backwards compatibility. The CharSequence interface was introduced in Java 1.4. Java APIs that predate Java 1.4 do not use it. Furthermore, changing an preexisting method that uses String to use CharSequence risks binary compatibility issues; i.e. it could prevent old Java code from running on a newer JVM.
In the remainder it could simply be - "too much work, too little time". Making changes to existing standard APIs involves a lot of effort to make sure that the change is going to be acceptable to everyone (e.g. checking for the above), and convincing everyone that it will all be OK. Work has to be prioritized.
So while you find this frustrating, it is unavoidable.
1 - This would leave the Java API designer with an awkward choice. Does he/she write the API to make (expensive) defensive copies whenever it is passed a mutable "string", and possibly change the semantics of the API (from the user's perspective!). Or does he/she label the API as "unsafe for untrusted code" ... and hope that developers notice / understand?
Of course, when you are designing your own APIs for your own reasons, you can make the call that security is not an issue. The Java API designers are not in that position. They need to design APIs that work for everyone. Using String is the simplest / least risky solution.
See http://docs.oracle.com/javase/6/docs/api/java/lang/CharSequence.html
Do you notice the part that explains that it has been around since 1.4? Previously all the API methods used String (which has been around since 1.0)
Is there any way we can inject new methods and properties into classes during run-time.
http://nurkiewicz.blogspot.com/2009/09/injecting-methods-at-runtime-to-java.html states we may do that by using Groovy.
Is it possible by just doing using Java?
Is it possible by just doing using
Java?
The simple answer is an emphatic "You don't want to do that!".
It is technically possible, but not without resorting to extremely complex, expensive and fragile tricks like bytecode modification1. And even then, you have to rely on dynamic loading to access the modified type and (probably) reflection to make use of its new members. In short, you would be creating lots of pain for yourself, for little if any gain.
Java is a statically typed language, and adding / modifying class type signatures can break the static typing contract of a class.
1 - AspectJ and the like allow you to inject additional behaviour into a class, but it is probably not the "runtime" injection that you are after. Certainly, the injected methods won't be available for statically compiled code to call.
So if you were really crazy, you could do something like what they outline here. What you could do is load the .java file, find the correct insertion point, add whatever methods you need to, call the java compiler and reload the class. Good luck debugging that mess though :)
Edit This actually might be of some use...
You can do some quite funky things with AOP, although genuine modification of classes at runtime is a pretty hairy technique that needs a lot of classloading magic and sleight of hand.
What is easier is using AOP techniques to generate a subclass of your target class and to introduce new methods into this instead, what AOP called a "mixin" or "introduction". See here to read how Spring AOP does it, although this may be quite lame compared to what you're actually trying to achieve.
Is it possible by just doing using Java?
Quite so, the "only" thing you have to do is define an instrumentation agent which supplies an appropriate ClassFileTransformer, and you'll have to use reflection to invoke the added methods. Odds are this isn't what you want to do, though, but it's doable and there's a well-defined interface for it. If you want to modify existing methods you may be interested in something like AspectJ.
While it might be possible, it is not useful.
How would you access these new fields and methods?
You could not use these methods and fields directly (as "ordinary" fields and methods), since they wouldn't be compiled in.
If all you want is the possibility to add "properties" and "methods", you can use a Map<String, Object> for the "dynamic properties", and a Map<String, SuitableInterface> for the "dynamic methods", and look them up by name.
If you need an extension language for Java, an embedded dynamic language (such as Javascript, or Groovy) can be added; most of these can access arbitrary java objects and methods.
I need to decide on which one to use. My case is pretty simple. I need to convert a simple POJO/Bean to XML, and then back. Nothing special.
One thing I am looking for is it should include the parent properties as well. Best would be if it can work on super type, which can be just a marker interface.
If anyone can compare these two with cons and pros, and which thing is missing in which one. I know that XStream supports JSON too, thats a plus. But Simple looked simpler in a glance, if we set JSON aside. Whats the future of Simple in terms of development and community? XStream is quite popular I believe, even the word, "XStream", hit many threads on SO.
Thanks.
Just from reading the documentation (I'm facing down the same problem you are, but haven't tried either way yet; take this with a grain of salt):
XSTREAM
Very, very easy to Google. Examples, forum posts, and blog posts about it are trivial to find.
Works out of the box. (May need more tweaking, of course, but it'll give you something immediately.)
Converting a variable to an attribute requires creating a separate converter class, and registering that with XStream. (It's not hard for simple values, but it is a little extra work.)
Doesn't handle versioning at all, unless you add in XMT (another library); if the XML generated by your class changes, it won't deserialize at all. (Once you add XMT, you can alter your classes however you like, and have XStream handle it fine, as long as you create an increasing line of incremental versioning functions.)
All adjustments require you to write code, either to implement your own (de)serialization functions, or calling XStream functions to alter the (de)serialization techniques used.
Trivial syntax note: you need to cast the output of the deserializer to your class.
SIMPLE
Home page is the only reliable source of information; it lists about a half-dozen external articles, and there's a mailing list, but you can't find it out in the wild Internet.
Requires annotating your code before it works.
It's easy to make a more compact XML file using attributes instead of XML nodes for every property.
Handles versioning by being non-strict in parsing whenever the class is right, but the version is different. (i.e., if you added two fields and removed one since the last version, it'll ignore the removed field and not throw an exception, but won't set the added fields.) Like XStream, it doesn't seem to have a way to migrate data from one version to the next, but unlike XStream, there's no external library to step in and handle it. Presumably, the way to handle this is with some external function (and maybe a "version" variable in your class?), so you do
Stuff myRestoredStuff = serializer.read(Stuff.class, file);
myRestoredStuff.sanityCheck();
Commonly-used (de)serializing adjustments are made by adding/editing annotations, but there's support for writing your own (de)serialization functions to override the standard methods if you need to do something woolly.
Trivial syntax note: you need to pass the restored object's class into the deserializer (but you don't need to cast the result).
Why not use JAXB instead?
100% schema coverage
Huge user base
Multiple implementations (in case you hit a bug in one)
Included in Java SE 6, compatible with JDK 1.5
Binding layer for JAX-WS (Web Services)
Binding layer for JAX-RS (Rest)
Compatible with JSON (when used with libraries such as Jettison)
Useful resources:
Comparison, JAXB & XStream
Comparison, JAXB & Simple
I'd recommend that you take a look at Simple
I would also suggest Simple, take a look at the tutorial, there and decide for yourself. The mailing list is very responsive and you will always get a prompt answer to any queries.
So far I have never use Simple framework yet.
Based on my experience with Xstream. It worked well on XML. However, for JSON, the result is not as precise as expected when I attempt to serialize a bean that contain a List of Hashtable.
Thought I share this here.
To get XStream to ignore missing fields (when you have removed a property):
XStream xstream = new XStream() {
#Override
protected MapperWrapper wrapMapper(MapperWrapper next) {
return new MapperWrapper(next) {
#Override
public boolean shouldSerializeMember(Class definedIn,
String fieldName) {
if (definedIn == Object.class) {
return false;
}
return super.shouldSerializeMember(definedIn, fieldName);
}
};
}
};
This can also be extended to handle versions and property renames.
Credit to Peter Voss: https://pvoss.wordpress.com/2009/01/08/xstream
One "simple" (pun intended) disadvantage of Simple and Jaxb is that they require annotating your objects before they can be serialized to XML. What happens the day you quickly want to serialize someone else's code with objects that are not annotated? If you can see that happening one day, XStream is a better fit. (Sometimes it really just boils down to simple requirements like this to drive your decisions).
Was taking a quick look at simple while reading stackoverflow; as an amendment to Paul Marshalls helpful post, I thought i'd mention that Simple does seem to support versioning through annotations-
http://simple.sourceforge.net/download/stream/doc/tutorial/tutorial.php#version
Simple is much slower then XStream(in serialization objects to xml)
http://pronicles.blogspot.com/2011/03/xstream-vs-simple.html