Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Future Java Might Look Like

blog.codefx.org

Post reply on HN
Print view View original

81–90 of 105 posts

Re: What Future Java Might Look Like

#81

Post by nradov »

xaduha wrote: post #67
nradov wrote: post #60

Earlier quoted context omitted.

I'm not convinced that's any better than specifying the language version as a compiler command line argument.

It's plenty better. You're saying on the source code level that it's not designed to be run by anything but an implementation of that specification version.

But in practice the language version is always specified in the build script which is bundled with the source code. In Java that's typically a Maven pom.xml file. So you only have to change it once per module rather than in every separate source code file. I see no particular advantage in specifying the language version in each and every file; those source code files aren't meant to stand on their own anyway.

Re: What Future Java Might Look Like

#82

Post by xaduha »

pjmlp wrote: post #79
xaduha wrote: post #75

Earlier quoted context omitted.

> Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. Not true. You're running bytecode, not Java. Compiled JVM languages benefit from JVM optimizations all the same. No one will actually 'kill' Java, it's about mindset of the users and companies. Kill Java = Give another JVM language a try. Oracle JVM isn't the only JVM implementation.

> Oracle JVM isn't the only JVM implementation. Quite true, but from Azul, IBM, HP, Jamaica, Aonix, Excelsior, Gamato,CodenameOne, ... who is interested in replacing Java (the language)?

First, JVM vendors have to conform to specifications, that's all. And introduction of invokedynamic and other stuff that makes it easier for other JVM languages to exist obviously means that they aren't against the idea.

All in all I'm for interoperation. "And", not "or". No one is forcing you to rewrite existing Java code.

Re: What Future Java Might Look Like

#83

Post by paulddraper »

sixbrx wrote: post #59
paulddraper wrote: post #56

Earlier quoted context omitted.

You can have local variables in the constructor. The discussion you linked to shows you how.

Which post # in the discussion did you have in mind? There's some misdirections in that thread with ideas that didn't survive the javap test (which I think rather makes my point). I may do Scala again in the future and would like to know how to avoid this (without factory methods as I mentioned). If you mean Paul P/extempore's self described "if you can handle a little perversion" method then - "no thanks", that's pr…

    class Rational(n: Int, d: Int) {
      require(d != 0)

      val (numer, denom) = {
        val g = gcd(n.abs, d.abs)
        (n / g, d / g)
      }

      // ...
      private def gcd(a: Int, b: Int) = if (b == 0) a else gcd(b, a % b)
    }
Now `g` is a local variable.

Re: What Future Java Might Look Like

#84

Post by TheGuyWhoCodes »

xaduha wrote: post #75
TheGuyWhoCodes wrote: post #72

Earlier quoted context omitted.

Well that's just your opinion, I think java is pretty nice with Java8. When you see someone say let's kill Java what does that mean for the JVM? Because Oracle will not say ya cool let's just focus on other languages running on the JVM like kotlin and Scala and drop java all together. Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. I think it's good tha…

> Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. Not true. You're running bytecode, not Java. Compiled JVM languages benefit from JVM optimizations all the same. No one will actually 'kill' Java, it's about mindset of the users and companies. Kill Java = Give another JVM language a try. Oracle JVM isn't the only JVM implementation.

If we take Scala for example that's only true if you write Java-like Scala code and what's the point of that?

Once you go deep with Scala magic it goes downhill, but prob. 80% as fast.

I think Java and other JVM languages can co-exist nicely, depending on the task at hand, there is no "need" to kill anything, I wish you could mix and match code from different JVM languages easily.

Re: What Future Java Might Look Like

#85

Post by xaduha »

nradov wrote: post #81
xaduha wrote: post #67

Earlier quoted context omitted.

It's plenty better. You're saying on the source code level that it's not designed to be run by anything but an implementation of that specification version.

But in practice the language version is always specified in the build script which is bundled with the source code. In Java that's typically a Maven pom.xml file. So you only have to change it once per module rather than in every separate source code file. I see no particular advantage in specifying the language version in each and every file; those source code files aren't meant to stand on their own anyway.

The point is to remove obstacles that prevent you from introducing backward incompatible changes into the language, obstacles than prevent your language from evolving. Implementations can support several specifications of the language, you can keep those source code files as is or you can mix them. You can take advantage of new features in new files, but keep everything else working.

Imagine you updated your pom file and bunch of stuff stopped working. If it's easy enough to fix you do it, if not you might just revert pom changes and stay with older version of the language, module or whatever. That wouldn't happen with versioned specification languages.

> I see no particular advantage in specifying the language version in each and every file

You obviously stuck with this mindset and not thinking about it hard enough.

Re: What Future Java Might Look Like

#86

Post by jpitz »

overgard wrote: post #62
matrix wrote: post #26

While these would be welcome improvements to Java, the future of Java is not about these sorts of tweaks. What Java really needs to revitalize their ecosystem is a sustained focus on improving developer experience with modern applications. That means elevating languages like Kotlin and Clojure, and producing modern libraries for basic web development so that there's a foundation of high quality components that people…

Its weird how far java has fallen behind C# (especially given that C# was, to put it kindly, originally just basically "microsoft java".) It would seem like Oracle could just follow the blueprint, so I'm sort of surprised they haven't

The falling-behind happened early, and fast. MS took full advantage of second-mover status to change fast and add features. They also targeted fewer platforms initially.

While the market niche was certainly aimed squarely at the same demographic as Java users, the language owes as least as much to Borland Object Pascal as it does to Java.

