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

51–60 of 84 posts

Re: Moving Java Forward Faster

#51

Post by flukus »

doodpants wrote: post #3

> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9. Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?

I'd be more worried about 0 padding the month, imagine the breakage an october release could cause.

Re: Moving Java Forward Faster

#52

Post by stickfigure »

dragonwriter wrote: post #27
jswizzy wrote: post #20

Earlier quoted context omitted.

FP and OOP are compatible styles. In fact, I would argue that FP is more object orientated than procedural code such as loops.

Not really; FP and OOP are dissimilar in their approach to mutable state and it's management, for instance. You can come up with a synthesis (or probably many different syntheses) of ideas from the two styles to make a style blending inspiration from each, but they aren't directly compatible, and most direct combinations mhave tension between the two styles, or directly subordinate one to the other, for that reason.

Nothing in OOP requires mutable state.

    Thing changedThing = oldThing.change();
When you start writing code like this, Java can be quite pleasant.

Re: Moving Java Forward Faster

#53

Post by sitepodmatt »

haglin wrote: post #26

This is a major change: "After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds " http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe... Java Flight Recorder will be open source.

To be honest I didn't even know what Java Flight Recorder was - and I've been doing Java, Clojure and Kotlin for a number of years. I don't see this being a major change for those that have always been on OpenJDK

Re: Moving Java Forward Faster

#54

Post by pjmlp »

sitepodmatt wrote: post #53
haglin wrote: post #26

This is a major change: "After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds " http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe... Java Flight Recorder will be open source.

To be honest I didn't even know what Java Flight Recorder was - and I've been doing Java, Clojure and Kotlin for a number of years. I don't see this being a major change for those that have always been on OpenJDK

I use Java since its introduction in 1996, never installed OpenJDK other than when it came by default on some random Linux distribution.

Java Flight Recorder and Visual VM are great tools, only matched by .NET ones to monitor application performance.

Re: Moving Java Forward Faster

#55

Post by 1ba9115454 »

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…

> Now what would be your estimate for the same system, but written in Kotlin? How about Scala?

Perhaps the same, but the code is going to be much safer.

I think that is something you've missed we want features in Java that let us write more reliable code. Otherwise we will migrate.

I'm already starting the process of migrating to Kotlin for any Java work and I'm learning Haskell for side projects.

Re: Moving Java Forward Faster

#56

Post by ivan_gammel »

saosebastiao wrote: post #50
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.

Last time I've had casting problem was when someone passed Scala Map to Freemarker. If it takes 4 extra months to debug NPEs, then someone still needs to learn how to code, because things that compiler can fix, experienced programmer should be able to do avoid at first place.

Re: Moving Java Forward Faster

#57

Post by pjmlp »

bitmapbrother wrote: post #31
haglin wrote: post #29

Earlier quoted context omitted.

Maybe Google should use openJDK instead of using their own proprietary version of Java. No one benefits of fragmentation.

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.

Here it comes again, the Google support team excuse for their Java fork!

The JVM is doing just fine controlling embedded devices in factories, printers and phones.

http://www.ricoh-developer.com/content/device-sdk-type-j-sdk...

https://www.aicas.com/cms/

https://developer.cisco.com/media/onePKGettingStarted-v1-1-0...

https://developer.gemalto.com/taxonomy/term/39/group/80?view...

http://www.gemalto.com/m2m

https://www.ptc.com/en/developer-tools/perc

http://www-03.ibm.com/software/products/bg/real-time

I just got bored to post links, there are many more I can keep on posting.

All from companies that used to work with Sun, nowadays with Oracle, without doing the forking game Google has done.

Re: Moving Java Forward Faster

#58

Post by pjmlp »

sk0g wrote: post #35
haglin wrote: post #33

Earlier quoted context omitted.

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.

And Google should spend their time and money improving Java, owned by a company that massively sued them?

Apparently the server team does exactly that!

Search for Google.

http://openjdk.java.net/projects/mlvm/jvmlangsummit/agenda.h...

http://openjdk.java.net/projects/mlvm/summit2014/agenda.html

Re: Moving Java Forward Faster

#59

Post by pjmlp »

bitmapbrother wrote: post #47
haglin wrote: post #33

Earlier quoted context omitted.

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…

LWAWT could be a start.

Then there are quite a few embedded device OEMs that don't have the same problems than Google has supporting standard Java, some of them targeting real time embedded devices.

Maybe Google should ask them how they manage to do it.

Re: Moving Java Forward Faster

#60

Post by jdmichal »

stickfigure wrote: post #52
dragonwriter wrote: post #27

Earlier quoted context omitted.

Not really; FP and OOP are dissimilar in their approach to mutable state and it's management, for instance. You can come up with a synthesis (or probably many different syntheses) of ideas from the two styles to make a style blending inspiration from each, but they aren't directly compatible, and most direct combinations mhave tension between the two styles, or directly subordinate one to the other, for that reason.

Nothing in OOP requires mutable state. Thing changedThing = oldThing.change(); When you start writing code like this, Java can be quite pleasant.

It's only very special circumstances where my POD types do not consist entirely of `final` fields. Though I usually skip defensive copying within PODs... One should know better than to trust values from random places. So I defensively copy at use time instead if I want to modify it.
Post reply on HN