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

Java Is Underhyped

jackson.sh

Post reply on HN
Print view View original

591–600 of 808 posts

Re: Java Is Underhyped

#591

Post by Retric »

relaxing wrote: post #572
Retric wrote: post #482

Earlier quoted context omitted.

It’s surprisingly rare for things to split like that. At most companies people will be more skilled at front end or back end work, but it’s rarely a clean separation with front end vs back end teams. That’s an outgrowth of most projects being quite small. Paying a team or 20+ people to work on one thing is freaking expensive to the point where it needs major benefit or huge company to be worth it. On the other hand m…

Those are pretty strong assertions with no statistics to back them up. It doesn’t reflect the ecosystem I work in. I think you underestimate the number of huge companies that see major benefit from large teams working large development efforts.

I don’t know where you would even look for that kind of statistics for companies that might use Java. That said, America has:

1,829,875 companies with 5-9 employees 779,922 companies with 10-19 employees 467,634 companies with 20 - 49 employees 170,749 companies with 50 - 99 employees

Of that a few are pure software companies, but it’s far more common to want to automate something. Which often means outsourcing it, but then they simply can’t afford these kinds of large projects.

At the other end only 23,553 companies have 1,000+ employees. Yet even at that scale it’s not guaranteed to have large development teams in house, a single hospital can have 1000+ employees and use mostly 3rd party software with a few generalists to stitch everything together.

Re: Java Is Underhyped

#592

Post by dragonwriter »

doctor_eval wrote: post #322
dragonwriter wrote: post #215

Earlier quoted context omitted.

> I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language. The Factory pattern’s pervasive use in Java was in large part a fairly direct consequence of JavaBeans requiring nullary constructors, so that the normal constructor work for a Bean had to be done elsewhere, i.e., by a Factory. Now, Beans was just a…

I’m not going to say you’re wrong because you are probably right :) but I don’t remember things happening in that order. JavaBeans was a super early Java spec and it introduced some (IMO) poor idioms, such as the mandate to use getters/setters. And I certainly agree that JavaBeans had a huge influence over the rest of Java culture (for the worse IMO). But my memory is that pervasive use of Factories came along many y…

> And I thought the factory pattern itself came from the GoF, but I might be misremembering.

It did, and GoF certainly influenced OOP outside of Java, too. But EJB created a need into which the Factory pattern was really the only solution. (GoF precedes EJB and even Java.)

