3 ms·
The standard method for getting around this in the java world is to create 'sane' libraries (in the case of android http, something like http://loopj.com/androi
by RyanZAG 13y ago
The standard method for getting around this in the java world is to create 'sane' libraries (in the case of android http, something like http://loopj.com/android-async-http/ http://loopj.com/android-async-http/ ) and then just use the library. The strong point of Java is just how many libraries there are - you often don't need to touch the actual built in Java APIs. On the server side (non-android) this has gone even further through the use of new annotation based libraries that generally autodiscover classes in your code, removing a lot of boilerplate.
One area in Java that is still incredibly annoying, however, is the ubiquitous getter/setter pattern that bloats all Java code for zero benefit to anyone.
- StavrosK 13y agoYep, that's what I ended up using, and it works very well. I especially like the interface (well, by Java standards).
- Yhippa 13y agoI feel something as commonplace as making a HTTP GET or POST should be standardized at this point. There are many implementations which still require a decent amount of boilerplate.
- RyanZAG 13y agoThe core java library has mostly been kept unchanged for a decade now (I think?). Java 8 is doing the largest change to it in a long time by changing the collections to work with lambdas. The main goal behind the standard Java library (from what I have gathered) has always been to provide a mid-level API to most possible functionality in an OS so that library developers can develop simple Java libraries that work across all platforms supported by Java. The big changes to the JRE libraries in the early years of Java was really what caused all of the big problems Java has had. Since the JRE stopped evolving, (server side) Java has really thrived with most code being very easily deployable anywhere and everywhere in the enterprise. If you're going to program in Java, you should use libraries for commonplace tasks, and you should use an IDE to autocomplete package names and 'run' blocks. If you do this, Java really does work very well. For huge classes of coding tasks, the excessive boilerplate and compile time checks / exceptions can make it possible to tell very quickly if code is correct or not even without tests which is a major boon for code review purposes in enterprise. Ultimately what I'm trying to say is that Java really does work very well and has come a very long way in creating a very productive environment for large projects, and it's why Java is so popular and heavily used even when at first glance it looks terrible.
- depsypher 13y agoYou can even get rid of getter/setters with annotations: http://projectlombok.org/ http://projectlombok.org/