Ask TheServerSide: What feature do you want to add to Java?

Discussions

News: Ask TheServerSide: What feature do you want to add to Java?

  1. Whenever I am on a panel, someone tends to ask What feature would you add, or take away, from Java?. One of the features that I would love to have is true closures. C# 2 has gotten pretty close with their anonymous delegates, and I think Java can take it from there.

    What feature would you like to see?

    More info on closures: The power of closures in C# 2.0

    Threaded Messages (173)

  2. Remove Constructor nonsense[ Go to top ]

    Ability to inherit constructors, and to call super() and this() wherever you want in the constructor. There's no reason to restrict this, and I'm tired of putting object construction code in an init() method.
  3. Remove Constructor nonsense[ Go to top ]

    I'd personally like to see first-class support for tuples, relational-concepts in general and XML. I realize these approaches are theoretically/experimental, but the concepts seem sound to me from what I've read and I'd love to program in a new way just to get that "excitement" back into programming. Of course, pleasing me is probably not the best direction :)
  4. Usefull[ Go to top ]

    It would be usefull if java can offer such goodies :
    - a sizeof operator
    - bit fields like in C
    - of course unsigned char, int, long
    - an way to tell the JVM to use a specific version of a jar (java -cp acme.jar[1.28]; ...) without having to rename those jar on your disk, which leads to multi-versionned jars (we can imagine a big acme.jar that contains all the different versions, for instance)
  5. Theres not much I want to do with the language. I'd remove Static Imports, which I think just make the code harder to read and don't really add anything. Then I'd leave the language syntax alone to a great extent. There are some things I'd like to see done the core libraries, most of which revolve around client and GUI which I think has lagged behind J2EE and Server Side Java for too long. Maybe Sun could use some of its vast MS payout to pay some guys at Apple and Trolltech to help it work on an update of Swing. I actually quite like Swing up to a point, but building large, complex GUI with it gets somewhat painful.

    Anyway, some specifics:
    1. Optimise casting of Float and other Objects to Strings: Float in particular is awful and causes endless problems on larger web apps.
    2. Higher Resolution Timer (Bug ID 4478186). System.currentTimeMillis() has a resolution of 55MS on Windows 9x and 10-15ms on Win2k/XP. Linux and Mac have 1ms. Please, Please guarantee is runs at at least 1 MS.
    3. Hotspot SIMD optimisations: Java would have some advantages over C++ compliers here since Hotspot could check which SIMD instructions the processor supports (if any) and automatically generate SIMD code for that processor. Moreover older Java applications could take advantage of the SIMD Hotspot upgrade without needing to be recompiled.
    4. More font smoothing options: Swing components aren't anit-aliased, the anti-aliasing default is off, and no support exists for sub-pixel font rendering. (Bug ID's 4726365 and 4808567).
  6. No -- More -- "throws Exception" !!![ Go to top ]

    I really don't like declaring the Exceptions as part of method interface. I believe they are an utter innecessity, it requires extra coding and usually not at the correct level of Exception hierarchy. Simple "throws Exception" is added by many developers just to shut up the compiler.

    I wouldn't want to force catching of those exceptions either. IMHO, "Exception part of interface" feature must be taken out of Java. An exception is thrown, fine. Let whoever want to catch it, catch it. It will percelate up eventually and will show in stack trace. During testing, then, the developer can choose to do something about it. In production, one default catch statement at the uppermost level will be sufficient to ensure the application does not stop on all types fof Exceptions, so on.

    -B
  7. No -- More -- "throws Exception" !!![ Go to top ]

    This was one thing I really liked coming from VB to Java (a few years back). Not knowing what might happen is much worse than being forced to deal with it up front.
  8. Yes, checked exceptions is the best candidate to remove, serialization and impliet stuff like RMI is the next, It is safe to remove interfaces too, JAVA is not COP language anyway. Remove useless feature before to add new experiment .
  9. Thought ya'll might find this interesting.

    What Sun thought about Delegates back when Microsoft first started introducing them in J++.

    About Microsofts Delegates
  10. tuples[ Go to top ]

    so that functions can return multiple values and assignments can happen in parallel
    User key;
    Cart value;
    for ( Iterator i = aMap.mappings().iterator(); i .hasNext(); )
    {
        [ key ; value ] = ( [ User ; Cart] ) i.next();
        ...
    }
  11. Let's see[ Go to top ]

    You could easily create a class now: Tuple<K,V>
  12. tuples[ Go to top ]

    so that functions can return multiple values and assignments can happen in parallel
    User key;Cart value;for ( Iterator i = aMap.mappings().iterator(); i .hasNext(); ){ [ key ; value ] = ( [ User ; Cart] ) i.next(); ...}
    +1 vote

    Comment: the implementation should be light weight, e.g. stack based instead of creating a new wrapper object so methods that legitimately needs to return more than 1 thing can do so efficiently without incuring wrapper object creation overhead. This is very handy in high performance complex algorithms.

    The later post suggesting that we can already do this by using a wrapper object is IMHO missing the point.

    Another added benefit is this enhances code clarity. I am sure many people will point out the pass-by-reference style of calling is another alternative. Again, I think it is not only ugly, but error prone.
  13. tuples[ Go to top ]

    so that functions can return multiple values and assignments can happen in parallel
    User key;Cart value;for ( Iterator i = aMap.mappings().iterator(); i .hasNext(); ){ [ key ; value ] = ( [ User ; Cart] ) i.next(); ...}
    -1

    Comment: How often do you need that and thanks to generics we can use Tuple<K,V>. If you want to have it on the stack than pass it as an out paramter - complex alogarithm implementers should be able to handle that;). IMO just because of the added syntax it would decrease readability - at least learnability. Further I don't know wheter it would be necessary to implement a new type, which IMO would be not very good.
  14. what are tuples really?[ Go to top ]

    so that functions can return multiple values and assignments can happen in parallel
    User key;Cart value;for ( Iterator i = aMap.mappings().iterator(); i .hasNext(); ){ [ key ; value ] = ( [ User ; Cart] ) i.next(); ...}
    -1Comment: How often do you need that and thanks to generics we can use Tuple<K,V>
    My guess is that in such cases the design is incomplete.
    If you need to return two values from a method you should think
    what these two values MEAN in the context of your problem domain.

    Maybe you just missed an important business object and are "emulating" it
    by passing around big parameter lists and thingls like "Tuples".
  15. I couldn't agree more[ Go to top ]

    Multiple assignation is THE useful command lacking in most programming languages. Without it, it is impossible that a function returns several parameters.

    I know, I know. You can use an out parameter. But these is a workaround, not a real solution. This makes code unnecessarily dirty and less readable. The signature of a method is not determined by its business meaning but by its implementation details.

    Using the same reasoning, we could say that it is useless that methods return results. Every result can be returned as an out parameter. Good bye, functions. Only procedures are allowed.

    We can go further. Why several parameters? All the parameters you need can be passed by using Tuple<V,T>. When you have three parameters, you can use Tuple3<V,T,X> and so on. You only need one parameter and no results at every method. Java made easy!

    If you had multiple assignation, you could return a result and an error code at the same time, simplifying error management.

    It is not that implementing multiple assignation is hard. Fifteen years ago, when I was a college student, I did it in a "Compilers" course.
  16. I tend to like this.[ Go to top ]

    Enables a clear API: clear what's being returned without the need of a wrapper object.
    Enables true contract based programming by means of exceptions. I.e. no longer we'll see exceptions being (mis)used to handle business logic flow.
  17. tuples, object references, etc[ Go to top ]

    Hi people,

    Tuples suggested by MT: - tuples, improved cast/ assignment structures or multiple-outs from a function would be very useful.

       [ key ; value ] = ( [ User ; Cart] ) i.next();
       [ resultCode; foundUser ] = attemptLogin( name, password);

    But I think Java's philosophy is too simplistic for these to happen :-)

    First-class properties... I'd agree with Konstantin. We should recognize object state, as fundamentally important. This simplisticism :-) philosophy has instead allowed this be become somewhat confused with non-stateful calculated and secondary getter methods.

    Not having to code properties manually, would also be useful.... but I use templates to get around this.

    Classloader madness... worst thing about classloaders is the complete absence of useful engineering/ diagnostic from the JVM. If it would issue a report as to which classpath it had searched before failing, we'd have solved all these problem already.

    Boolean.getBoolean(string). What can I say. This API mistake is the single most common bug cause I am aware of, I've seen it again and again.

    Allow subclasses to return subtypes of the original return type when overriding methods... this would be great for those of us building infrastructure, less relevant for applications.

    Closures, functional language stuff... all good.

    Now, Type Inference: I'm definitely in favour, but don't want to silently add check-casts as these change the meaning.

    We can, however, get significant benefits to code from inferring if-conditions into the operand clauses.

       if (obj instanceof OrderLine)
         return obj.reportLineDetails();

    We could also use better language support for 'null optionality'. This would reference a field or property, but default to null rather than throwing NullPointer if the subject were null.

       order->customer->name
       orderLine->product->getCode()
       
    I believe in application robustness, in being able to handle partially-formed data.

    Information is king and our job is to do what we can with it, rather than fall over because of some minor deviation. So the Java language adding proper support for optionality, would be a big help.

    ...This is actually indicative of Java's simple take on OO theory and object referencing, and ties into the tuple return-value idea:

    The point here is that coding OO is not just about calling methods on existent references. The OO context is actually larger and should encompass identifying, setting and optional object references. As it is, these are hard to modularize because the language can't represent them.

    Basically to improve this we'd need out-params, pass by reference, tuples or similar.

       // - new customer, matched existing, invalid... etc
       custLookupMsg = representCustomer( custName, &customer);
       o.print( customer->name);
       o.println( " "+custLookupMsg);

    Any takers?

    Lastly, while we're at it it would be nice to script variables/ expressions into our string code.

       o.println( " ${custLookupMsg}");



    Cheers,
    Thomas Whitmore
    www.powermapjdo.com
  18. Off the top of my head...[ Go to top ]

    All I can say is you asked for it ;)

    * Please do something about java.awt.List and java.util.List name collisions (as if no one ever uses Collections in a GUI application)
    * Have java.net.URL extend java.net.URI, since a URL by definition is simply a specialization of a URI.
    * Make things that look, feel and smell like URLs really URLs. For example, JDBC connection strings, JNDI lookups, etc., etc. In fact, revamp these to use URIs for consistency.
    * Please, please, please make jar/zip files writeable (i.e. insert/modify entries) without having to reconstruct from scratch. If this can't be done, provide a platform neutral filsystem-in-a-file framework/supporting classes.
    * Properly support file permissions -- yes, this is challenging due to platform variances, but it can be done with some sensible abstraction and design. What's there now is sufficient for trivial applications, but needs to be expanded for more sophisticated apps.
    * Provide a simple but oh so useful persistence framework -- let's say java.util.persistence -- that has file-backed implementations of Collections classes. I'm tired of writing my own or using incomplete third party pieces here.
    * XPATH and XSL support in the XML framework.
    * OK, one language specific thing: introduce the notion of a struct -- for lightweight field aggregation. Sometimes classes are just too heavy for simple things. The C# way of doing structs, properties, etc. is compelling.
    * Native shared memory access, along the lines of NIO (now you see why the point above may be of interest).
    * Provide a default XML serialization mechanism.

    I'll stop now, but I had to get those off my chest. I've often pondered how to refactor the hole dang thing language changes optional) and get us back to the simplicity of Java 1.0 (without the limitations and design mistakes or course).

    I guess we all have dreams.
  19. Off the top of my head...[ Go to top ]

    All I can say is you asked for it ;)
    ...
    * Provide a default XML serialization mechanism.
    ...
    I guess we all have dreams.
    How about this as a default serialization mechanism:
    http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLEncoder.html
    http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLDecoder.html

    I guess some dreams come true;)

    sv
  20. Off the top of my head...[ Go to top ]

    True, but I was thinking along the lines of a somewhat more flexible mechanism such as Betwixt (http://jakarta.apache.org/commons/betwixt/) or XStream (http://xstream.codehaus.org/). I should have made that more clear in my post.

    I see a more fundamental issue here though, and that is Sun lagging far behind the curve with respect to introducing core extensions to the API. For example, a big part of the blame IMHO why we have one too many Java XML parser implementations is due to Sun taking an eternity to introduce javax.xml.*. Likewise, developers have needed to flexibly serialize Java objects for quite some time; this void is being filled by a grab bag of third party libraries. Once these get entrenched, it's close to impossible to extricate them and should a Java standard emerge, it's a dollar short and a day late. (java.util.logging is another example that comes to mind).
  21. Off the top of my head...[ Go to top ]

    All I can say is you asked for it ;)...* Provide a default XML serialization mechanism....I guess we all have dreams.
    How about this as a default serialization mechanism:http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLEncoder.htmlhttp://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLDecoder.htmlI guess some dreams come true;)sv
    Unfortunately the XML{En,De}coder is only applicable to JavaBean's.
  22. Off the top of my head...[ Go to top ]

    Here, here. We need a JAXS :-)
  23. Still using AWT?[ Go to top ]

    Please do something about java.awt.List and java.util.List name collisions (as if no one ever uses Collections in a GUI application)
    Why are you using AWT?
  24. Still using AWT?[ Go to top ]

    Sure, any decent GUI app requires classes from java.awt.* -- GridBagLayout, Rectangle, Graphics2D, Color, Font, FontMetrics, etc., etc. As a finer point, since Swing file dialogs look and behave nothing like their native counterparts, sometimes java.awt.FileDialog is required to have a respectable application.

    Now, not all code has clean imports. So in this particular case, the second one uses Collections classes, a naming collision occurs.

    Either way, I consider it poor design to have a fundamental naming collision. This isn't the only example, just one that has assuredly bitten a few people in the past.

    Does that fact that javax.swing.text.Document collide with org.w3c.dom.Document bug me? I don't know, since it hasn't bitten me yet. BTW, clean imports don't help one bit here.

    I do get what you are saying though, and yes, AWT as a set of UI widgets is dead. But that doesn't excuse future API designers/architects from the responsbility to pay attention to the details -- since it's the details that often make the difference between enjoying what you do and drudging through the muck.
  25. I still sometimes miss default method arguments as in C++. Especially useful for multiple constructors, to avoid a proliferation of constructors invoking this(default, default...). There are ways around it, but they're less concise. Ultimately I think the recent surge in interest in new languages for the JVM (especially Groovy) is great. I think it would be a mistake for Java to try to please everyone all the time. There are times when other languages may be more appropriate, and it's better to be able to use them within the JVM than turn Java into a complex monstrosity trying to please everyone.

    Tiger will go a long way towards addressing my main irritations with Java: untyped collections and lack of standard enumerations.

    Rgds
    Rod
  26. I still sometimes miss default method arguments as in C++. Especially useful for multiple constructors, to avoid a proliferation of constructors invoking this(default, default...).
    Actually, I discourage this pattern. Instead, have all your constructors converge toward a private init() method.

    Why? Because it makes it easier to spot what the "canonical init method" is.

    Otherwise, you have to hunt the code for whatever constructor has the most parameters (and of course, the name of the constructor changes for each class, which doesn't help).

    That being said, I totally agree, I would love to have default parameters.

    --
    Cedric
  27. init() means no final members[ Go to top ]

    Actually, I discourage this pattern. Instead, have all your constructors converge toward a private init() method.
    I agree that it does make it easier to track down initializtion, you lose the ability to use final members which must be initialized inside a constructor.
  28. 1. Stop getter/setter nonsense and have property keyword and model it exactly as in Delphi, and not as in C#.
    property MyUserType user; [ read readUserIfNull;] [ write saveUserIfDifferent;]
    both read and write functions are optional.

    2. Fix classloaders madness. Implementation details must not alter language semantic.
    3. Deprecate and remove api calls like Boolean.getBoolean( string );
    4. Have standard JVM hook for AOP weaving, something like System.weave( … );
    5. Allow constructor inheritance.
    6. More attention to interoperability with ‘native’ platforms. No more rewriting databases, smtp servers etc. in Java.
  29. 1. Stop getter/setter nonsense and have property keyword and model
    Could not agree more! getXxxx() and setXxxx() just drives me mad!
  30. How about read and write keywords to generate getters and setters?

    public class MyClass {
      read write int i;
    }

    would define a variable that is readable and writeable, so you can write

      MyClass a = new MyClass();
      a.i = 1;
      int j = a.i;

    The compiler could generate and call public getI() and setI(int) methods out of sight. You could override the default getter setter implementation by writing your own getI() setI(int) if needed. If the variables are not read write then the compiler would create protected getI() set(int) methods.
  31. How about read and write keywords to generate getters and setters?

    <PRE>public class MyClass {
      read write int i;
    }</PRE>

    would define a variable that is readable and writeable, so you can write

    <PRE> MyClass a = new MyClass();
      a.i = 1;
      int j = a.i;</PRE>

    The compiler could generate and call public getI() and setI(int) methods out of sight. You could override the default getter setter implementation by writing your own getI() setI(int) if needed. If the variables are not read write then the compiler would create protected getI() set(int) methods.
    Nope. The point of properties is not simply removing get or set methods. It is the flexibility in definition and in usage. I guess you have not used Object Pascal (OP).

    The property is typed. If an object value is needed and there is no getter, the object of the declared type is returned. If there is getter defined, then it is called and its result is returned. The same with setter. If property is used as lvalue and there is a setter, it is called to set a property value. By the way, properties can be indexed, so you can obtain prop[index] which in reality might call get(obj, index) (sorry, I do not remember the exact OP syntax)

    The OP concept of properties is powerful and easy to use. The declaration is simple, the usage is simple, just like regular simple type object. Java should have this from the very beginning considering that Delphi 1.0 was released in 1995 and betas were available even earlier.


    The feature that I would like to see in Java is multiple inheritance for interfaces, it would make life easier for EJB projects ;)
  32. How about read and write keywords to generate getters and setters?public class MyClass { read write int i;}would define a variable that is readable and writeable, so you can write MyClass a = new MyClass(); a.i = 1; int j = a.i;The compiler could generate and call public getI() and setI(int) methods out of sight. You could override the default getter setter implementation by writing your own getI() setI(int) if needed. If the variables are not read write then the compiler would create protected getI() set(int) methods.
    The access to properties or fields needs to be transparent to access via reflection too.
    This post talks about the subject:
    http://www.martinfowler.com/bliki/PublicCsharpFields.html
  33. I guess the important distinction here is between attributes that define the class type, and plain member variables. Attributes are a design intention while member variables are an implementation. What I'd like in Java is more declarations of the design so you don't have to infer the design intention from usage patterns. To solve the reflection access add another keyword.

    public class MyClass {
       attribute read write String name;
       private String buffer;
       ...
    }

    Now it's clear that "name" is an attribute (property), while buffer is just an implementation detail. The advantage of having an attribute keyword would be to help automate conversion to SQL, XML, UML, or whatever comes along in 10 years.

    People say the implementation class of "name" might change, so it shouldn't be exposed. I suppose there are ways around that. Maybe by redeclaring an implementation by a different class if needed. Suppose we had used "name" as a String for 10 years, but suddenly we need to change the implementation to use a StringBuffer internally.

    public class MyClass {
       attribute read write String name;

       // declare implementation of name
       private StringBuffer name2;

       // replace default getter of attribute name
       public String getName() {
         return name2.toString();
       }
       
       // replace default setter of attribute name
       public String setName(String name) {
         name2.setLength(0);
         name2.append(name);
       }
    }

    Now we use

       MyClass a = new MyClass();
       a.name = "Joe";

    Just like we have for 10 years.
  34. I voted for it, there's a RFE entry open in the Java Bug Database:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4979053

     At Javalobby there's been some debate about it:

    http://www.javalobby.com/thread.jspa?forumID=61&threadID=13747

     Regards,


       Xavi
  35. Keep setters and getters[ Go to top ]

    Why do so many people want to get rid of setters and getters? They're not that bad. Can't your IDE create them for you with a simple keystroke? Are all of your setters/getters so trivial?

    If they are, then consider using a public member. Want it read-only? Make it final. Not OO, you say? Well neither are a bunch of trivial setters and getters, according to Allen Holub (http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html).

    I cringe when I need setters/getters. I do have them. And I typically add checks to them. For example, when I have a setName(String) method, I usually want to prevent the name form being null, too long, or containing characters that might break what I'm using the name for. Without a setter you can't do that.

    If you make setters/getters optional (so the compiler can create the trivial case for you by default), it's just more syntactic sugar that will make the code harder to read and the language harder to learn.

    KEEP SETTERS AND GETTERS
  36. Keep setters and getters[ Go to top ]

    Why do so many people want to get rid of setters and getters? They're not that bad. Can't your IDE create them for you with a simple keystroke? Are all of your setters/getters so trivial?If they are, then consider using a public member. Want it read-only? Make it final.
    Because properties are so much easier to use. With properties you get consistent syntax and semantics. You can also have indexed properties, which is very convenient.

    From Object Pascal help:

    It may help to think of properties as special accessor fields that enable you to modify data and execute code contained within your class. For components, properties are those things that show up in the Object Inspector window when published. The following example illustrates a simplified Object with a property:

    TMyObject = class
      private
        SomeValue: Integer;
        procedure SetSomeValue(AValue: Integer);
      public
        property Value: Integer read SomeValue write SetSomeValue;
      end;
      procedure TMyObject.SetSomeValue(AValue: Integer);
      begin
        if SomeValue <> AValue then SomeValue := AValue;
      end;

    TMyObject is an object that contains the following: one field (an integer called SomeValue), one method (a procedure called SetSomeValue), and one property called Value. The sole purpose of the SetSomeValue procedure is to set the value of the SomeValue field. The Value property doesn’t actually contain any data. Value is an accessor for the SomeValue field; when you ask Value what number it contains, it reads the value from SomeValue. When you attempt to set the value of the Value property, Value calls SetSomeValue to modify the value of SomeValue. This is useful for two reasons: First, it allows you to present the users of the class with a simple variable without making them worry about the class’s implementation details. Second, you can allow the users to override accessor methods in descendant classes for polymorphic behavior.
  37. If you don't need getters and setters, use public objects. I don't care what anyone says. But, don't complain when you find out you have to tweak data 10 years from now. At the very worst, you write a new method, or format your string before sending it with a decorator.
  38. raw strings
  39. Better memory control[ Go to top ]

    I don't know if this has already been introduced in Java but
    what I sometimes times feel the need for is capability to immediately
    garbage collect very large objects similar to C++ "delete". This provides
    better control over available memory when large objects are getting created
    very frequently. This should exist along with automatic garbage collection.
    I would like to know if there is any existing mechanism to achieve the
    desired effect.
  40. Take a look at Sun's official top 25 Java RFEs:

    http://bugs.sun.com/bugdatabase/top25_rfes.do

    a) Java should support const parameters (like C++) for code maintainence
    b) Allow subclasses to return subtypes of the original return type when overriding methods. For example:

    public class Test extends Object implements Cloneable {

       public Test clone() {
          ...
       }
    }

    The need for this will be less with generics but it still is usefull as classes need to be generified in that case.

    My votes to overridable constructors and default paramaters too.

    MC
  41. This is my list[ Go to top ]

    -attributes/properties -> no more writing/generating get/setters + no more getX setX

    They could just poor it in... you'd only need to change the compiler to create appropriate get/setters (for compatibility)

    -default arguments as in C++ -> method(String a, String b, String c = "123", int a = 5);
    This one too..the compiler could easily create the methods for you. Although a better solution could be storing the info in the class.

    -I don't know if it's done, but you could cache jitted code in a cached file. On ntfs you could store it in a named stream.

    -FreeBSD JVM!!


    And probably more.. :)



    by the way the tss code for replying is very annoying..
  42. Get rid of that bloated disaster known as Swing and put in something that looks native and performs decently on all platforms without all the complexity.

    MEMO TO SUN: If you have to figure out how to simplify something, maybe you should look at how and why it became too complex in the first place so you can avoid doing it again.
  43. Get rid of that bloated disaster known as Swing and put in something that looks native and performs decently on all platforms without all the complexity.
    Could not diasagree more!
    Long live Swing! All it need is a simplified L&F creation. Might be just matter of promoting and explaining existing L&F ideology. No XUL please, but (X)UIScript is welcome, kind of Jetty.
  44. I don't know if it's done, but you could cache jitted code in a cached file. On ntfs you could store it in a named stream.

    The JRockit JVM has an experimental feature to do this. However, it's not really a language issue, more of a JVM enhancement.

    There are many features one could wish for in the JVM. The most common hard-to-spot error is usually related to classloader.
    One option that would make our life simpler would be to allow sutff like -classpath ./libs/**/*.jar.
    In addition, having better debug options for the classloader. Have an option to search for and warn about several different versions of a class on the classpath.

    But again, all of these relate to the JVM, not the language itself.

    In the language, I'd put my vote in for tuples. Similar things can be achieved with templates, but the syntax would be much cleaner if we could write

    (name, age) = getPersonDetails(personId)

      instead of

    Tuple<String, int> details = getPersonDetails(personId);
    name = details.first;
    age = details.second;
  45. Ruby-ize java[ Go to top ]

    IMHO, we should look forward now and try to incorporate the wonderfull features of Ruby in Java.
    -Abhijit
  46. Dammit, CLOSURES![ Go to top ]

    I think an issue we have with Java is that it's responding to what people are asking for. Generics, pretty for loops and auto-boxing are no brainers, but they don't make THAT much difference to day to day coding. Please, no more syntactic sugar enhancements to an already over-cluttered language.

    Closures, on the other hand, make a HUGE difference. They increase encapsulation by making it easy to hide the underlying representation of objects, avoid the need for evil batch-style processing and (unlike iterators) are easy to implement. They also give us the power to create our own control stuctures for things like iteration, exception handling, transaction scoping, etc.

    The Smalltalk, Ruby and Groovy guys got this. IMHO, the improved productivity from these languages, particularly as codebases get larger, have less to do with the fact that they are dynamicly typed and more to do with cleaner APIs thanks to closures. The C# guys also managed to see the bigger picture.

    My 2 groats.
  47. A couple things more[ Go to top ]

    Inheritance for static methods.
    Force inheritance of visibility.

    So you can, as an example. Force implementing classes to use the singleton antipattern.
  48. Inheritance for static methods.
    Yeah! That is really missing feature. In Delphi it was great! You could have static inheritance. In Java there is no such thing! In our current project this is a big problem since we define our few layers of business object (meta data level and implementation level).
    The metadata level is based on static implementations, since naturally it does not have instances...BUT because Java has nothing for inheritance of static methods it was quite a big work around to somehow compensate this.

    This is really a BIG MINUS to Java as an object oriented language!
  49. declarations for database integration[ Go to top ]

    I'd like two feature for better database integration. First, be able to declare a member variable nullable, so if it wasn't nullable you wouldn't have to check for null values. A non-nullable variable would have to be set in the constructor, but could be reset, as long as the value isn't null.

    Second I'd like to see a way to declare a String length limit that is enforced. This would prevent persistence error due to String lengths that exceed the length of the corresponding database column.

    public class MyClass {
        read write nullable String length(10) name;
    }
  50. Continuations!!!
  51. As you didn't specify the language, I'd like to suggest a change to the platform. We're beginning to see more problems with the classpath in out organisation, not with the implementation but Sun, but the manner in which developers use the classpath. Some developers try to avoid problems by dropping jars into the lib/ext folder, but then they bypass security. I'd like to be see a tool like apt in debian, ports in freebsd or even just cpan in perl for consistent library management.

    I know maven and jpackage are efforts towards that goal, but they aren't standard. Until there is, there will always be problems moving between companies or even sys admins within companies.
  52. 1. No need to maintain slow ass unpredicable memory hog worst ever designed SWING.
    2. Make improvements in classloader, make it to load classed dynamically in a better way.
    3. Make VM more dynamic for development purposes where in debuggin is really easy, loading new classes / replacing old ones in runtime easy etc.
  53. 1. No need to maintain slow ass unpredicable memory hog worst ever designed SWING.2. Make improvements in classloader, make it to load classed dynamically in a better way. 3. Make VM more dynamic for development purposes where in debuggin is really easy, loading new classes / replacing old ones in runtime easy etc.
    Dont forget EJBs. We can survive without them very easily ( actually it will save us pain and maintenance cost ).
  54. 2. Make improvements in classloader, make it to load classed dynamically in a better way.

    You can do this now woth the OSGi framework. Read about it here <
    an download an open source implementation:
    <
    <
  55. The urls didn't show in my previous post.

    > 2. Make improvements in classloader, make it to load classed dynamically in a better way.

    You can do this now woth the OSGi framework. Read about it here:
    http://www.osgi.org/osgi_technology/index.asp?section=2

    And download an open source implementation:
    http://www.knopflerfish.org/
    http://oscar.objectweb.org/
  56. 1. No need to maintain slow ass unpredicable memory hog worst ever designed SWING.2. Make improvements in classloader, make it to load classed dynamically in a better way. 3. Make VM more dynamic for development purposes where in debuggin is really easy, loading new classes / replacing old ones in runtime easy etc.
    This strikes me as an outdated comment written by someone stuck on an old JVM.

    1) Swing may be complex, but it has a great deal of flexibility and does a better job at "write once run anywhere" than alternatives. It is also quite fast in Java 1.4.2 and higher JVMs. For instance, most find NetBeans 3.6 running in 1.4.2 as fast or faster than Eclipse...

    2) Do you have real suggestions? One can load classes in all sorts of crazy, dynamic ways.

    3) You can easily load new classes in Java 1.4 and higher JVMs. I don't know what antique JVM you're using...
  57. I agree that Swing is a good framework in a good hands. What SUN needs is to fix L&F for native platforms. Check out these links:
    JGoodies or
    L2FProd
    As you see it's a very nice looking stuff :) and it's as fast as SWT :).

    Giedrius
  58. Performance and memory footprint should improve significantly if we could create stack allocated objects (value objects, automatics, lightweights, whatever you want to call them). Also would love to allocate objects by value as members of structs and arrays.

    I would also like simple native-code access, similar to C# unsafe blocks. The idea of making it hard and inefficient (JNI) just to discourage native calls is silly. I think we are all mature enough to know when it appropriate to use native libraries. So for those instances why not make it fast and easy?
  59. I would also like simple native-code access, similar to C# unsafe blocks. The idea of making it hard and inefficient (JNI) just to discourage native calls is silly. I think we are all mature enough to know when it appropriate to use native libraries. So for those instances why not make it fast and easy?
    +1
  60. +1 ?! -10 !!![ Go to top ]

    The point of JNI isn't to make it hard and inefficient. It was to allow clean separation. Are you so confident that you can write inline native code that will work on every platform in a simple inline block? Are you going to write the ability to compile any dreamable language into the Java compiler?

    A C# unsafe block simply allows you to perform unsafe operations in the current language. JNI allows you to link and execute native (machine) code at runtime. Those are two very different things.
  61. I could ask the same questions of JNI. Are you so confident that you can write JNI code that will work on every platform? Does JNI have the ability to link to native code of any calling convention?

    Keep in mind that I'm not suggesting everyone start writing Native code for the fun of it. But there are times when it is required. In those instances it should be simple, and as efficient as possible, which JNI is not.

    As for linking to native code in C#, that is much more simple and efficient than JNI, and you don't need to code and package useless proxy dlls.
  62. I'd love to have this feature too, but I can't envision an implementation that will not subvert the relative safety that the JVM spec provides today.

    I suppose there could be some sort of code signing or other scheme to allow these type of operations to occur in relative safety. But just as soon as I say that, I think of ActiveX and the gaping security holes that presents and shudder at the thought.

    Given the choice, I'd rather have more safety with a little less convenience. As always, pick one: security or ease of use.

    For safe and sane developers, something along the lines of an explicit delete operator would be extremely useful too, although the reality is code runs in an unsafe world where not everyone has a legitimate agenda.
  63. How is JNI safe?[ Go to top ]

    How is JNI safer than "unsafe" blocks, or some other mechanism to make simple and efficient direct external calls? As far as i know, JNI can not prevent native code from corrupting a JVM?
  64. transactional methods[ Go to top ]

    This is speculative. How about transactional methods that don't change the object state unless they complete without throwing an Exception? This would make some of the cleanup normally done in a catch clause automatic. Assignments made to member variables would not be copied into the actual variables until the method completes. Transactions would be chained.

    public class MyClass {
      int i;

      public transaction void do() throws Exception {
         i += 5;
         ...
         if (bad) throw new Exception(); // value of i not changed.
         ...
         // now local value of i gets copied to member i.
      }
    }
  65. A few things I'd like[ Go to top ]

    JARPATH (instead of specifying individual jars in the CLASSPATH)

    The ability to set default TCP options (especially KEEPALIVE) from a system property. Maybe also an easier way to create socket factories.

    I agree with some of the other things mentioned here like simpler properties and closures. Along with closures, it would be nice for arrays and containers to make use of closures. Also, some of the enhancements to File that Groovy adds for using closures. Closures in AWT & Swing for specifying actions would be handy, too.

    I'd also like to see platform-specific optional packages. For example, Python has a lot of useful Windows-specific functions. It would be nice to see built-in support for creating a Windows service. I somehow doubt this will ever be considered since it goes against the WORA principle - the only thing I can say is that it doesn't appear to me that the presence of platform-specific functions in Python has caused it to become rooted to a single platform.
  66. Add more formal/strict versioning.[ Go to top ]

    A better versioning system needs to be added so different versions of libraries can co-exist (or the behavior needs to be formally defined). I would also like to specify the versions of my dependencies and have system enforce my version requirements.
  67. A higher level unit of organization (beyond packages) to facilitate component based development outside of the container. We've got .jar files, but you can't control anything at the .jar level.
    Along with this, the ability to define a components published interface. Along with that, the ability to declare an class' "friend" to facilitate testing a component's implementation without requiring an implementation class to become part of the component's published interface. Maybe even the ability to define a component's relationships to other components.
    I think this higher level (physical) view of a system is often times missing, but it can contribute quite a bit to easier maintenance, reuse, and deployment.

    --kirk
  68. Auto-delegation as described here: http://c2.com/cgi/wiki?AutomaticDelegationForJava

    This would make it much easier to define your own validating list, for example. (You know that delegating to an inner ArrayList is the right thing to do, but it takes so much code to do so it is tempting to inherit ArrayList instead.)

    Declarative lists aren't that big a deal, but declarative maps would be great:

    Map peopleByName = new Hashtable(){ "bob":bob, "sarah":sarah };
  69. Round trip modeling[ Go to top ]

    I know there are many skeptics here concerning MDA. I used to be one of them. Java classes can be generated from a model but model information is lost. Java classes have information to recreate class diagrams and sequence diagrams but information needed for higher level models is lost.

    I hope attributes will be able to handle this but there has to be something like XMI defined for Java. I don't keep up with the JCP maybe this is already in the works.

    The idea is to generate code from the model and then be able to regenerate the entire model from the code. This isn't impossible and if Java doesn't do this, you know who will.

    Gary
  70. more stuff[ Go to top ]

    A MultiMap interface along with associated implementations.

    A Pair class just like in C++, i.e. first and second. How many times must projects write this.

    A way to specify packages that can be used to autoqualify classes, i.e.
    java -Dautoqualify=mypackage1,mypackage2 ...

    and then write code like:

    MyClass1 mc1 = Class.forName("MyClass1");

    rather than:

    MyClass1 mc1 = Class.forName("mypackage1.MyClass1");

    Makes a big difference when you start getting into large projects with class heiarchies that run into four or more levels.

    I like getters and setters. They are their for abstraction, i.e. a get is not always just "return foo;". You can just use public properties if you do not like them so whats the problem.

    Bruce
  71. Add preprocessor construct, at least #if def debug
  72. Ability to partition applications in a JVM instance such that individual applications can be started and stopped without brigning down the JVM. Ability
    for these applications to share data with each other (without having to isolate
    the common classes and putting them in the parent class loader).

    Such a feature would be a boon for service provider environments hosting
    several web-apps on appservers.
  73. Ability to partition applications in a JVM instance such that individual applications can be started and stopped without brigning down the JVM. Abilityfor these applications to share data with each other (without having to isolatethe common classes and putting them in the parent class loader).
    Couldn't agree more.
    Also,
    1. Side by side execution
    2. Ability to "specify" the dependencies (version 4.5 of that API, version 2.3 of this one etc)
    3. Refine Swing default look and feel (please let professional GUI designers create it. and then get it done by application developers).
    4. Introduce the concept of an "application", so that we don't see java.exe or javaw.exe in the task manager. Make this possible in a platform neutral way.
    5. Guard against adding un-necessary language features (you can find lots of them in this thread ;-) )

    We need a simple language, a framework that provides us with lots of flexibility and features without burdening us with complications.

    And, a big NO to the "transactional objects" specified in one of the threads above. (We are already having lots of trouble with EJB containers anyway :-) )
  74. JSR 121[ Go to top ]

    There already is one called the Java Isolation API, JSR 121:

    http://jcp.org/aboutJava/communityprocess/review/jsr121/index.html
  75. What to remove![ Go to top ]

    A St. something said once:"you are done, not when you have nothing more to add, but when you have nothing more to remove".

    So things like govy are simplifying Java. rt.jar is 18 megs!

    Of the top deprecate: girdbag, ejb, corba package can go to another jar...


    .V
  76. What to remove![ Go to top ]

    "you are done, not when you have nothing more to add, but when you have nothing more to remove".
    +1
  77. What about a true enumerated type[ Go to top ]

    I'm talking about a true enumerated type (like Delphi) not the C++ one. This can remove the big overhead and the headache of creating enumerated types classes. The enumerated type should be lightweight and type safe.
  78. "this method" and automatic type cast[ Go to top ]

    1. It would be great if the reflection mechanism could know the "this method" - the running method.

    public void someMethod() {
        this.method.getName(); //someMethod
    }

    2. Second the compiler could resolve some casts automatcally

    String name = request.getAtribute("name"); //the compiler can resolve cause Object can cast to String. Its simple, I think :)
  79. Raw Sockets?[ Go to top ]

    You guys can ask for the crazy language features, i'll simply ask for Raw Sockets. theres been lots of small network utilities i've wanted to write, and i've been forced to whip em out in C# (bleh) instead. Come on SUN! Help me to give up C# for good! (except when people pay me money to do it).
  80. Lightweight objects![ Go to top ]

    The 8-byte per object overhead kills designs with many small objects. And even though new is now almost free for small temporary objects on single-processor machines, its performance is still pretty bad on multi-processors. I want struct-like entities that have zero memory overhead and whose lifetime is bound by ther containing parent. Basically, give me primitives with fields.
  81. type anchoring[ Go to top ]

    PL/SQL has a tremendously useful concept called anchoring, where you can declare the type of one variable based on the type of another. E.g. you can say:

    orderId orders.id%type;

    to declare a variable orderId of the same type as the id column in the orders table. It also works without tables just by referring to another variable's type. In Java I would like to be able to do something like this to declare a variable with a type that a particular getter returns:

    Person.getBirthDate().class aBirthDate;

    So if the return type of Person.getBirthDate() changes, say, from Long to Calendar, my variable would also change its type.

    Of course, if the variable is actually used by a particular piece of code, anchoring isn't of much use because it is likely that you have to change the code anyway when they type changes. But very often, variables/parameters are just passed through without being used and that's where this facility comes in very handy. In a way this has some similarities with generics.
  82. Make a class a singleton[ Go to top ]

    public singleton class MyClass...
  83. Singletons are evil[ Go to top ]

    Singletons are evil. Too many times I've been forced to deal with the mess left behind by singletons. Just because you can't think of a reason why someone would want more than one instance of your class doesn't mean someone else won't. True singletons prevent multiple instances, subclasses, or anything else that might allow more than one to come into existence. You have to be all knowing to fortell that no one will ever want to do that.

    I was burned by the Java Mail API's lazy-initialized default instance (sort of a singleton) when I found out in integration testing that someone else's component was also lazy-initializing the default instance and whoever happened to get initialized first, one. Fortunately, their default instance was for convenience but they still allowed for multiple instances if needed -- which I did.

    Besides, because of the wonderful classloader heirarchy, if someone really wanted to have more than one instance of your class, they could still do it. all you gain by making a singleton is the ability to annoy others.

    Providing convenient access to a default instance is one thing, but a singleton is much more restrictive than that.
  84. I would like to be able to declare a class as a constraint on another classes objects. For example, if I have a class like this:

    class Person {
       public int getAge(){...}
    }

    I want to be able to define a class Adult as:

    class Adult extends Person where getAge() >= 18;

    And then I could have a parameter of this type in some method:

    public void buy(Adult a){...}

    Obviously type checking would have to be dynamic in this case. One could easily write procedural code inside the buy method to check for the age constraint, but that way, the constraint would be buried inside the implementation of the method instead of being part of the interface where it belongs.
  85. Couldn't agree more[ Go to top ]

    Especially in a language like Java, which is managed at run-time, why can't I just declare a class to be a singleton? The VM should take care of it. That will get rid of all stupid double locking stuff (which doesn't work anyway)!
  86. Better GarbageColector interaction[ Go to top ]

    Will be very usefull if Java will provide an API, for interacting with the Garbage collector.
    Will be great to have a class GarbageCollector, which can provide some methods like:

    suspend() - suspend the garbage collection process until resume() methosd will call
    resume() - restart the garbage collector
    colect()- ask tyhe garbage collector to collect all the avilable memory(not only sugests like System.gc() method)

    This method help alot for better memory management of JVM, and also can improve performance in some critical situations(if there is a critical task, which I want to be executed as fast as possible whith any costs, calling GarbageCollector.suspend() will be helpfull)
  87. I'd like to see some form of garbage collection control. It is presumed that Java knows more about an application and decides when garbage collection may occur. This may cause problems with some programs operating close to real-time with a large numbers of allocated classes. While it may be safer for Java to pick up the garbage collection, only the application designer knows the optimal time to perform this task.

    I'd also like to see some form of function member variables.
  88. Make java a functional language :))[ Go to top ]

    Here's my list:
    -Closures,
    -native tuples and lists (list comprehensions),
    -First Class Functions,
    -Type Inference

    ...looks like I could've just said - Make java a functional language :))
  89. Better NullPointerException[ Go to top ]

    How about having the NullPointerException contain the name and/or type of the reference that was null?
  90. Better NullPointerException[ Go to top ]

    Something like System.ShutUp() to rollback a shutdown.
  91. And ClassCastException[ Go to top ]

    How about having the NullPointerException contain the name and/or type of the reference that was null?
    And have ClassCastException contain the name of both the source and destination types!
  92. Java needs to be like[ Go to top ]

    Ruby, or Groovy, or Delphi, or C#, or C++ any of the 1/2 dozen other even more obscure languages mentioned above.

    Or even better get rid of EJB, or Swing or AWT or what ever other package you don't like.

    Perhaps some people here are using the wrong tool for the job...almost as many people that confuse OPTIONAL packages or frameworks with the core language of platform. If you don't like Swing or EJB don't use them. I happen to like Swing and hate EJB, so I use Swing and Hibernate\Spring.

    I sometimes miss the "delete" from C++ but I won't loose sleep over it. Most of the other syntatic garbage in this thread is just that - garbage. It won't make code more readable(less read able frankly, which is also my opinion of the new loop construct) and it makes precious difference once it's compiled to bytecodes. All I see are people wishing to push into the core language and platform the newest "sexy" constructs which are yet to prove themselves - AOP, MDA and various flavours or what OOP should be.
  93. Surprised no one pointed out the basic issues with types, like no (shock, horror) built-in decimal type. (And BigDecimal is worthy of a Hani.)

    We're also missing unsigned types (other than the 16-bit variety called char) and support for exceptional arithmetic (over/under-flow detection.) Also, 128- and 256-bit FP binary and decimal types would be nice. Also a built in binary string type (a constant byte[], as String is a constant char[].)

    Then there's the abominations of (and related to) date, time, date/time, the lack of interval, etc.

    In other words, forget all the high-level stuff when the core JVM and language types are so weak.

    On the other hand, it's amazing what you can do with such a "weak" language ;-)q

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  94. Better JVM[ Go to top ]

    Maybe Sun should realize that hosting more than Java code on a JVM is going to be pretty common practice and improve the instructions to help languages that are closer to the functional world. Things like tail calls, closures, first order functions or tuples should first see support in the bytecode and then on the language.

    Maybe throw away the stack based ISA and go for a more compiler-friendly representation, something like a SSA tree with annotations. This would make jitters fasters and able to produce better code.

    One thing that would be cool is to leverage the language support for reflection, have Object.class, it would be cool to have Object.equals.method. I know there are some pretty nasty namming resolution issues with this, but it would still be nice.
  95. JDOM is very nice, very easy, and should be in Java 1.6.

    RPC-encoded SOAP requests are not scalable. They should not be in any part of Java. See my blog to learn why.

    Make Jython, Groovy, and anything else that compiles to Java byte code an officially supported effort.

    -Frank Cohen
    www.pushtotest.com
  96. 1. More native implement
    Java(program) is not cross-platform, it is JVM dependence.
    And JVM is not true cross-platform in somecase.
    So, Java is not real cross-platform after all.

    Somebody not using SWT because it is not exist in every platform. But what if the standard implement of J2SE 1.X already have it? We can run SWT if can run Java.

    Same as SWT, we can add NIO, Crypto, and othres....
    If some platform cannot do in JVM, we can use java code to implement.

    2. Dummy JNI
    I don't know, but can the native method written in Java class?
    Then we can change the implement native <-> java without changeing the Java code.

    3. Archive not only zip
    Like Collections, a interface for using archive files. Zip is one of the implement. Then we may have zip/rar/iso/cab without change the code alot.

    4. a better String.equals
    we use it a lot....
    check the hashCode() is equals or not before starting the loop....
    only do the loop if hashCode are equals (hashCode must equals if String equals, am I right??)
    hashCode is cached, but do forloop everytime?

    If the String is equals, but using two char[]/String object, merge them.
    I wonder how long the VM will keep the huge char[]?
    (Where can i found java 1.5 src online?)

    5. more optimize for CPU
    I heard that Sun JVM have optimize for SSE(but where?).
    But can we use them in our java source without native code?? (e.g. image processing)
    And will there an preformance improvement if java.util.Arrays use them?

    (Does Sun JVM really use the code in src.zip??
    or they run in differnece way in debug mode?)

    6. unsigned numbers.....
    unsigned byte, unsigned int, unsigned long.......

    7. add something common into J2SE/SDK
    like log4j, ant, they are too common

    8. another vote to return multiple values
    I don't want to build a lot of value class, or Object[].

    9. JSP+
    like ASP.NET, they have WebControl and easily to control the "View" without making a lot of tag. And can do it dymanic in widget.
    I know there are 3rd party code can do some(in JSP with taglib), but still too young to use.

    10. CleanType for Swing / AWT
    (still missing in 1.4.2; and, I never heard anything about it on 1.5)
    One of the reason why some people use Eclipse not Netbeans.

    11. Run as Servies
    Without any 3rd party.

    12. smart class casting....
    String value=session.getAttribute("key"); // without (Strnig)
    Byte b=new Byte(123); // without (byte)

    The compiler can know what I am going to do.


    Correct me if I wrong.
  97. More access control[ Go to top ]

    Things like C++'s friend construct give you a more fine grained
    control over who is allowed to call methods etc.
    Protected and package default is not enough IMHO.

    But in times where everyone creates public setters/getters for every
    "property" and throws out encapsulation out the door, this doesn't seem
    important.

    To those folks who complain about setter/getter: Learn how to properly
    use them. If you expose all your attributes as "properties" you are probably
    doing something wrong! (Or are forced to use the wrong framework).
  98. Just to add a few things:

    1. Ahead Of Time Compilation with Caching of compiled code: There is just no need that Eclipse or any other big Java application is jitted everytime it is run. This should be done at the initial startup, then a memory dump should be cached on disk, then hotspot could go on as usual. The next run only the memory dump will be loaded, then hotspot could start immediately. Thus startup times of big applications could be greatly improved. Also the perceived speed of java would be higher.

    2. To me it was a very bad idea to map to native threads on the different OSs. This leeds to different behaviour on different platforms of your application. WORA here is just no reality. Make real lightweight green threads with portable thread semantics. I want to be able to write applications with more than 10000 threads (with 1:1 thread mapping) that behave identical on every platform. Also implement Context Switching in microseconds. That is possible. Take a look at the Erlang programming language.
  99. Java is not yet there[ Go to top ]

    Java is very instrumental due to portability and due to
    vast support it has but not yet there in terms of becoming
    a convincing object oriented language. What I would like
    to see is:

    1/ Multiple inheritance
    I have the feeling that in early Java days it was left
    out just because it was too much of a burden to implement.
    Why is it still out is however a secret to me.
    Real world object do have multiple parents so why the
    language should force on us ugly workarounds? Not to speak
    of how instrumental multiple inheritance would be in so
    many situations when the sacred single base class role is
    already occupied.

    2/ Dynamic classes
    Why not if there is already dynamic interface implementation?

    3/ Properties
    Java can hardly live forever with the get/set hack which
    is an obvious and ugly afterthought.

    4/ Macros
    Not THOSE macros of course;)! Forget about C - think better
    of Listp. People are doing such things for Java with
    preprocessors and byte code enhancers. Why not Sun too?
    Lot of other issues could be solved by macros.

    More down to earth issues:

    1/ Compile time configuration
    Essentially missing and badly needed.

    2/ Seamless conversions or/and variant type
    I do not understand why Java stops half the way in dealing
    with seamless conversions between numbers and strings. Why
    are e.g. numbers seamlessly covnerted to strings in expression
    context but not in assignment or parameter passing context?
    Also the other way around: why can I not say double d="123.4";?
    A variant type (the only scalar type of most scripting languages)
    could also do the job.

    3/ Better implementation of sockets. It is such a pain that
    thread waiting on a socket can not be interrupted at all times
    (depending on platform) and there is not even usable platform
    independend timeout.


    BTW - Thank Sun for finally prvoding (in 1.5) typed
    containers and metadata. Those are high on my list too.
  100. Here's a thought....
    Why don't we clone C++'s or C#'s syntax into Java? Better still... why don't we build a VM for C++, and forget Java altogether?
    Come ON, people!!! Use some common sense!
    Change is not good by definition. We need EVOLUTION, not mere change.
    Those who want attributes instead of getters and setters don't like Java. So, use C#. NOBODY is pointing a gun to your heads, you know.
    A distinction must be made, I think, between the Java language, the JVM, the core class libraries and the standards.
    The language (any programming language) should be ingenieered after OOP concepts, not just considering the lazyness of programmers... And redesigning the classloaders architecture has nothing to do with the language's syntax. How good or bad Swing is is not something you must consider when defining the garbage collector's behavior. See my point?
    If and only if there's something wrong with the language, well, let's address that issue. But it think it's not a wise idea to mix everything in the same bag and rewrite the language, the core libraries, and the standards at once. That would pretty much be comming up with a different language and platform.
    Someone suggested this feature:

    public singleton class OhManImSoLazy
    {
    }

    Sure, let's do that. Next, someone will suggest this horror:

    public singleton persistent class OhManAintThisBetter
    {
    }

    So, we end up with a big fat JVM just because we dont like to write 5 lines of code to implement the singleton pattern. What we want is the JVM to do OUR job, and get paid for it, right?
    And educated request is, in my oppinion, multiple inheritance. Having a method return an arbitrary number of values is just noise and, again, lazyness.
    Something good about this post: we get to see how muy people like or dislike Java.
    I guess that if I had lots of free time I'd suggest an open source project to build a VM and differtent languages targetted to it (perhaps Java being one of them). .NET's open source counterpart, let's be honest. THAT way we could address everybody's needs and requests, and yet keep things sepparated...

    Regards
    Martin
  101. Those who want attributes instead of getters and setters don't like Java.

    Do you not like ice cream if you put whip cream on top?
    A first class properties is cleaner because it moves up the
    abstraction level. That's different than not liking java.
  102. Do you not like ice cream if you put whip cream on top?
    I'd say you do not like line plain ice cream (aka Java), but ice cream with a cherry (aka Java + not Java stuff). A cherry is clearly not ice cream.
    Perhaps I feel REALLY purist this days... ;)
    Didn't mean to be an ass, but I hope you got the meaning... Java with properties and some other features suggested in this post (structs, a delete operator, an such) is not Java any more. Java++, perhaps, but not Java. Would you feel yourself with a nose popping outta your forehead?

    Regards.

    Martin
  103. public singleton class OhManImSoLazy{}Sure, let's do that. Next, someone will suggest this horror:public singleton persistent class OhManAintThisBetter{}
  104. public singleton class OhManImSoLazy{}Sure, let's do that. Next, someone will suggest this horror:public singleton persistent class OhManAintThisBetter{}
    I just thought it would be nice if you could really ensure that there were only one instance of a class in a VM in a consistent reliable manner. Aren't patterns like singleton just work arounds for things missing from a language? We have dynamic proxies to help with the proxy pattern. They don't call them:

    OhManImSoLazyDynamicProxy{}
  105. Aren't patterns like singleton just work arounds for things missing from a language?
    If that was true, we should populate languages with keywords to solve every design issue possible, right? A "singleton" keyword, a "persistence" keyword, a "this-is-an-bmp-entity-ejb" keyword, a "this-is-a-stateless-session-ejb-published-as-web-service" keyword... see my point?
    Perhaps that's a smart approach, but it's not Java. Call it JavaX, myJava, JavaReoladed or whatever you want.
    If you wonder "Do Generics in JDK 1.5 mean plain old Java died in J2SDK 1.4?"... my answer is another question. Do you think the Visual Basic in Visual Basic .NET is the same Visual Basic we had in Visual Basic 6.0? Are C and C++ the same language? Their names are similiar; but there are a lot of dudes called Martin out there who are not me...
    Another example? Adding a "delete" operator to effectively remove an object and release its memory space is a significant change... A basic concept of Java is: any given object lives until the garbage collector says different. It's one of the top ten statements in very Java-4-Newbies book. Challenging that core concept would turn Java into something else.
    Conclusion: certain changes affect the very nature of things. That change might be good or bad, of course, but we should agree on the fact that we are dealing with something different - even if we keep the name for convenience.

    Yeah, I'm a purist...

    Regards.

    Martin
  106. Hey Martin Dude, I guess you need to visit your logic. There is no such thing as PURE JAVA. There is no such thing as PURE. Absoulte, everything is relative, remember Albert Einstein. So scale down you Nose in forehead, argument, nose is already in forehead, we are trying to fix it.
  107. That all depends on what YOU understand by pure. It's clear to me that we don't agree on the word's meaning, nose on forehead or not.
    And I'd really like to know why are you trying to fix something that's not broken t begin with. The fact that something is not the way you like does not mean it's broken.
    "I'd like to have properties because it's convenient to have them" does not mean getters/setters are wrong...
    I guess people complain just because they can do it for free. I saw no argument in this post saying "this is wrong beacuse OOP concepts say different". I read a lot of "i can do this in C++ but not in Java", though...
  108. Interpreted jsp[ Go to top ]

    Interpreted jsp.When one work the view this is particularly annoying to always wait for the jsp machine to end its job, dreaming about php fast written responses. Of course there are other machines like Velocity but this is not jsp.
    Some thing like a directive in a beginning include, like
    <%@ page langage="java" machine-name="interpreter" %>
    And when out want to put it live you just change this.
  109. I like to see real class variable & method will the same features as instance variables and methods (ie. same overloading, protection and scope rules).
  110. In no particular order...

    - Attributes in the language rather than a getter/setter pattern
    - Tuple return types
    - Structs
    - Covariance and contravariance
    - Remove "throws"
    - More networking support. e.g. Ability to implement "ping"
    - Optional manual memory management, like C# "unsafe"
    - Internally scoped classes, like C# "internal"
    - Jagged arrays, like C#
    - Indexers, like C#

    Not really language features, but...
    - A more comprehensive JAR versioning/packaging system.
    - Would be nice if a process list returned an application name rather than "java -server -cp blah blah..."
    - Was going to mention a UUID generator, but just noticed Java 1.5/5.0 has one. Probably a bunch of hidden goodies in there.

    And...fix Java's memory footprint.

    Matt Youill
    betfair.com
  111. Conclusion & Supplement[ Go to top ]

    1.Property Support
    never need to choose between public field or getter/setter;easy to override;make 3rd party tools like commons.beans more useful
    also, should use jdk1.5 meta to specify boundary/vetoable, what's more, compiler hence auto-generated getter/settter would provide common interceptor for accessing/modifying property, so we needn't to write in every beans' setter/getter for caching or ORM.

    2.AOP Support
    A destiny.Using CGLIB is a roundtrip, this feature should be language level.But we might have to wait a long time before AOP is mature enough

    3.Interface instantialization
    a truely interface-oriented language should let us easily instantialize a interface.
    "Document doc=DocumentFactory.createDocument();" is just too verbose,why not "Document doc=new Document();"?
    The system will search the implemention is order somehow like this:
    First in system property, like "java.xml.Document=org.jdom"
    Secondly, in proxy property, like "java.lang.reflect.Proxy=org.springframework.BeanFactory"
    Then.....

    4.XML native feature support
    not only more nicely XSLT,XPath,XQuery integrated
    but also apply this tech to common Java Object, like the EL in jsp, and more powerful, M$ & Adobe's InfoPath

    5.Manually GC object
    System.gc(Object o), which in turn call Object's finalize() method.(finalize method seems never exist since it was invented.)

    6.Object.equals(Object o1,Object o2)

    7.More information in NPE and ClassCastException

    8.Make clonable() truely useful or deprecate it
  112. Switch statements typeless[ Go to top ]

    Switch types should be typeless, e.g. this should be valid Java code:

    String myString = "hello";
    switch(myString){
      case "hello":
        System.out.println("hello world!");
      break;
     ...
    }
  113. Switch statements typeless[ Go to top ]

    +1 to typeless switch statements
  114. Covariance
    FYI, Java 5.0 has support for covariant return types. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4144488
  115. Need an option to delete objects as in C++[ Go to top ]

    As many had mentioned before, it would be really great if there is a delete operator as in C++. Garbage collection can be a backup option, but one needs a direct mechanism to delete objects. This option should have been present right from the beginning. I never understood Sun's argument for not providing one.
    - My 2 cents.
  116. Need an option to delete objects as in C++[ Go to top ]

    Having an explicit "delete" within a garbage collection framework makes no sense because when you do your delete a full blown garbage collection would have to be run in order to check that your deletion isnt creating dangling references.

    That is unless you are preposing a delete that potentially allows deangling refs ...

    Paul C.
  117. delete() considered harmful[ Go to top ]

    To all the folks advocating for more control over the GC:

    Imagine you have a delete, and imagine you mistakenly call it on some object to which there are still 'live' references elsewhere in your code. One of two things can happen. The GC can make sure the object is safe to delete by traversing all references in your VM. This degenerates into the equivalent of invoking a System.gc() and gains you essentially no efficiency. Or, the GC can delete it, freeing the memory on the heap, without checking that the object is still referenced.

    What would happen if we chose unsafe delete? Calling a getter on the deleted object would likely return garbage. Calling a setter might corrupt another object. Calling a method would try to execute garbage java byte code. Leading to whatever the VM equivalent is of dumping core. Also leading to all the security exploits found in C and C++.

    Trust yourself? While this type of bug is extremely common is C and especially C++, I trust myself too. But do you want the authors of the libraries that you depend on to have this ability? I don't. Knowing that a library call to some non-so-well-written code might corrupt the heap would not make me feel too good.

    GC is fundamentally a trade of robustness and safety for performance. It's an exceptionally good trade. Plus run-time optimization does a lot to mitigate the performance loss. If you allow a 'back-door' around the GC you loose most of the benefit, because you could never be sure.

    I would propose that making JNI easier to work with would better address the cases where the trade-off isn't worth it. If you need the speed code in C or C++. And, it might be a better idea to communicate with the native code via sockets so the native code can run in a separate process from the VM.

    Just my two cents,

    -Chris
  118. Pass by copy & pass by reference semantics when calling functions.

    [] operators on indexible Collections

    Parallel processing constructs (openmp-like?)

    Refactoring the runtime objects
  119. nothing too much[ Go to top ]

    Maybe I'm in a minority but I don't really want to see too much change to the Java language. Over the various releases (particularly for Tiger) so many new features have been added that the language has lost the feel of simplicity that I remember it having when I first started. Java is now starting to look a little cluttered, what with all the additions like generics, etc. It just isn't so pretty anymore. Add to that the fact that it also has so many deprecated methods and classes (somebody sort out java.util.Date) and I can't help but feel that we should stop adding stuff to Java. You can only add so much to a language before it is just messy (C++ anyone?). To me Java is starting to smell like it is in need of a good refactoring.

    Much as I don't really want to add much more to the Java language, that doesn't mean we should just stop any progress. If people want new features like closures etc, why not start on a new language to run on top of the JVM? That way you get your funky new feature, without crowding out the rest of the Java language. That doesn't have to mean some script language like Groovy (hate the name) necesarily, just that it is possible to write alternative languages onto the JVM.

    just my £0.02
  120. Multimethods[ Go to top ]

    .
  121. Metaprogramming[ Go to top ]

    There's definitely a trend if you look at aspects, generative programming, model-driven programming, or even (maybe) things like EJB containers and OR mapping tools. All do some kind of programmatic manipulation of code -- metaprogramming.

    The last decade or so was about integrating OOP into the mainstream and Java was instrumental in helping this along (as opposed to the C-with-inheritence mindset common to this day in the C++ world). It seems that metaprogramming is getting ready to go mainstream and I think Java as a platform could benefit from playing a similar supporting role.

    I guess the place for this is not so much in the language except insofar as the language VM and compiler can be made to make life easier for metaprogramming tools.

    -Chris
  122. Summary[ Go to top ]

    This thread was really interesting, so I made a summary of the ideas that I thought were noteworthy (not necessarily good, just noteworthy). There is some editing by me 'cause I wrote the summary.


    Functional language constructs:
    closures
    continuations
    optimized tail recursion
    multimethods
    support for metaprogramming


    C++ish language features:
    unsigned numeric types
    Multiple Inheritence or some limited form of multiple inheritence to support mixins.
    friend construct which would allow a class to give privilidged access to another class or all classes in another package.


    Syntactic Sugar / Convenience
    ability to inherit constructors
    ability to inherit static methods
    default parameters in method signatures
    remove the need to create getter and setters for attributes
    allow some form of operator overloading on anything that implements Number


    GUI / Swing-bashing
    Deprecate AWT, it sucks!
    Deprecate Swing, it sucks!
    Create a new GUI library like either SWT, Cocoa, KDE, XUL.
    Create a new GUI library based on declarative metadata and high level interfaces that allow multiple implementations and fully native look-and-feel.


    API features:
    Better support for interacting with file systems and the host OS in general. maybe java.os.windows, java.os.solaris, java.os.linux, java.os.macos
    Better JNI
    Date and Calendar suck! Java needs better date, time, and date/time handling. Start by not confusing the three. Support data math, for example:
    Date warrantyExpirationDate = todaysDate.addDateInterval( ninetyDayDateInterval );


    Compiler / VM features:
    support for multiple languages running on the VM with interoperability between them.
    ability to put all jars in a lib directory into your classpath
    ability to efficiently detect overflow of integer and similar datatypes
  123. My personal favorites[ Go to top ]

    I picture a friend construct working something like:

    class MyClass {
      friend: com.mydomain.SomeOtherClass;
      friend: net.sf.hibernate.*;

      // no public setter for this!
      // immutable to most of the world
      // except for friends
      private sensitiveData;
    }

    Now hibernate and my own SomeOtherClass see sensitiveData as publicly settable, but to the rest of the world it's read only.

    I'd like to see an extension for operator overloading on anything that extends java.lang.Number. That would make it much nicer to work with the non-primitive numeric types. Imagine:

    Complex c = new Complex(1.1,3.1234);
    Complex d = new Complex(123,1.0);

    Complex e = c + d;
    Complex f = c + 100.0;

    -or-

    Matrix m = new Matrix( ... hmmm how would you make this part non-ugly? );
    Matrix n = new Matrix( ... );

    Matrix scaled = m * 10.0;
    Matrix product = m * n;

    hmmm, maybe you'd also want to generify Matrix so you could have a matrix of integers or a matrix of double.

    We're lucky to have so much cool stuff going on in the world of programming languages. Remember when your only choice was who's C compiler you wanted to use?

    -Chris
  124. My personal favorites[ Go to top ]

    I picture a friend construct working something like:

    class MyClass {
      friend: com.mydomain.SomeOtherClass;
      friend: net.sf.hibernate.*;

      // no public setter for this!
      // immutable to most of the world
      // except for friends
      private sensitiveData;
    }

    Now hibernate and my own SomeOtherClass see sensitiveData as publicly settable, but to the rest of the world it's read only.
    Wouldn't the "friend" notion be an ideal candidate for an application of metadata?

    Regards,
    Jens
  125. friend[ Go to top ]

    class MyClass {
       friend: com.mydomain.SomeOtherClass;
       friend: net.sf.hibernate.*;
       // no public setter for this!
       // immutable to most of the world
       // except for friends
       private sensitiveData;
    }

    Probably more like this:

    import some.package.SomeClass;
    friend some.package.SomeClass;

    class MyClass {
       // Whatever
    }
  126. My wishlist[ Go to top ]

    1. Unsafe/manually managed code. For those moments when you need that extra speed.
    2. Smaller, leaner, faster VM.
    3. "customer.order.totalAmount" syntax instead of customer.getOrder().getTotalAmount()"
    4. Simpler Perl-like regex functions (ie, m//, s///, etc)
    5. Tuple assignment, like (custNo, custName, custPhone) = (matcher.get(1), matcher.get(2), matcher.get(3));
    6. A GUI toolkit done right. Native look, and not over-engineered (like Swing).
  127. You asked for it[ Go to top ]

    A lot has already been said, but here is my 2 cents.

    1. Extend classes with version information and version requirements of other classes.
    Add version aware class loaders.

    2. Named parameters: e.g.
    public void myFunc(int x = 1, int y = 2, int z = 3) { ... }
    and then
    myFunc(x = 5, z = 1);

    3. Multiple return values
    a, b = x();

    4. Property keyword with default implementation and optionally includepropertyChange and vetoableChange calls.
    @property String name;
    @readonly @property String name;
    @writeonly @property String name;
    @invokePropertyChange @property String name;
    @invokePropertyChange @property String name;
    @invokeVetoableChange @invokePropertyChange @property String name;
    And of course use them like normal variables: myInstance.name = "bla";

    5. Include the return type in method overriding.
    Now
    public int doThis(int)
    is different from
    public int doThis(String)
    but not from
    public String doThis(int)
    IMHO return values can be considered "output" parameters and therefor should be included in the override logic.

    6. Automatic deligation (automatically create methods that redirect all calls to another object).
    class X delegates y [interface Z,...]
    {
    Y y = new Y();
    }

    7. Aspects. I like aspects. I love aspects.

    8. One preprocessor command for writing code that is compileable with different Java versions.
    E.g. JDBC class wrappers; with each Java iteration more methods are added
    and each time I need to copy the whole tree of sources to support a new release and then making alterations, ah well, you get the idea.
    #java1.4
    #endjava1.4

    9. Split up Java in multiple optional jars instead of one big rt.jar. If I don't need Swing, why deploy it with my app?
    The rt.jar has been growing steadily over the last few years.
  128. Mapped Substings[ Go to top ]

    I would like to see:

    -Mapped Substings (or similar name)
       The ability to create a substring which implements CharSequence, that does not create a new object every time I want to create a substring.

    -Implement more methods that accept the more general CharSequence, instead of just String e.g. Graphics.drawString.

    -*Optional* cached JIT for client-side startup improvements.

    -Improved Swing L&F

    -Font smoothing in Swing (not just basic AA).
  129. Substrings already do that[ Go to top ]

    I'm pretty sure (not quite 100%) that the current implementation of java.lang.String uses the exact same internal char[] as the parent String. Yes, a new class is beign created, but not a new char[] with a copy of the data. That's one of the things you're able to do since Strings are final and can guarantee that the internal char[] won't change.

    To me, that sounds exactly what you asked for (unless my "pretty sure" turns out to be wrong).
  130. You're right[ Go to top ]

    Substrings do share an array with their parents. Should have checked first :)
  131. Bassically my suggestion is to allow a default "destination" for unimplemented
    interface methods.
    I think this would clean up alot of code and allow a clean implementation of
    mixin style classes without the need for full blown multiple inheritance.

    interface If1 {
    void doSomething();
    void doSomthingElse();
    void doYetMoreStuff();
    }

    class MyFacade implements If1 {
    private delegate If1 if1Implementor;

    // -- not required because delegation is implicit for these methods
    //
    // public void doSomthing() {
    // if1Implementor.doSomthing();
    // }
    // public void doSomthingElse() {
    // if1Implementor.doSomthingElse();
    // }
    //

    // explicit implementation takes precidence over implicit delegation
    public void doYetMoreStuff() {
    // do stuff here ...
    }

    public MyFacade (If1 if1param) {
    // maybe have the compiler issue a warning if a delegate is not
    initialised in constructor
    if1Implementor = if1param;
    }
    }


    Paul C.
  132. Just some Ideas[ Go to top ]

    1.) A mechanism to be sure to have consistent objects (properly constructed)
    Something to mark several setters as some kind of combination

    Pseudocode:
    d = new Dings().setA().setB(); // OK
    d = new Dings().setA(); // throws new Exception("b not inited");

    The primary goal of OO is encapsulation, but our glory set/getter mean that no one can be sure that his object was properly built.

    Maybe some kind of different approach:
    d = new Dings();
    d.setA();
    d.setB();
    d.constructed(); // throws Exception if something is not inited proper.
    This method should be inherited from Object. Just some kind of "Default" way to ensure OO encapsulation.

    2.) A compiletime way to receive the full qualified classname. Maybe by mean of a new keyword. So for example Dings.compileclass will be a String "my.package.Dings" inside the Bytecode.

    I already written a RFE but no one was interested into such kind of feature. When you got a versioning Pluginengine it would be really usefull to have such a feature, because the normal Dings.class Syntax will lead into a "ClassNotFoundException". The cause is rather simple: The classloader needs the fqcn to find the correct ClassLoader, but Dings.class already needs the seeked classloader to be able to deliver "my.package.Dings".

    (Okay i know: The developer is able to write String dependency = "my.package.Dings", but why should he loss the Refactoring features of his IDE?)

    3.) Some kind of Deamon Features for Webcontainers / Application Servers. It is still a pain to run Tomcat on your server in comparison to daemons like apache httpd.

    4.) A look & feel chooser inside the JRE. The normal has no knowledge concerning the configuration of look & feels. So some kind of control center might give him the ability to chose his prefered l&f. This l&f should be the default skin of all java applications.

    5.) Versioning! Inside Jars as minimum. Okay tools like maven are already trying to solve the problem, but its still far away from optimum. Versioning information should be keeped inside the jar itself. Also additional information like the licence type. The jar should be a more complete container.

    6.) Versioning part 2: Just a nice to have feature could be a mechanism to have class level versioning. Could be usefull for undo/redo pipes. I dont care about the realization. There should be just some kind of well known mechanism to do the job. Maybe it should be just available inside mappers like JDO?

    7.) Autoupdater. The installed JRE should be able to update itself. Just some kind of backgroundprocess using unused Ressources. I know this could lead into problems with several applications. But im sure that there might be a way to solve the problems. Im also sure that application developers will ensure that their applications run properly when they know that their users will automatically become the new released JRE.

    8.) Offer an intelligent Module repository. Look at debians apt-get and think about benefits for java. Users should not need to download any package manually. When there is one controll center which offers him the ability to download all known java Applikations in a well defined way, he will be glad to use this toolset. It will give him the ability to keep all appliactions up to date without any hassle. Also offer a way to include security mechanism for commercial applications inside the network. (Means: include a ability to unlock applications whenever this user payed for it. Some kind of bundled licence file mechanism)

    I know that several operating systems have such a network. So why might it be good to invent the weel again? Because Sun is able to do it better. Because suns mechanism would be available on each OS because it will be pure Java. It will also avoid licence problems with distributions like Debian. Sure it will be little bit effort to install the jre inside debian, but when the user has done this job he will be able to use the java network without any additional hassle.

    just some ideas
    cybi
  133. I like #2[ Go to top ]

    2.) A compiletime way to receive the full qualified classname. Maybe by mean of a new keyword. So for example Dings.compileclass will be a String "my.package.Dings" inside the Bytecode.
    Which is it? I'll vote for it! I want this stoo!
  134. compiletime fqcn[ Go to top ]

    Hmm *research* *think over*

    Firstly i discussed the idea inside the de.comp.lang.java newsgroup. I think it was in the beginning of july. After it i started an RFE. Sun answerd that they think that it is impossible to achieve the fqcn at compile time because this information is only available at runtime. I think that the sun guy missunderstood my idea because i had no interest into runtime information.

    The RFE was an internal one and i dont think that there is a possibility to review it (id: 286132).

    The sun guy wrote, that i should start a topic inside their forum. I should try to discuss the issue to see if others see some sense behind my idea. After that i should start a fresh RFE containing a cleaner description of the problem ;o)

    I startet this topic (july 20): http://forum.java.sun.com/thread.jsp?forum=7&thread=539757

    Just recognized that someone answered one month afterwards (I tracked the topic for ~3 weeks). The guys discussing the issue inside the dclj lost their interest and as such no one tried to help ;o) Some of them seen a sense behind such a feature, but they simply lost their interest after i wrote the RFE / forum.java.com topic. Possible because they dislike english or maybe because of their holidays?

    So or so, i still think that such a feature could be valuable. But without some guys behind such an idea, no one will hear my unknown voice.

    cybi aka Neuhauser Bernhard
  135. Don't like combo validation[ Go to top ]

    1.) A mechanism to be sure to have consistent objects (properly constructed)Something to mark several setters as some kind of combinationPseudocode:d = new Dings().setA().setB(); // OKd = new Dings().setA(); // throws new Exception("b not inited");The primary goal of OO is encapsulation, but our glory set/getter mean that no one can be sure that his object was properly built. Maybe some kind of different approach:d = new Dings();d.setA();d.setB();d.constructed(); // throws Exception if something is not inited proper. This method should be inherited from Object. Just some kind of "Default" way to ensure OO encapsulation.
    I disagree here. What you are asking for is a side-effect of setters and getters, which are evil. Yes, sometimes they are a necessary evil. But why did you even expose A and B as separate setters if they are never to be used independently? Why not...

        public void setAAndB(int a, int b) { ... }

    If you're stuck using a framework that enforces setters/getters, then how about this?

        public void setAAndB(AAndBWrapper aAndB) { ... }

    Remember, OO is about being abel to encapsulate your data and control its state becuase you can only access/modify by sending messages to the object. If you write your API such that someone can send a messsage to change the value of "a" without "b" then it's your fault. If you want to control it, then do so. Let's not clutter the langauge with more features to prop up a failing crutch.
  136. Versioning is inside jars[ Go to top ]

    5.) Versioning! Inside Jars as minimum. Okay tools like maven are already trying to solve the problem, but its still far away from optimum. Versioning information should be keeped inside the jar itself. Also additional information like the licence type. The jar should be a more complete container.
    See http://java.sun.com/docs/books/tutorial/jar/basics/manifest.html#versioning

    This data is exposes through the core Java class "Package".
  137. Think before you change[ Go to top ]

    I do not think that there is much wrong with the Java language and would like to see a little more stability. I have to say that I do not look forward to the introduction of Generics as I do not think them necessary and I am not really convinced that the benefits in type checking are worth having. I remember using C++ templates which resulted in messy code all over the place.

    I think that a lot of the features requested here (like doing away with getters and setters) can be achieved by using tools (code generation) and IDEs (how difficult is it to generate getters/setters).

    I would like to see a stable Java language that does not follow every "new trend" and fashion statement. By introducing new language features, I think Java becomes more and more bloated and less simple.

    And as always: Simplicity is key.
  138. Think before you change[ Go to top ]

    I would like to see a stable Java language that does not follow every "new trend" and fashion statement. By introducing new language features, I think Java becomes more and more bloated and less simple. And as always: Simplicity is key.
    +1
  139. inherit constructors[ Go to top ]

    Inherit Constructors:

    I would also love to see that feature, i allways thought there must be some real strong technical argument against it.
  140. Sun please take the knife to Java.[ Go to top ]

    I really wish Sun would break the cardinal sin of software and break Java backward compatibily

    The list of items to cut is far to long so I won't even attempt it. They could start by dropping depricated methods from the Object class.
  141. Shared JVMs[ Go to top ]

    I want to start a single, lightweight, JVM that can be shared among applications. This way a lightweight jvm can be started with the OS and java applications will then have fast loading time and use less memory; otherwise java will have a hard time becomeing a standard for the desktop.
  142. Not that nothing is impossible in java and there is always a workaround, but would like to have some of these-

    1. A Singleton framework which works on a multi threaded app robustly.
    2. Improvement over the existing garbage collector scheme.(current gc thread when it runs it is sometimes too late, when the server is struggling to keep afloat).
    3. Improve on the HttpUrlConnection object impl. Currently i am stuck with a limitation of it that it cannot set a client side timeout over a specific connection, bvut have to alter a system properties to do so.
    4. More and special logging on a null pointer exception, probably a warning when any object is set to null and is about to throw a null pointer exception.
    5. Ban having multiple classes declared and coded in same java file.
    6. package level object proetection, i.e no one except classes from that particular package and sub packages can use it.
  143. 6. package level object proetection, i.e no one except classes from that particular package and sub packages can use it.
    Definately an interesting feature. Also aids in the ability to have layered implementations. I.e. divide layers over explicit packages while ensuring the proper API is exposed to upper layers.
  144. I would like to see[ Go to top ]

    Dynamic typing like smalltalk :)

    | x point |
    point := Point new.
    x := point x.
    x inspect.

    Isint this pretty? Wish Java could do this!
  145. The requirement for super() to be the first statement is the real pain and I would like it to be relaxed.
  146. Also would like to see this...[ Go to top ]

    I am not a computer scientist and dont claim to be an expert in this domain as well. But then certainly do wish to see this :)

    private String returnString(){
        return new String();
    }

    this.returnString() = new String("Wasssssup");
  147. Another access specifier?[ Go to top ]

    How about a new access specifier other than default (package), private, public and protected? What I am looking for something that makes the type accessible from only the current package AND its subpackages.

    For example, most real world applications partition modules like
    com.company.module
    com.company.module.subpackage1
    com.company.module.subpackage2
    etc.

    Now, I have to make classes/methods in com.company.module package to be public if I want them to be accessed from classes in subpackage1. This disturbs me because I am against making anything public unless I absolutely have to. Now, classes in com.company.othermodule can also access it.
  148. Add new bytecode for inner classes, real generics runtime type info, etc.

    Provide option to produce classes for older versions of the JVM (like Retroweaver)

    -- dimiter
  149. Just a few small enhancement to Java...[ Go to top ]

    In order of importance:

    1. Memory allocate/free, Pointer + real desctructor (not the cheesy finalizer)
    2. Multiple inheritance
    3. LISP like lamda function
    4. Stack base local variables
    5. Math library with APL like syntax
    6. Replace get/set with real property like VB with optional interceptor support
    7. Remove exception replace with devine interceptor (JSR, anyone?)
    8. Anotation base logging
    9. Allow source written in XML
    10. Built-in object database with standard schema for all configuration: support multiple VM, library repository, certificate/security with export tool go generate "legacy" format file.
  150. 1. Memory allocate/free, Pointer + real desctructor (not the cheesy finalizer)
    2. Multiple inheritance
    3. LISP like lamda function
    4. Stack base local variables
    5. Math library with APL like syntax
    6. Replace get/set with real property like VB with optional interceptor support
    7. Remove exception replace with devine interceptor (JSR, anyone?)
    8. Anotation base logging
    9. Allow source written in XML
    10. Built-in object database with standard schema for all configuration: support multiple VM, library repository, certificate/security with export tool go generate "legacy" format file.
    Yup, that would just about destroy Java for good ..

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  151. Just a few small enhancement to Java...[ Go to top ]

    Agree.That's just amusing..hehe,goes too far
  152. Just a few small enhancement to Java...[ Go to top ]

    Yup, that would just about destroy Java for good ..Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters
    The first time I used java I liked it because it is simple. It might take a lot
    of code on some challenging situations. But not really that hard to put up. I
    stopped using Java in last year to learn ObjC. And I was impressed with ObjC
    simplicity combined with robustness and flexibility. Also the feeling I got with
    the first time I used java. I just have to put up with the braces and the
    messaging. I like the power of delegates (Selector?) but like few people here
    it is usually a case to case basis. What I found out with using ObjC is that it
    might not be a good language of choice on a big software project because things
    easily get hairy with the way it handles memory.

    What I am trying to say is that a simple, concrete language is best, and just make a point that that language will stay sane as you scale up the complexity of the program.

    Syntatic improvement are good as long as it doesn't the sanity of the language
    itself. I agree with the few people here to delegate it instead to the IDE.
  153. Not small at all[ Go to top ]

    In order of importance:1. Memory allocate/free, Pointer + real desctructor (not the cheesy finalizer)2. Multiple inheritance3. LISP like lamda function4. Stack base local variables5. Math library with APL like syntax6. Replace get/set with real property like VB with optional interceptor support7. Remove exception replace with devine interceptor (JSR, anyone?)8. Anotation base logging9. Allow source written in XML10. Built-in object database with standard schema for all configuration: support multiple VM, library repository, certificate/security with export tool go generate "legacy" format file.
    1. As a high level progromming language, 1,3,4 is not needed at all .... look at C#, simpliciy is the most important thing, we have to fight with .Net

    2. Setter/Getter is a very important feature for OO (Encapsulation) ..... IDE can generate that for you ..... even equals(), hashcode(), toString(), etc ...
    Don't use it if you want to, but i can't see any point to remove it.

    3. Allow source written in XML10? hm ....It's personal choice .... I know that you can write JSP using xml format .... but most people prefer scriplets
  154. Method Missing[ Go to top ]

    It would be nice if Object had a methodMissing method.

    To give you class a chance to do something instead of and automatic NoSuchMethodError.
  155. 1/ The first thing I would like to see would be properties à la C#.
    The best thing would be you can declare properties with implicit
    get and set, or you can implement your own get and set.
    May add something like a keyword "property". This would reduce
    dramatically the code size of projects.

    class Foo
    {
      private property int age; // get and set are implicit

      private property String name
      {
        get
        {
          // Do what I want
          ....
          return name;
        }
        set
        {
          toto = thisvalue;
        }
      }

    }

    And as far as I know, this could be possible without any change of the JVM,
    because it allready uses implicit get and set for attributes.

    2/ The second thing I would like is to improve the content of exceptions :
    for example when there is a ClassCastException, I'd like to access the
    objet which is badly cast and the target type in the exception,
    when there is an ArrayOutOfBoundException, access the array and the bad index,
    and so on...
    I think exceptions should carry all informations to take decisions when they occur.

    3/ My dream would be to get rid of all the obsolete classes nobody should use
    anymore : Vector, Enumeration, AWT, (Swing : I don't know)... I'd like to
    start a new language on the basis of Tiger, with the same JVM, but taking
    advantage of new features everywhere (enums wherever I can instead of int constants, Iterator instead of Enumerator, StringBuilder instead of StringBuffer, etc...) This would be a more simple language, with less classes.
    Come on, we won't gonna support Java 1.0 for the next 20 years, won't we ?
  156. Keep it simple.

    Dont Over engineer java and cut things to skeleton.

    1. Introduce Delegates.

    2. Using keyword (not import -- import is good)

    3. Don't force package structure to match directory structure -- thats obsolete.

    4. Introduce Xml Serializer.

    5. Properties -- Bean rules are obsolete, and makes application loose, it feels like bean are tumbling and we are some how keep it straight, we need to be more confident, and introduce property key word.

    Good luck.
    Mehul
  157. 3. Don't force package structure to match directory structure -- thats obsolete.
    It was obsolete from the very beginning. I still cannot get the reason for this decision. It was probably one of the hardest concept to grasp when I started with Java ;)
  158. 3. Don't force package structure to match directory structure -- thats obsolete.
    It was obsolete from the very beginning. I still cannot get the reason for this decision. It was probably one of the hardest concept to grasp when I started with Java ;)
    Which descision? Never such decison was made!
    JLS just legitimates tools which have this limitation. Read the spec!
    JLS spec even describe the situation when source code is taken from database
    not from fs.

    And imo this is a good thing package structure to match directory structure as it brings natural order to source tree organization.

    Michal
  159. Structure is good , packaging is good, namespace is good, where we store it should not be forced that is the point here. We dont care what JLS says, compiler forces it, and it should not, people are structured enough, you need not force them to use which directory code goes, and what is the parent directory and what is the child directory. It beats the spirit. This is where java community suffers, there are too many "open" (source) (ideas) going on, some one needs to make wise decision, or keep it flag based, those who want, them can turn the flag on and compiler will error out, those who dont , dont use the flag. Default flag is turned off. Peace... or we want to fight over default flag is turned on?
  160. Structure is good , packaging is good, namespace is good, where we store it should not be forced that is the point here. We dont care what JLS says, compiler forces it, and it should not, people are structured enough, you need not force them to use which directory code goes, and what is the parent directory and what is the child directory. It beats the spirit. This is where java community suffers, there are too many "open" (source) (ideas) going on, some one needs to make wise decision, or keep it flag based, those who want, them can turn the flag on and compiler will error out, those who dont , dont use the flag. Default flag is turned off. Peace... or we want to fight over default flag is turned on?
    "People are structured enough"? I wouldn't bet on it. I can imagine once this restriction is lifted(assuming it's even technically feasible), we'll start seeing bunch of dudes throwing 500 .java files in one directory. And worse yet, some other (moderately smarter) people who actually want to keep things organized might start their project by keeping files in different directories, but eventually lose track of them in the endless refactoring. Now I can hear all the cursing from whoever is unlucky enough to take over these source files. ;-)

    The worst a forced directory structure has on us is a few extra mouse clicks or "cd" commands, which IMHO is still way better than the worst from a freeform structure.
  161. JX this is dis-ease that java guys and architects and thinkers suffer from , that programmer no trust is put.

    Give freedom, dont force idiologies on others, no body is foolish to put 500 java files, in one directory, give me an example where you have seen it?

    Have done so any time?....I guess no...Visit C# world and you will see how things can be so much easier, to build, dont just give weird examples, without real world experience. My suggestion is based on experience, it can be abused, if abuser has no brains, i dont think we are talking to VB developers here, we are all smart java guys after all.
  162. JX this is dis-ease that java guys and architects and thinkers suffer from , that programmer no trust is put.Give freedom, dont force idiologies on others, no body is foolish to put 500 java files, in one directory, give me an example where you have seen it?Have done so any time?....I guess no...Visit C# world and you will see how things can be so much easier, to build, dont just give weird examples, without real world experience. My suggestion is based on experience, it can be abused, if abuser has no brains, i dont think we are talking to VB developers here, we are all smart java guys after all.
    My experience actually exactly comes from a C# project I once stumbled upon. The guy who wrote the code took the liberty of not keeping the source files according to their namespace definition (worse yet you can have multiple namespaces defined in the same cs file). Looking at a stack trace, there was no way to tell right away where the class source is.

    Want some Java example? Just look and see how many Java developers are putting all the classes in the default package due to prototyping, schedule pressure, laziness, not caring, or whatever other reasons.

    I have nothing against freedom. But in this particular case, as you said, if you are sane enough not to do insane things, why _would_ you want this kind of freedom?

    And to comment on your last sentence, which I thought was in sarcastic tone but obviously not - I tend _not_ to judge people's intellectual level by the languages/tools/OS they use.
  163. Ok JX take this to next level.

    Do you use short cut on tool bar, or Start/Program Files, or you go to directory where software is installed and click the exe?

    Point is namespace and package is for arranging APIs, not where it goes,
    why do you care about where it goes?.

    I dont understand why you want to tie underlying file system , directory structure to packging?

    I can have on directory called com.company.dao and have all my code there
    why i need to have com, directory, and company directory and dao directory to have my package? one package for that you need three directories? why not
    have one folder called com.company.dao and thats it.

    Thats the freedom i am talking about, from underlying directory. Didnt java freed us from OS? Then why its hanging on to the directories? Thats where i see dis-ease. Free from on, stuck to other. Mulitple namespace defined in same CS? you are talking about aliasing?

    I am not talking about aliases here. So i dont know what you mean by multiple namespaces defined in same cs file. Looking at stack trace?!! where the source code is coming?...It is strange, you got to know more than that.

    Insane , sane i dont want to go into that fight, keep it simple, if you use shortcut to launch applications, why not, then there is no valid arguments against making it free from directory structure.
  164. Ok JX take this to next level.Do you use short cut on tool bar, or Start/Program Files, or you go to directory where software is installed and click the exe?Point is namespace and package is for arranging APIs, not where it goes,why do you care about where it goes?.I dont understand why you want to tie underlying file system , directory structure to packging?
    I thought my example was pretty clear in explaining why -- given a FQN (as those showing up in stack traces, to answer you question below), how would you quickly locate where the source file is in a freeform directory structure?

    I'm not sure your application launching scenario makes an analogy here - accessing source files is far more frequent than accessing actual executable files. To be able to use an application, you do not need to find the actual executable, hence a shortcut would suffice.
    I can have on directory called com.company.dao and have all my code therewhy i need to have com, directory, and company directory and dao directory to have my package? one package for that you need three directories? why nothave one folder called com.company.dao and thats it.
    Did you pick the directory name com.company.dao out of some self-displined naming convention which still links to your package name? Or are you proposing to still force people to name their directory according to package names, except the tree is flatten out in your scheme?

    If it's the first case, what prevents some other people from picking simply name "dao", or even just "src"?

    If it's the second, then what's the big difference other than a few extra mouse clicks?
    Thats the freedom i am talking about, from underlying directory. Didnt java freed us from OS? Then why its hanging on to the directories? Thats where i see dis-ease. Free from on, stuck to other.
    Where did you get the impression that "java freed us from OS"? ;-) It only freed us from _differences_ between OS, and even believing that much could be a bit naive thesedays. ;-)
  165. You are taking my shortcut scenario litrally, when i said com.company.dao, a directory name, matches package name, thats only for readablitiy, reachablity.

    It should not be forced upon.

    I still donot understand why you have problem locating src files, and have to use stack trace to find it.

    Once freeform is given we can flatten the strcuture as you are saying an save click. Take your argument, exe and java src file, you are saying going to source is far more frequent than actual executable. Lets say
    5 Clicks 10 times a day. 50 click, your mouse wears down, you finger, joins, we might get disease if keep programming for 20 years. That is inconveince dear friend - "Always Save yourself when you can".

    Now lets assume that you dont have to click, if you use IDEA, you can use CTRL+N to search and ALT+F1 to see where files are located physically. Lets use tools like Eclipse, you can goto source files, ide now a days are smart. So there is no need to force directory, if you want search facility put in ide. Dont waste time forcing directory strctures, when you already have smart tools. I am not going to post anymore, TSS -- hope this thread, listens and you guys spend 3 months, and give good java to all of us, that we can be proud of.
  166. I really cant understand your point ov view.

    There are 2 tremendously benefits inside the current approach:

    1) The jvm/compiler has a chance to find classes as fast as possible.
    The speed of the jvm is not relevant, because the compiler is able to force the directory structure. This has no dependenc on the .java Files. The speed of the compiler might get enhanced with some kind of location caches. But still, why complicate it when it works well yet?

    2) Every Java developer on the whole Planet knows abotu the directory Structure. When there is a org.company.HellWorld Class, he will find it!

    Or do you think that this approach would be intuitive?:
    MyPrivateSource/Hugo/HelloWorld.Java
    MyOtherSource/Jannuary2004/HelloWorld.Java

    Good luck when you try to find the File inside 3rd Party projects. Everyone is allowed to drop his Files wherever he wants. Dont sounds to be a good idea or?

    Maybe you force the usage of org.package.subpackage/File.class, but other programmers will not do that! And when you think that your approach is better, why not prescribe it as new alternative way?

    allowed: org/demo/subpackage/File.java
    allowed: org.demo.subpackage/File.java
    allowed: org.demo/subpackage/File.java
    allowed: org/demo.subpackage/File.java
    dissalowed: stupid/noMeaning/JustToBeHappy/File.java

    And also im not able to see the point in your example that the current approach forces additional mouse clicks. Switch your project Space inside your favorite IDE to flat structure and the IDE itself will handle the Structure by magic. Eclipse is able to do that, so i really think that other IDEs will also have their way to handle the problem in an appropriate manner.

    Currently it is hard enough to find the Source code inside of projects hosted inside sf.net's cvs. Every project thinks that their own style is the best. Hard enough to lokate the root folder of their sources and some of them also split the root folder into several minor bundles lokated somewhere inside their repository. Yes, currently it is hard enough to lokate Source files, so dont make it harder.

    cybi
  167. which Class file[ Go to top ]

    When java loads a class, its based on the class path.
    It would be great to have a utility, like which classname, which gives back the full directory path of the class file.
    With this it would be eazy to know, which class file is used by Java.

    Regards
    Mayur Purandar.
  168. which Class file[ Go to top ]

    When java loads a class, its based on the class path.
    That's not part of Java. CLASSPATH is an implementation detail of the Sun proprietary implementation of the JVM spec.

    ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  169. Mayur,

    To find out the full directory path of the class file , use -verbose flag while invoking the jvm. it generates list of classes loaded with their source location.

    java -verbose <main-class>

    hope this helps
    shrini
  170. No more endorsed dirs[ Go to top ]

    1) How about not bundling outdated XML parsers with the J2SDK? Then we could start to do away with the concept of endorsed directories.
    2) +1 for multiple inheritance
    3) Perhaps the concept of hierarchical packaging so you can fine tune method access? For example, protected setX() in a class in package my.package can be accessed by classes in my.package.sub, but not from package my.
  171. Remove deprecated methods[ Go to top ]

    What is the point in deprecating them if people are still allowed to use them 4,5,10 years later?
  172. unsigned numerical types like in C[ Go to top ]

    I'd like to see unsigned byte,short,long. This is really useful if you need to parse binary data streams.
  173. Examples using Closures[ Go to top ]

    Hi see the example using Closures given by me at http://wwww.simplyjava.com It shows how simple and smaller the code can be written with the help of closures. In my example I have eliminated need of one interface and two interface by using Function Type and closures.
  174. My wishlist for Java![ Go to top ]

    -attributes/properties -> no more writing/generating get/setters + no more getX setX

    They could just poor it in... you'd only need to change the compiler to create appropriate get/setters (for compatibility)

    -default arguments as in C++ -> method(String a, String b, String c = "123", int a = 5);
    This one too..the compiler could easily create the methods for you. Although a better solution could be storing the info in the class.

    -I don't know if it's done, but you could cache jitted code in a cached file. On ntfs you could store it in a named stream.

    -FreeBSD JVM!!


    And probably more.. :)

    Regards,

    http://www.techproceed.com