Speaking of Object Pascal, MS also got Anders Hejlsburg to design it.

Oracle/Sun, stuck with a huge, conservative enterprise user base, was shackled by backwards compatibility.

In hindsight, I don't think it weird that Java fell behind the way it did.

Re: What Future Java Might Look Like

#87

Post by unclebucknasty »

rootlocus wrote: post #76
unclebucknasty wrote: post #61

Earlier quoted context omitted.

A pg dictum is a de facto "guideline" here. That's pretty well understood. Not sure why you think it's valuable to try parsing a distinction. I don't think anyone is suggesting that guidelines are designed to help people get upvotes. In fact, my comment wasn't about upvotes at all, but how encouragement to downvote for disagreement undermines constructive discussion and contradicts the GP's guideline-citing assertion…

> A pg dictum is a de facto "guideline" here. That's pretty well understood. Not sure why you think it's valuable to try parsing a distinction. Perhaps. However, since not everyone has read every comment pg ever made, it's safe to say only what's written in the guidelines is supposed to be common knowledge and easily available for reference. > effectively: "make well-reasoned arguments with which everyone can agree."…

>it's safe to say only what's written in the guidelines is supposed to be common knowledge

And, yet, you immediately trotted out the dictum on this thread, as have so many before you. I mean, c'mon. Stop it. It's common knowledge around here.

>They don't say "make arguments with which everyone can agree"

Greenlighting the use of downvotes to express disagreement does exactly this. Not even sure why you think there's an argument to be made otherwise. If you want your comment to be read, instead of literally faded into oblivion as the result of downvotes, then you'd better be sure it's somewhat in agreement with the community.

>It was your own deduction...

Sure was, and it didn't take much effort to deduce it. In fact, I would say no effort. It was just lying there to trip over. OTOH, the entirety of your argument seems to rest on the willful denial of the obvious.

Re: What Future Java Might Look Like

#88

Post by xaduha »

TheGuyWhoCodes wrote: post #84
xaduha wrote: post #75

Earlier quoted context omitted.

> Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. Not true. You're running bytecode, not Java. Compiled JVM languages benefit from JVM optimizations all the same. No one will actually 'kill' Java, it's about mindset of the users and companies. Kill Java = Give another JVM language a try. Oracle JVM isn't the only JVM implementation.

If we take Scala for example that's only true if you write Java-like Scala code and what's the point of that? Once you go deep with Scala magic it goes downhill, but prob. 80% as fast. I think Java and other JVM languages can co-exist nicely, depending on the task at hand, there is no "need" to kill anything, I wish you could mix and match code from different JVM languages easily.

Kotlin solves what Scala didn't. Great Java interop, first class IDE support, easier to get into. Whichever way you look at it Kotlin code is nicer than Java, even if written Java-like.

Re: What Future Java Might Look Like

#89

Post by unclebucknasty »

odabaxok wrote: post #43
unclebucknasty wrote: post #37

Earlier quoted context omitted.

> It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning Not strictly. The guidelines encourage people to start conversation with reasoning, but also encourage people to downvote for disagreeing. So, there's some dissonance in there as it says, effectively: "make well-reasoned arguments with which everyone can agree."

We are going OT here, but one last comment in this thread to clarify what I meant. Putting a comment saying just "Just another vile article", without any thoughts about why it is vile, is just completely against the guidelines (from the points mentioned in my previous comment). Even if you agree with its content or not. Also, I do not believe the guidelines encourage people to down-vote for disagreeing (or at-least f…

>Putting a comment saying just "Just another vile article", without any thoughts about why it is vile

I agree that it doesn't add to the discussion, which might be a good reason for downvoting (i.e. as a form of "quality control"). OTOH, if you happen to agree with the statement, then the ethos is that it's cool to upvote it on that basis alone. Yet, it still adds no more to the discussion.

My overall point is that agreement/disagreement as a basis for surfacing (or submerging) people's comments/ideas is a poor choice in either direction, if it's stimulating, challenging discussion we want.

>I have never tried it, still under 500 karma..

Meh. It's overrated. Can't even remember the last time I downvoted a comment (as you might've guessed) :)

Re: What Future Java Might Look Like

#90

Post by sixbrx »

paulddraper wrote: post #83
sixbrx wrote: post #59

Earlier quoted context omitted.

Which post # in the discussion did you have in mind? There's some misdirections in that thread with ideas that didn't survive the javap test (which I think rather makes my point). I may do Scala again in the future and would like to know how to avoid this (without factory methods as I mentioned). If you mean Paul P/extempore's self described "if you can handle a little perversion" method then - "no thanks", that's pr…

class Rational(n: Int, d: Int) { require(d != 0) val (numer, denom) = { val g = gcd(n.abs, d.abs) (n / g, d / g) } // ... private def gcd(a: Int, b: Int) = if (b == 0) a else gcd(b, a % b) } Now `g` is a local variable.

As discussed in the thread, that doesn't work given that we're trying to avoid extra storage, it adds an extra tuple member to the class. It's still true as of the latest compiler just like it was in 2009:

    $ scalac -version
    Scala compiler version 2.12.1 -- Copyright 2002-2016, LAMP/EPFL and Lightbend, Inc.

    $ javap -private Rational
    Compiled from "Rational.scala"

    public class Rational {
      private final scala.Tuple2 x$1;
      private final int numer;
      private final int denom;
      public int numer();
      public int denom();
      private int gcd(int, int);
      public Rational(int, int);
    }
Post reply on HN