AFAIK, the core JVM will still be modular. The disagreements were around how to expand that modularity out of just the JVM "kernel" and into user space.
I'm not entirely sure what that actually buys, when classes are loaded only on demand anyway...
Rejected by Oracle's competitors. I'm pretty sure that Oracle will do what it does the best and be a dick and release it anyway. IMHO, that would be the right choice.
The rest of the world is behind Java in some developments like container-style isolation of different applications in the same runtime environment. However people still mock Java in things the community is behind. Wait till the cool kids discover conatiner managed transactions. Then it will THE GREATEST THING EVAH !!
.Net has done such a thing with Application Domains since its very early days on Windows. Recently they've decided it's not worth the trouble to move over to .Net Core.
For iteratively developing a piece of code. For quickly checking what a function X does with arguments Y and Z. For interactively manipulating a data structure until I finally know exactly what transformation I want to do, which I then save in the source code. For exploring and possibly modifying the run-time state of the program.
Simply being able to repeatedly invoke functions from the REPL without breaking your flow changes the way you program. It's a completely different experience from the usual edit->compile->run cycle, and even from the TDD edit->run tests cycle.
Also, if the language didn't just bolt a REPL on top of itself because it's fashionable, but actually was designed as an interactive programming medium, you'll have powerful introspection and runtime code modification possibilities that together speed up the debugging process. (Experienced readers will know which language families I have in mind here - the ones which surprisingly weren't even mentioned in JEP222 which this article links to).
I do Java for my $dayjob and I can tell you that while IDE helps a lot with types and moving around the code, it doesn't give you interactivity offered by a proper REPL.
(Conversely, a language with a decent support for interactivity enables IDE developers to provide tools further enhancing interactive programming.)
Hot swapping breaks in arcane ways that most people won't bother searching how to avoid, code swap is simply considered unreliable by most of my colleagues. But this is anecdotally speaking, of course.
I'm also curious. I routinely use the Python REPL, for example; so it's not that I don't see how a REPL can be useful - it's that Java is so much more verbose that I find it difficult to imagine using a Java REPL. I struggle to think of a good use case for this.
Java is not that verbose anymore. Java 8, in particular, made the language much more concise. Also, I expect Java IDEs will offer their power of autocomplete to be usable in REPL too.
I'm not going to tell you you're doing things wrong or you need to see the light. Only that maybe you're missing out on a pretty powerful feature that's really worth checking out.
I used a REPL in Java right around when they did the name change to J2SE, so that must have been 20 years ago? By the OPs definition it was still 10 years too late though so there is that.
Although there's no REPL provided with Go, I've found that gore (https://github.com/motemen/gore) works pretty well. It feels similar to the old Java REPLs you'd find hidden in Intellij or other Java IDEs -- sometimes you can see the seams in its facade.
Nitpick, but God, I hate this hero image. It's "fantasy UI" is so lazily done it hurts the eyes. It's just the same block copy-pasted around and resized multiple times. Did whoever made this picture think nobody would notice?
I love Java. I think it has changed the world for the better.
That being said, I just can't get excited about new language features now that I have discovered Kotlin. It is essentially Java but with a much smarter compiler and a more modern and sane syntax.
The designers basically removed everything that made Scala slow to process and hard to optimize. As a side-effect, Kotlin is much easier to read and understand than Scala.
They've had to add back a lot of things piecemeal as they realised they'd missed important use cases for Scala's more general features as they tried to "simplify" them. The language's history so far suggests the original design was far from well-thought, and I expect that trend to continue in a more visible way post-1.0.
(E.g. as applications get larger you tend to need to understand the reasons for why something didn't happen, so you move from Option on to using an Either-style type that carries some information in the failure case. But Kotlin is hardcoded around using null to express absence and it's impossible to migrate from that to something that includes a reason).
That's what I feel as well. I feel that Scala started "too big" and gets "slimmed down" over time (like, implicit is now not-so-recommended), while Kotlin goes the other way around. I still prefer Scala whenever possible, but Kotlin really shines for Android (I tried Scala, I couldn't stand build time on top of the already-long Android build).
I've programmed Scala professionally for the last 4 years. The compiler used to be rather slow, but nowadays, it is fast enough for my taste. Just be careful with the cake-pattern, which slows down compilation substantially.
Also, I notice that, as I write type-safe code, I don't usually compile that often and, when it compiles, it is likely correct.
I used to like Java when it was simpler. Generics I thought were great, but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language. And I still can't have multiline strings (on a language used for Web programming!).
The multi line issue pisses me off on a daily basis, esp when writing tests that deal with JSONs. It's so much readable with multi line strings in python and groovy.
I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.
Why not embed the JSON as a file in the test resources and read it in during the test setup? Is there a particular reason it needs to be embedded in the source code of the test?
Its to maintain context. If a developer is looking at a large test code then it becomes difficult to switch back and forth between 10s of JSON files and the main test code. Having the input, output and the test data in the same file is much more convenient.
Um, you really should be loading that sort of text/data from an external resource rather than embedding it in source code. Those sort of text blocks really don't belong in source code.
Why not? Why should a developer need to go through hoops like saving a string to a file then performing IO to load the string into a test case? What's the advantage of moving a string literal into a non-source file?
If I'm trying to test how my system will parse a specific JSON case into a domain object, isn't it easier to read if my test case is completely expressed on the screen?
The I/O will happen anyway, either at the start of the test when loading the compiled test program WITH the big chunk of a string or when reading it from disk, of course you'll add a bit of latency for opening the file itself but it's a very small price to be paid for maintainability.
Even when I develop in Python with multiline strings I use fixture files to better organise my code.
Edit: removed an "even" before maintainability that was part of a first draft.
This is just nonsense not everything will go into a file. Somethings are easier to read on the test itself. It's a case by case problem and choosing is a great asset.
The caretakers of Java strayed. Adopting goofy dynamic and lambda features, trying to attract the cool kids was a mistake.
They should have stuck to their original mission of reducing programming mistakes and boosting productivity.
String processing, a la perl, Python, is something every single developer does every day. We need multilines, intrinsics, first class regexes, etc. every day.
They should have made 'utf8', 'utf16', etc first class scalars, reducing the memory footprint of java.lang.String, and everything reliant on String, ages ago.
They should have increased conciseness, a la Kotlin, Ceylon, Nice, Boo (minus the duck typing), ages ago.
I'm also eager for lightweight objects (value types?), a la Kava, which I think has been pushed back to JDK 10.
Okay, this is completely tangential to the article, but I see this footer on the website:
"We are using cookies to improve your experience of our site. By clicking ‘Agree’ or ignoring the banner, you are assenting to our use of cookies."
I don't really care, but is this strictly speaking legal? "If you don't read this, you agree to it"? If I read it, am I "ignoring the banner"? Usually if you don't agree, they are supposed to not store cookies and ask every time, which is something I'm actually OK with.
I'll tell you a little secret, Java is the number one programming language in the world just because it is used by millions of programmers for Android apps and a few enslaved programmers in corporate gulags. Once Kotlin takes the Android world by storm Java will sit next to Cobol in the history books of technology.
But Android tooling is heavy dependent on Java and Google even had to drop their Jack/Jill compiler replacement, because they weren't able to make it work properly with all the tooling that targets the JVM.
So they pivoted to translating JVM bytecodes into ART ones (originally Dalvik ones, DEX) again.
However even with the way Google has handled the Java story, the whole Android eco-system is heavyly dependent on it.
They also pivoted the Brillo project with the promise of a set of C++ userspace frameworks, into Android Things using Java instead, including the ability to write device drivers in Java.
Hence why thinking that Kotlin can manage without Java and its eco-system is kind of strange, even on Android.
EDIT: Of course it runs on Dalvik as well when targeting pre-Lolipop devices.
Our enterprise used a lot of Oracle (e.g. Java) products but never committed to actual Java development. As of late they have been heavily divesting themselves of Oracle as rapidly as possible.
> Java is the number one programming language in the world just because it is used by millions of programmers for Android apps and a few enslaved programmers in corporate gulags
This is an incorrect and terribly biased opinion. I have been working primarily in Java for over five years and neither of those applies to me. Java has been a core language in ML and NLP for at least a decade.
At one point Scala was going to take over the world. It was hot favorite of many fastest growing companies. Then the companies grew and moved to Java with or without much fuss.
Your secret does seem like secret to lot of people. In my knowledge Java is big because lots and lots of companies use Java stack for boring enterprise applications. And in those places people could care less about cool stuff and work on things that pays.
Cobol is still used in very critical software at big Banks. Java along with it quite respectful place. Whereas Kotlin is a little bit of lot of things. Runs of JS/JVM/Native but none of them a unique strength for Kotlin. So it will be very difficult to compete with languages which committed to single platform and have serious business use cases.
One of Kotlin's design goals was 100% compatibility with java.
Whenever I work on a java-codebase and see a class that could be expressed much simpler in Kotlin I press "Cmd+Option+Shift+K".
Intellij IDEA automatically converts this file to Kotlin. The codebase continues to work without issues and I can proceed extending this part in Kotlin.
92 comments
[ 3.3 ms ] story [ 170 ms ] threadI thought Jigsaw was rejected.
However they have been talking how to solve this and the new release is planned for end September.
I'm not entirely sure what that actually buys, when classes are loaded only on demand anyway...
https://docs.microsoft.com/en-us/dotnet/framework/app-domain...
Also, are you familiar with Groovy and Scala and their intended uses?
Like, all the time?
REPL becomes an integral part of the programming process if your language has one.
Could you give me an actual example on how you use REPL during development?
Simply being able to repeatedly invoke functions from the REPL without breaking your flow changes the way you program. It's a completely different experience from the usual edit->compile->run cycle, and even from the TDD edit->run tests cycle.
Also, if the language didn't just bolt a REPL on top of itself because it's fashionable, but actually was designed as an interactive programming medium, you'll have powerful introspection and runtime code modification possibilities that together speed up the debugging process. (Experienced readers will know which language families I have in mind here - the ones which surprisingly weren't even mentioned in JEP222 which this article links to).
But not Java, which is statically typed and an IDE that takes care of most of the stuff you mentioned.
edit: java also has hot swapping of running code.
(Conversely, a language with a decent support for interactivity enables IDE developers to provide tools further enhancing interactive programming.)
I've programmed in numerous languages that offer a REPL. I've never found them useful.
I'm sure you'll now tell me I was using the wrong languages, or just needed to do it differently and by God I'd see the light!
I would suggest that instead you accept that not everyone is like you. Everyone's creative process is different. A REPL has never fit into mine.
You think I haven't experimented with REPLs from time to time? :)
It's 2017, where are the REPLs for Go and Rust?
I know Java since the early releases and the only thing that comes to mind is Beanshell, which was around that time.
Nobody's gonna make a REPL for languages nobody uses :^)
/s
(Yes, I hate half-assed design.)
That being said, I just can't get excited about new language features now that I have discovered Kotlin. It is essentially Java but with a much smarter compiler and a more modern and sane syntax.
The designers basically removed everything that made Scala slow to process and hard to optimize. As a side-effect, Kotlin is much easier to read and understand than Scala.
No. It's not.
(E.g. as applications get larger you tend to need to understand the reasons for why something didn't happen, so you move from Option on to using an Either-style type that carries some information in the failure case. But Kotlin is hardcoded around using null to express absence and it's impossible to migrate from that to something that includes a reason).
Also, I notice that, as I write type-safe code, I don't usually compile that often and, when it compiles, it is likely correct.
The incremental compilation is pretty good.
None of the new features has anything to do with dynamic languages[0]. Streams and lambdas are still statically typed.
[0] Well, there is DynamicInvoke, but this is not a Java feature, but a JVM feature.
I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.
If I'm trying to test how my system will parse a specific JSON case into a domain object, isn't it easier to read if my test case is completely expressed on the screen?
Even when I develop in Python with multiline strings I use fixture files to better organise my code.
Edit: removed an "even" before maintainability that was part of a first draft.
They should have stuck to their original mission of reducing programming mistakes and boosting productivity.
String processing, a la perl, Python, is something every single developer does every day. We need multilines, intrinsics, first class regexes, etc. every day.
They should have made 'utf8', 'utf16', etc first class scalars, reducing the memory footprint of java.lang.String, and everything reliant on String, ages ago.
They should have increased conciseness, a la Kotlin, Ceylon, Nice, Boo (minus the duck typing), ages ago.
I'm also eager for lightweight objects (value types?), a la Kava, which I think has been pushed back to JDK 10.
"We are using cookies to improve your experience of our site. By clicking ‘Agree’ or ignoring the banner, you are assenting to our use of cookies."
I don't really care, but is this strictly speaking legal? "If you don't read this, you agree to it"? If I read it, am I "ignoring the banner"? Usually if you don't agree, they are supposed to not store cookies and ask every time, which is something I'm actually OK with.
I'll tell you a little secret, Java is the number one programming language in the world just because it is used by millions of programmers for Android apps and a few enslaved programmers in corporate gulags. Once Kotlin takes the Android world by storm Java will sit next to Cobol in the history books of technology.
That means you have all the libraries, performance and profiling tools that java has.
Please read the OP before commenting.
But Android tooling is heavy dependent on Java and Google even had to drop their Jack/Jill compiler replacement, because they weren't able to make it work properly with all the tooling that targets the JVM.
So they pivoted to translating JVM bytecodes into ART ones (originally Dalvik ones, DEX) again.
However even with the way Google has handled the Java story, the whole Android eco-system is heavyly dependent on it.
They also pivoted the Brillo project with the promise of a set of C++ userspace frameworks, into Android Things using Java instead, including the ability to write device drivers in Java.
Hence why thinking that Kotlin can manage without Java and its eco-system is kind of strange, even on Android.
EDIT: Of course it runs on Dalvik as well when targeting pre-Lolipop devices.
This is an incorrect and terribly biased opinion. I have been working primarily in Java for over five years and neither of those applies to me. Java has been a core language in ML and NLP for at least a decade.
- HN
Your secret does seem like secret to lot of people. In my knowledge Java is big because lots and lots of companies use Java stack for boring enterprise applications. And in those places people could care less about cool stuff and work on things that pays.
Cobol is still used in very critical software at big Banks. Java along with it quite respectful place. Whereas Kotlin is a little bit of lot of things. Runs of JS/JVM/Native but none of them a unique strength for Kotlin. So it will be very difficult to compete with languages which committed to single platform and have serious business use cases.
Whenever I work on a java-codebase and see a class that could be expressed much simpler in Kotlin I press "Cmd+Option+Shift+K".
Intellij IDEA automatically converts this file to Kotlin. The codebase continues to work without issues and I can proceed extending this part in Kotlin.
* The API and implementation will not be part of Java SE.
* The API will live under the jdk.incubtor namespace.
* The module will not resolve by default at compile or run time.
Modular source code is internal reorganization of JDK. Hopefully it will not affect Java developers negatively.
Process API: It can provide PIDs finally. Seems like big feature for Java 9.
JShell: May find some use. Not sure how many Java developer care about it.