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

61–70 of 84 posts

Re: Moving Java Forward Faster

#61

Post by jdmichal »

eropple wrote: post #28
newforice wrote: post #14

Earlier quoted context omitted.

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.

Please explain how "I don't have to init an ArrayList and add to it manually" is such a heaven-forfend perversion of that traditional, solid language .

To be fair, the implementation of Streams within Java is certainly filled with ugly boilerplate compared to LINQ in C#. But that's no reason to criticize their mere existence.

Re: Moving Java Forward Faster

#62

Post by goatlover »

greydius wrote: post #39
fauigerzigerk wrote: post #11

Earlier quoted context omitted.

Imagine the shock when our descendents wake up on Jan 1 2118 and all their systems are accidentially running on a 100 year old JVM :)

I just had the horrible realization that java will still exist in 2118.

They'll be running the JVM in a Docker container in Linux written in JS in the browser compiled to web assembly running on a Rust WebOS. But it will be okay, because it the hardware will be a 1024 core quantum processor.

Re: Moving Java Forward Faster

#63

Post by karianna »

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.

This is actually a huge change for operations / devops. JFR is the only tooling out there today that can accurately and safely gather important performance metrics from the JVM in a low impact manner. All other APM vendors like ourselves (jClarity) have to perform hacks of some sort to try and emulate JFR's capabilities. This high quality data source is something that our engineering team is very excited to have opened up!

Re: Moving Java Forward Faster

#64

Post by karianna »

Hi All,

I represent the London Java Community (LJC) on the Java Community Process (JCP) Executive Committee (EC), aka the Java standards body. I also help run the Adopt OpenJDK programme for OpenJDK outreach and onboarding new developers to work on Java itself.

Now that the acronyms are out of the way :-). We're working at the JCP with Oracle to streamline the standardisation process in order to facilitate these faster releases and provide other Java vendors the ability to run their reference implementations against an in flight Technical Compatibility Kit (TCK), which is what you need to pass in order to call yourself Java.

I'm really, really pleased that Oracle is increasing the cadence. Java 9 allows for incubation modules and so if something isn't ready, it can simply be put in there for early testing without it impacting the main release.

Some folks asked about alternative platforms. In terms of providing high quality releases of OpenJDK for alternative platforms we've created a portal at https://www.adoptopenjdk.net with the build farm run via https://ci.adoptopenjdk.net (code in various repos at https://www.github.com/AdoptOpenJDK). We've only just received the Java Test Compatibility Kit J(TCK) from Oracle and once we have the binaries tested against that then folks will be able to get the latest OpenJDK binaries for all of the esoteric platforms (ARM, z360, AMD variants, AIX, Solaris and so forth).

We'd love for folks with devops skills to come and join us (Docker, IaaS, Jenkins, make skills welcome).

If you have any specific questions please throw them my way!

Re: Moving Java Forward Faster

#65

Post by saosebastiao »

ivan_gammel wrote: post #56
saosebastiao wrote: post #50

Earlier quoted context omitted.

> 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.

That's what I hear. I personally think it's a shame that we have to live through years of terrible bugs in terrible languages just to become an experienced programmer that can finally know how to always avoid those mistakes in the first place.

If you're already there, great. I applaud your superior experience, and hope you really enjoy your C++ footguns. But don't tell me that the scala compiler doesn't have value to me just because you're a code god and don't need it. I actually benefit from languages that help me avoid stupid mistakes.

Re: Moving Java Forward Faster

#66

Post by geodel »

pjmlp wrote: post #57
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.

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://ww…

Well if Java on phone is really fine then Google's pathetic attempts at Android should not matter as billions will keep buying those great Oracle certified Java phones.

Re: Moving Java Forward Faster

#67

Post by pjmlp »

geodel wrote: post #66
pjmlp wrote: post #57

Earlier quoted context omitted.

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://ww…

Well if Java on phone is really fine then Google's pathetic attempts at Android should not matter as billions will keep buying those great Oracle certified Java phones.

Those versions don't exist anymore because the way Google ripped off Sun and offered a gratis version to OEMs and carriers.

Nothing to do with technical capabilities, rather money.

And lets not forget that also helped Oracle getting Sun.

If it was Microsoft, Apple, everyone would have bashed them, but it is Google, so it is fine.

Re: Moving Java Forward Faster

#68

Post by mreinhold »

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 agree with what you say about language evolution, but this proposal isn't just about the language—it’s also about APIs, tools, and implementation-specific features (e.g., JITs and GCs), which can evolve more flexibly than the language itself.

Re: Moving Java Forward Faster

#69

Post by brianwawok »

crumbles wrote: post #46
Latty wrote: post #41

Earlier quoted context omitted.

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.

And what do you define as a great language?

Language greatness is pretty subjective and task specific. There are some languages I will never declare great (i.e. PHP, JavaScript, Ruby), but others could be great for different tasks..

Re: Moving Java Forward Faster

#70

Post by s73ver_ »

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?

Yes. I don't care about their petty squabble. As an Android dev, I'm sick and tired of not being able to use things because Google thinks they're special.
Post reply on HN