22 ms·

I'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 ye

by MarkMc 8y ago

I'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 years like some flavour-of-the-month Javascript framework. Even on the client where Java has lost to Javascript, I'm finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javascript+CSS+DOM (+ maybe Electron). Personally I think it's a shame Sun dropped the ball with client Java - if they had chosen SWT over Swing and provided a minimal JVM then maybe Java Web Start would have beaten Javascript web apps. It's also a shame Sun sold Java to Oracle - Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun. I'm now trying Dart to develop a few Flutter apps. It's no doubt a better language, but not that much better - I think Flutter would have been more successful if it was built on Java. [0] https://www.solaraccounts.co.uk https://www.solaraccounts.co.uk

Justsignedup 8y ago
just had this conversation with a co-worker today. java is a stable api but it also doesn't evolve. The tradeoff is you get a program guaranteed to work no matter the upgrade vs being able to build better toolage. React changes every year or 2. It is exhausting. But you get way better patterns and some things that drastically improve productivity.
- sixstringtheory 8y ago
  Java gives you a flexible object oriented language and an incredible set of libraries. It's got an archiver for artifact and dependency management. It now has lambdas and has FRP style stream programming. I'd say it's kept up pretty well with modern fashion, while it's been doing other things far longer than newer, more popular languages. Take Swift, now my daily driver (which I love so much compared to ObjC, which I moved to after Java)... an example of something Java had way before Swift is "Protocol Oriented Programming". Also, Swing's GridBagLayout predates iOS' AutoLayout and CSS (edit: don't know where I was going with CSS haha...). Everything old is new again, and I'm sure Java reinvented a few wheels of it's own. Also keep in mind that React is a library, not a language. If you want to compare things, compare Javascript to Java, or the Java stdlibs to React. Maybe that's what you meant when you said Java. IMO, Java and its libraries are nicer to work with solely due to its static nature and OO design. It is worlds apart from a scripting language when you need to refactor, or even just understand, legacy code. And if you can't even run tests on that legacy code anymore, like a React project over a year or two old? What are the better patterns and productivity boosts you get from React vs. a Java ecosystem?
  - humbleMouse 8y ago
    In addition to all of these good things, you can also use groovy which has a ton of shorthand syntax and makes writing code super easy. Groovy also makes writing tests short and simple. I love java and all jvm languages honestly.
  - euyyn 8y ago
    Kotlin though. Everything you said, but a joy to write instead of a chore.
    - pjmlp 8y ago
      I am betting Kotlin is the new Groovy. Lets see where it stands 5 years from now, specially if Fuchsia actually gets released.
      - ptx 8y ago
        Kotlin is different because of the focus on tooling, which is the advantage Java still had over all the dynamically typed JVM languages. Also, Kotlin/Native is in beta now and could target Fuchsia (compiling AOT to native code using LLVM).
        pjmlp 8y ago
        What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Still not able to use several of Android Studio features available to Java, like incremental compilation and slim APKs? Kotlin advocates seem to forget JVM will never be rewritten in Kotlin, the language is just yet another guest, with the usual syndrome to wrap existing libraries, having to take care about FFI for Java access, not having all features taking advatange of the latest bytecodes, e.g. lambdas implementation. As for Kotlin/Native, there is nothing to worry about versus what Go, Rust, C++, Dart, D, Nim offer in terms of performance, libraries and in some cases tooling. Having to buy CLion for a graphical debugger isn't a selling point versus the established alternatives. Fuchsia is being written in Go, Rust, C++ and Dart, with the team now hiring for node.js support. https://www.androidpolice.com/2019/03/19/google-working-to-bring-javascript-app-support-to-fuschia/ https://www.androidpolice.com/2019/03/19/google-working-to-b...
- freewilly1040 8y ago
  Doesn't evolve _quickly_. Which as you say is say is part of the tradeoff of giving a trustable guarantee that the tooling you do use will continue to work for a long time.
- mosdl 8y ago
  There are plenty of java projects that change apis. Comparing a framework to a language is stupid.
- Consultant32452 8y ago
  I've been working professionally in Java for almost 20 years. I can't remember the last time I saw someone use features introduced after 1.6. The time API in 1.8 was nice. I've never seen anyone use lambdas in production code. I'm sure people do use newer stuff, but I think it's the minority. So in practice it's even more stable than it is in the headlines.
  - Scea91 8y ago
    Strange, our production code is full of streams and lambdas. It probably depends on the type of product.
  - euyyn 8y ago
    Chromium (and so Chrome too) uses lambdas in its Java parts.
  - qw 8y ago
    I work for a large company and the code base is full of streams and lambdas. Streams are almost used too much and could be replaced with a simple for-loop.
    - ionised 8y ago
      Yeah, stream overuse is definitely an issue at our company.
  - jcadam 8y ago
    I started using Streams and lambdas immediately, along with functional interfaces. Java is still not nearly as pleasant as Scala or Clojure, however.
  - ionised 8y ago
    We start using new features pretty much as soon as the new JDK version is released to general use.
  - astura 8y ago
    I started using them ASAP.
- jaabe 8y ago
  If you develop, not if you maintain. This is a major reason we stay away from JS frameworks after burning the hands on implementing an AngularJS that was obsolete a year later. That and a few page reloads never killed anyone.
  - deleted 8y ago
    [deleted]
- coldtea 8y ago
  >java is a stable api but it also doesn't evolve You have probably missed the last 5 years. From streams, to closures, to default methods, to functional interfaces, to local type inference, to new Process APIs, to modules, to unsigned arithmetic, to new date/time APIs, http client, 2 new GCs, shell REPL, etc... with more to come, and new releases every 3 months...
  - ptx 8y ago
    > unsigned arithmetic I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)? Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types. [0] https://kotlinlang.org/docs/reference/basic-types.html#unsigned-integers https://kotlinlang.org/docs/reference/basic-types.html#unsig...
    - coldtea 8y ago
      >I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)? Yes, but it's also a new feature (along with dozens of others). The complaint I answered was that Java is stagnant somehow, when it has been evolving fast in the last 5 years, and is accelerating its pace (release cadenze) even more. >Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types. Which, given that the JVM doesn't support them at the bytecode level (iirc), they also use some similar trick of working with signed numbers under the hood, just hide it better at the syntax level.
