7 ms·

> Somehow I would like they would have focused on value types and reified generics for Java 9 instead of jigsaw and postponing them to Java 10+. I hear you. Co

> Somehow I would like they would have focused on value types and reified generics for Java 9 instead of jigsaw and postponing them to Java 10+. I hear you. Cost-benefit wise Jigsaw doesn't look attractive to me. To be honest I would have preferred Java 9 in the fall of 2016 without Jigsaw.

pjmlp 10y ago
Java is getting lots of new competition from languages that have proper support for value types, have layout control and have AOT available for free on their reference compilers. On the desktop it already lost to .NET, Qt and HTML 5. On the mobile it might reign in Android, but Android Java is not 100% Java and I don't see Google improving the language, in case Oracle stops doing it now that they had another setback. They went silent on future of JEE and IBM is now doing lots of Swift and Go support, while making J9 language agnostic. So I really don't care about jigsaw.
- Longhanks 10y ago
  Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java. Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.
  - pron 10y ago
    Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and Java is better for larger ones (due to amazing monitoring, polyglotism, dynamic code loading etc.).
    - pjmlp 10y ago
      Yeah, Rust is not the real adversary. The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js. Monitoring tools similar to VisualVM will come. Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.
      - the8472 10y ago
        > Monitoring tools similar to VisualVM will come. Well, in java-land visualvm already exists and is more of an entry-level/free tool with its big brothers available if it should prove insufficient. Java tooling is amazing, I miss it in most other languages.
      - pron 10y ago
        It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. Those problems are sometimes obscured by the novelty and promise of the shiny alternative, and take a while to be felt among those who always opt for the new thing, but they are invariably discovered later on, and by that time something newer comes along, whose problems are yet unapparent. The problems are there because unlike Java and the JVM (and Fortran, COBOL, C and Rust), those platforms were not developed after careful consideration of the industry's needs (Erlang/Elixir is a different story, and, indeed its fundamental problems are more environmental than technical). In addition, in smaller/less-critical projects, Java was an accidental leader in a short period of time where the competition disappeared and Java itself was novel, but it was never "supposed" to be there to begin with. VB and Delphi were very popular choices early on. I'd estimate that even when Java was the shiny new thing, VB, Delphi and other rapid-development languages had a larger share of the market than Go, Node, Ruby, Python, Haskell and OCaml combined today. And frankly, I don't see companies developing en masse large-scale applications in C++14. Unless you have very specific needs, there's just no reason to go there and pay a higher development cost, and if you do have those needs, you're probably already there. In large corporations (including trendy ones, like Google, Amazon, Netflix, Twitter and many more, let alone more conservative ones) the JVM still reigns supreme, with competition lagging far, far behind. I'm not saying it won't eat into the JVM's market share -- although they're mostly cannibalizing one another -- but I don't see any potential leader in the pack. It's possible that there won't be one, with many sharing the cake. So I think that (again, with the notable exception of .NET) the non-JVM market is composed of novelty-seeking organizations and a share that wasn't Java's to begin with, but accidentally was for a short while (the two segments intersect).
  - virmundi 10y ago
    A lot of tooling. Eclipse just works. You don't have to use Intellij. Spring makes most things a breeze. Maven handles dependencies and complex builds easily. A lot of the language issues disappear with the right, battle tested tooling.
  - kpil 10y ago
    One benefit is the extremely large set of 3rd party libraries and tools. It's hard to catch up outside the mainstream bread and butter stuff. Also, finding experienced developers, devops, etc. While Kotlin is interesting, and can use java code, maybe it's a little too small and have less battle tested toolchains so java probably feels like a slightly safer bet for large projects and conservative organisations.
