
Java: Missing Features - henrik_w
http://www.infoq.com/articles/Java-The-Missing-Features
======
alkonaut
Apart from primitive specialization the biggest omission in my opinion is the
lack of value types ("structs"). It's almost impossible to write code that is
heap allocation free or allows reasoning about cache locality.

~~~
vrotaru
Just yesterday I've watched this:
[https://www.youtube.com/watch?v=88-szpeNfrU](https://www.youtube.com/watch?v=88-szpeNfrU)

Long story short: keep the traditional getters and setters but have just a
byte[] field to store the object state. For example If you need just the date
(without the time) you can store it in 2 bytes, say 7 and 8, and in getDate()
method you do

    
    
        public Date getDate() {
             int day = bytes[8] * 256 + bytes[9]
             return new Date(day * MILLIS_PER_DAY);
        }
    

Some of the improvements are amazing

------
lolklyn
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](https://msdn.microsoft.com/en-us/library/bb384062.aspx)

~~~
mbfg
might want to checkout lombok.
[https://projectlombok.org/](https://projectlombok.org/)

~~~
josecflk3
Just keep in mind that some of the features are a bit iffy. If you use their
vals IntelliJ will syntax highlight it as an error in red for the simple
reason that it's non-compliant with the Java language spec. Also, you'll
usually need a new version on Lombok every time a new version of Java comes
out, otherwise what used to compile with the previous java version will no
longer compile. If you use the auto constructor you're going to have fun
finding usages since there's nothing to click on, and changing the order of
fields in your class will silently change the ordering of parameters in your
constructor - double the fun of the fields are of the same type. You'll also
be left wondering why you went to all the trouble of adding dodgy language
extensions instead of just using a language which provides those features
anyway. That and your code (subjectively) looks really ugly plastered with
annotations everywhere. Some people like Lombok, just make sure it's a choice
you make going in with your eyes open.

~~~
ks
_> If you use their vals IntelliJ will syntax highlight it as an error in red
for the simple reason that it's non-compliant with the Java language spec._

There's a free plugin that adds Lombok support to Intellij. You will be able
to use getters/setters/builders etc. as if they were compiled.

~~~
josecflk3
Builders etc. work fine, it's the vals that are permanently underlined in red,
even with the plug in. It compiles OK with vals, but still highlights it as an
error in red in the editor.

------
pjmlp
Some of those missing features are being worked on for Java 10 and can be
tested already from the early prototype that is available.

JVMLS 2015:

[https://www.youtube.com/playlist?list=PLX8CzqL3ArzUo2dtMurvp...](https://www.youtube.com/playlist?list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU)

Technical Keynote at JavaOne 2015

[https://www.oracle.com/javaone/on-
demand/index.html](https://www.oracle.com/javaone/on-demand/index.html)

Of course, first we still need to get Java 9.

And then when Java 10 with value types, reiffed generics, new FFI API, long
Arrays is available, one can write blog posts about being forced to use Java 7
with these missing features on Android.

------
i_s
> The issue of primitive specialisation of generics is only tangentially
> related to type erasure, and run-time visible generics are actually much
> less useful than Java folk wisdom insists.

Run-time visible generics are pretty important because it lets us avoid boxing
everything. In .NET, they don't have this problem, and as a result primitive
dictionaries are ~17x faster [0]. Java folk wisdom seems pretty accurate to me
in this case.

[0] - [http://fsharpnews.blogspot.com/2010/05/java-
vs-f.html](http://fsharpnews.blogspot.com/2010/05/java-vs-f.html)

~~~
bad_user
He's talking about reification versus specialization. The .NET runtime is
specializing generics for value types and that's how you avoid boxing. For
normal classes though, specialization would not have any benefit and the
boxing argument goes away.

Interestingly, specialization can be done at compile-time and doesn't
necessarily have to be a runtime feature. Here's a Scala compiler plugin doing
that: [http://scala-miniboxing.org/](http://scala-miniboxing.org/)

~~~
masklinn
> He's talking about reification versus specialization.

It's neither according to the usual (C++-inherited) lingo where specialisation
is the userland override of generics reification. Refinement may be a better
term for what the article is talking about (runtime-optimised instances
without reified types).

And refinements should already be doable in java today with no static type
information, Pypy does it with list strategies, I expect Objective-C's hidden
classes could also enable it (though I'm not aware of such a use).

> Interestingly, specialization can be done at compile-time

That's where they started...

------
incepted
The author of the article seems to be essentially looking for Kotlin (except
for the structural typing part, which is a terrible idea and which Kotin
thankfully ignored).

~~~
jinst8gmi
Structural typing is actually very useful when you need it occasionally, which
is one of the reasons I've largely ignored Kotlin so far. The jury is still
out on that one.

------
runT1ME
Ok weird, as a scala programmer these aren't the main pain points when I go to
a less powerful language. I miss monadic comprehension, implicit
parameters/higher kinded types (for type classes) and inference the most.

------
deanCommie
Moving from C# to Java 3 years ago was a painful experience in language
expression.

However, IntelliJ, Java8 Streams, and Google Guava made the process tolerable.

I've grown to begrudgingly tolerate the weak Generics support, but the one
thing absolutely still drives me insane is that I cannot have a method
overload for a different generic parameter

i.e.

    
    
        public void do(List<ABC> abcs);
    
        public void do(List<DEF> defs);
    
    

FFS Java, come on. (Yes, I know, type erasure, it's still humiliating)

------
nurettin
>For example, it was only with C++14 that lambda expressions finally arrived.

nope.

------
dajohnson89
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?

~~~
andrew-lucker
So would this affect all flat memory allocation? Say if you wanted to allocate
100GB for a bloom filter, would you need to break it into chunks?

~~~
bad_user
Yes, you'd need 6 arrays of 2147483648 longs (max int), plus one array of
536870912 longs, so a total of 7 arrays. Not that bad really.

~~~
jerven
Yes, I have code like that and its annoying and bug prone. Even if its a write
one exercise :( Would be nice if could just avoid that exercise in bit
shifting and anding.

------
twic
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<Integer> 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<Integer> list = new ArrayList(1, 2, 3);
      List<Integer> 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<String, Boolean> 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](https://github.com/poetix/mtuples)

But i can't see that going mainstream.

~~~
Pyxl101
The visitor pattern essentially gives you pattern matching for your example.
It can even give you destructuring pattern matching, if you wish. With a fixed
hierarchy, each visit method handles one concrete case, and its signature can
destructure fields and pass them individually. It's a hoop to jump through but
not so bad.

~~~
twic
Very true, but you have to write it all by hand, so it's the usual tedious and
error-prone boilerplate until IDEs learn to autogenerate it. It would be nice
to have an automatic solution like you get with real ADTs.

------
ww520
Things that would be good to add in Java are:

\- Collection and map literal.

\- Value type.

\- Multiple return values.

\- Destructure.

\- Pattern matching.

~~~
saiya-jin
that multiple return values got me interested. I can see this exploding
complexity/unreadability of the code at first glance.

honest question - what would be real added value compared to dedicated wrapper
type holding all you need for return?

~~~
jinst8gmi
1\. Not having to declare a pointless wrapper class.

2\. Tuples support pattern matching.

3\. For simple cases the return type is clearer, no need to dig up another
class declartion to figure out what the field types are.

------
logn
I would like to see support for json and regex, similar to JavaScript.

