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 10: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 7 ... 18  | » ]
Amr Ali

Posts: 3
Nickname: amreg
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 3:59 PM
Reply to this message Reply
Advertisement
1) Date manipulation is awful.
2) Why can't i pass objects by reference, this is very fundamental.
3) I think operator overloading will be very useful.
4) Type erasure is painful.
5) boxing and unboxing should be also used in generics, for example: List <int> x = new ArrayList<int>(); should be allowed, and the compiler should "box" it to be List <Integer> x = new ArrayList<Integer>();
6) inline methods should be supported.
7) String comparasion in switch statmens should be allwed.
8) the concept of "reference type" and "value type" of C# is very useful, why it is not avaialbel in Java?

Chris Dutton

Posts: 15
Nickname: cdutton
Registered: Jul, 2004

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 5:50 PM
Reply to this message Reply
> 7) String comparasion in switch statmens should be
> allwed.

Why stop with Strings? Why not do something like what Ruby does with ===, or incorporate pattern matching modeled after Scala into the language?

The effort would be better expended on fundamental improvements to the semantics of Java, than in hacking on more exceptions to the rules.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 6:12 PM
Reply to this message Reply
IMO, Java the language is in good shape. Some of the libraries are painful. The Javabean concept with set/get for dozens of fields is awful.

responding to a few of the specific complaints

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

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

This saves 1 character of typing in this example ("var" instead of "List"). What's the big deal? Also, for years we have heard "code to an Interface, not an implementation". I don't 100% agree with that dogma, but your suggestion goes entirely contrary to it.

>Bean objects

Don't use bean style objects, They are an abomination that the dark forces at Sun spread upon the world.

>2) Why can't i pass objects by reference

You can. Put them in an array. Sure, it's a kludge, but I hardly ever need this ability. Could you please provide some examples of where you are using this a lot?

>3) I think operator overloading will be very useful.

Please, no!!!!!

Dave Webb

Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 6:50 PM
Reply to this message Reply
> Don't use bean style objects, They are an abomination
> that the dark forces at Sun spread upon the world.

What other options are there? Public fields in classes?

Valery Silaev

Posts: 5
Nickname: vsilaev
Registered: Feb, 2007

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 6:57 PM
Reply to this message Reply
If I would have time machine and I get back in pre-java-5 time then I'd like to see
1. Function as first-class objects and free-standing functions (like Nice)
2. Closures (obvious result of [1])
3. Static reflection with compile time checking (again, as result of [1]) -- so you may get reference to object/class methods and invokes them in type-safe manner or pass as method argument or return from method
4. Delegates -- actually, this would be combo of [3] and [2]. The items [1] through [4] are my major pain with Java language – I forced to use inflexible reflection API or one-method interfaces for trivial things here and there: factory method, event listeners, callbacks etc.
5. Type parameters variance enforced in declarations rather then in client code -- like in Scala, see Scala examples for collection classes.
6. Type aliases and/or more type inference -- I'm sick of statements like HashMap<String, Date> events = new HashMap<String, Date>(). Also I'd like to know the name of that idiot who named class java.sql.Date after existing java.util.Date and made first a subclass of second.
7. C#- or Delphi-like properties. Yes, I know your contra-argument -- IDE can write code for JavaBean-like properties. Unfortunately, IDE can't read code for me ;) Items [5] to [7] are my second complain – Java language is unacceptably verbose.
8. Strong OS integration. Guys, do you think it's normal that two Java applications on same computer talk to each other via sockets? Where is shared memory support? Where are functions to monitor file systems? Also, please take a look at JNIWrapper library -- a lot of code that Sun delegates to developers may safely exist in JRE/Standard lib itself. Java programs are aliens on any OS unless a lot of effort put in custom JNI code.
9. JRE installation should be modular with on-demand loading of necessary part. Core must have size at max. 1-3MB. I don't need JDBC API and JdbcOdbc driver in 100% percents of desktop applications I've developed. Many of my applications don't use WS (but rather REST-like HTTP queries). After stupid move from CORBA to WS (CORBA with inefficiencies as one of my fellow developers says) why JRE contains CORBA classes? Why I have to download AWT and Swing when I need JRE for Tomcat? Size of JRE is smaller then size of .NET, but JRE packaging is dumb and does not reflect “client xor server” scenarios.
10. Serious API rewrite: java.util.Calendar -- excellent example how to write non-OOP code in OOP language; java.net.* -- where server-side Java ends due to heavy use of statics (take a look how authorization and proxy are supported); java.net.* -- closed for extensions (heh, ever tried to access WebDAV server with standard network library?); javax.swing.* -- you must understand 80% of framework to do 20% of your task Core Java API are superseded by open-source Java libraries for a long time – it’s time to include them in core