- markokrajnc 10y ago
  "... but Android Java is not 100%" => Android N will use OpenJDK.
  - pjmlp 10y ago
    Android N will use selected parts of the OpenJDK, it isn't 100% Java 8 compliant. And with Marshmallow having 7.5% market share[1] how long do you think will take for developers even to start caring about Java 8 support on Android N? [1] https://developer.android.com/about/dashboards/index.html https://developer.android.com/about/dashboards/index.html

pjmlp 10y ago

Java is getting lots of new competition from languages that have proper support for value types, have layout control and have AOT available for free on their reference compilers. On the desktop it already lost to .NET, Qt and HTML 5. On the mobile it might reign in Android, but Android Java is not 100% Java and I don't see Google improving the language, in case Oracle stops doing it now that they had another setback. They went silent on future of JEE and IBM is now doing lots of Swift and Go support, while making J9 language agnostic. So I really don't care about jigsaw.

Longhanks 10y ago
Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java. Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.
- pron 10y ago
  Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and Java is better for larger ones (due to amazing monitoring, polyglotism, dynamic code loading etc.).
  - pjmlp 10y ago
    Yeah, Rust is not the real adversary. The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js. Monitoring tools similar to VisualVM will come. Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.
    - the8472 10y ago
      > Monitoring tools similar to VisualVM will come. Well, in java-land visualvm already exists and is more of an entry-level/free tool with its big brothers available if it should prove insufficient. Java tooling is amazing, I miss it in most other languages.
    - pron 10y ago
      It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. Those problems are sometimes obscured by the novelty and promise of the shiny alternative, and take a while to be felt among those who always opt for the new thing, but they are invariably discovered later on, and by that time something newer comes along, whose problems are yet unapparent. The problems are there because unlike Java and the JVM (and Fortran, COBOL, C and Rust), those platforms were not developed after careful consideration of the industry's needs (Erlang/Elixir is a different story, and, indeed its fundamental problems are more environmental than technical). In addition, in smaller/less-critical projects, Java was an accidental leader in a short period of time where the competition disappeared and Java itself was novel, but it was never "supposed" to be there to begin with. VB and Delphi were very popular choices early on. I'd estimate that even when Java was the shiny new thing, VB, Delphi and other rapid-development languages had a larger share of the market than Go, Node, Ruby, Python, Haskell and OCaml combined today. And frankly, I don't see companies developing en masse large-scale applications in C++14. Unless you have very specific needs, there's just no reason to go there and pay a higher development cost, and if you do have those needs, you're probably already there. In large corporations (including trendy ones, like Google, Amazon, Netflix, Twitter and many more, let alone more conservative ones) the JVM still reigns supreme, with competition lagging far, far behind. I'm not saying it won't eat into the JVM's market share -- although they're mostly cannibalizing one another -- but I don't see any potential leader in the pack. It's possible that there won't be one, with many sharing the cake. So I think that (again, with the notable exception of .NET) the non-JVM market is composed of novelty-seeking organizations and a share that wasn't Java's to begin with, but accidentally was for a short while (the two segments intersect).
- virmundi 10y ago
  A lot of tooling. Eclipse just works. You don't have to use Intellij. Spring makes most things a breeze. Maven handles dependencies and complex builds easily. A lot of the language issues disappear with the right, battle tested tooling.
- kpil 10y ago
  One benefit is the extremely large set of 3rd party libraries and tools. It's hard to catch up outside the mainstream bread and butter stuff. Also, finding experienced developers, devops, etc. While Kotlin is interesting, and can use java code, maybe it's a little too small and have less battle tested toolchains so java probably feels like a slightly safer bet for large projects and conservative organisations.
markokrajnc 10y ago
"... but Android Java is not 100%" => Android N will use OpenJDK.
- pjmlp 10y ago
  Android N will use selected parts of the OpenJDK, it isn't 100% Java 8 compliant. And with Marshmallow having 7.5% market share[1] how long do you think will take for developers even to start caring about Java 8 support on Android N? [1] https://developer.android.com/about/dashboards/index.html https://developer.android.com/about/dashboards/index.html