spricket 8y ago
One of my Java guilty pleasures is pulling in some 14 year old library and it just works. Absolute gold for a company with a lotta old code sitting around. I also do a good bit of frontend and holy crap it's exhausting. That's the main reason I push hard for Java backend. Backends tend to stick around about a decade longer than you would like, while front end code is due for a rewrite every 3 years
theandrewbailey 8y ago
> It's also a shame Sun sold Java to Oracle Worse: Oracle bought Sun.
- pjmlp 8y ago
  Worse: IBM, Google and everyone else could have done it as well, but decided not to counter-offer.
gigatexal 8y ago
Biggest barrier to entry for me is the build dependency system Maven. And I never understood Ant. I did like the language when I played around with Java 8. Streams are amazing.
- BinaryIdiot 8y ago
  Maven is an incredible system. It can do so much and yet, even though I've setup countless apps and services, I can never use it without looking literally everything up. Maven and spring are the worst parts, for me, when dealing with Java. I don't mind the language at all.
  - gigatexal 8y ago
    Yeah I felt the same. The language is fine. It’s got a fantastic set of libraries and a large ecosystem and one would be hard pressed to not find a job being a competent Java dev but maven ugh
    - eitland 8y ago
      With maven, less is more. Huge maven files usually means something is wrong. Follow the conventions and it is less than a screenful for a basic project. I typically solved maven problems by removing cruft and falling back to the standards.
  - thecleaner 8y ago
    What was your problem specifically ? For me these two worked great together actually. I really loved Spring. Maybe the problem has some overlooked fix that I can help with ?
    - BinaryIdiot 8y ago
      Nothing in particular just lots of seemingly random issues trying and failing to get them working correctly, likely due to my lack of knowledge but every time I try to better learn them my brain just can't handle it. I don't know what it is. I think part of it is my auto-cringe when I see XML nowadays.
