Summary
There has been much discussion of proposed new features for Java in recent times, but what problems do those features need to address? What are your actual pain points today with Java?
Advertisement
There has been much discussion and debate about new features for Java, such as the various closures proposals. Instead of talking about specific new features for the Java language, I'd like to take a step back and survey what the problems really are with Java right now. There's an old saying, "If it ain't broke, don't fix it," so I'd like to simply ask what's broke with Java right now?
Please post your list of Java pain points in the discussion forum. To keep weed out minutia (Java pin pricks), such as there's in the dictionary Cloneable wouldn't have an e, try and limit yourself to your top three pain points, in reverse order. Your most painful point will be your number 1, second most painful number 2, and third most painful number 3. Lastly, for each pain point, please try and explain the real business cost of the problem.
1) Lack of interactivity in development environments. I recently had to update a java web service and was frustrated by my inability to write a two liner and run it to see what it did. I do most development using Seaside in Squeak now and am accustomed to frequently writing snippets to verify my code does what I think it will. So I get more testing done in the more interactive environment and I have fewer bugs.
2) Crappy and inconsistent api design. This consumes a LOT of extra time looking stuff up for every other line of code. Even when I did Java daily (which I did for a few years) this was the norm. So productivity was way down.
3) Too much pointless boilerplate - too much typing to say too little. The stock answer to this is 'autocompletion' and 'tool support' but that's lame. When I say I can't walk, don't hand me crutches - fix my legs.
Lack of something akin to constructor classes <http://citeseer.ist.psu.edu/jones95system.html> to write better generic libraries. I needed it to properly parametrize a library I wrote that could group a collection of objects in a tree according to the given criteria. I wanted to write
report.by(PRODUCT).by(MONTH).group(sales)
and have the compiler verify the correct generic type (i.e. the resulting object has is of type
publicstaticfinal Property<Person, String> NAME = new Property<Person, String>() {
publicvoid set(Person p, String s) {
p.setName(s);
}
public String get(Person p) {
return p.getName();
}
}
This is a form of static reflection, which is very useful and nicer than working with strings (i.e. it's better to have a method
public <A,B> void foo(A a,Property<A,B> p, B b) {p.set(a,b);}
where the compiler can ensure that if p is not null it's a valid property). Together with a decent hierarchy for functions it can simplify many programming problems and require less creation of trivial
Runnable
s and
Callable
s.
A way to externally implement interfaces. Why can't I define a
interface that works for both IO thingies and SQL thingies without having to predict the future?!?! Structural subtyping also would be a nice solution to this problem, OTOH something like this <http://blogs.msdn.com/ralflammel/archive/2006/12/21/more-haskell-in-java-7-or-8.aspx> would be too much for Java (says someone who uses Haskell at home).
All three points above hit me at least once weekly on my day job (i.e. J2EE programming).
There are other more painful points, but changing them would be too radical and the resulting language wouldn't be recognizable as Java anymore.
It doesn't support mixins. This looks like an idle fancy, but it's not. *Not* having mixins leads many programmers into 'inheritance-for-convenience', that is, faking mixins by inheriting from the class that provides most of their functionality. Static imports only go so far towards fixing this, Scala's mixin feature could do the rest.
null. One big hole in the type system that is near impossible to fill in a perfect way. Gilad Bracha's pluggable types could help, but IDEs are some way from being that useful.
The annotation processor has a very limited view of the AST, and is only really for annotations. I'd rather have true macros a la Lisp, either as part of the language or an IDE.
The wasted time needed to put together even the simplest user interface. It still can take an hour or more to do what took a few tens of seconds with VB6 in the previous century.
The wasted time maniplating the Calendar, GregorianCalendar and Date classes to perform simple date and time handling.
The wasted time getting simple number displays to format properly.
The wasted time handling streams and file I/O.
The wasted time coming to grips with the obscure syntax that is being used to introduce new features.
The requirement to retain backwards compatability with depricated methods from versions of Java that were superceded in the prevous.
As Todd says, just way too much verbage. But it's not the verbage in itself that's the problem. The problem is that even when you've found all the words/method calls/syntax etc. then the solution you write is still only an approximation to the solution you want.
1) AWT/Swing - the single reason I choose to write web apps rather than desktop apps. HTML is 10 times more productive. 2) Date/Calendar - why oh why! 3) Bean objects - it feels like 50% of my lines of code consists of set/get methods. Whatever other nice things Scala has got, I think that feature on its own would pay for itself in preserving my 'e' and 't' keys.
As a general comment, I'd prefer the general Java effort to move in the direction of making things simpler and more reliable in what it does at the moment, and supporting other languages, rather than trying to be something it's not.
I'd agree that where the Java platform hurts the most is not the language itself, but adequate tool support for dealing with day to day drudgery.
I'd like to compare the Sun endorsed Netbeans platform with Visual Studio.
1. An easy way to pull a GUI together Vincent said it well, and I repeat, when do we get to press "next, next, next" to pull together a data driven application in a few seconds ;) Visual studio has been providing this for aeons.
2. An easy way to package and deliver such a GUI In .NET, it takes seconds to create a setup program that an end-user can double click and execute. In Java one has to deliver an executable jar file? I wouldn't expect an end-user to know what that is. Shouldn't something as simple as this be a standard feature, ideology about platform independence not withstanding?
My take is that the the Java camp has always concentrated on trying to design elegant APIs but always fails to go the last mile: end-user and developer friendliness in terms of usage.
XML configuration files. Java doesn't let me type in nested data structures (dictionaries of lists of sets, for example), so I have to put my Tomcat, Ant, and Hibernate configs in XML. Problem is, what do I single-step through when I get it wrong? And over time, all these "configuration" syntaxes turn into mini-programming languages, since they all need conditionals, iteration, and so on. Compare CONS or SCons to Ant, and you'll see how easy life *isn't* for Java developers...
Some time ago (maybe with the introduction of JNDI?) a pattern of inappropriate abstraction seemed to take root, especially in the javax.* families. It seemed to work like this: Java needs X; other pacakge(s) provides X; we'll define a generic interface to X and a bridge/SPI framework make a consistent way of doing it. Even if there is only one useful provider of a feature, we'll make an abstraction.
This has led to the horrid XML, security/crypto and JNDI frameworks. The main usage of JNDI in my experience is to obtain references to database connection pools. I guess when I have had the misfortune of using EJB, I had to deal with it for that as well. And to get meaningful data from an LDAP drirectory you have to use the LDAP-specific APIs anyways.
And was it ever that hard to parse XML via:
MyFavoriteDOMParser p = new MyFavoriteDomParser(); p.parse(whatever); org.w3c.dom.Document thankYou = p.getDocument();
or
org.xml.sax.XmlReader xr = new MyFavoriteSAXParser(); xr.setContentHandler(thankYou); xr.parse(whatever);
e tc.
I won't even go into the pain of trying to interact with X.509 certificates here. That API set by itself is enough to drive one to consider a new career.
Seriously, all of this talk about continuations seems like complexity for complexity's sake. How many ham-and-egg Java applications are even algorithmic enough to take advantage of this feature? Given Java's well-known reputation for verbosity, one would think that something like *macros* would be the fashionable Lisp-y feature to implement.
"It doesn't support mixins. This looks like an idle fancy, but it's not. *Not* having mixins leads many programmers into 'inheritance-for-convenience', that is, faking mixins by inheriting from the class that provides most of their functionality. Static imports only go so far towards fixing this, Scala's mixin feature could do the rest."
Definitely agree about the first half. I don't understand how static imports fix this at all. Am I just being obtuse? There are many different ways mixins could be realized, and Scala's implementation is nice because it's fully interoperable with Java, which gives it some hope.
"null. One big hole in the type system that is near impossible to fill in a perfect way."
The Nice Programming Language can do it, which just demonstrates the gripe most people have about null is very valid. Hindsight is 20/20, however.
Hmmm...seems like many people aren't gripping about existing Java features but rather asking for new ones. Maybe Java is almost perfect in what is has but just incomplete??? ;-)
1. Collections API doesn't doesn't separate mutator methods in interfaces from read methods; creating "unmodifiable" collections with the same interface as mutable collections is a hack; immutability should be something explicit in the contract
2. Date/Calendar API - see JodaTime for something better, but that I think could still be improved.
3. Finer grained exceptions with more information on what failed and why
Flat View: This topic has 264 replies
on 18 pages
[
123456
|
»
]