Live data from Hacker News

Java: Missing Features

infoq.com

1–10 of 54 posts

Re: Java: Missing Features

#3
Some of these, like reified generics, would be great, and it's sad it's too late to add them to the JVM. Some of these, like more expressive imports, seem pretty pointless given that we use IDE's. But some of these are quite un-Javaish.

Structural typing would really go against the grain of the language, and i have a very hard time believing it would actually be useful. What method name is currently widely used with the same semantics across many classes, without being specified by an interface or base class? I can't think of one. There used to be close(), but that's been dealt with. Are there others?

Collection literals seem like a poor idea when there are so many different collection implementations. If i say:

  List list = {1, 2, 3};
What kind of list do i get? ArrayList, as that's the usual go-to? A foot-shooting opportunity for anyone doing concurrent programming! And a frustrating missed chance for anyone with a functional bent who would prefer an immutable list. Moreover, it seems unnecessary when you could easily just add constructors or factory methods like:

  List list = new ArrayList(1, 2, 3);
  List list = ArrayList.of(1, 2, 3);
Which leave the choice in the hands of the programmer for only a minimum of extra syntax.

Maps are a bit harder, because you need a way to describe pairs. In most projects i work on, i end up creating some helper methods that let me write:

  Map map = map(entry("Java", true), entry("Go", false));
And i wish there was a better syntax for that.

Something like algebraic data types would be good, though. You can already implement un-extendable classes using mild hacks:

    public abstract class Shape {
    
        private Shape() {}
    
        public static class Circle {
            public static Circle of(int radius) {
                return new Circle(radius);
            }
    
            public final int radius;
    
            private Circle(int radius) {
                this.radius = radius;
            }
        }
    
        public static class Rectangle {
            public static Rectangle of(int width, int height) {
                return new Rectangle(width, height);
            }
    
            public final int width, height;
    
            private Rectangle(int width, int height) {
                this.width = width;
                this.height = height;
            }
        }
    
    }
Because the constructors are all private, so putative subclass can't call them. But you don't get pattern matching, and of course it's all rather verbose.

There are various madmen out on the edge of town trying to create terse approaches to this by meddling with forces beyond mortal knowledge:

https://github.com/poetix/mtuples

But i can't see that going mainstream.

Re: Java: Missing Features

#5
post #4
post #2

What I would love to come over from C# is: * Auto-Properties - Get rid of all those ugle getters and setters cluttering up POJOs * Object and Collection Initialisers - https://msdn.microsoft.com/en-us/library/bb384062.aspx

might want to checkout lombok. https://projectlombok.org/

Isn't that just a boilerplate generator? I think the point is to have sane defaults and shorthand for common tasks so boilerplate generation isn't needed.

Re: Java: Missing Features

#6
post #5
post #4

Earlier quoted context omitted.

might want to checkout lombok. https://projectlombok.org/

Isn't that just a boilerplate generator? I think the point is to have sane defaults and shorthand for common tasks so boilerplate generation isn't needed.

If I'm not mistaken, Lombok generates the boilerplate at the bytecode level, not at the source code level. Which makes it much more like a language feature, and while I haven't used it extensively seems like a decent library solution to what is normally considered a language problem.

Re: Java: Missing Features

#7
I've been bitten by the "Long indices for arrays" lack once before. But then again, I had no reason for storing a String of length greater than MAX_INT in memory in the first place. Streaming it was the better approach in my case.

Honest question: is there ever an acceptable case for having such a long String in memory?

Re: Java: Missing Features

#9

I've been bitten by the "Long indices for arrays" lack once before. But then again, I had no reason for storing a String of length greater than MAX_INT in memory in the first place. Streaming it was the better approach in my case. Honest question: is there ever an acceptable case for having such a long String in memory?

Maybe some large data structure in memory based on a flat array and indices underneath?
Post reply on HN