tannhaeuser 8y ago
The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serving APIs (expressjs and core http request API, which expressjs middlewares forwards and decorates) is stable since node.js v0.1 or at least 2015, and infinitely better than Java's servlet, JSP, and taglib APIs (web.xml/jetty-config.xml anyone?). The flip side of Java's stability is stagnation. On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess. SWT? I'm glad it works for you. Last I heard, IBM had pulled out of developing Eclipse and SWT/RCP over ten years ago. In the one project where we used it, the app looked like an IDE, and customers hated, then cancelled it. Designed as wrappers for OS-native GUI controls, it has even less of a place in a browser than Swing had. Last I looked, of the Java rich-client frameworks, only Swing has been updated with HIDPI support, whereas JavaFX and SWT haven't. None is using any of those (with the exception of experimental JFX apps) for new apps in this decade.
- vbsteven 8y ago
  You can call Spring (boot) over-engineered. I call it feature full and extensible. Whereas in the modern JS world, you start out with a lean project and then add small libraries from NPM that all work slightly different for every feature you need, in the Spring world where the framework has matured for 10+ years most of the things you will need are in the box or are available as external libraries that all work on the same defined interfaces. Spring Boot with Java 11 or Kotlin are still my preferred backend stack for that reason. It’s solid, has aged well and makes me super productive.
  - nickspacek 8y ago
    Actually they just said that Java's server-side stack is overengineered, and that Spring/Spring Boot hides that complexity. I think that is mostly true.
    - 8y ago
ksec 8y ago
>Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun. They didn't and Google didn't want a pay a single dollar to Sun on Java. As James Gosling has mentioned multiple times. I don't understand why people are still painting Google as Saint after all these years.
- merb 8y ago
  actually they didn't want to pay a single dollar to sun, because of licensing reasons, not because they didn't wanted to buy java. currently they recreated the java apis by pulling in apache harmony and they tought that they are in the right or at least in a fair use position (they still think they do). but I agree, I'm not sure if the direction of java would've been better when google would have the stewardship.
  - pjmlp 8y ago
    They had the opportunity to buy Sun when it went on sale, instead they thought they could get away with it.
tobiaswk 8y ago
I love Dart and Flutter. I actually think it was a good idea not to use Java. Dart is much more modern and nice to work with in my opinion. There are many reason and I won't dwell into it here. The biggest-ish project I've built with Flutter is an alternative to Nissan's ConnectEV app; it's used with the electric vehicles Nissan Leaf and Nissan E-NV200. You can see statistics, battery status and control climate control and charging of your vehicle. My alternative is called "My Leaf" on the Play Store and "My Leaf for Nissan EV" on the App Store. It's completely open source; https://gitlab.com/tobiaswkjeldsen/carwingsflutter https://gitlab.com/tobiaswkjeldsen/carwingsflutter It consists of the main Flutter app and a Dart library for communicating with Nissan's API.
- schwurb 8y ago
  I am currently building my first mobile app on Flutter and quite happy I choose that technology! Developing in AndroidStudio + Flutter does not feel like the chore I remember developing android apps to be.