But... Now we have Java 6 and Java 7 is in development. And I understand that any significant changes to Java language or API will just kill this language sooner then it dies itself if things stay "as is". So my only wish is: stop altering Java! Instead, introduce and aggressively promote new statically-typed JVM language that is fully interoperable with Java! Take Scala as basis... Or Nice... Or both. Yes, this is .NET route, but who says that is wrong route?

VS

Stephen Colebourne

Posts: 3
Nickname: scolebourn
Registered: Feb, 2007

Re: What Are Your Java Pain Points, Really? Posted: Feb 10, 2007 7:05 PM
Reply to this message Reply
Firstly, many of the answers so far have been solutions, and don't answer the question Bill posed. Perhaps some who have commented so far might rephrase their answers?

Secondly, for those who complained about Date/Calendar, think about contributing to JSR 310 - https://jsr-310.dev.java.net/.

Finally, my three items -
1) That the code I have to write to express my intent is so verbose that once complete I can no longer see the intent.

2) er, I think (1) is about it really

3) yep, (1) is definitely the whole problem with Java

The trouble is that until you look beyond the confines of Java you probably don't realise how far we are from being able to write the 'simplest thing that works'.

Robert Konigsberg

Posts: 6
Nickname: konigsberg
Registered: Feb, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 11:27 AM
Reply to this message Reply
1. Here documents. Mult-line strings. Call it what you will. Embedded XML isn't it.

2. Easy Closures.

That would do it for me.

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 12:11 PM
Reply to this message Reply
I'm glad you asked this question -- it's an excellent one.

I think some of the previous posts have been spot on about the general ugliness and inconsistency of the Java APIs, as well as in pointing out some clumsy implementations of essential classes for dealing with dates, numbers, and so forth. As bad as this stuff is though, over time, even these have been supplanted for me by my current top three Java pain points, which are, without further ado (drum roll please):

1. Java reflection is godawful. Method overloading -- a bit of syntactic sugar with little practical value -- greatly complicates the issue, but the implementation is horrible anyway. Java really ought to have a relatively simple and consistent set of APIs to provide this functionality.

2. No real class methods. In Java, classes aren't proper objects, and therefore don't have methods. They have constructors (which are not methods) and they can have static 'methods,' which are nothing more than functions, and are therefore not extensible, i.e. you can't override them in a subclass. Constructors are lame. They don't have return values, and they require calls to super to occur on the first line of code, both of which tremendously limit their flexibility. If constructors were methods, then I could, for example, return an instance of a subclass -- something I frequently would like to do. Constructors also have weird inheritance rules that unnecessarily complicate their usage in subclasses.

The lack of true class methods in Java has led many developers to adopt the Factory (anti-)pattern. Since that approach is terribly flawed IMO, in time, hacks to the compiler (or the runtime) began to surface to support AOP. That leads me me to wonder -- if things like this are so fundamentally broken in Java, why do the spec leads focus all their energy on new language features like generics and closures?

3. Lack of dynamism. Because method invocations are statically bound in Java, we are forced to provide a cast in order to call a method on an object typed to a superclass. Note that I'm not arguing against facilities that allow casting; that's obviously a good thing. However, there are cases where it would be extremely useful to not be forced to cast to a more specific subtype, though of course that would necessitate adding language-level support for dynamic binding.

For example, suppose you needed to implement generic copy and paste behavior. The objects to which these behaviors might apply could be files, bitmaps, sounds, graphics, etc., so you might be dealing with objects from different class hierarchies. It would be convenient to have these objects provide their own implementations of cut, copy and paste, since the implementations would vary according to type. User interface code could simply call these methods, as needed, without needing to know which specific subtype it was currenlty dealing with.

Java interfaces would seem to provide a way to deal with this situation, but unfortunately that approach has often proven to be too inflexible. For one thing, all the relevant code has to be compiled against the same interface file, which in many cases is simply not possible. This approach can also lead to backwards-compatibility nightmares when for new versions of an interface. Some previous posters in this thread have proposed mixins as a solution, though dynamic binding (especially with the addition of improvements to Java reflection) seems to me to be a simpler approach, as shown in the following example (with a nod to Objective C):

private Object selectedObject;

