Those changes seem to look like a completely new language, cross of Java/Scala/Swift - why don't they call differently, like Jalaft? The main reason to use Java was its backward compatibility. If I needed to learn a new language every 6 months, I'd learn another one to be honest.
I think the issue he was speaking to was that if many of the new features require doing things in a new way then it really is something new. But your point is well taken as well. C++ is still C++ whether you use standard templates or not.
That's part of why it's such a nightmare to parse.
The GCC C++ parser is over a megabyte of ASCII text. Think about it: it takes over a million characters to figure out how to parse C++ code. This complexity is partially because there are so many ways to do the same thing.
All auto parameters, or make it a template? `if constexpr` or `std::enable_if_t`? Macros for generic programming or variadic variadic template templates? Overloading or specialization?
I love C++, and backwards compatibility is something that's been valuable for it, but it certainly comes with its challenges.
”if many of the new features require doing things in a new way then it really is something new.”
Firstly, nothing requires you to do things in a new way.
Secondly, if “you could already do that” implies “not really something new” for a programming language, updates to the syntax of programming languages can never count as “really something new”.
If a new language feature is available, someone in your team will start to use it, because it compiles, and code becomes shorter, so why not. And you will have to review their code daily, which forces to "relearn" the language. I think this is why OP complains.
Why wouldn't you rather learn a new one if your old one is changing rapidly into a weaker version of some other language that did it better already? I personally don't care at all about those new things; I have them in Scala, I don't need them in Java. I can mix those two as I like anyway.
I'd much rather see type erasure fixed, as that messes up every single language based on JVM. But that would be like "the incompatible change" of a decade...
> I'd much rather see type erasure fixed, as that messes up every single language based on JVM
What? Type erasure is one of the main reasons why the JVM is targeted by so many languages (Java, Clojure, Kotlin, Scala, Groovy, JRuby, etc.). Had the JVM gone the way of the CLR the programming language landscape would probably look a lot different than it does today.
Perhaps you mean lack of support for value types? That does affect every language running on the JVM.
These are just syntactic sugar, not going to change much to the way Java programs are coded. I found these changes rather tame compared to historical ones. Java 8 (lambdas), Java 5 (generics, annotations) and Java 1.1 (inner/anonymous classes, reflection) were far more disruptive.
I do not agree with that, this is not just syntactic sugar, for example in case of large 'else if' statements the complexity to choose proper branch is O(n), instead with pattern matching the chosen branch will be at constant time.
While the article mentions Pattern Matching, it seems to be something for the distant future. I was referring changes of Java 11, which seems to me the focus of the article.
I agree, its a complete change in paradigm. Lots of projects are a mix of the old and new ways of doing things which is a mess. Developers too - are you a traditional style Java dev or a new style?
If it keeps going in its new direction, soon they'll just be able to name it javascript. :)
The rapid release cycle is going to pose challenges downstream for all the people developing tooling and other aspects of the ecosystem which are not used to moving that fast (eg: Groovy still grappling with the module changes to Java9, let alone 10 or 11). While we all griped about it for many years, the slow pace of Java evolution was in some ways one of it's biggest features. I am curious to see whether the community starts to move fast too, or if actually what happens is that people completely ignore the non-LTS versions and we actually get an effective release cadence of 2-3 years or so in practice.
That's just it, some projects will likely try to catch up just in time for the next LTS, while others may run a similar set of release branches, one targeting the LTS or the latest release. It's really dependent on individual projects, not so much the whole ecosystem at once. In Rust we have web frameworks that run on the Stable compiler, and then there's Rocket which currently only runs on the nightly compiler (at least last I checked).
I think the jump to 9 is going to be a little rough while organisations figure out modules and all the new flags tickle into a billion build scripts but 10 and 11 don't seem too bad.
I heard one good approach is to start testing newer releases in your CI systems as soon as possible but wait for the next LTS ever few years to migrate production.
Groovy 3 is full of nice-to-haves. Which is why it's taken forever. Anything that was a "problem" as you say got put into 2.4 / 2.5 (except for solving the Java9 module problem which is unsolved in any release ...).
It sounds like Groovy 3 is just a forever-pending product designed to be a catchment for the stuff Groovy's backers aren't really very concerned about, or perhaps don't even want put into Groovy. It's still in alpha, being delayed until after a Groovy 2.6 release and the project managers have had a "conversation" sometime down the line about what features should go into Groovy 3.
If Groovy's project managers at Apache don't want a Groovy 3 release to avoid a debacle like Python 3 or Grails 3, then they should just come out and say so. Instead, they're letting others waste their time working on it while putting up roadblock after roadblock to slow it down.
Personally, I just write lambda or try with resources in Java. Groovy is great, but not for everything, I still write Javaish and with static typing whenever I write Groovy. Calling Java code from Groovy and Groovy from Java again is easy as they share the byte code.
If you can make it past 8 to 9 then 9 to 10 and 10 to 11 are much easier.
The reason the community is struggling with Java 8 to Java 9 is that 9 broke a TON of stuff. It's not backwards compatible at all. Basically every non-trivial app broke. The breakages are mostly in things that were technically never guaranteed, even trivial things like the version number went from "1.8" to "9" which makes sense but broke loads of programs that tried to parse the version.
But some of it is also just bad processes and habits in the community. Some of the programs that broke due to the version number change from 8 to 9 broke again from 9 to 10 just months later because they had enums that listed every possible version.... their codebase literally encoded the assumption that new major java releases hardly ever happened!
Can anyone familiar with the Java ecosystem chime in here? Is this more of a marketing ploy it are they actually releasing features at a significantly faster rate?
Yes, there are new features and I would say at an accelerated rate (though slightly arbitrary). It also means features that were being punted back from releases (like modularity in jigsaw) get a chance to surface without waiting several years, which in turn allows releases to hit schedules since the downside is reduced.
sure. It used to be that major releases were tied with major features. InvokeDynamic on 7, Lambdas on 8, Jigsaw on 9. So since these were the features that were expected, the release only shipped when they were fully baked. Now is on a train-release model. You get whatever is ready to ship (big features can't delay a release anymore).
The backtick is just a problematic character. Python 3 had good reasons to drop it, so I'm surprised when anyone else starts to use it.
Among the reasons Python devs cited were that it was hard to get printed correctly in books, and hard for users to write in general, depending on keyboard layout.
Yup, using a grave accent as a symbol in this time and age of Unicode is just clueless. It's a symbol usually used as a diacritical mark for letters, like è. It's thus often a "dead key" (a key that awaits the next one because it is expected to be used combined with another), just not on US keyboards. How hard is it to at least consider the general set of Western keyboards before deciding upon these things?
Hint: Let programming languages use characters 1) in the ASCII character set and 2) not diacritical marks, and you'll be fine... It's honestly not rocket science. I think it's a programming language designer's responsibility to just know these things in 2018.
In the competing .NET Framework, @ is used for raw string literals, as in @"raw string". The diacritical marks ~ and ^ do occur there for bitwise logical operations and ~ in declarations of destructors but I don't think this is optimal. I never really understood why they inherited C++'s destructor syntax to have a semi-obnoxious special symbol just for this particular one case that is used at most once per entire class definition, that is shared with bitwise complement (???), no less... Is it so bad with keywords? Or why not just use "!" as in "not". It would at least make more sense.
Java users in the enterprise like myself in some of my client work won't be massively enthralled by this approach, though not necessarily for good reasons. Audit and compliance teams love to pick up on software versions not on the latest version, so the idea of having a six month churn just means I can see man-months of effort being plowed into no-op changes.
We're also unlikely to benefit since vendor software can't upgrade (or won't certify new versions) and the mannequin developers consultancies place offshore can barely work with Java 1.4 concepts. Best I can hope for is improvements in GC and better defaults.
Weird, why ? So long as the version is supported, compliance doesn’t raise the issue. Of course plenty of compliance is done by recent graduates working for big accounting firms
> We are "reclaiming" the syntactic real estate of "_" from the space of identifiers for use in future language features. However, because there are existing programs that might use it, it is a warning for identifiers that occur in existing syntactic positions for 8, and an error for lambda formals (since there is no existing code with lambdas.)
Scala's pattern matching (which btw is structured "value match { ... }" - think of .match as an always-present extension method) goes much farther than it is easy to imagine Java going quickly; consider examples such as regexp capture decomposition, case classes, static type checking, and guards.
Scala overloads underscore in various ways, my favorite being:
val emails = users.map(_.email)
Unlikely that will make its way into Java anytime soon, if ever, but it would be a nice enhancement -- being forced to pepper your code with lambda expressions a la `x => x.foo` is annoying when the alternative `_.foo` conveys the same meaning.
As someone who hasn't used Java since the early 2000s, I am surprised that it took them this long to get some features that I have taken for granted for many many years elsewhere. What surprises me even more is that there are Java islanders treating this update as something to be proud of. Can someone enlighten me as to why this language is still popular? I get that there is legacy software that uses it, and therefore a demand. But what is the appeal otherwise?
It has easy learning curve, it's verbosity while cursed upon makes it also easier to grasp the code by less-then-expert, it's performant, it has huge ecosystem, it can run everywhere.
C# ticks all the same boxes and is much better from a language point of view.
The only reason Java still exists is because it created a generation of professionals who only know Java, only do Java, and won't learn anything else. That group is still large enough to maintain critical mass and create new greenfield Java projects despite the fact that Java is a shit-poor choice of language for those projects today.
Yeah, and Google made their opinion of Java quite clear by adding first-party support for Kotlin.
As for Java being popular because it has mindshare, you are agreeing with my original point. It doesn't continue to exist because it's a good language. It continues to exist because of inertia.
>Yeah, and Google made their opinion of Java quite clear by adding first-party support for Kotlin.
Which is good for Android developers as they crave that syntactic sugar. Unfortunately, businesses have different priorities.
>As for Java being popular because it has mindshare, you are agreeing with my original point. It doesn't continue to exist because it's a good language. It continues to exist because of inertia.
It may not have all of the syntactic sugar that other languages have at the moment, but given its new release cadence its only a matter of time before it reaches feature parity.
Agreed. Java was first, so that's primarily why it is where it is today in terms of market share. But C#, and its functional cousin F#, are now leading the way in the evolution of modern programming languages. With .Net Core now being open source and all-platform, we should all look forward to it supplanting Java and JVM as the ubiquitous language and runtime.
We used to be a Microsoft/.NET shop, and switched to Java for the ecosystem, as well as the fact that all the interesting things in cloud happen outside of Redmond.
Somewhat nicer syntax and some functional features isn’t going to fix the wider problem Microsoft has, which is the reason for .NET core existing, I suppose.
>which is the reason for .NET core existing, I suppose.
True, .Net Core exists because Microsoft eventually realized its mistake of tieing its programming framework too closely to its operating system. But... that mistake is now in the past, for some years now.
>all the interesting things in cloud happen outside of Redmond.
We're getting a bit off-topic from OP with this, but can you please give an example of some other cloud provider's service for which there is no Azure equivalent?
> We're getting a bit off-topic from OP with this, but can you please give an example of some other cloud provider's service for which there is no Azure equivalent?
I'm not referring to Azure feature line items, but rather that in the industry, Microsoft is usually an afterthought.
The innovation happens elsewhere, and then Microsoft has to themselves try and port it to Windows. If you're running on Azure, eventually you're running on Windows (yes yes, it can do Linux VMs).
We did .NET forever, and always had to try and make do with half baked adapters and integrations when wanting to use things like Hadoop or Spark back in the day, not to mention containers took forever to come to Windows.
Got tired of waiting for Microsoft or the community to port things over, just switched to the platforms and languages where this was all native. I'm sure you'll say it's better now, I've been hearing that for quite some time now, but every time I look, it's still confusing, muddled and in beta.
Kubernetes, JVM & Node.js works great for us now, and GCP is absolutely rock solid and performant.
And we don't have to wait for Microsoft to bless us with the only implementation we're ever going to get, the OSS community is much, much, more active outside of the Microsoft bubble.
Java was propelled by investment banks that saw Java as a manna from heaven comparing to C++ CORBA and the mess it was. Suddenly you had something simple yet even more powerful than C++ when it came to time to deliver a flawless distributed app. Java's main drawback is the amount of boilerplate code, but frankly that's more of an issue of framework/design patterns than the language itself; similar problems are in Python, Scala or even Haskell, just at a slightly higher conceptual level.
Language-wise C# overtook Java quickly, but SUN was all about openness and about not being big bad Microsoft, and that resonated with the majority of idealistic developers.
I code C# for a living and I still prefer Java. A lot of the things added to C# are mis-features IMO. When stuff gets added to Java it's usually been thought out better than the way MS used to cram new features into C#. I quick look at C++ ought to show that every feature under the sun isn't always the best approach.
I take issue with your "professionals who only know Java" line. I knew C, C++, Lisp, Pascal and Assembler before coding Java. I've learned C#, Javascript, Python and Rust since. I still consider Java one of my favourite languages. It's a pretty poor ad-hominem argument.
I object to the idea that Java has an easy learning curve. Java is only easy because there is a massive investment put into it up front, in the form of freshman CS courses. So (a) a lot of the learning curve gets attributed to programming itself being difficult, and (b) once you internalize the model you categorize everything else as being "easy" or "hard" based on how similar it is to Java.
If you take people who instead learned Python as their first language, and put them through all the ceremony that is getting "hello world" to work in Java, you're going to get a very different reaction. A lot of this is very dependent on perspective.
I completely disagree. I learned Java after C++ and I found it to be a breeze to learn - and I was self taught. Python is a good language too, granted.
I agree with your experience, but not your conclusion. How quickly you can switch from C++ to Java is a function of how similar Java and C++ are, not how easy one or the other is.
For the record, I also learned C++ first. I also found Java to be a breeze. And then I discovered a whole world of other languages, and learned that in the grand scheme of things, Java and C++ are actually really similar to each other. Even Python is not so incredibly different, though it is vastly easier thanks to dynamic typing.
Compare any of these to stack based languages (Forth), array-based languages (APL), dataflow/graphical languages (LabView), homoiconic languages (Lisp), dependently-typed languages (Coq), etc. There are so many paradigms that are so dizzyingly different from each other. C++ and Java really are much more similar than they are different.
And it's worth pointing out that many if not most of these, though they would probably induce shock in a typical C++/Java programmer, are actually built on top of a small set of core concepts that is probably more coherent than either of Java or C++. And this matters a lot for people who are learning truly from scratch. There isn't necessarily enough data to make any definitive statements here, but there are schools that start with e.g. Haskell as a first language, and offhand I would probably say they get off the ground faster than a lot of Java/C++ introductory courses I see.
Sure, C++ and Java are both Algol based languages. I agree that a different paradigm is a better way to go for learning - LISP as I mentioned or Haskell as you mentioned. I have done a little Haskell and Erlang, but not enough to say that I know those languages. LISP I value chiefly for making me think differently which I guess is what you are going for in your comments.
Although, I do still assert that Java is an inherently good language. I knew C before C++ and I would rank C and Java as 'better' languages than C++ from a design perspective. C and Java for being simple. C++ is good in other ways - it is arguably 'powerful' although the bang for buck over Java is reasonably low in that regard these days. My point is, I know several Algol languages and in my opinion C++, C# are the 'worse' ones and Java, C are the 'best'. I completely accept that other people will view this entirely differently and that this is largely a matter of taste.
First and foremost the reason why it's still so popular is its commitment to backwards compatibility. Enterprises love languages that don't continuously break their code bases. And then there's its unparalleled ecosystem, its massive developer talent pool and its availability on a number of platforms.
And with the introduction of Graal and Truffle I'd say Java is one of the more interesting languages to follow nowadays.
I'm a fan of Java. I enjoy writing Java and working on NEW systems in Java.
There's tons of cool stuff going on in Java and JVM land.
It has great library ecosystem, concurrent data structures, sane enough memory models.
There is great new cutting edge work going on on the JVM: G1GC, grasp/truffle, etc. There are great distributed systems/platforms like gRPC, zookeeper, cassandra, kafka, and hadoop.
The IDEs are great. Debuggers are fantastic. Hot patching live code could be better but it's not hard if you plan for it.
As for the Java language itself: sure it can be a bit cumbersome and verbose from time to time. But reading even the trickiest code is usually pretty explicit and decipherable. Not being the most "featureful" language plays to it's strengths. I find myself missing Java when in python or go as much as the reverse. It's part of the reason why Kotlin seems to be taking back some Scala fans. Kotlin is more Javay.
As much hate as it gets its a surprise to hear that people think it's confined to legacy work. From where I'm sitting I'm pretty optimistic about its future.
I liked the predictability of Java code; no nasty surprises like in Scala, no changing API like in Python, no incoherent addons like C++. You just learned how to express some things and then you could focus on algorithm/problem itself uninterrupted. With Scala or C++ I have to fight with some weird definitions here and there, dig deep into compiler to understand why some error is happening, waste a lot of time on things that should be trivial but aren't. Now I am worried that Java is going to become the same with the newer additions.
The JVM is a different beast than the one you knew 15 years ago. GC is not a problem (usually) anymore. Change of hardware? Change of OS? Want to develop on something else? No big deal, it's all on the JVM. And it's a pretty damn fast JVM.
It's got an extensive library ecosystem that isn't going anywhere. Because enterprise uses it so extensively, there's lots of support for it, lots of demand for it. Amazon is big on Java- heck they hired Gosling last year.
Java is stable, not going anywhere, and an easy choice to make. So yes, people are happy that it's getting better linguistically. Stop being a language snob.
As far as speed-of-evolution, it is worth understanding that the slower speed is at least partly a by-product of different goals. This talk, "Stewardship: The Sobering Parts" by Brian Goetz, is informative and well worth the watch: https://www.youtube.com/watch?v=2y5Pv4yN0b0
I think the language has huge bang for buck. It's fast, it's simple, it has excellent tooling and libraries. I can't see a similar value proposition anywhere else.
Languages features are not very important for some people. Tooling is more important: I'll take Java with Idea over Haskell with vim any day. Implementation is more important: I'll take fast multithreaded JVM over slow Python with GIL (or single-threaded node.js) any day. Portability is more important: I'll take JVM over .NET any day (.NET core might change that, just an example). I don't need esoteric language features to write useful software. Even something as basic as Go or Java 1.4 is more than enough. Sure, additional features are nice, but not necessary and sometimes even harmful.
The appeal of Java was the reduced (limited) design vocabulary. No meta programming. Just straightforward imperative programming. For data processing, parsing, CRUD, etc.
Java should have focused on being a better "business" language. Type inference, string intrinsics, built-in regex, intrinsic arrays and maps, lightweight objects.
I love functional programming. For my own projects. When I want to get my lambda on, I'll use Clojure. No way I want to wade into someone else's extravagantly tortured dynamically typed, meta tagged, lambda spaghetti code.
Annotations, optionals, generics, lambdas, and other cargo cult inspired additions have reduced Java's core value proposition.
Fortunately the tooling and JVM are awesome sauce.
Because a lot of these features are already implemented in kotlin. They are written way more concisely with way less ceremony and boilerplate. Plus with kotlins interop you can piecemeal your codebase away from legacy java no matter the version. It's just a better language at this point
The use of `var` is a great improvement over the current method of declaring variables. I love Swift for many reasons (optionals, structs/objs, succinctness, no GC, etc.) and var-style declarations is one of them.
I like quite like Java but Oracle scares me. They've started charging for runtime licenses, which I never heard of before. Oracle is a good enough reason to avoid Java.
Meh. The Oracle bashing mostly feels like FUD. Yea you might run into license issues if you use the Oracle JDK, but the world has rapidly moved to using OpenJDK which is just fine these days.
Please someone correct my perception here, but it looks the the goal of the rapid release cadence is now to get more enterprise support contracts: if you want to stay on LTS, you have to pay.
I think it's doubtful that anybody will be able to correct your FUD. Once you've bought into this delusion it really seems to trap people forever and rags like the Register are absolutely delighted to feed the fear with nonsense articles for precious clicks. Nothing can change the mindset. It doesn't matter that Java itself is completely open source (Open JDK), that Oracle isn't doing anything they haven't done before (you've always had to pay for support of EOL'd JDKs and JDK 8 is five years old like other EOL'd releases), or that, frankly, Oracle's actual track record here -- that is when you look at the actual actions taken by Oracle over the last ten years -- is generous to a fault. None of this matters to somebody who is committed to the FUD.
In the end the thousands of businesses an thousands of open-source projects that use Java will continue to use Java. Others will invest in the FUD around Java and Oracle. Life will go on. It'll be interesting to see who comes out on top.
I guess the worry might be that they will now potentially EOL a lot faster. No one will port their codebase every 6 months (or year or whatever). Not sure what the official EOL strategy is now.
It doesn't, rather I think Oracle's plan will end up driving people towards OpenJDK.
It looks like they're firing their pesky B, C, D, and F customers and keeping their A ones, ie the ones who will pay millions in maintenance.
The rest of us, who are currently tied to Sun Java for its stability and who aren't going to pay big maintenance, will have to switch to OpenJDK if we want stability. It's either that or constantly port every 6 months, and pray all the kabillion dependencies we have work okay.
Yep, and remember they also are HUGE into suing or threatening their own customers for benchmarking their products [1], or perhaps pointing out security problems [2]. Etc.
Oracle is definitely not a nice company. But they sure do take good care of Java as a whole. And I don't see any "risk" or threat if you are using OpenJDK.
I am on Oracle's side, my point is that people keep giving advises to switch to OpenJDK as means to get rid of evil Oracle (on their eyes) as if it was developed by someone else.
I am on Oracle's side, my point is that people keep giving advises to switch to OpenJDK as means to get rid of evil Oracle (on their eyes) as if it was developed by someone else.
I don't even use OpenJDK, rather always install Oracle commercial's JDK.
I thought the whole .Net Framework/.Net Core/.Net Standard distinction was crazy. But the more I read about the Oracle JDK vs OpenJDK and the difference in the support schedule and licensing, I find that Microsoft's strategy is much more understandable.
And as far as the LTS version of Java, 3 years seems a little long to wait for any updates but 6 months seems short to to drop support.
If I ever get back into Java, it will be solely for Android development. Does any of this affect Android development?
I haven't used Java in years, is the Java ecosystem under Oracle as bad as it appears from the outside?
I think what Oracle is doing wrt. LTS is actually quite reasonable.
However they adopted the versioning scheme from Ubuntu and I honestly think it is confusing.
What really is going on is this:
1 Major version 1
2 Major version 1 + latest and greatest features pack 1
3 Major version 1 + latest and greatest features pack 2
4 Major version 2
5 Major version 2 + latest and greatest features pack 1
6 Major version 2 + latest and greatest features pack 2
7 Major version 3
8 Major version 3 + latest and greatest features pack 1
9 Major version 3 + latest and greatest features pack 2
...
Picking a version scheme that made that obvious would have been helpful.
Adopting Ubuntu-like date versioning was one proposal but not the one they ultimately went with. They instead went with a major version for every release like Chrome or Firefox. I think moving to a time based release was a good move but a major version per LTS might have reduced a lot of the apprehension around it.
I really do not understand why this is getting so much hate?
I really think this new time based release versioning is much preferred to alternatives.
I think the biggest problem is that it is in the nature of most developers to want to live on the bleeding edge. We want to have these new shiny purple things. And it just hurts us deep down inside to go with the safe and mature option.
Again, nobody is forcing you to adapt a new version as soon as it comes out.
Except you are essentially being forced since the previous version becomes immediately unsupported. By the time you consider and work through all the implications of upgrading to Java 10 it will be September and Java 11 will have come out, and Java 10 will be obsolete and unsupported. That’s a bit crazy for a major version that just came out in March.
You can start testing new release before it is out.
E.g. for 11, you get final RC at 8/30, and the release is on 9/25. Which means that you get almost a month while you can be 99% sure that you are testing with the target JDK.
And also, the cadence means that java changes will be much smaller, so no more big bang like Java 9.
The only real problem might be the bytecode releated libraries like ASM/bytebuddy, those need to move faster then previously (and they are, e.g. butebuddy already supports java 11 bytecode version).
For those concerned about being forced to use Oracle’s JDK / support you can definitely just use OpenJDK now. The build farm we have put together at AdoptOpenJDK.net will produce professionally tested OpenJDK binaries for all major versions and platforms with free LTS support. You can then also always go to a commercial vendor like Oracle for extra paid support if that’s what your org needs.
131 comments
[ 3.5 ms ] story [ 69.0 ms ] threadI think the issue he was speaking to was that if many of the new features require doing things in a new way then it really is something new. But your point is well taken as well. C++ is still C++ whether you use standard templates or not.
The GCC C++ parser is over a megabyte of ASCII text. Think about it: it takes over a million characters to figure out how to parse C++ code. This complexity is partially because there are so many ways to do the same thing.
All auto parameters, or make it a template? `if constexpr` or `std::enable_if_t`? Macros for generic programming or variadic variadic template templates? Overloading or specialization?
I love C++, and backwards compatibility is something that's been valuable for it, but it certainly comes with its challenges.
Firstly, nothing requires you to do things in a new way.
Secondly, if “you could already do that” implies “not really something new” for a programming language, updates to the syntax of programming languages can never count as “really something new”.
I'd much rather see type erasure fixed, as that messes up every single language based on JVM. But that would be like "the incompatible change" of a decade...
What? Type erasure is one of the main reasons why the JVM is targeted by so many languages (Java, Clojure, Kotlin, Scala, Groovy, JRuby, etc.). Had the JVM gone the way of the CLR the programming language landscape would probably look a lot different than it does today.
Perhaps you mean lack of support for value types? That does affect every language running on the JVM.
As someone who grapples with erasure as well, I haven't heard this argument before. Could you explain that?
Learning from other peoples' code is not generally considered harmful.
If it keeps going in its new direction, soon they'll just be able to name it javascript. :)
I heard one good approach is to start testing newer releases in your CI systems as soon as possible but wait for the next LTS ever few years to migrate production.
Apache Groovy hasn't even updated its syntax to support Java 8 lambdas. It's coming in Groovy 3, apparently.
If Groovy's project managers at Apache don't want a Groovy 3 release to avoid a debacle like Python 3 or Grails 3, then they should just come out and say so. Instead, they're letting others waste their time working on it while putting up roadblock after roadblock to slow it down.
The reason the community is struggling with Java 8 to Java 9 is that 9 broke a TON of stuff. It's not backwards compatible at all. Basically every non-trivial app broke. The breakages are mostly in things that were technically never guaranteed, even trivial things like the version number went from "1.8" to "9" which makes sense but broke loads of programs that tried to parse the version.
But some of it is also just bad processes and habits in the community. Some of the programs that broke due to the version number change from 8 to 9 broke again from 9 to 10 just months later because they had enums that listed every possible version.... their codebase literally encoded the assumption that new major java releases hardly ever happened!
The quicker pace with smaller changes will hopefully help with this friction.
Among the reasons Python devs cited were that it was hard to get printed correctly in books, and hard for users to write in general, depending on keyboard layout.
Hint: Let programming languages use characters 1) in the ASCII character set and 2) not diacritical marks, and you'll be fine... It's honestly not rocket science. I think it's a programming language designer's responsibility to just know these things in 2018.
In the competing .NET Framework, @ is used for raw string literals, as in @"raw string". The diacritical marks ~ and ^ do occur there for bitwise logical operations and ~ in declarations of destructors but I don't think this is optimal. I never really understood why they inherited C++'s destructor syntax to have a semi-obnoxious special symbol just for this particular one case that is used at most once per entire class definition, that is shared with bitwise complement (???), no less... Is it so bad with keywords? Or why not just use "!" as in "not". It would at least make more sense.
Can’t wait what next 10 will bring - native json and html/jsx/xml perhaps?
We're also unlikely to benefit since vendor software can't upgrade (or won't certify new versions) and the mannequin developers consultancies place offshore can barely work with Java 1.4 concepts. Best I can hope for is improvements in GC and better defaults.
> We are "reclaiming" the syntactic real estate of "_" from the space of identifiers for use in future language features. However, because there are existing programs that might use it, it is a warning for identifiers that occur in existing syntactic positions for 8, and an error for lambda formals (since there is no existing code with lambdas.)
Example:
It basically means that one of the lambda parameters is unused.And citing this JEP 302:
In principle - it's just convenient in many ways.
The only reason Java still exists is because it created a generation of professionals who only know Java, only do Java, and won't learn anything else. That group is still large enough to maintain critical mass and create new greenfield Java projects despite the fact that Java is a shit-poor choice of language for those projects today.
Also that whole "Android" thing happened.
Yeah, and Google made their opinion of Java quite clear by adding first-party support for Kotlin.
As for Java being popular because it has mindshare, you are agreeing with my original point. It doesn't continue to exist because it's a good language. It continues to exist because of inertia.
Which is good for Android developers as they crave that syntactic sugar. Unfortunately, businesses have different priorities.
>As for Java being popular because it has mindshare, you are agreeing with my original point. It doesn't continue to exist because it's a good language. It continues to exist because of inertia.
It may not have all of the syntactic sugar that other languages have at the moment, but given its new release cadence its only a matter of time before it reaches feature parity.
Somewhat nicer syntax and some functional features isn’t going to fix the wider problem Microsoft has, which is the reason for .NET core existing, I suppose.
True, .Net Core exists because Microsoft eventually realized its mistake of tieing its programming framework too closely to its operating system. But... that mistake is now in the past, for some years now.
>all the interesting things in cloud happen outside of Redmond.
We're getting a bit off-topic from OP with this, but can you please give an example of some other cloud provider's service for which there is no Azure equivalent?
I'm not referring to Azure feature line items, but rather that in the industry, Microsoft is usually an afterthought.
The innovation happens elsewhere, and then Microsoft has to themselves try and port it to Windows. If you're running on Azure, eventually you're running on Windows (yes yes, it can do Linux VMs).
We did .NET forever, and always had to try and make do with half baked adapters and integrations when wanting to use things like Hadoop or Spark back in the day, not to mention containers took forever to come to Windows.
Got tired of waiting for Microsoft or the community to port things over, just switched to the platforms and languages where this was all native. I'm sure you'll say it's better now, I've been hearing that for quite some time now, but every time I look, it's still confusing, muddled and in beta.
Kubernetes, JVM & Node.js works great for us now, and GCP is absolutely rock solid and performant.
And we don't have to wait for Microsoft to bless us with the only implementation we're ever going to get, the OSS community is much, much, more active outside of the Microsoft bubble.
Language-wise C# overtook Java quickly, but SUN was all about openness and about not being big bad Microsoft, and that resonated with the majority of idealistic developers.
If you take people who instead learned Python as their first language, and put them through all the ceremony that is getting "hello world" to work in Java, you're going to get a very different reaction. A lot of this is very dependent on perspective.
For the record, I also learned C++ first. I also found Java to be a breeze. And then I discovered a whole world of other languages, and learned that in the grand scheme of things, Java and C++ are actually really similar to each other. Even Python is not so incredibly different, though it is vastly easier thanks to dynamic typing.
Compare any of these to stack based languages (Forth), array-based languages (APL), dataflow/graphical languages (LabView), homoiconic languages (Lisp), dependently-typed languages (Coq), etc. There are so many paradigms that are so dizzyingly different from each other. C++ and Java really are much more similar than they are different.
And it's worth pointing out that many if not most of these, though they would probably induce shock in a typical C++/Java programmer, are actually built on top of a small set of core concepts that is probably more coherent than either of Java or C++. And this matters a lot for people who are learning truly from scratch. There isn't necessarily enough data to make any definitive statements here, but there are schools that start with e.g. Haskell as a first language, and offhand I would probably say they get off the ground faster than a lot of Java/C++ introductory courses I see.
It's one line with the official java REPL jshell. Two lines, if you want a GUI (Swing).
And with the introduction of Graal and Truffle I'd say Java is one of the more interesting languages to follow nowadays.
It has great library ecosystem, concurrent data structures, sane enough memory models.
There is great new cutting edge work going on on the JVM: G1GC, grasp/truffle, etc. There are great distributed systems/platforms like gRPC, zookeeper, cassandra, kafka, and hadoop.
The IDEs are great. Debuggers are fantastic. Hot patching live code could be better but it's not hard if you plan for it.
As for the Java language itself: sure it can be a bit cumbersome and verbose from time to time. But reading even the trickiest code is usually pretty explicit and decipherable. Not being the most "featureful" language plays to it's strengths. I find myself missing Java when in python or go as much as the reverse. It's part of the reason why Kotlin seems to be taking back some Scala fans. Kotlin is more Javay.
As much hate as it gets its a surprise to hear that people think it's confined to legacy work. From where I'm sitting I'm pretty optimistic about its future.
The JVM is a different beast than the one you knew 15 years ago. GC is not a problem (usually) anymore. Change of hardware? Change of OS? Want to develop on something else? No big deal, it's all on the JVM. And it's a pretty damn fast JVM.
It's got an extensive library ecosystem that isn't going anywhere. Because enterprise uses it so extensively, there's lots of support for it, lots of demand for it. Amazon is big on Java- heck they hired Gosling last year.
Java is stable, not going anywhere, and an easy choice to make. So yes, people are happy that it's getting better linguistically. Stop being a language snob.
Java should have focused on being a better "business" language. Type inference, string intrinsics, built-in regex, intrinsic arrays and maps, lightweight objects.
I love functional programming. For my own projects. When I want to get my lambda on, I'll use Clojure. No way I want to wade into someone else's extravagantly tortured dynamically typed, meta tagged, lambda spaghetti code.
Annotations, optionals, generics, lambdas, and other cargo cult inspired additions have reduced Java's core value proposition.
Fortunately the tooling and JVM are awesome sauce.
At first I read it like: "Man at this point there is 0 reason to use kotlin".
But come to think about it, it makes just as much sense.
Perhaps you can explain why you think there is 0 reason not to use Kotlin now?
http://www.theregister.co.uk/2016/12/16/oracle_targets_java_...
Please someone correct my perception here, but it looks the the goal of the rapid release cadence is now to get more enterprise support contracts: if you want to stay on LTS, you have to pay.
In the end the thousands of businesses an thousands of open-source projects that use Java will continue to use Java. Others will invest in the FUD around Java and Oracle. Life will go on. It'll be interesting to see who comes out on top.
http://www.oracle.com/technetwork/java/eol-135779.html
Aren't we talking about the company that wants to copyright api no matter what effect his has on the rest of the industry.
The same oracle that buys and kills interesting project making the world a less interesting place.
The people that are suing google for violations that the original owners of the IP tacitly allowed.
You are awful quick to call criticism of oracle FUD and delusion. Are you sure you don't work there?
All corporations are alike and many geeks are naive to assign human behavior to companies.
It looks like they're firing their pesky B, C, D, and F customers and keeping their A ones, ie the ones who will pay millions in maintenance.
The rest of us, who are currently tied to Sun Java for its stability and who aren't going to pay big maintenance, will have to switch to OpenJDK if we want stability. It's either that or constantly port every 6 months, and pray all the kabillion dependencies we have work okay.
1. https://news.ycombinator.com/item?id=15886333
2. http://www.businessinsider.com/oracle-cso-goes-against-bug-b...
That would have made a lot of people happy.
I don't even use OpenJDK, rather always install Oracle commercial's JDK.
Given how much Google and IBM cared for Sun's fate, I doubt very much they would pick up OpenJDK development, if all those devs went away.
Then you could enjoy your free license with a programming language frozen in maintenance mode.
Anything that stops businesses asking me to target Java 1.4 on abandoned Red-Hat 5 servers is good on my book.
And as far as the LTS version of Java, 3 years seems a little long to wait for any updates but 6 months seems short to to drop support.
If I ever get back into Java, it will be solely for Android development. Does any of this affect Android development?
I haven't used Java in years, is the Java ecosystem under Oracle as bad as it appears from the outside?
Then we will see where Kotlin lands, specially since Fuchsia uses Dart.
However they adopted the versioning scheme from Ubuntu and I honestly think it is confusing.
What really is going on is this:
Picking a version scheme that made that obvious would have been helpful.With an increment in the major version number indicating that a release contains significant new features and/or old features being removed.
The scheme you propose would imply that it is only LTS releases that get significant new functionality.
I think the biggest problem is that it is in the nature of most developers to want to live on the bleeding edge. We want to have these new shiny purple things. And it just hurts us deep down inside to go with the safe and mature option.
Again, nobody is forcing you to adapt a new version as soon as it comes out.
And also, the cadence means that java changes will be much smaller, so no more big bang like Java 9.
The only real problem might be the bytecode releated libraries like ASM/bytebuddy, those need to move faster then previously (and they are, e.g. butebuddy already supports java 11 bytecode version).
If you can do testing in a month than use non-LTS, it is quite simple.