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

Moving Java Forward Faster

mreinhold.org

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Moving Java Forward Faster

#41

Post by Latty »

pents90 wrote: post #40

This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and…

I think that good languages offer features that make your code better, not let you write it faster.

Sure, it may take me two months to write that thing in Scala still, but I'll have more confidence it will work well, and it'll be nicer to read, maintain and work with moving forward.

Scala is an interesting example for this, because the language is a grab-bag of features that definitely can be abused by people who don't know better, it's definitely easy to write worse code in it.

The reality is there is an easy blueprint for Java, because C# is Java, but done better. It's moving at a good clip, but the features coming in are very useful and well thought out.

Re: Moving Java Forward Faster

#42

Post by maxxxxx »

theandrewbailey wrote: post #36
maxxxxx wrote: post #24

Earlier quoted context omitted.

It will mess up sorting. I agree with the suggestion. There really is no good reason why they wouldn't use yyyy.

How will it mess up sorting? So long as each release has a number greater than the last, they can be sorted properly. Don't ASCII sort. https://blog.codinghorror.com/sorting-for-humans-natural-sor...

Sure you can be careful. But why not add the 2 characters and be sure?

Re: Moving Java Forward Faster

#43

Post by filereaper »

pents90 wrote: post #40

This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and…

Brian Goetz the Java Language Architect addressed the very points you raised in a talk called "Stewardship: the Sobering Parts" [1]

I highly recommend anyone with these very valid concerns to view it once.

[1] https://www.youtube.com/watch?v=2y5Pv4yN0b0

Re: Moving Java Forward Faster

#44

Post by xienze »

haglin wrote: post #33
bitmapbrother wrote: post #31

Earlier quoted context omitted.

As of Android 7 they do use the OpenJDK. If you're implying that they should replace the Android SDK/ART with OpenJDK/JVM then that would be foolish. The OpenJDK and JVM were never designed to work within the constraints of embedded mobile devices.

Why can't Google submit patches to make it work for embedded devices? I don't see the point of a separate version of Java. Imagine if you could develop Android apps against the latest version of Java.

I think it's more of a legal/licensing move than a technical challenge. You write and compile Java but then it's translated to bytecode for a different VM (Dalvik, I presume this is still the case though I hear there's additional native compilation that occurs now). Net result, developers get to write Java but Google doesn't have to pay royalties for a proper VM on every device.

Re: Moving Java Forward Faster

#45

Post by orangecat »

newforice wrote: post #14
callinyouin wrote: post #8

Earlier quoted context omitted.

I can't tell if you're being sarcastic, but I'm guessing you aren't. Anyway, from a full time Java developer's perspective, lambdas and the FP stuff added to Java 8 have sort of been a holy grail. Filtering with streams have single-handedly made my life as a developer measurably easier, but then again I'm a back-end web dev so it comes up a lot. If you're a Java developer, I'd strongly recommend going back and trying…

You seem to have jumped to the conclusion that I haven't tried the FP features. If I hadn't tried them, I wouldn't be criticizing them. If I wanted to work in FP style, I would choose an FP language; not encourage a traditional, solid language to be perverted to do something that is completely against the nature and design of that language.

Yes, adding lambdas to Java is as silly as adding function pointers to C.

Re: Moving Java Forward Faster

#46

Post by crumbles »

Latty wrote: post #41
pents90 wrote: post #40

This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and…

I think that good languages offer features that make your code better, not let you write it faster. Sure, it may take me two months to write that thing in Scala still, but I'll have more confidence it will work well, and it'll be nicer to read, maintain and work with moving forward. Scala is an interesting example for this, because the language is a grab-bag of features that definitely can be abused by people who don…

> I think that good languages offer features that make your code better, not let you write it faster.

And great languages let you do both.

Re: Moving Java Forward Faster

#47

Post by bitmapbrother »

haglin wrote: post #33
bitmapbrother wrote: post #31

Earlier quoted context omitted.

As of Android 7 they do use the OpenJDK. If you're implying that they should replace the Android SDK/ART with OpenJDK/JVM then that would be foolish. The OpenJDK and JVM were never designed to work within the constraints of embedded mobile devices.

Why can't Google submit patches to make it work for embedded devices? I don't see the point of a separate version of Java. Imagine if you could develop Android apps against the latest version of Java.

What would you use to build the UI for your app? AWT? Swing? JavaFX? There is also the issue of all of the Android specific SDK code that would probably never be applicable for cross platform reuse. And then there's the JVM which would also probably require massive changes to adhere to Android's VM requirements (as it stands right now, ART and the JVM aren't even in the same architectural ballpark as one is register based and the other is stack based). The level of resistance to these changes would introduce would also be a major issue and more so than the friction Google faces when trying to upstream Android related changes to the Linux kernel.

Incidentally, there's a project called OpenJDK Mobile[1] on the OpenJDK project site that aims to port the OpenJDK to popular mobile platforms. Not sure where they're at with it, but it seems to be a WIP.

[1]http://openjdk.java.net/projects/mobile/

Re: Moving Java Forward Faster

#48

Post by linuxhansl »

+1000

We did this (at a much smaller scale) with Apache HBase (starting at 0.94, which I release-managed). We went to a monthly release cadence.

We saw the frantic last minute commits just before a release (and followed by multiple smaller releases just after the big release to stabilize the code base) essentially vanish. If the feature wasn't done, it simply got in a month later.

For us it required an "transitive compatibility" (i.e. one can go from version X to version X+3 without upgrading to X+1 and X+2 first), and stable functional tests, so that confidence in a release is automatic and does not need to be established manually.

Re: Moving Java Forward Faster

#49

Post by x0x0 »

Latty wrote: post #41
pents90 wrote: post #40

This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and…

I think that good languages offer features that make your code better, not let you write it faster. Sure, it may take me two months to write that thing in Scala still, but I'll have more confidence it will work well, and it'll be nicer to read, maintain and work with moving forward. Scala is an interesting example for this, because the language is a grab-bag of features that definitely can be abused by people who don…

Not to mention the implicit dismissal of developer happiness. That's one of the best things about the ruby and rails communities: why shouldn't our tools be nice to use? Kotlin has (imo) that same attitude as compared to java.

Re: Moving Java Forward Faster

#50

Post by saosebastiao »

pents90 wrote: post #40

This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and…

> Admit that it would be the same.

Sorry, can't do that. If my estimate was 2 months in Scala, it would be 6 months in Java: 2 to write the software, and 4 to find and chase down all the NPEs, casting exceptions, and concurrency bugs, while building a test kit for things the scala compiler already verified the moment my scala code compiled.

Post reply on HN