Earlier quoted context omitted.
Go work with C++, and you'll pine for Java.
And go work with C# and you'll pine for nothing. I've used all three and after a few years of C#, the other two are just a distant memory.
JDK 8 Release Notes
231–240 of 314 posts
Re: JDK 8 Release Notes
#232For me, the best part of this release is the fact that the TLS stack has been significantly improved, and is now quite good. The lack of some critical features in Java 7 (e.g., inability to enforce cipher suite order) made TLS effectively unusable. The list of improvements is quite long, actually: - Server Cipher Suite Preference - Strong Server Ephemeral Diffie-Hellman Parameters - Authenticated (GCM) Suites - Hardw…
Re: JDK 8 Release Notes
#233Earlier quoted context omitted.
Checked Exceptions and null. I write a lot of Java and I generally enjoy the language, but those two things; if Oracle could fix those somehow I would be extremely pleased. I'm so tired of writing null checks and I hope Optional is not the final answer since it too can be a null due to programmer error. I am really worried about Optional getting abused in Java 8... Actually, I waffle on checked exceptions; it seems e…
I like checked exceptions in certain situations. I generally dislike the checked ones that come with Java ^1, but it can be very useful to create your own. I had a situation where I was interacting with an API that would sometimes fail over things I could not control. But, the code responsible for interfacing with the API didn't have the context for handling those errors. Initially I threw a Runtime (ie: non compile…
Re: JDK 8 Release Notes
#234I have to admit I thought Java was dead in the water after Java 6, but Java 7 while a fairly quiet release was a decent release and Java 8 actually moves the language forward into a better place. As for the future here's what I would like to see: - Separation of language and libraries. Really the JDK should just ship with just a very small core of classes and everything else should be optional installed via a depende…
Multiple return types: Questionable benefit there. Exceptions are nice when used properly. Option classes handle the rest. Categories: Default methods probably do what you want. Get rid of primitives: Are you nuts? It turns out computers work on primitives. It's good to support them. "Proper" generics: maybe you mean specialization, or maybe you mean reification. It's a choice. Properties: If they irritate you that m…
Re: JDK 8 Release Notes
#235Earlier quoted context omitted.
> It has a very complicated type system, but doesn't even allow you to express things like function composition or generic sums at the language level. Yeah, sure, it doesn't have Haskell's . or algebraic datatypes, just like lots of other languages. I'm not sure what's complicated about the Java type system, but I suspect you're trying to say you don't like subtyping. Moving on... > Its syntax is stunningly verbose (…
Checked Exceptions and null. I write a lot of Java and I generally enjoy the language, but those two things; if Oracle could fix those somehow I would be extremely pleased. I'm so tired of writing null checks and I hope Optional is not the final answer since it too can be a null due to programmer error. I am really worried about Optional getting abused in Java 8... Actually, I waffle on checked exceptions; it seems e…
https://github.com/benjiman/expressions/blob/master/src/test...
implementation
https://github.com/benjiman/expressions/blob/master/src/main...
Re: JDK 8 Release Notes
#236Why does Android requires obsolete JDK 6 and not the latest stable version? Android should probably be the biggest project that uses JVM.
Because it does not use JVM. The language is Java, but the virtual machine is Dalvik.
Re: JDK 8 Release Notes
#237Earlier quoted context omitted.
Can you please give a use case of a program that a few hundred ms delay during startup would be an issue?
Practically any command line utility? eg. ls, cat, sort, uniq, ps, what have you. I'm constantly amazed that make(1) can do successive recompiles of a 50k LOC project in less than a second, while gradle / maven / etc takes upwards of a minute.
For some low-level programs executed hundreds of time per session (like "ls") I agree it adds up and might cause frustration. Java is a bad choice for this niche, but you are not going to write them in Python anyway, aren't you?
PS: Just tested "LS" in Java, less than a second run, I could personally live with that.
Re: JDK 8 Release Notes
#238Earlier quoted context omitted.
Nashorn is going to get faster with time. It is not a browser engine so don't try to compare it directly with V8 etc.
> Nashorn is going to get faster with time. It is not a browser engine so don't try to compare it directly with V8 etc. v8 is not a browser engine either ,it's a javascript engine,just like Rhino. you are mixing up Webkit with v8.
- I think you're partly correct but also confused. Webkit is a rendering engine and yes V8 is a JavaScript engine not a browser engine that was created for Chrome Browser by Google. It's used for Node.JS etc now but it's sole purpose was to make Chrome faster and that is not the same purpose of Nashorn - nashorn is a replacement for Rhino. That is what I'm trying to say.
Re: JDK 8 Release Notes
#239Earlier quoted context omitted.
Not sure if I enjoy SBT but Scala/Play/Akka is definitely great
Does anyone enjoy SBT? My love for Scala is profound, but fuck SBT
I'm not crazy about the syntax and I avoid build.sbt files, but as a tool it's very pragmatic and takes care of my needs perfectly. It has incremental compilation and continous testing built in. For testing within SBT with something like say ScalaCheck simply works out of the box with no configuration necessary, by simply slapping a ScalaCheck test in the test directory. SBT has cross compilation support, something that is needed for Scala. Some of the best Maven plugins have been ported to it (I enjoy sbt-release for example). I tried my hand at writing a simple SBT plugin and it really isn't bad. Dependency management is based on Maven repositories, again something that I miss a lot on other platforms. Publishing stuff on Sonatype has been painless. SBT's support for sub-projects in the same repository worked flawlessly for me and it is easy to setup. The console support is great too, allowing one to easily open a Scala console with the right classpath loaded (compile/runtime versus test). And in general I like how it just works out of the box.
Every time I end up interacting with Python for example, I get headaches from the clusterfuck that is setuptools, easy_install, pip, wheels, virtualenv, virtualenvwrapper or whatever the fuck they are using these days. Every time I interact with Ruby, I get headaches from rake, gem and gemspecs, bundler, rbenv, rvm or whatever else they are doing these days. I don't even want to remember Javascript and the clusterfuck that is npm, bowler, brunch.io, grunt.js, closure, amd, commonjs, browserify or whatever else they are doing these days. Or about .NET that's still in the Ant/Delphi age with MSBuild.
For Scala, the only fair competition that SBT has is Maven. And the only (other) pragmatic build/packaging/dependency management tool that I used has been Clojure's Lein, but lein lacks for example the capability of keeping a JVM process loaded, so you suffer the startup time every time you invoke a command, plus it seemed weird that lein doesn't offer things like continous testing out of the box. And speaking of configuration formats, lein's profiles are simply confusing.
You don't have to use SBT if you don't like it. Maven works fine and SBT's secret sauce, which was the incremental compilation, has been extracted in project Zinc and so it now works with Maven. But I still prefer SBT over Maven and when switching to other platforms it now feels like going back to 1999.
Re: JDK 8 Release Notes
#240You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…
This sort of reaction is surprising to me. Java has been a useable, performant language for some time now. The tooling is excellent, the JVM is astonishingly good, and it will run circles around Python, no less Perl. I don't think many of the arguments against Java are based on how it works once you've written it, but rather to the horrendous verbosity, class-explosion-as-a-design-pattern, painfulness to read (not de…
5 years ago those 3 languages were the talk of the town for alternate JVM languages, but things change. Scala's pulled way ahead of the pack, Clojure's consistent, and Groovy's on a downward trajectory, following in Beanshell's and JPython's footsteps. Eclipse users are drifting into Xtend, and IntelliJ users may look at Kotlin more. JDK 8's Nashorn is likely to scoop up those who just want to write quick-n-dirty's manipping Java classes.