cztomsik 8y ago
The success of javascript is hugely because of no dependency-hell (not being able to upgrade some lib to a new version, because it would conflict with some other lib which requires it in its current version and you can't have both of them loaded at the same time)

by MarkMc 8y ago

Justsignedup 8y ago

just had this conversation with a co-worker today. java is a stable api but it also doesn't evolve. The tradeoff is you get a program guaranteed to work no matter the upgrade vs being able to build better toolage. React changes every year or 2. It is exhausting. But you get way better patterns and some things that drastically improve productivity.

sixstringtheory 8y ago
Java gives you a flexible object oriented language and an incredible set of libraries. It's got an archiver for artifact and dependency management. It now has lambdas and has FRP style stream programming. I'd say it's kept up pretty well with modern fashion, while it's been doing other things far longer than newer, more popular languages. Take Swift, now my daily driver (which I love so much compared to ObjC, which I moved to after Java)... an example of something Java had way before Swift is "Protocol Oriented Programming". Also, Swing's GridBagLayout predates iOS' AutoLayout and CSS (edit: don't know where I was going with CSS haha...). Everything old is new again, and I'm sure Java reinvented a few wheels of it's own. Also keep in mind that React is a library, not a language. If you want to compare things, compare Javascript to Java, or the Java stdlibs to React. Maybe that's what you meant when you said Java. IMO, Java and its libraries are nicer to work with solely due to its static nature and OO design. It is worlds apart from a scripting language when you need to refactor, or even just understand, legacy code. And if you can't even run tests on that legacy code anymore, like a React project over a year or two old? What are the better patterns and productivity boosts you get from React vs. a Java ecosystem?
- humbleMouse 8y ago
  In addition to all of these good things, you can also use groovy which has a ton of shorthand syntax and makes writing code super easy. Groovy also makes writing tests short and simple. I love java and all jvm languages honestly.
- euyyn 8y ago
  Kotlin though. Everything you said, but a joy to write instead of a chore.
  - pjmlp 8y ago
    I am betting Kotlin is the new Groovy. Lets see where it stands 5 years from now, specially if Fuchsia actually gets released.
    - ptx 8y ago
      Kotlin is different because of the focus on tooling, which is the advantage Java still had over all the dynamically typed JVM languages. Also, Kotlin/Native is in beta now and could target Fuchsia (compiling AOT to native code using LLVM).
      - pjmlp 8y ago
        What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Still not able to use several of Android Studio features available to Java, like incremental compilation and slim APKs? Kotlin advocates seem to forget JVM will never be rewritten in Kotlin, the language is just yet another guest, with the usual syndrome to wrap existing libraries, having to take care about FFI for Java access, not having all features taking advatange of the latest bytecodes, e.g. lambdas implementation. As for Kotlin/Native, there is nothing to worry about versus what Go, Rust, C++, Dart, D, Nim offer in terms of performance, libraries and in some cases tooling. Having to buy CLion for a graphical debugger isn't a selling point versus the established alternatives. Fuchsia is being written in Go, Rust, C++ and Dart, with the team now hiring for node.js support. https://www.androidpolice.com/2019/03/19/google-working-to-bring-javascript-app-support-to-fuschia/ https://www.androidpolice.com/2019/03/19/google-working-to-b...
freewilly1040 8y ago
Doesn't evolve _quickly_. Which as you say is say is part of the tradeoff of giving a trustable guarantee that the tooling you do use will continue to work for a long time.
mosdl 8y ago
There are plenty of java projects that change apis. Comparing a framework to a language is stupid.
Consultant32452 8y ago
I've been working professionally in Java for almost 20 years. I can't remember the last time I saw someone use features introduced after 1.6. The time API in 1.8 was nice. I've never seen anyone use lambdas in production code. I'm sure people do use newer stuff, but I think it's the minority. So in practice it's even more stable than it is in the headlines.
- Scea91 8y ago
  Strange, our production code is full of streams and lambdas. It probably depends on the type of product.
- euyyn 8y ago
  Chromium (and so Chrome too) uses lambdas in its Java parts.
- qw 8y ago
  I work for a large company and the code base is full of streams and lambdas. Streams are almost used too much and could be replaced with a simple for-loop.
  - ionised 8y ago
    Yeah, stream overuse is definitely an issue at our company.
- jcadam 8y ago
  I started using Streams and lambdas immediately, along with functional interfaces. Java is still not nearly as pleasant as Scala or Clojure, however.
- ionised 8y ago
  We start using new features pretty much as soon as the new JDK version is released to general use.
- astura 8y ago
  I started using them ASAP.
jaabe 8y ago
If you develop, not if you maintain. This is a major reason we stay away from JS frameworks after burning the hands on implementing an AngularJS that was obsolete a year later. That and a few page reloads never killed anyone.
- deleted 8y ago
  [deleted]
coldtea 8y ago
>java is a stable api but it also doesn't evolve You have probably missed the last 5 years. From streams, to closures, to default methods, to functional interfaces, to local type inference, to new Process APIs, to modules, to unsigned arithmetic, to new date/time APIs, http client, 2 new GCs, shell REPL, etc... with more to come, and new releases every 3 months...
- ptx 8y ago
  > unsigned arithmetic I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)? Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types. [0] https://kotlinlang.org/docs/reference/basic-types.html#unsigned-integers https://kotlinlang.org/docs/reference/basic-types.html#unsig...
  - coldtea 8y ago
    >I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)? Yes, but it's also a new feature (along with dozens of others). The complaint I answered was that Java is stagnant somehow, when it has been evolving fast in the last 5 years, and is accelerating its pace (release cadenze) even more. >Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types. Which, given that the JVM doesn't support them at the bytecode level (iirc), they also use some similar trick of working with signed numbers under the hood, just hide it better at the syntax level.

spricket 8y ago

One of my Java guilty pleasures is pulling in some 14 year old library and it just works. Absolute gold for a company with a lotta old code sitting around. I also do a good bit of frontend and holy crap it's exhausting. That's the main reason I push hard for Java backend. Backends tend to stick around about a decade longer than you would like, while front end code is due for a rewrite every 3 years

theandrewbailey 8y ago

> It's also a shame Sun sold Java to Oracle Worse: Oracle bought Sun.

pjmlp 8y ago
Worse: IBM, Google and everyone else could have done it as well, but decided not to counter-offer.

gigatexal 8y ago

