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

71–80 of 84 posts

Re: Moving Java Forward Faster

#71

Post by eropple »

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.

Kotlin, Java's superior offspring, is even better, as the use of data classes provides an automatic implementation of a `copy` command. (Scala does too, but Scala also explodes when I look at it, so, enh.)

Re: Moving Java Forward Faster

#72

Post by bitmapbrother »

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…

Thanks Oracle support team lead and Oracle legal fund contributor, but I have to wonder if you even know what the actual definition of a fork is because there was no fork. So you're either being disingenuous or deliberately trying to construct a false narrative.

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

Here's a link on what forking is.

https://en.wikipedia.org/wiki/Fork_(software_development)

Re: Moving Java Forward Faster

#73

Post by bitmapbrother »

pjmlp wrote: post #67
geodel wrote: post #66

Earlier quoted context omitted.

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.

No, those Java phones don't exist because they were a failure. Court documents even revealed that Oracle gave up trying to build one.

Re: Moving Java Forward Faster

#74

Post by bitmapbrother »

pjmlp wrote: post #59
bitmapbrother wrote: post #47

Earlier quoted context omitted.

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.

Why would they waste their time when Sun/Oracle couldn't even figure it out to this day.

Re: Moving Java Forward Faster

#75

Post by SomeHacker44 »

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…

Common Lisp has moved forward exactly zero "officially" for decades. Yet, modern CL implementations are largely compatible with one another, largely interoperable with modern multicore hardware and multithreaded operating systems, largely capable of using Unicode and other representation formats, etc.

Of course, CL was designed with "extending CL" as a feature, and not locking the CL user into CL as it is "today." Shame so few other languages bother with this (Java and Clojure on the JVM come to mind immediately as hard to extend). Other languages have very active language evolution (Haskell/GHC comes to mind).

I like my languages to evolve. Preferably not the way Java did (I still hate the 1.5 type erasure hack).

Re: Moving Java Forward Faster

#76

Post by crumbles »

brianwawok wrote: post #69
crumbles wrote: post #46

Earlier quoted context omitted.

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

> Language greatness is pretty subjective and task specific. There are some languages I will never declare great

If greatness is subjective AND task specific, then the languages you will never declare great could be considered great by others for the tasks they perform. And by your own admission if they were great subjectively AND for a particular task, that would make those languages great. But, you still claim that you would never declare them great?

Re: Moving Java Forward Faster

#77

Post by pjmlp »

bitmapbrother wrote: post #74
pjmlp wrote: post #59

Earlier quoted context omitted.

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.

Why would they waste their time when Sun/Oracle couldn't even figure it out to this day.

Sun had it figured out and was even sponsoring SavaJe OS, but then Google ripped off their work and gave it away for free.

Re: Moving Java Forward Faster

#78

Post by pjmlp »

bitmapbrother wrote: post #73
pjmlp wrote: post #67

Earlier quoted context omitted.

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.

No, those Java phones don't exist because they were a failure. Court documents even revealed that Oracle gave up trying to build one.

A failure thanks to Google stealing Sun's work.

And in any case, market failure is not an excuse to steal someone's else work, by not licensing it like every other company was doing at the time, and still are.

Google is the only notable exception.

Re: Moving Java Forward Faster

#79

Post by pjmlp »

bitmapbrother wrote: post #72
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…

Thanks Oracle support team lead and Oracle legal fund contributor, but I have to wonder if you even know what the actual definition of a fork is because there was no fork. So you're either being disingenuous or deliberately trying to construct a false narrative. >I just got bored to post links, there are many more I can keep on posting. Here's a link on what forking is. https://en.wikipedia.org/wiki/Fork_(software_de…

If you feel I bother with your ad hominem attacks being called Oracle support team lead and Oracle legal fund contributor, you are wasting your time.

Actually now that you mention it, maybe I should add "Sun support team lead and Sun legal fund contributor" to my profile.

Google should be penalized just like Microsoft was, but sadly it is the love child of Silicon Valley wannabe Google employees, so they get a free pass while Microsoft was bashed to death.

Re: Moving Java Forward Faster

#80

Post by bitmapbrother »

pjmlp wrote: post #79
bitmapbrother wrote: post #72

Earlier quoted context omitted.

Thanks Oracle support team lead and Oracle legal fund contributor, but I have to wonder if you even know what the actual definition of a fork is because there was no fork. So you're either being disingenuous or deliberately trying to construct a false narrative. >I just got bored to post links, there are many more I can keep on posting. Here's a link on what forking is. https://en.wikipedia.org/wiki/Fork_(software_de…

If you feel I bother with your ad hominem attacks being called Oracle support team lead and Oracle legal fund contributor, you are wasting your time. Actually now that you mention it, maybe I should add "Sun support team lead and Sun legal fund contributor" to my profile. Google should be penalized just like Microsoft was, but sadly it is the love child of Silicon Valley wannabe Google employees, so they get a free p…

Ever hear the one about the pot calling the kettle black?

Google did nothing wrong with its use of 38 open source Java API header files. Neither did the juries that presided over the trials. What I do find troubling, however, is your improper use of the word "Fork", to describe what happened.

Post reply on HN