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

Negotiations Failed: How Oracle Killed Java EE

headcrashing.wordpress.com

Post reply on HN
Print view View original

291–300 of 526 posts

Re: Negotiations Failed: How Oracle Killed Java EE

#291

Post by mlpinit »

tcptomato wrote: post #224
ChuckNorris89 wrote: post #131

Earlier quoted context omitted.

Hungary and Poland aren't the first to abuse the unanimous-1 veto. The Netherlands always vetos Romania's application to enter the Schengen zone as Romania's harbors to the Black Sea will provide cheaper alternatives for import of goods to the Dutch ones.

Right, a port at the other end of Europe without good connections to the West, whose usage maybe makes sense only for ships passing through the Suez and Bosporus is a competitor to the ones sitting on the Atlantic. And it doesn't have anything to do with the fact that the Romanian coastal surveillance system was conveniently down when cocaine started to shop up on the beaches.

I'm not sure about the merits of the original claim, but you can't dismiss the Suez like that. It's the connection you need between the Mediterranean Sea and the Indian Ocean and it lends itself to a ton of traffic: https://www.marinetraffic.com/en/ais/home/centerx:32.2/cente...

Re: Negotiations Failed: How Oracle Killed Java EE

#292

Post by oaiey »

realusername wrote: post #190
oaiey wrote: post #163

Earlier quoted context omitted.

That is not Enterprise Software. It is less the language and the frameworks which are making it Enterprise but the requirements placed on them and the software development lifecycles. Imagine you do a medical product and the regulations needed for FDA approval require you to check for vulnerabilities in your product and build infrastructure. Have you ever checked all packages in a npm dependency tree for vulnerabilit…

> Imagine you do a medical product and the regulations needed for FDA approval require you to check for vulnerabilities in your product and build infrastructure. Have you ever checked all packages in a npm dependency tree for vulnerabilities? The same way as any other language? With audits? I don't get your comment.

To write the same functionality I need 10x the packages (from 9x vendors) in JavaScript compared to a Java/.NET ecosystems. The infamous left-pad packages is a sample for something found in the base class libraries of the other languages. And this does not only stand true for vulnerability analysis but also for other analyze jobs like for licenses or gdpr compliance. The amount of work is just higher with the amount of packages you use.

Re: Negotiations Failed: How Oracle Killed Java EE

#293

Post by erik_seaberg »

sonnyblarney wrote: post #254
dtech wrote: post #52

Earlier quoted context omitted.

Too little too late, and I highly doubt that (5-year-old) Valhalla will deliver even one of the promised features (value types) in the next 3 years. Remember that the original plan was to have all Valhalla features in Java 10. Java/JVM was in the ideal position to dominate the software world for the whole 21th century 15 years ago. Instead they did an IE6 and stagnated for so long that their competitors became plain…

"LLVM and webassembly are eating JVM's cake," > webassembly is not eating any cake. And C++ is still around, and one of the top choices, despite 25 years of other languages chipping away at it. Java is very mature, it doesn't need to evolve a whole lot - and most everything you need is there. Oracle is definitely a risk to this, but I don't see TS/JS/Node taking over. Kotlin is a strategic choice by Google due to Ora…

Kotlin for JVM has a lot of potential. It takes a lot of the pointless busywork out of Java (this is Go's problem), yet the median hiring candidate can probably handle it (this is Scala's problem) and you don't sacrifice decades of library coverage.

Re: Negotiations Failed: How Oracle Killed Java EE

#294

Post by sonnyblarney »

erik_seaberg wrote: post #293
sonnyblarney wrote: post #254

Earlier quoted context omitted.

"LLVM and webassembly are eating JVM's cake," > webassembly is not eating any cake. And C++ is still around, and one of the top choices, despite 25 years of other languages chipping away at it. Java is very mature, it doesn't need to evolve a whole lot - and most everything you need is there. Oracle is definitely a risk to this, but I don't see TS/JS/Node taking over. Kotlin is a strategic choice by Google due to Ora…

Kotlin for JVM has a lot of potential. It takes a lot of the pointless busywork out of Java (this is Go's problem), yet the median hiring candidate can probably handle it (this is Scala's problem) and you don't sacrifice decades of library coverage.

Kotlin is nice, but to me it's mostly just 'different', not necessarily an 'advantage'.

Without Android adoption (and G did this specifically because of Oracle issues) I don't think anyone would really be using it. Outside of Android, it's not a big thing.

I've gone Java to Kotlin and back again simply because the few advantages to Kotlin just aren't worth the phase shift. FYI almost every single code example in Android has Kotlin and Java the same length. It's not really any shorter or more concise in the end.

I wish Kotlin well, and it's a great example of how the JVM can be leveraged.

The JVM is probably Java's greatest foundational asset, which is why Graal has such potential, if Oracle doesn't screw it up ...

Re: Negotiations Failed: How Oracle Killed Java EE

#295

Post by coldtea »

scarface74 wrote: post #200
coldtea wrote: post #194

Earlier quoted context omitted.

> Because development that happened in 1994 is really relevant today. 1994? We still depend on tons of features, infrastructure, and techniques developed in the 60s and 70s. Heck, most of what the JS world considers "state of the art" was already available in 70s languages. As for the snark, first, the innovations the parents refers to is not "JavaBeans, Java Server Pages, and Java Server Faces", but stuff like rock-…