Biggest barrier to entry for me is the build dependency system Maven. And I never understood Ant. I did like the language when I played around with Java 8. Streams are amazing.

BinaryIdiot 8y ago
Maven is an incredible system. It can do so much and yet, even though I've setup countless apps and services, I can never use it without looking literally everything up. Maven and spring are the worst parts, for me, when dealing with Java. I don't mind the language at all.
- gigatexal 8y ago
  Yeah I felt the same. The language is fine. It’s got a fantastic set of libraries and a large ecosystem and one would be hard pressed to not find a job being a competent Java dev but maven ugh
  - eitland 8y ago
    With maven, less is more. Huge maven files usually means something is wrong. Follow the conventions and it is less than a screenful for a basic project. I typically solved maven problems by removing cruft and falling back to the standards.
- thecleaner 8y ago
  What was your problem specifically ? For me these two worked great together actually. I really loved Spring. Maybe the problem has some overlooked fix that I can help with ?
  - BinaryIdiot 8y ago
    Nothing in particular just lots of seemingly random issues trying and failing to get them working correctly, likely due to my lack of knowledge but every time I try to better learn them my brain just can't handle it. I don't know what it is. I think part of it is my auto-cringe when I see XML nowadays.

tannhaeuser 8y ago

The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serving APIs (expressjs and core http request API, which expressjs middlewares forwards and decorates) is stable since node.js v0.1 or at least 2015, and infinitely better than Java's servlet, JSP, and taglib APIs (web.xml/jetty-config.xml anyone?). The flip side of Java's stability is stagnation. On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess. SWT? I'm glad it works for you. Last I heard, IBM had pulled out of developing Eclipse and SWT/RCP over ten years ago. In the one project where we used it, the app looked like an IDE, and customers hated, then cancelled it. Designed as wrappers for OS-native GUI controls, it has even less of a place in a browser than Swing had. Last I looked, of the Java rich-client frameworks, only Swing has been updated with HIDPI support, whereas JavaFX and SWT haven't. None is using any of those (with the exception of experimental JFX apps) for new apps in this decade.

vbsteven 8y ago
You can call Spring (boot) over-engineered. I call it feature full and extensible. Whereas in the modern JS world, you start out with a lean project and then add small libraries from NPM that all work slightly different for every feature you need, in the Spring world where the framework has matured for 10+ years most of the things you will need are in the box or are available as external libraries that all work on the same defined interfaces. Spring Boot with Java 11 or Kotlin are still my preferred backend stack for that reason. It’s solid, has aged well and makes me super productive.
- nickspacek 8y ago
  Actually they just said that Java's server-side stack is overengineered, and that Spring/Spring Boot hides that complexity. I think that is mostly true.
  - 8y ago

ksec 8y ago

>Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun. They didn't and Google didn't want a pay a single dollar to Sun on Java. As James Gosling has mentioned multiple times. I don't understand why people are still painting Google as Saint after all these years.

merb 8y ago
actually they didn't want to pay a single dollar to sun, because of licensing reasons, not because they didn't wanted to buy java. currently they recreated the java apis by pulling in apache harmony and they tought that they are in the right or at least in a fair use position (they still think they do). but I agree, I'm not sure if the direction of java would've been better when google would have the stewardship.
- pjmlp 8y ago
  They had the opportunity to buy Sun when it went on sale, instead they thought they could get away with it.

tobiaswk 8y ago

I love Dart and Flutter. I actually think it was a good idea not to use Java. Dart is much more modern and nice to work with in my opinion. There are many reason and I won't dwell into it here. The biggest-ish project I've built with Flutter is an alternative to Nissan's ConnectEV app; it's used with the electric vehicles Nissan Leaf and Nissan E-NV200. You can see statistics, battery status and control climate control and charging of your vehicle. My alternative is called "My Leaf" on the Play Store and "My Leaf for Nissan EV" on the App Store. It's completely open source; https://gitlab.com/tobiaswkjeldsen/carwingsflutter https://gitlab.com/tobiaswkjeldsen/carwingsflutter It consists of the main Flutter app and a Dart library for communicating with Nissan's API.

schwurb 8y ago
I am currently building my first mobile app on Flutter and quite happy I choose that technology! Developing in AndroidStudio + Flutter does not feel like the chore I remember developing android apps to be.

cztomsik 8y ago

The success of javascript is hugely because of no dependency-hell (not being able to upgrade some lib to a new version, because it would conflict with some other lib which requires it in its current version and you can't have both of them loaded at the same time)