Discussions

News: Bill Venners asks, What are your Java Pain Points

  1. In a discussion forum at Artima, Bill Venners has asked participants to describe their top three Java pain points. The motivation for this question comes from Bill's monitoring of the debate about new features for Java.
    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.
    In the thoughtful manner that is characteristically BIll, he sets the ground rules to try and keep the discussion constructive and focused. When answering Bill's question, Bill asks that all pain points be accompanied with a explanation of the "real business cost". Some of the points brought up so far include;
    • The semicolon ";"
    • Explicit typing
    • Type erasure
    • Lack of nested data structures that lead to XML configuration file
    • Date manipulation
    • Functions as first class objects
    • closures
    At more than 200 posts the discussion continues to be focused on the original question. TSS would also like to ask: What are your Java pain points? What are their associated business costs?

    Threaded Messages (76)

  2. I'm not even going to say it[ Go to top ]

    The apoplexy that two simple words sends some people into prevents me from actually saying aloud the feature I want, so I'll allude to it: I'd like to be able to treat bigints, complex numbers, and quaternions like regular numbers, the way I am allowed to in several other languages.
  3. apologies[ Go to top ]

    I rather wish I could delete my own posts -- my general crankiness these past few days should not sink the level of discourse on this forum. There's reasoned arguments to be made for and against particular language features, I could probably even present some, but I'm just tired and lazy and I apologize for posting such snippy and glib flamebait. chuck (aka Dr. Jekyll)
  4. Re: I'm not even going to say it[ Go to top ]

    The apoplexy that two simple words sends some people into prevents me from actually saying aloud the feature I want, so I'll allude to it: I'd like to be able to treat bigints, complex numbers, and quaternions like regular numbers, the way I am allowed to in several other languages.
    I want to be able to write financial code that looks sensible. I want the use of math operators to be extended for use with java.lang.Number and subclasses. Personally, I don't want the full use of that 'two simple words' feature - I understand the problems it can cause, but I think there is a strong case for financial use at least.
  5. From a language design[ Go to top ]

    view the setters and getters the main problem with them, although they are needed in an encapsulation context, they clutter the code tremendously and make it unreadable. It is not funny if you have around 20 locs of core code and 200 locs of setters and getters! This has been the worst decision in language design java has. Besides that, the reflection api is highly annoying it is too complicated compared to languages which have reflection in the language. 3-4 lines of code alone for simply executing an aribtrary method by its name is too much!
  6. I come from the C++ world. So, I am not at all pained by the semicolon or the explicit typing etc. My biggest beef right now is the const keyword. I would like to have it implemented. The compiler should throw an error if I do this: const Map m = f(); int i = m.size(); // ok Integer foo = m.get("me"); // ok m.put("you", 45); // error That way, I can write a function like this: const Map f() { return this.myMap; } And not have to defensively copy everything from myMap before returning.
  7. const keyword[ Go to top ]

    What you refer to with the map can be easily accomplished without copying the map: return Collections.unmodifiableMap(this.myMap); Granted, it is a solution specifically coded for in the jdk, as opposed to a generic solution, but it works for your example.
  8. Re: const keyword[ Go to top ]

    What you refer to with the map can be easily accomplished without copying the map:


    return Collections.unmodifiableMap(this.myMap);


    Granted, it is a solution specifically coded for in the jdk, as opposed to a generic solution, but it works for your example.
    It works, but introduces a performance hit (wrapper class around our Map). Const is pure syntatic sugar, so no performance impact, and is more elegant.
  9. Re: const keyword[ Go to top ]

    *const* also increases readability of code. I find it very useful when used in function parameters; one does not have to look at the implementation of the function to figure out if the passed onject is being modified or not.
  10. Re: const keyword[ Go to top ]

    What you refer to with the map can be easily accomplished without copying the map:


    return Collections.unmodifiableMap(this.myMap);


    Granted, it is a solution specifically coded for in the jdk, as opposed to a generic solution, but it works for your example.


    It works, but introduces a performance hit (wrapper class around our Map). Const is pure syntatic sugar, so no performance impact, and is more elegant.
    You can create the unmodifiable version together with the internal one, so you could omit the creation upon all invocations. As for the performance, a wrapper around an array costs only one invocation more. Direct array access was 260 ms ( 10,000,000 items 10x read all elements) For a wrapper around the same array took: 1276. For the wrapper around the previous did: 2202, next wrappers 3033, 4050 resp. An extra invocation costs around 8-10ns on my PC, if it is not acceptable, then you need to pass maps around without the extra protection. (But hey, you could return the original in production environments and the checked map for the developement version) I think const-correctness is a very powerful feature. Sadly not commonly understood and applied. If not applied consistenly you end up with a mess, const_cast-ing and stuff. Java have 10+ years of libs now, I don't know whether they would be patched to include consts, as every new 'const' keyword causes 10 more places to put one :-) And it is hard to include them without breaking old applications. I like const corrertness, but I think it is not feasible for java anymore... :( Cheers, Tamas
  11. Re: const keyword[ Go to top ]

    What you refer to with the map can be easily accomplished without copying the map:


    return Collections.unmodifiableMap(this.myMap);


    Granted, it is a solution specifically coded for in the jdk, as opposed to a generic solution, but it works for your example.


    It works, but introduces a performance hit (wrapper class around our Map). Const is pure syntatic sugar, so no performance impact, and is more elegant.
    Plus, const errors show up at compilation time rather than runtime.
  12. I come from the C++ world. So, I am not at all pained by the semicolon or the explicit typing etc. My biggest beef right now is the const keyword. I would like to have it implemented. The compiler should throw an error if I do this:

    const Map m = f();
    int i = m.size(); // ok
    Integer foo = m.get("me"); // ok
    m.put("you", 45); // error

    That way, I can write a function like this:
    const Map f() {
    return this.myMap;
    }

    And not have to defensively copy everything from myMap before returning.
    +1 I do not come from C++ world, but I miss the const keyword too, much more then, say, closures, not to mention new property syntax.
  13. I too think that the const keyword would do some good, altough there is the final keyword, it only works for the referenced variable: public void doSomething(final Map map) { //(...) map.put("you", "45); //this is legal } But let's say I have this piece: class A { List list;} class B { Map map;} class C { A a; B b; } (...) final C c = new C(); doSomethinOnC(c); (...) static void doSomethinOnC(/*final should be here!*/ C c) { c = new C(); } I think final modifier is only enforced based on lexical scope rules, since the piece of code above is legal. About the const modifier, for the big nested classes with alot of subclasses on them, wouldn't const have to travel all references (kinda like the gc) and mark them as const also?
  14. const Map .. an alternative approach[ Go to top ]

    I come from the C++ world. So, I am not at all pained by the semicolon or the explicit typing etc. My biggest beef right now is the const keyword. I would like to have it implemented. The compiler should throw an error if I do this:

    const Map m = f();
    int i = m.size(); // ok
    Integer foo = m.get("me"); // ok
    m.put("you", 45); // error

    That way, I can write a function like this:
    const Map f() {
    return this.myMap;
    }

    And not have to defensively copy everything from myMap before returning.
    I'm not against const per se, but another approach to immutable collections would be to have immutable and mutable versions of the interface (ie "Map extends ImmutableMap") and separate out the methods appropriately. Hence, in the case above the method would be declared "ImmutableMap f()". Obviously, in the case where the actual object returned was a normal Map, the the immutability could be potentially cast away, but might this be the case if a const was used as well ( I can't remember if that's the case in C++, for example?)
  15. I'll post here since the Artima thread is already too long. JSPs. They have always been a terrible idea. String handling. I shouldn't have to convert between String and StringBuffer to access a method that is one, but not the other. Swing. A specific example is that you cannot explicitly control tab order in JTable. You can't tab over read-only columns.
  16. Scoped Destructors[ Go to top ]

    When I read code a lot of the ugliness seems to be because there aren't stack objects with destructors called. All the cleanup code is in the exception blocks. It's so bad people justify using frameworks to get rid of this boiler plate cleanup code.
  17. Re: Scoped Destructors[ Go to top ]

    When I read code a lot of the ugliness seems to be because there aren't stack objects with destructors called. All the cleanup code is in the exception blocks. It's so bad people justify using frameworks to get rid of this boiler plate cleanup code.
    All Java objects reside on the heap. Stack objects and destructors just don't fit into the basic Java language architecture.
  18. finally[ Go to top ]

    Quite a lot if bugs I encounter origin at failing to release resources when something goes wrong... something you would normally do using a finally statement, but which cannot really be enforced using existing semantics. One of the possible solutions would be extending the language with closures as described in the closures proposal on javac.info: We could use the shorthand with this API to close a number of streams at the end of a block of code: with(FileReader in : makeReader()) with(FileWriter out : makeWriter()) { // code using in and out } I think it would solve a lot problems!
  19. Java NIO[ Go to top ]

    Java NIO! Having asynchronous non-blocking IO is a great advancement over regular blocking sockets. BUT, the API is hideously complex and the naming conventions are anything but intuitive, it's like the makers though: "Hey, non-blocking IO is pretty advanced, so lets make it so anyone without intimate knowledge of low-level networking will struggle to even read a "Hello World!" message from a client-connection!". Putting anyone but a really top-notch expert developer on working with NIO is a completely lost cause..
  20. Top 3 Java Pain Points[ Go to top ]

    1) To use a secured JAX-WS web service client in a Java EE5 web application you must use @WebService to have a secured client injected into your app. @WebService will only work in servlets. Those who use web frameworks typically don't use servlets and therefore can't use a secured web service without calling into an EJB, which can use @WebService. You can use the web service client in POJO's without @WebService, but it won't support security. Security and it's configuration still seems to be vendor-specific. 2) There appears to be no datediff methods on Calendar, Date, etc... if I want to know how many seconds have passed between to Date objects I have to write that myself. 3) We NEED a fully functional free JVM for Pocket PC that is maintained. Maybe PhoneME is this solution?
  21. Re: Top 3 Java Pain Points[ Go to top ]

    2) There appears to be no datediff methods on Calendar, Date, etc... if I want to know how many seconds have passed between to Date objects I have to write that myself.
    long secondCount = date1.getTime() - date2.getTime();
  22. Datediff[ Go to top ]

    2) There appears to be no datediff methods on Calendar, Date, etc... if I want to know how many seconds have passed between to Date objects I have to write that myself.


    long secondCount = date1.getTime() - date2.getTime();
    My example using seconds was very basic. What if you need to find out how many days, weekdays, weeks, months, quarters, years, or whatever are between two Date instances? Other languages have this built-in. Even SQL has that built in (datediff) http://msdn2.microsoft.com/en-us/library/ms189794.aspx
  23. Closures now please![ Go to top ]

    Closures would be so niiice. They would allow us to write Native Queries in the following way: List cats = database.query({ Cat cat => cat.getName().equals("Wolke") } ); If you want want to read more about closures, I recommend Neil Gafter's blog. -- Carl Rosenberger db4objects
  24. Friend classes or packages[ Go to top ]

    The ability to "trust" friend classes or packages has caused me a lot of pain in the past, leading to "public hidden" object hierarchies.
  25. JSP is painful[ Go to top ]

    Any one who worked with jsp knows it is painful: a. It takes a long time to compile, sometimes twice (one in IDE, the other in web/app server). b. It has to be deployed into a server, ouch, I have to start that server which takes forever. It got to be fixed. Yes, destructor is a must have. Java without destructor is a step backward!
  26. Re: JSP is painful[ Go to top ]

    Yes, destructor is a must have. Java without destructor is a step backward!
    Java classes have a destructor called finalize(); If you need to release resources earlier, then code a release method. What exactly you are missing? Cheers, Tamas
  27. Re: JSP is painful[ Go to top ]

    Yes, destructor is a must have. Java without destructor is a step backward!


    Java classes have a destructor called finalize();

    If you need to release resources earlier, then code a release method.

    What exactly you are missing?

    Cheers,

    Tamas
    Within a garbage collected language like Java, I'm not clear on how people would want a destructor to differ from finalize. When would this destructor be called? I've heard people complaining about the lack of destructors in Java before and it always strikes me that these are C++ people who have made the switch to Java but still haven't stopped thinking like C++ programmers. The problem with finalize is that there is no guarantee when it will be called or even if it will be called. It's entirely possible that if your JVM doesn't get squeezed for memory, the GC won't run and the objects will never get finalized. Or, it may be hours or even days before the GC gets around to sweeping up these objects and calling finalize. You simply don't know, and you have no control over it. So you have no control over when or even if your resources will get released. Relying on finalize to tidy up and release resources is not a good idea. You should design your application so that it behaves like a good citizen and tidies up after itself in a controlled manner when it's done. But then, of course, you'd actually have to think about how your application is going work before you start writing it, and we wouldn't want that, would we?
  28. Re: JSP is painful[ Go to top ]

    Relying on finalize to tidy up and release resources is not a good idea. You should design your application so that it behaves like a good citizen and tidies up after itself in a controlled manner when it's done. But then, of course, you'd actually have to think about how your application is going work before you start writing it, and we wouldn't want that, would we?
    +1 We all know, that saving 10 chars and 3 lines will improve our productivity and a new way of expressing the same idea simplifies the code. They are THE FACTS(c) ;-) We should have MACRO in Java, that would be FUN!
  29. Re: JSP is painful[ Go to top ]

    Indeed, one way or another if you need deterministic management of a limited resource in a block structure language then its most easily controlled via some stack based mechanism. In C++ that is a destructor of an auto object, in java its a finally block. A destructor in a heap object of a GC language simply isnt a useful contruct, because by definition only the GC knows when (if ever) there are no dependencies on that that object and it is therefore safe to call the destructor. Paul.
  30. Four errors out of four possible[ Go to top ]

    Any one who worked with jsp knows it is painful:
    Could be but not for the reasons you give.
    a. It takes a long time to compile, sometimes twice (one in IDE, the other in web/app server).
    No, configure your development environment so that you only has to compile them once
    b. It has to be deployed into a server, ouch,
    No, just copy them to a catalog and the server will compile them (takes a second or so)
    I have to start that server which takes forever.
    No, the server doesn't have to be restarted every time you have changed a JSP
    Yes, destructor is a must have. Java without destructor is a step backward!
    Java has chosen to use garbage collection. I think that most people using Java think that this is a positive thing. If you don't like it perhaps you should consider if Java is for you. The closest thing to a destructor is finalize.
  31. Re: Four errors out of four possible[ Go to top ]

    Any one who worked with jsp knows it is painful:
    Could be but not for the reasons you give.
    a. It takes a long time to compile, sometimes twice (one in IDE, the other in web/app server).
    No, configure your development environment so that you only has to compile them once
    b. It has to be deployed into a server, ouch,
    No, just copy them to a catalog and the server will compile them (takes a second or so)
    I have to start that server which takes forever.
    No, the server doesn't have to be restarted every time you have changed a JSP
    Yes, destructor is a must have. Java without destructor is a step backward!
    Java has chosen to use garbage collection. I think that most people using Java think that this is a positive thing. If you don't like it perhaps you should consider if Java is for you. The closest thing to a destructor is finalize.
    It took only a second to compile JSP? Never for me, it tooks 10's of seconds to do so. BTW, please don't comment on just part of a sentence. I use MyEclipse which will autodeploy only the modified JSP into the server and of course the server will pick it up automatically too. But still everytime you start the server, it takes half a minute to a couple of minutes depending on how many pages and how many jars your web application has. To work on a single page, the web app has to work as a whole. This is against the unit testing spirit because the dependency is too big. Regarding destructor, I don't miss memory management. What I miss is resource clean up. Look at the messy SQL connection, statement and result set clean up code!
  32. Or real modules[ Go to top ]

    The problem is that we use packages as modules, and we fake submodules using 'subpackages', that don't exists either. Things like org.coders.Frobber and org.codersFrobber.core. Packages are namespaces, not modules, so we still need either smarter packages, or real modules.
  33. I would like to see: 1. 64-bit indexes (arrays, collection classes, etc). This may need to co-exist with 32-bit indexes for compatibility. Much like "chars" and "code points". 2. Built-in versioning on a per-class basis. For example, I want to be able to say thing like: import com.alopecoid.MyClass-2.1.5; or import com.alopecoid.MyClass-2.1.0+; or something like new com.alopecoid.MyClass-2.1.5() etc Basically I want classes resolved with the class loaders taking into account different versions of a class. You might specify a specific version, or a compatible version, or a range of versions to be found on the classpath. This way when some 3rd party package requires version 2.x and you need version 3.x, you can use them in unison without needing separate class loaders. And you can use drop in replacements for bug fixes or anything that is "API compatible". 3. Mixin classes. Kind of a compromise between multiple inheritance and interfaces. Not entirely needed, but useful as more of a convenience in some cases.
  34. SWING![ Go to top ]

    Definitely Swing is the worst pain,even the simple GUI need lots of paitence and time to build.
  35. I would also say JSP but thats not java thats build with java, complaining about Hibernate would be the same. - The fact that code is not fully swapable in debugmode. - Nullpointers in regard to autoboxing, if i want to autobox an Integer thats null then make it 0 instead of throwing a nullpointerexception. The fact that one uses int instead of Integer should imply this. - Calendar API.
  36. 1) Nulls. If a memory corruption is the most annoying bug in C/C++ programs, a NullPointerException is the most annoying bug in Java programs. Java forces you to think on possible null values EACH TIME you call a method. Possibility to make a mistake is too high. Possible solutions are: null free types ('notnull' modifier) or possibility to handle a method call on a null value. 2) Properties, lists and maps access syntax. When you implement an algorithm from a book, a line of code like a[i].point.x := b[n+1-i].point.x; you should code as a.get(i).getPoint().setX(b.get(n+i-1).getPoint().getX()); So, if an implementation of List becomes the standard way to represent an array in application code and properties becomes the standard way to access fields, then we need the standard syntax for arrays and field access also. Readability of Java code is significantly decresed after properties and Collection API took place of plain fields and arrays. 3) Web hosting friendly. If you develop a Web site (not an enterprise Web application or top e-commerce portal, but just a site) your platform is a hosting service. It is not matter of cost, it is the possibility to buy an independent service to run a site. When you are in the Web site development business, your client doesn't need specification of machine, operating system, etc, he will buy. Your client wants specification of service and list of companies providing this service as a standard option. Nebojsa
  37. My pain points: 1) Properties are horrible. Private and public properties should be one-liners. Now, my behavioural code is drowned in getters and setters. The costs are related to reading the code, lowering productivity. 2) The date/calendar part of the libraries are horrible and error-prone. Handling dates is a pain, and people here spend time trying to find third-party tools to do it for them. 3) I miss basic AOP constructs all the time - I want to have something like inversion of control constructs in the language. That would let me reduce the level of coupling between fine-grained design bits with less clutter. It would also get rid of most of the unproductive politics surrounding AOP at the moment.
  38. I would like a syntactically sweetened catch clause: try { //code } catch(Exception1, Exception2) { //do stuff } this would be really usefull in the reflection methods, for instance, when you have to catch alot of different exceptions. As for Date manipulation, there is a JSR on its way. I guess closures will change the way we solve problems, just don't know if it will be such a good thing for everyone.
  39. I would like a syntactically sweetened catch clause:

    try {
    //code
    } catch(Exception1, Exception2) {
    //do stuff
    }


    this would be really usefull in the reflection methods, for instance, when you have to catch alot of different exceptions.
    I strongly agree with this.
  40. +1 on const +1 on try/catch sugar -1 on auto-boxing/unboxing, I like strict type-checking up front otherwise I'd be programming on another language. Unsigned primitives (like in C++) would be nice too...
  41. What are the semantic of const?[ Go to top ]

    I don't understand how const is different from final. If the issue is mutable objects, the solution would seem to be to expose an immutable wrapper (rather than hiding that wrapper, which is what Collections.unmodifiable* does). Can somebody explain to me how this const will work in the java world?
  42. I don't understand how const is different from final. If the issue is mutable objects, the solution would seem to be to expose an immutable wrapper (rather than hiding that wrapper, which is what Collections.unmodifiable* does). Can somebody explain to me how this const will work in the java world?
    Don't confuse "const" and "immutable." If you have a "const" object, you can can't mutate that object. This essentially means a class has two interfaces: "const" interface and the "non-const" interface. Immutable means no one can change the object, including the object itself. This is like the flyweight pattern, except an immutable object doesn't have to be light weight (although it probably should be). Of course there's the question of what exactly immutable means. For example, let's say you have two strings, which are really wrappers to arrays along with begin and end indexes, and you concatenate them together. Elements of the arrays outside of the begin/end indexes are irrelevant to the logical value of the string, so you could concatenate them by creating a new array to hold the concatenation that can be shared amongst all three string objects, and the old arrays can be thrown away. In this case logically everything is immutable, but the internals change. So instances cannot be safely shared amongst multiple threads without synchronization. However, an often cited benefit of immutable objects is that you can freely share them amongst threads without synchronization. In order to do that, you need to know that either the internals really are immutable or that the object manages it's own synchronization. As for the const keyword, it would really have to be better defined. I used it a lot in C++, but it could have been much better designed.
  43. Don't confuse "const" and "immutable." If you have a "const" object, you can can't mutate that object.
    I assume "can can't" means "can't" here. I think this is mentioned in the article link, but it seems as though you could do that already with the proper abstractions... separating the mutable methods of a List, for example, into a new interface. This might be inconvenient from the perspective of somebody using the api, which is (I'm guessing) why the standard api doesn't go there. Feel free to go there yourself if you need to!
    As for the const keyword, it would really have to be better defined.
    I agree -- and that's essentially what I'm asking for... the definition. (from another post)
    And not have to defensively copy everything from myMap before returning.
    Wrapping isn't copying. If you keep a reference to the original collection that is wrapped in an unmodifiable version, then changes to the original collection will be reflected in unmodifiableCollections based on it. List things = new ArrayList(); List unmodifiableThings = Collections.unmodifiableList(things); things.add("foo"); unmodifiableThings.contains("foo"); // true That's why they don't call the method Collections.immutableList
  44. I assume "can can't" means "can't" here. I think this is mentioned in the article link, but it seems as though you could do that already with the proper abstractions... separating the mutable methods of a List, for example, into a new interface. This might be inconvenient from the perspective of somebody using the api, which is (I'm guessing) why the standard api doesn't go there. Feel free to go there yourself if you need to!
    Yes. You can do it with interfaces. In fact, I'm working on a library (in my free time) of immutable collections in (what I think is) a functional style.
  45. I would like a syntactically sweetened catch clause:

    try {
    //code
    } catch(Exception1, Exception2) {
    //do stuff
    }


    this would be really usefull in the reflection methods, for instance, when you have to catch alot of different exceptions.


    I strongly agree with this.
    Java exception should be enhanced with a code (and possibly a bundle + plus parameters) like: class OnceForAllException extends RuntimeExcepion { public String code; public String category; public String message; public String[] parameters; } Details discussion can be found here: http://www.theserverside.com/news/thread.tss?thread_id=41661#215137 With this, you can catch the OnceForAllException and check the code to do the proper recovery. Of course, you might need some others to simulate set/logjmp or error to signal an system error (like OutOfMemoryError) etc.
  46. Well now, probably one of thuh biggest pain points in Java is this here web site. But I iz gonna quote Captain Kirk who famously said in Star Trek V: The Final Frontier "I don't want my pain taken away! I need my pain!" Waskally!
  47. Better exception handling[ Go to top ]

    I think random ordering of the handling of the exceptions in the list would be exciting!
  48. I would like a syntactically sweetened catch clause:

    try {
    //code
    } catch(Exception1, Exception2) {
    //do stuff
    }


    this would be really usefull in the reflection methods, for instance, when you have to catch alot of different exceptions.
    +1
  49. I hope to see in a near future. 1. catch(Exception1, Exception2, ..) It reduce the number of catches when more than one need to be performed in the same way. 2. Native AOP language (or API) and native weaving (compile time, loading time and run time). Many frameworks are being created and used to feed this functionality. I believe it could be native in Java language.
  50. My 3 pence worth: 1) ability to set/get user properties in an Object: i.e. void setUserProperty(Object key, Object value); void getUserProperty(Object key); 2) Operator overloading: aids readability (if used sensibly!) 3) Redesign UI support, desktop and Web, from the ground up with a common component model.
  51. Building Swing GUI in Java[ Go to top ]

    I want a tool like Powerbuilder to Swing GUI. It is amazing that Powerbuilder had/has a such nice tool long time before the java era. Now the Java IDEs add their own proprietary java classes when Swing GUI is built using these tools. I do not use MS Visual Studio, but I noticed that is becoming like PowerBuilder.
  52. Re: Building Swing GUI in Java[ Go to top ]

    I want a tool like Powerbuilder to Swing GUI.

    It is amazing that Powerbuilder had/has a such nice tool long time before the java era.

    Now the Java IDEs add their own proprietary java classes when Swing GUI is built using these tools.

    I do not use MS Visual Studio, but I noticed that is becoming like PowerBuilder.
    Have you used a current Java IDE? I use both VS.Net and Eclipse daily. I'd much rather use Eclipse. And for building UIs? Pretty much the same technique. Yes, Powerbuilder was kewl, but it built too much dependance on the relational data structure.
  53. pain points - features to add[ Go to top ]

    1) setting up classpath is still a PITA. Why not have a -jardir param to pass in that pulls in all the jars from a specified dir. 2) deploy to exe, rpm, etc. Compile to native format, including the JRE pieces that are needed. I miss the old days when I could crank out a delphi app and send someone an exe and that's all they needed... it was so simple and useful. 3) jvm heap size auto-grow. Java is inherently unstable because of the requirement to specify max heap size. You have to wait and see if the app crashes to find out if you have it set right. No other VMs make you specify it, they just grow as needed. 4) better arrays. Arrays in Java are a joke. Should be dynamic. I want to be able to do stuff like: String[] blah; blah <- "a"; blah <- "b"; String[] blah2; blah2 <- "c"; blah2 <- "d"; String[] merge = array1 | array2; String out = merge.join(","); at this point out would be "a,b,c,d" In other words, make arrays like Ruby arrays. 5) closures 6) properties 7) switch statements on strings!
  54. Re: pain points - features to add[ Go to top ]

    4) better arrays. Arrays in Java are a joke. Should be dynamic. I want to be able to do stuff like:
    Try the collection classes. Arrays are meant to be a primitive structure.
  55. Re: pain points - features to add[ Go to top ]

    4) better arrays. Arrays in Java are a joke. Should be dynamic. I want to be able to do stuff like:


    Try the collection classes. Arrays are meant to be a primitive structure.
    I use the collections all the time. I still stand by my request....
  56. Re: pain points - features to add[ Go to top ]

    4) better arrays. Arrays in Java are a joke. Should be dynamic. I want to be able to do stuff like:


    Try the collection classes. Arrays are meant to be a primitive structure.


    I use the collections all the time. I still stand by my request....
    I think your request would be better served by using operator overloading on the collections classes, similar to Python and C++. That would get the syntax you want without breaking the low-level efficiency of arrays.
  57. Re: pain points - features to add[ Go to top ]

    4) better arrays. Arrays in Java are a joke. Should be dynamic. I want to be able to do stuff like:


    Try the collection classes. Arrays are meant to be a primitive structure.


    I use the collections all the time. I still stand by my request....


    I think your request would be better served by using operator overloading on the collections classes, similar to Python and C++. That would get the syntax you want without breaking the low-level efficiency of arrays.
    I'm not sure how this would break the efficiency of arrays... if the arrays are pre-set in size then they behave as they do now. If the compiler sees arrays being dynamically changed then it handles it differently. I'm not a compiler guy, but this seems very doable to me.
  58. Re: pain points - features to add[ Go to top ]

    1) setting up classpath is still a PITA. Why not have a -jardir param to pass in that pulls in all the jars from a specified dir.
    As of Java 6 wildcards are supporting when defining classpath
  59. Re: Building Swing GUI in Java[ Go to top ]

    Powerbuilder? VS.NET? Eclipse with Jigloo or whatever? Have you guys used Borland's Delphi/C++ Builder ever? It was (and still is, unfortunately without a strong corporate support, Borland is almost finished) by far the most advanced GUI Builder ever. Using Delphi, it was easy and fast to create very advanced GUI's. Visual Studio and Eclipse can't reproduce what Delphi achieved in this area until today - even though MS hired some of Borland developers.
  60. Re: Building Swing GUI in Java[ Go to top ]

    Powerbuilder? VS.NET? Eclipse with Jigloo or whatever? Have you guys used Borland's Delphi/C++ Builder ever? It was (and still is, unfortunately without a strong corporate support, Borland is almost finished) by far the most advanced GUI Builder ever. Using Delphi, it was easy and fast to create very advanced GUI's. Visual Studio and Eclipse can't reproduce what Delphi achieved in this area until today - even though MS hired some of Borland developers.
    +1
  61. Re: Building Swing GUI in Java[ Go to top ]

    Powerbuilder? VS.NET? Eclipse with Jigloo or whatever? Have you guys used Borland's Delphi/C++ Builder ever? It was (and still is, unfortunately without a strong corporate support, Borland is almost finished) by far the most advanced GUI Builder ever. Using Delphi, it was easy and fast to create very advanced GUI's. Visual Studio and Eclipse can't reproduce what Delphi achieved in this area until today - even though MS hired some of Borland developers.
    I have not used Delphi so I cannot compare. I have heard good things. But from what I have heard, I still don't get it. Have you ever used Pacbase? If not, then Pacbase by far is the most ... ;)
  62. Re: Building Swing GUI in Java[ Go to top ]

    I want a tool like Powerbuilder to Swing GUI.

    It is amazing that Powerbuilder had/has a such nice tool long time before the java era.

    Now the Java IDEs add their own proprietary java classes when Swing GUI is built using these tools.

    I do not use MS Visual Studio, but I noticed that is becoming like PowerBuilder.


    Have you used a current Java IDE? I use both VS.Net and Eclipse daily. I'd much rather use Eclipse. And for building UIs? Pretty much the same technique.

    Yes, Powerbuilder was kewl, but it built too much dependance on the relational data structure.
    PowerBuilder doesn't rely on Relational Data at all. In a project for Credit Suisse First Boston in 1998, we used PowerBuilder to talk to Mainframe, and then display the data into datawindows. It is Model-View-Controller based architecture. It was in 1998, the debugger was powerful to use. We used 64M memory machine and performance was very satisfying.
  63. Re: Building Swing GUI in Java[ Go to top ]

    I want a tool like Powerbuilder to Swing GUI.

    It is amazing that Powerbuilder had/has a such nice tool long time before the java era.

    Now the Java IDEs add their own proprietary java classes when Swing GUI is built using these tools.

    I do not use MS Visual Studio, but I noticed that is becoming like PowerBuilder.


    Have you used a current Java IDE? I use both VS.Net and Eclipse daily. I'd much rather use Eclipse. And for building UIs? Pretty much the same technique.

    Yes, Powerbuilder was kewl, but it built too much dependance on the relational data structure.


    PowerBuilder doesn't rely on Relational Data at all. In a project for Credit Suisse First Boston in 1998, we used PowerBuilder to talk to Mainframe, and then display the data into datawindows. It is Model-View-Controller based architecture. It was in 1998, the debugger was powerful to use. We used 64M memory machine and performance was very satisfying.
    I didn't say it relies on it. But I guess I should have said "data sets" instead. It has been while since I used it. I taught myself PB back in 95, and then touched it sometime around 2000. So it could have changed. But the idea around Datawindows is datasets, not objects (although PB was OO in concept). Also, I can see PB accessing the mainframe. Mainframes also use RDBMSs. :) On the other hand a lot of data is stored in [straight]VSAM, IMS, ADABAS and etc. As for MVC - I didn't see it. Again, I am not saying PB was bad. It was kewl. But I can create a GUI and app much faster in Winforms/C# and Swing/Java.
  64. It is a another pain for me. I have a XSL built and it is compiled using Xalan XSLTC and when the XSL becomes larger, XALAN XSLTC throws is error saying that method size larger than 64k.
  65. numbers[ Go to top ]

    it's about time java provide better support numbers. a long time back cameron and others suggested some additions to make calculations better. I would love the addition of objects that allocate on the stack, similar to how C# allows both. for performance intensive stuff like a RETE rule engine, having the option would be great. peter
  66. .Net is investigating functional programming features to enable parrallel processing on multi-cores. What is Java doing in that space?
  67. NullPointerExceptions[ Go to top ]

    Nullable variables would save us from tons of unnecessary bugs and null checks. Nice (amongst others) got this right: http://nice.sourceforge.net/manual.html#optionTypesJava http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5030232
  68. Re: NullPointerExceptions[ Go to top ]

    Nullable variables would save us from tons of unnecessary bugs and null checks.
    ... would have saved us ... The default nullable references (and the resulting NullPointerExceptions) were my biggest disappointments when I encountered Java years ago.
  69. 7 wishes...[ Go to top ]

    Here goes my wish list. Most of it is pure syntatic sugar, of course. But I think that productivity should always be an issue, and there is always room for improvement. "Syntactic sugar" can do this, e.g. I use the for-each loop whenver possible, because it keeps the variable definition in one place, and no more confusing indexes when nesting for loops. (1) Setter/Getter I won't argue against people who say setters/getters are not object oriented. Maybe they're right, maybe not. All I see is a lot code wasted with set/get methods. I'm not concerned about creating (since any modern IDE does that in a millisecond), but about maintenance. Code is cluttered, simple questions arise like "where do I put my javadoc comment ??". 99,9% of my get/set/is methods are really plain field access. The remaining 0.1% remain unnoticed on a first glance at the source code. If get/set pairs were generated automatically, any hand-coded get/set method would be clearly visible. (2) Enhance Hot Code Replacement http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812 -> Improve productivity (less server restarts) As of Java 6 it seems to be possible to add private methods; that was not possible with Java 5 as far as I remember. So at least one improvement per java version. But being able to add/remove public methods/fields etc would also be great. Even if stability was compromised, I'd switch it on in dev mode and turn it off in production. (3) Simpler Resource cleanup I haven't given this much thought until now, but from reading this thread (and others) I think that closing statements etc. could be easier and a lot of unnecessary code could be saved. Maybe closures are the way to go. java.io.Closable is a step in the right direction, but the concept could be generalized (e.g. applied to SQL statements also). Current: InputStream is = null; InputStream isr = null; BufferedReader br = null; try { is = ... } finally { if(br != null) br.close(); } or with some helper method InputStream is = null; InputStream isr = null; BufferedReader br = null; try { is = ... } finally { IoUtils.close(br, isr, is); } Better: With { InputStream is = new FileInputStream(); InputStream isr = new InputStreamReader(isr); BufferedReader br = new BufferedReader(isr); } try { } /* java will close all ressources defined in the with block */ (4) catch(Exception1, Exception2 ex) as discussed above (5) Type erasure - keep at least some information about generics at run-time, e.g. for reflection based tools (6) Easier access to maps (properties) e.g. props["key"] instead of props.get(key); (7) Maybe a better way of debugging NullPointerExceptions. e.g. if I have objectA.getB().getC().getD() and a NPE is thrown, there is no way to determine which object was null. Not sure if that is possible...
  70. Re: 7 wishes...[ Go to top ]

    (7) Maybe a better way of debugging NullPointerExceptions. e.g. if I have

    objectA.getB().getC().getD()

    and a NPE is thrown, there is no way to determine which object was null.
    Er, don't use method chaining then. Object B = objectA.getB(); Object C = B.getC(); Object D = C.getD(); NPE now has the correct line number in the stack trace. Or write defensive code that actually checks for nulls :-s
  71. ByteBuffers[ Go to top ]

    When using the nio libraries, one is forced to use the awkward ByteBuffer class. It is extremely difficult to understand what parts of this class a JVM supports. Developers are basically left to experimentation. A problem I frequently encounter is the need to iterate over a stream or ByteBuffer, taking a few bytes, and converting them into a Java primitive. If you're working with direct ByteBuffers, the conversion process entails: 1. Extracting a few bytes into a byte[] 2. Converting the byte[] into a String 3. Converting the String into a Java wrapper object 4. Converting the wrapper object into a primitive For performance critical applications that do this thousands of times, its a bummer. A lot of intermediate objects are created and thrown away just because the classes that do the conversions don't take streams or ByteBuffers directly.
  72. Re: ByteBuffers[ Go to top ]

    java.util.Scanner do any good? It takes the stream/channel directly and seems pretty directed at parsing text only streams, but if that what you're doing it looks right.
  73. Re: ByteBuffers[ Go to top ]

    Our input is based on tokenizing a variable number of bytes, interpreting it in a predefined manner, and possibly using it to interpret future data. Scanner is a lexical analyzer that wouldn't support our needs. It tokenizes based on regular expressions rather than a dynamic number of bytes. Under the hood, it follows basically the same inefficient algorithm I describe by taking raw bytes, converting it into a String, converting it into a wrapper object, and then converting it to a primitive. What I need is the ability to go straight from a stream to a primitive with a minimal amount of overhead.
  74. I was beginning to believe you, until I looked at this: http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all Idiomatic Java (BufferedReader.readline + Integer.parseInt) takes only 25% more CPU time than idiomatic C (gcc fgets/atoi) - despite the extra allocation (not to mention VM startup). Since Java is doing a character character set translation as well that seems pretty good. I guess all the articles were right - the JVM really is very good at handling short lived allocations.
  75. +1 for the autoboxing working correctly +1 for the JSPs being hauled into the garbage bin and Java the language could use the built-in, easy AOP from the Dojo event system. I'd KILL to be able to say , java.beans.EventManager.connect( System.out, "println", new MethodInterception(){ public void method (Method invocation ){ // will i let it happen? hrm?? } }); , but also with join points instead of references to ojbects being used to qualify "when" the listening happens. As for Java the platform: better support for Java on the embedded device front. Where's my Java in a car? JavaSpaces connecting anything but the printer we keep hearing about? Why don't I beleive, for better or for worse, that Java can do anything? Where's the marketing?
  76. Destructors would be nice[ Go to top ]

    Deterministic destructors, a la C++. They make resource management so much more elegant and robust. Then we could finally say goodbye to 'finally'...
  77. java pain points[ Go to top ]

    1.GUI: Building UIs is such a pain. In MS Visual Studio, UI is so damn easy and building UI with Java (in any editor) is a big task in itself. I fear building GUI much more than coding the entire backend. 2.Calendar and Dates: Everytime I don't work with those for like a week, I have to go search the documentation about how to work with Dates, date formatting and other related stuff. 3.EJBs: Haven't tried the 3.0 yet, but 2.0 was a pain. So many rules to consider.