public void cutSelectedObject()
{
if (selectedObject.respondsTo("cut()") {
selectedObject.cut();
}
}

The preceding code snippet assumes the addition of a respondsTo method to the Object class, and that the Java compiler and runtime have been modified to support dynamic binding. This would allow the interface that defines the cut, copy and paste methods to be provided as a specification, rather than as a compile-time artifact. Calling code could then proactively check to see if an object responds to a given message before attempting to send it, and in this way avoid runtime exceptions.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 1:49 PM
Reply to this message Reply
Jonathan,

>1. Java reflection is godawful. Method overloading -- a bit of syntactic sugar with little practical value

I personally greatly appreciate method overloading. Writing methods that can take a variety of parameter types in dynamic languages like Python that don't support method overloading can be a pain. I think in a statically type languages method overloading is essential.

I agree that the reflection API could be greatly improved.

>2. No real class methods. In Java, classes aren't proper objects, and therefore don't have methods.

I agree that classes should be proper objects.

>3. Lack of dynamism

I think better support for dynamic languages should added to the JVM but I don't think Java the language should be made dynamic. Making Java "dynamic" would break the conceptual integrity of the language.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 3:07 PM
Reply to this message Reply
> 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.
I think this problem could be solved if the apache commons libraries were integrated into the JDK.
Yes, this answer is 'tool support', but that won't hurt in daily work.
What still makes me shudder: How much code I have written until I found out that apache commons already had it.

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 4:59 PM
Reply to this message Reply
1. bean manipulations awkward yet beans are a core feature. We wouldn't need the majority of our libraries if we could easily code a lot more magic with them. (typesafe method and field references belong in this category)
2. no multiline strings - if you don't want me doing this, make some invisible configuration mechanism which can "auto-read and reload" config data without the use of stupid properties classes or 3rd party configuration apis. OR just give me multiline strings. i've written a stupid javascript page so i can go back and forth between "java quoted strings" and real strings.
3. re-implement equality. i just generate this and hashcode methods with my ide. pointless boilerplate. keep the old "version" around so people have some pointlessly tricky question to ask on interviews.
4. startup time, been said before. have the JVM ready to go, and make applications start as children of it. start up time pains me.
5. first class functions (not closures) would be very nice as a way to simplify some dynamic behavior.

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 5:04 PM
Reply to this message Reply
Re: "simplest thing that works". I'll happily stick with the simplest type-safe thing that works.

The thing to remember is that ultimately Java development is not that slow. It's always in a statistics vacuum that people seem to fervently agree that Java development takes forever and Ruby apps are instantly up and running.

Bob Foster

Posts: 4
Nickname: bobfoster
Registered: May, 2004

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 8:16 PM
Reply to this message Reply
3. The cruft in the language is piling up at an alarming rate. Boxing is a bad patch. Generics are a half-assed implementation. Annotations appear to be fully outa control. Closures...one can only keep the proposals keep thrashing past the deadline.

2. The footprint is enormous and growing rapidly.

1. The only platform you can ship a Java application to and assume Java will be there is MacOS X, and it is usually 6-9 months behind on major releases. Java installation is too hard for mere mortals, e.g., customers. Java is too big (see 2) to ship with your application, even if the licensing made it possible. If you want to ship a small web application, you won't be able to find a web host that supports Java at a reasonable price. If you want to produce a commercial desktop application or an applet that doesn't run in a controlled environment, forget Java. Your customer's machine won't have the version you need or won't have Java at all.

Ronald Pomeroy

Posts: 2
Nickname: sleepy
Registered: Feb, 2007

Re: What Are Your Java Pain Points, Really? Posted: Feb 11, 2007 10:43 PM
Reply to this message Reply
Calendar, GregorianCalendar.

Replace it all with JodaTime.

Need I say more?

Ron

Ronald Pomeroy

Posts: 2
Nickname: sleepy
Registered: Feb, 2007

Re: What Are Your Java Pain Points, Really? Posted: Feb 12, 2007 12:15 AM
Reply to this message Reply
Ok - I do need to say more :-)

Inconvienence.

I SHOULD be able to get from a filename to a stream in a few short steps:

String filename = "myFile.txt";
FileOutputStream = filename.asOutputStream(Stream.READONLY);
...

Reduntancy.

Why must I tell the compiler TWICE in one line the type of a variable:

I.E - MyClass something = new MyClass();

I'd just like to say:

var something = new MyClass();

And while I'm at it - why are constructors SOOO special that they need to reverse the rest of the messaging semantics (I.E - receiver dot message) ?

Can't it be:

var something = MyClass.new();

I also never liked using = for assignment. I prefer it be used as the test for
equality and == for identity. Throw in operator overloading and we can replace all that bla.equals(that)
code with bla = that (hey that's 1 character V.S. 6)

Extensibilty.

Why can't I add methods to existing classes? Is Sun afraid I'll hurt myself?

Closures.

The Java collection framework could learn a thing or two from Smalltalk.

Properties

Generating setters/getters is just pointless. Learn from Ruby.

I'm cutting myself off right here. I'm feel a streak of dynamic-language-advocacy welling up inside of me and I know that wouldn't be appropriate here :-)

RP

Flat View: This topic has 264 replies on 18 pages [ « | 1  2  3  4  5  6  7 | » ]
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-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us