But certainly its not the only thing; Java hit popularity right around the time GoF was most influential; OOP languages whose ecosystems developed earlier (e.g., C++) or later (e.g., C#, though GoF-heavy code isn’t unheard of there) wouldn’t be as influenced by it, all things being equal. Java just had the perfect combination of language features, early specs like JEE (which included Beans), and timing to be naturally inclined for maximum naive GoFism.

Re: Java Is Underhyped

#593

Post by qayxc »

jerven wrote: post #504
qayxc wrote: post #309

Earlier quoted context omitted.

> C++ chances that I can compile code from 2000 without issues is minuscule. Really? I have code from the late 90ies and it compiles just fine. Do you perhaps mean dependencies? Because the issue there is the completeness of the framework and libraries around Java rather than the language itself.

Yes, the C++ dependencies are unlikely to be available. Specifically dependencies on OS libraries that are just not available on current common systems. So you need to get them but they are not available anymore and may depend on code that doesn't compile anymore. Due to e.g. 32bit assumptions, changes in what a 'long long' means and small hiccups like that. Or the fact that C++ code was "almost" C++ code and not act…

> Specifically dependencies on OS libraries that are just not available on current common systems.

But again, that's a problem with the OS, not a problem with C++. POSIX compliant code still compiles just fine on POSIX-compliant platforms and 32-bit code compiles just fine with 32-bit compilers as well - nothing changed in that regard. It's a similar story with other APIs such as Win32.

> Due to e.g. 32bit assumptions, changes in what a 'long long' means and small hiccups like that.

If you try to compile 32-bit code as 64-bit code you're porting, not recompiling. You can also just specify -std=c++98 (with g++) or just use an old compiler.

In my experience the problems with Java code are just as annoying, but those problems don't come from within the language itself either.

Things that weren't natively available had to be added via external scripts, application servers, native libraries, etc. And getting a fragile jumbled mess to work that relied on a specific Tomcat server version, command line scripts, external libraries or - god forbid! - certificates, was a major PITA as well.

Even today trying to get something as simple as SSL certificates working with Java can be frustrating. Why? Because for some reason Java insists on keeping its own keystore because it's the JDK that decides which authorities are to be trusted - not the user, not the OS, only the JDK.

Well, one of the installed versions, which gets to be real fun if you're working with containers, but I digress...

Re: Java Is Underhyped

#594

Post by jcadam »

blacktriangle wrote: post #587
alcidesfonseca wrote: post #559

Earlier quoted context omitted.

Oracle suited Google for copying the APIs (not the implementation) of the Java standard APIs. It all started in 2010 [0] Kotlin was Google's backup if the suit went Oracle's way. [0] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_... .

I guess given the recent court ruling we should see if Google sticks with Kotlin as a hedge, sticks with Kotlin because the community has embraced it, or pulls away from Kotlin as a no longer needed source of extra work.

It's Google. They'll probably come up with a completely new programming language which they'll force on the community in some ham fisted way, then suddenly drop it in a few years when they can't figure out a way to massively monetize it.

Re: Java Is Underhyped

#595

Post by vbezhenar »

vips7L wrote: post #529
vbezhenar wrote: post #434

Earlier quoted context omitted.

As a developer who used Java for 12 years, I don't really like the direction Java takes. It's not happening like you're trying to describe. Java have some weak points which could be addressed easily. For example properties are relatively easy to implement, but instead developers decided to implement records which are very different. Modules are weird thing that nobody asked for and they broke old code (what a blasphe…

Providing records was never about providing properties, but yes I agree properties would be a great addition. > They throw out Java EE instead of improving it Giving EE to the Eclipse foundation and transitioning it to Jakarta EE is about improving it. It allows the Eclipse foundation to move faster without having to go through the JDK standardization process.

The first thing they did is performed source-incompatible change of package names. That's hardly improving in my book, more like sabotaging. I understand that's because of trademarks, but that's another issue: why didn't Oracle provide all the necessary legal protections at least for package names.

Re: Java Is Underhyped

#597

Post by spentu »

pulse7 wrote: post #120
thiht wrote: post #118

Earlier quoted context omitted.

Wait for updates or projects requiring a different JDK.

You just install any JDK in any directory - nothing to configure there - and then point IntelliJ to this directory... If this is hard, then... hmmm....

People tend to forget that everything seems easy when you know things.

I have been in situations where I had to compile some projects from other people and it has been painful every time. Especially as I might be in an environment where there are no IDEs that wrap things up for you.

Everyone has different experiences and requirements for their projects and not everything is same as it is for you. Don't take it personally and try to passively insult other people's intelligence.

Re: Java Is Underhyped

#598

Post by huonib »

mnd999 wrote: post #438
huonib wrote: post #402

Earlier quoted context omitted.

I think the problem is because of the virtual machine, instead of being compiled to an executable. I mean GraalVM is great - but why did it take so long to develop? I mean Sun could still be alive if developers and users had instant startup times, could have easily deployed Java to servers and clients, and that it was not only faster but used way less memory.

The virtual machine is (was?) the whole point. You can run the same binaries on your dev box or your server, whatever flavour of server that happens to be. Startup times are not an issue on servers as processes are typically long-lived anyway. It is a bit of an issue on serverless (lambda etc.) but that’s a relatively new thing. High memory usage is generally poor tuning - if you give the JVM 1gb it will use it and a…

I'm sorry, did you claim poor tuning?

look at this graph: https://alvinalexander.com/sites/default/files/inline-images...

from: https://alvinalexander.com/scala/graalvm-native-executables-...

Re: Java Is Underhyped

#599

Post by blandflakes »

chriswarbo wrote: post #562
blandflakes wrote: post #464

Earlier quoted context omitted.

Fun fact, this also happens in Scala - try to List.contains an object from a type different than that stored in the list. Compiles, returns false always.

I actually encountered this in Scala (my example originally had [square brackets] rather than ). My `.has` method uses cats.Eq and is monkey-patched on to the Iterable interface: implicit final class IOps[A: cats.Eq](val i: Iterable[A]) { def has(x: A): Boolean = i.exists(_.eqv(x)) }

Ha, yup. We use the .contains_ method with cats eq on the objects, but this is clever.

Re: Java Is Underhyped

#600

Post by vips7L »

KptMarchewa wrote: post #430
BiteCode_dev wrote: post #137

Earlier quoted context omitted.

JVM != Java. We are talking about Java as a language, not the JVM as a platform. You can also run Python on the JVM. Although, some Java compromises are definitely linked to the JVM.

>You can also run Python on the JVM. Jython is stuck on 2.7 and unmaintained.

Graal's implementation of python is maintained and up to date with python 3.
Post reply on HN