The Artima Developer Community
Sponsored Link

Weblogs Forum
What Are Your Java Pain Points, Really?

264 replies on 18 pages. Most recent reply: Jan 17, 2008 7:07 AM by GJ sonke

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 264 replies on 18 pages [ 1 2 3 4 5 6 ... 18  | » ]
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

What Are Your Java Pain Points, Really? (View in Weblogs)
Posted: Feb 9, 2007 4:22 PM
Reply to this message Reply
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.


Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 9, 2007 5:18 PM
Reply to this message Reply
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.

Daniel Yokomizo

Posts: 22
Nickname: dyokomiso
Registered: Sep, 2002

Re: What Are Your Java Pain Points, Really? Posted: Feb 9, 2007 6:20 PM
Reply to this message Reply
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
Map<Product,Map<Date,Collection<Sale>>>
).

Static reflection a la Metaphor <http://sky.fit.qut.edu.au/~neverov/metaphor/>. There are many places where I use things like:
public static final Property<Person, String> NAME = new Property<Person, String>() {
    public void 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
Closeable<throws E> {public void close() throws E;}
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.

Ricky Clarkson

Posts: 63
Nickname: rclarkson
Registered: Jul, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 9, 2007 6:55 PM
Reply to this message Reply
"A way to externally implement interfaces. Why can't I define a Closeable<throws E> {public void close() throws E;}"

Because you don't know how.

interface Closeable<E extends Exception>
{
    void close() throws E;
}

Ricky Clarkson

Posts: 63
Nickname: rclarkson
Registered: Jul, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 9, 2007 7:03 PM
Reply to this message Reply
The problems that I see with Java:

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.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 1:24 AM
Reply to this message Reply
These are just some very basic peeves:

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.

Andreas Andreakis

Posts: 3
Nickname: andreasa
Registered: Feb, 2007

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 2:06 AM
Reply to this message Reply
1) the semicolon ";"


2) Explicit typing. I would prefer infered typing, example:

//Compiler knows that list is of Type ArrayList
var list = new ArrayList(); 

The only place you have to specify Types are methodparameters and some other special (rather rare) cases.

Scala and the upcomming F3 Language (both JVM languages) work like this (http://blogs.sun.com/chrisoliver/resource/f3.html)


3) Missing runtime type check for Generics

suppose the follwing example, a method which checks if the given list contains an element of Type T:
public class MyClass<T>{
 
	public boolean containsTypeT(List list){
		
		for (Object object : list) {
			if(object instanceof T){ // ERROR 
				return true;
			}
		}
                return false;
	}//end method
}

This does not compile. Instead the method has to be rewritten as followed:

        // new Parameter Class<T>
	public boolean containsTypeT(List<?> list, Class<T> type){
		
		for (Object object : list) {
			if(type.isInstance(object)){
				return true;
			}
		}
		return false;
	}

Jay Sachs

Posts: 30
Nickname: jaysachs
Registered: Jul, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 4:02 AM
Reply to this message Reply
1) Lack of named parameters. Once you have these, most objects can conveniently become immutable.

2) Type erasure.

3) Ditch arrays, and add syntactic sugar for literal list construction. Also, add full support for generic tuples.



Posts: 20
Nickname: johnnyo
Registered: Oct, 2002

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 5:31 AM
Reply to this message Reply
For the language, I don't have any deep sources of pain. And I wish with all my heart that no changes to the language take place at all in JDK 7.

For the libraries, the biggest sources of pain are Date/Calendar and ResourceBundle :

http://www.javapractices.com/Topic208.cjp

For conventions, the biggest source of pain is preference of frameworks for JavaBeans over immutable objects :

http://www.javapractices.com/Topic84.cjp



Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 6:56 AM
Reply to this message Reply
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.

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 6:59 AM
Reply to this message Reply
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.

Greg Wilson

Posts: 6
Nickname: gvwilson
Registered: Oct, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 7:05 AM
Reply to this message Reply
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...

Sean Wellington

Posts: 2
Nickname: sean8223
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 9:19 AM
Reply to this message Reply
Cognitive dissonance in the core APIs.

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.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 9:32 AM
Reply to this message Reply
"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.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 11:42 AM
Reply to this message Reply
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 [ 1  2  3  4  5  6 | » ]
Topic: What Are Your Java Pain Points, Really? Previous Topic   Next Topic Topic: The Future of Online Dialog

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use