The contention was that other languages had a “lot to catch up” with Java because it’s been around for 25 years. So how haven’t other statically typed languages “caught up”? In fact, Java is so far behind C# with true Generics, LINQ - not the syntax the entire linq expressions -> expression trees -> runtime providers that can parse the trees and translate it to a destination syntax, etc. it’s laughable. Can anyone sa…

>In fact, Java is so far behind C# with true Generics

It's not "true Generics" it's a different generics tradeoff (tradeoff not just for backwards compatibility sake).

And LINQ is not that important in the grand scheme of things. Are Haskell, CL, or Smalltak also "far behind" C# for not having LINQ? It's just another feature. You can most of the same things with a fluent interface, streams, and functional composition, and without straying off the regular syntax of the language into a LINQ DSL.

Besides, last time I've checked, Java still has the performance edge over C#.

Re: Negotiations Failed: How Oracle Killed Java EE

#296

Post by erik_seaberg »

pjmlp wrote: post #50
realusername wrote: post #48

Earlier quoted context omitted.

I would not go as far to say it's dying but it's heavily slowing down for sure. First because of the big move out of the "entreprise" software and secondly because of Oracle legal team. It's definitely due to the licensing that Android is switching to Kotlin for example.

Except that Kotlin still lags behind Java compiler speed and it is heavily dependent on Java libraries.

Compiler speed is a fantastic tradeoff. I'm made of meat that runs at maybe 0.0001 MHz after coffee, so I want to offload anything I can to the compiler!

Re: Negotiations Failed: How Oracle Killed Java EE

#297

Post by coldtea »

scarface74 wrote: post #248
BoyRobot777 wrote: post #241

Earlier quoted context omitted.

F# does not have higher kinded types, because of CLR. So no, they don't manage "work around" generics. Regarding measurements: https://www.techempower.com/benchmarks/ Also, I am very interested to see new benchmark results once AOT SubstrateVM will be more widely adopted in JVM community. Demo: https://youtu.be/MN6jNIwl2FQ?t=1136 RedHat already working on a framework which takes full benefit of that: https://quarkus.…

And the only person who is saying that is so (with a lot of people disagreeing) is someone who “work[s] at Oracle on VM research”

Well, I agree, and I don't work at Oracle. So? Any other conspiracy theories?

Re: Negotiations Failed: How Oracle Killed Java EE

#298

Post by coldtea »

scarface74 wrote: post #250
pjmlp wrote: post #236

Earlier quoted context omitted.

Good luck running C# on the 100% OSes and hardware that runs Java VS97 better than Eclipse, without additional plugins? Alternative universe.

Eclipse was slow and had the usual non native Java smell that all cross platform GUIs have - especially on computers back then. But even now, Eclipse is sluggish compared to Visual Studio.

>Eclipse was slow and had the usual non native Java smell that all cross platform GUIs have

Actually Eclipse used a native GUI toolkit (Standard Widget Toolkit), backed by native widgets plus a few custom draw ones (like 100% native apps also resort to for custom stuff).

So, if it smelled "non Native", it wasn't because of Java.

Re: Negotiations Failed: How Oracle Killed Java EE

#299

Post by lanstin »

simonw wrote: post #88
fmhul wrote: post #65

Earlier quoted context omitted.

You'll always need more performance so you'll end up rewriting big parts of the codebase in C because you can't afford the servers and/or can't scale anymore. You'll be kicking the can down the road again and again. Also C is hard. At that point you will realise using Python was a stupid idea when you had other options like Go. It has happened to many people.

I don't think I've ever seen a commercial Python codebase that actually did rewrite things in C for speed. Much more likely is using a library like NumPy where someone else has done that C performance work for you. Plus in 2019, it's much cheaper to design for horizontal scale and spin up a few more instances.

I have personally rewitten a number of expensive inner loops into C to make Python be less slow. It is easy (if you find it hard Go wont be an option for you). I would say the argument against Python is not raw speed but concurrency model. I use gevent for io bouns studf but going multi CPU with data sharing is hard for the engineer and slow for the code compared to Go and goroutines. Subprocesses are ok and sending data over sockets is ok but serialization several times is sucky. Worse than extra memcpy. Also one big msg can block your interpreter.

Re: Negotiations Failed: How Oracle Killed Java EE

#300

Post by scarface74 »

coldtea wrote: post #295
scarface74 wrote: post #200

Earlier quoted context omitted.

The contention was that other languages had a “lot to catch up” with Java because it’s been around for 25 years. So how haven’t other statically typed languages “caught up”? In fact, Java is so far behind C# with true Generics, LINQ - not the syntax the entire linq expressions -> expression trees -> runtime providers that can parse the trees and translate it to a destination syntax, etc. it’s laughable. Can anyone sa…

> In fact, Java is so far behind C# with true Generics It's not "true Generics" it's a different generics tradeoff (tradeoff not just for backwards compatibility sake). And LINQ is not that important in the grand scheme of things. Are Haskell, CL, or Smalltak also "far behind" C# for not having LINQ? It's just another feature. You can most of the same things with a fluent interface, streams, and functional compositio…

LINQ itself is a big deal because of what it enables.

A simple LINQ expression can be passed around an translated on the fly by various providers. The same expressions can be translated to Sql, Mongo, regular IL, etc.

And no LINQ isn’t just syntax.

Last time I checked neither SmallTalk or Haskell are taking the world by storm...

Haven’t Java proponents been claiming Java was going to be fast for over two decades?

Post reply on HN