Wrapping up Java 9 new Features
aboullaite.me
aboullaite.me
- I love that they are adding REPL. I really wish C# had this. I use IPython all the time for Python. It is very helpful to mock something up quickly or try out different features.
- Adding private methods to an interface seems very wrong to me. An interface is just a contract without any implementation at all. I am not sure the reason behind this. Aren't abstract classes a thing in Java?
- I was sad to see that they have not included type inference to Java yet. It is just a syntax thing, but it makes writing code feel so much less wordy. Here's an open JEP for it: http://openjdk.java.net/jeps/286
Here you go :)
https://github.com/dotnet/roslyn/wiki/C%23-Interactive-Walkt...
Also: csi.exe. Try it :)
Type inference already happens for you when you are using a good IDE, like IntelliJ IDEA. You can just use the "Introduce Variable" refactoring. And better yet, it self-documents your code with the variable's type.
If you really want to know what a type is resolved to, you have both compilers and IDEs there to tell you. Relying on an IDE to write code is just hacking over a weak or broken language.
Maybe it is because we are used to our own paradigms, but the following is no less readable to me because of inference. And these are the 95% of cases.
var index = 0;
var name = "pwaivers";
var names = new List<string>();
var nameMap = new List<string, Dictionary<int, Address>>();
I have never seen a bug arise because of type inference. Do you have an example?
> unnecessary burden on the compiler
The compiler does a lot of work and this would probably be insignificant to add to it. However, I am totally open to learning more about this.
var index = getIndexFromSomewhere();
var name = getHandleFromUser("peter", "waivers")
*Edit: I'm absolutely a fan of the var syntax, having dabbled with scala. I'm just expressing what I think the original author's complaint is.
It doesn't have to be, as the compiler (and linter) will inform of any misuse of the type later on. And any editor worth its salt could even annotate the type right there.
string name = getHandleFromUser("peter", "waivers")
But the issue you have glossed over is that sometimes there is no nominal type - there is only an anonymous type, as for example returned by a LINQ query using new{}, or via monad-style combinators where you really don't want to see the type for fear of your eyes bleeding.
I concur. I've been dabbling with Java a bit again (mainly because of a hobby project in order to learn Clojure) after a pause of multiple years.
It boggles my mind that compiler inference didn't make it into the language yet. Everytime I have to declare a totally obvious type, I cringe.
It is already the case in lots of languages since 1990s and the sky has not fallen...
Allowing private methods means default implementations can be easily refactored to move common code to private methods without those internal methods themselves becoming part of the interface. Yes Java does have abstract types, but multiple inheritance is allowed from interfaces (which aren't structural) but not abstract types so interfaces are very widely implemented across the standard and other libraries.
Already exists: https://msdn.microsoft.com/en-us/magazine/mt614271.aspx
But I do a lot more these days with https://www.linqpad.net/ instead.
You can inherit from only one base class; if Java had multiple inheritance, as C++ has, a number of other problems would arise.
* Scala's CPS compiler plugin, now deprecated and unmaintained.
* Macro-based async/await library. It's neat but has many more limitations than C#'s equivalent or Kotlin's, and hasn't had any updates in a couple of yaers.
It looks like Kotlin has recently added experimental support for async/await. That language may be your best bet for now if you want to code in this style on the JVM.
Futures are interesting, but at the end of the day they are basically not that different from callbacks. Instead of writing a function that takes a callback, you write a function that returns a future that you essentially register callbacks onto. In Java 8 this type is called a CompletionStage. In fact, in one of Scala's coursera courses they teach you how to take callback-oriented code and convert it into code that returns futures. The fact that it is so easy to convert between the two helps illustrate that futures aren't really adding much. Yes you can compose using flatMap, but, again, I don't think this makes the code that much easier to write, or, more importantly, debug and maintain.
As an example, at $lastjob I converted a blocking networking library to a non-blocking one. I started out using futures but I found that it generated a lot of Lambdas, which made debugging much harder because the stacktraces were long and incomprehensible. I ended up switching to callbacks and used named, not anonymous classes to improve readability. Not only did the code feel easier to read and debug but I got better performance out of the library due to reduced memory pressure.
If you're familiar with JS, read about how babel implements ES7's async/await by wrapping promises. And then try it out. It's awesome.
Future<Long> f = executor.execute(() -> myFunc());
ps: user and ex plugin developer asking
And actually it does use less resources than either InteliJ or Android Studio, while having faster builds.
But i have never seen it working properly in
PROD enterprise application.
Having written a few Eclipse plugins was already enough.
There are now some very cool things that make starting a new OSGi project a lot easier:
* Declarative Services, for simplifying Component definitions (No more editing XML)
* bnd / bndtools for building your OSGified jar (No more manually editing the Manifest)
And hardly used in industry beyond eclipse project.
We also wrapped OSGi in a services framework we created (and by that, I mean my boss wrote it, and then I added some features and bugfixes later), which we open-sourced.
What's really cool is that the Flow stuff from the article resembles a publish/subscribe library that we wrote and also open-sourced (under the name JFlux, even), which in turn was built on some interfaces that bear a resemblance to the Java 8 functional interfaces, except written for Java 6.
Huh.... I wonder why that is?
Please see: http://openjdk.java.net/jeps/302 - Lambda Leftovers
Did you mean Java 7 and previous versions? You certainly can't paste Java 8 code into the Apache Groovy REPL if it has lambdas because Groovy hasn't been updated for Java 8, not to speak of the new features in Java 9. My guess is the sad state of the Groovy ecosystem is probably why Oracle even created JShell.
In fact, you can't even paste Java 7 code in there and have it behave the same because of lots of little incompatibilities like the meaning of the == operator. Every Java developer should know never to paste Java code into a Groovy REPL and rely on the result for testing purposes.
Groovy isn't Java. Like Java, Groovy generates JVM code, though it typically runs slower than Java code because Groovy is a dynamically-typed language. Although it added annotations for static typing into Groovy 2, they don't work for bulk code, only isolated test cases, and the latest versions of Groovy are still written in Java, not statically-annotated Groovy.
> performance increase is large compared to JDK 8 GA, ranging from 34x to 150x
Waiting for features is not unique to Java.
I bet Java 10 is probably going to be released earlier than ANSI C++ finally gets modules or concepts finalized.