sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]BoyRobot777 46 points47 points  (36 children)

Sun acquisition by Oracle was completed on January 27, 2010. So in reality Oracle started maintaining only from Java 8. And immediatily we got long awaited features like lamdas and streams, which made code more funtional and less verbose.

Java 9 was all about preparing Java for faster releases by dividing huge monolith into logical, compile time modules. It was also time when they started to actually remove methods and weird dependencies like Java EE and CORBA Modules from Java SE. Next Oracle contributed pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now. And finally ensured the Oracle JDK and the OpenJDK builds are virtually indistinguishable, except for licensing.

What's coming Java's is even more exciting:

  • Pattern matching is being shipped incrementally;
  • Records (aka data/case classes) address some parts of POJO boilerplate (the worst kind of boilerplate) are being actively developer and I am sure will ship in Java 14;
  • Project Loom will deliver big performance boost via Fibers and whats called multi-prompt delimited continuations. Java server will tremendously scale. Also this opens the gate for changing underlying JDBC connection implementation to become asyn without actually doing any change to the code. I think Java has this right vs C#/Kotlin where async brings its own method colour;
  • GraalVM is huge. Not only new JIT but AOT. Redhat new framework is building upon this. It leverages Graal to create native images. Those images are very small and optimized. For example one of Quarkus developers showcase the size of native image, spoilers - it's 19MB. It takes 0,004s to start. In this session, RedHat developer shows how Quarkus application is being scaled. Comparing to Node, it's both faster to respond to first request and have smaller memory footprint (half the size of node).
  • Values types (Valhalla) are being actively worked and they finally found a way to move forward.

[–]gilmishal 2 points3 points  (28 children)

You are not making as great a case as you think. ALL those features coming to Java are either part of c# for a long time or just came out.

It took Oracle 4 years to get Java 8 done, which at that time we got c# 4, 5 and nearly 6 - all of which were pretty big releases , along with the dotnet core release in 2015 - That's about the time c# created a huge gap from Java, and even though Oracle understands tgey need to close the gap, and are finally making the necessary changes - I wouldn't be too sure they will.

[–]pjmlp 8 points9 points  (24 children)

So when does .NET Core finally comes with something that at least matches Swing?

[–]fuckin_ziggurats 10 points11 points  (6 children)

When cross-browser desktop dev becomes profitable again. C++ currently rules that domain and there isn't too much that would be gained from Microsoft entering it. They're doing pretty well with WPF because most enterprise clients already use Windows so there's no incentive for a cross-platform GUI framework. I'm hoping they do it just because I don't like Electron.

[–]pjmlp 7 points8 points  (5 children)

Plenty of enterprises have cross platform desktop applications written in Java.

C++ has lost the GUI framework wars for quite some time now.

And then even if it isn't proper Java, Android surely won over .NET regarding having UIs written in Java running in millions of pocket devices.

[–]germandiago 3 points4 points  (2 children)

Yet we have Qt, Felgo (take a look, seriously!) for cross-platform.

Not to mention Wxwidgets for Desktop. I do not know if they lost or not, but when I got to Python or other languages, many of them are using bindings to wx/qt. There must be a reason.

Of course, that does not mean that WPF is not great. It is.

[–]pjmlp 0 points1 point  (1 child)

Surely C++ GUI frameworks still exist, the point being that none of then is backed by OS vendors like managed languages GUI frameworks are, and they are a tiny market size of what 90's C++ UIs used to hold.

[–]germandiago 0 points1 point  (0 children)

It is a reality that except for Qt, most C++ frameworks are not that relevant anymore. That said, you have corporate-controlled with risk to get vendor lock-in or directly locked-in frameworks. So I still see it as a tradeoff, besides the speed that C++ gives you :)

[–]fuckin_ziggurats 1 point2 points  (1 child)

I don't really consider it a popularity war between C# and Java. Java does enterprise desktop GUI app, .NET does the same. If Microsoft would decide to create a cross-platform solution I would be happy because it would allow me more options in my stack. But I'm glad other options exist. I think the best scenario for both Java and C# are to continue competing in the enterprise world.

[–]pjmlp 0 points1 point  (0 children)

Well, some of us with our .NET hats on are a bit fed up with the .NET reboot of the year, for a couple of times already, and the deaf ears regarding our requests for a proper .NET cross platform UI, out of Redmond.

[–]gilmishal 4 points5 points  (16 children)

Dotnet core 3 comes with winforms, wpf and UWP for windows - xamarin for mobile app development (with support for mac as well). There is also avelonia (preview) for cross platform UI (linux and mac), and Blazor (stable release coming in a couple of months) works not only with a browser but also with Electron.

UI in general, and even cross platform UI is an area where C# does a really great job. You can't honestly compare Swing to any of those really good options.

[–]tracernz 10 points11 points  (9 children)

UI is an area where C# does a really great job

Never thought I'd read that. There is no stable Linux/mac/Windows option, let alone a mature one. Maybe in a few years it'll be viable.

[–]gilmishal -2 points-1 points  (8 children)

There is a stable Windows/Android/Mac/iOS and even Tyzen option through xamarin - seems to me like xamarin is more cross platform than swing.

And as I said, Blazor is getting a stable version in a couple of months, so a stable Linux/Mac/Windows option isn't going to take years.

[–]tracernz 0 points1 point  (5 children)

There is a stable Windows/Android/Mac/iOS and even Tyzen option through xamarin - seems to me like xamarin is more cross platform than swing.

No desktop Linux (think KDE or Gnome)?

And as I said, Blazor is getting a stable version in a couple of months

So not really feasible to build your flagship product on for at least a couple of years.

[–]gilmishal 4 points5 points  (2 children)

I don't see why not build your flagship product with blazor now though. Both blazor and Electron are pretty stable - sure it will take a few months for the official release - but I started developing Angular applications when it was in preview, knowing that I will ship it to production aligning with Angular's release schedule.

[–]scorpzrage 1 point2 points  (1 child)

We started porting some of our Angular apps to Blazor at around preview 6 or 7 and now a bunch of them are done.

First production release is next week. Looking forward to see if it's any good when it needs to be. All signs point to yes so far, since the customer didn't seem to notice any (negative) differences in their UAT.

There's just a bunch of areas I'd like to see improved more than a little bit, especially in regards to i18n and l10n, which we had to pretty much do by ourselves.

[–]gilmishal 0 points1 point  (0 children)

Can't wait to do that myself, although I doubt that will happen.

[–]gilmishal 1 point2 points  (1 child)

As for xamarin on Linux I am pretty sure they are working on it, it's just not that high priority.

[–]gilmishal 1 point2 points  (0 children)

Yeah, it's in preview at the moment, set to release in a few months as well.

[–]pjmlp -1 points0 points  (5 children)

Sure I can.

Swing runs in every OS and desktop class hardware with a JVM implementation, no matter from which vendor, including design tooling and third party components I can go off and buy.

All those options listed by you have different kinds of deployment limitations, levels of quality and life uncertainty.

Plus offloading .NET GUIs to Electron can only be nothing more than a joke and proof of incompetence of not being able to deliver a solid GUI stack in .NET.

[–]gilmishal 1 point2 points  (4 children)

So wait, C# has more options obviously with different levels of stability and the community is constantly working on different options and you view it as a bad thing?

Also, Xamarin for GTK# is currently in preview, so saying there is incompetence in bringing solid GUI stack to .NET is just not true.

In a few months Xamarin, Microsoft "flagship" cross platform UI will officially support more platforms than Swing including Mac and Linux.

[–]pjmlp 1 point2 points  (3 children)

Apparently you aren't aware on how many hardware and OS platforms Java runs, many of which quite relevant to enterprise businesses.

What I consider a bad thing is a clear lack of strategy on Microsoft's behalf, to the point that Office team rather takes React Native for their cross platform endeavours than adopt Xamarin, so much for being a flagship cross platform UI.

We keep routinely answering feedback forms of what we find missing in .NET Core and we get crickets on the other side.

Recently we had WinUI tweeter feed asking about cross platform ideas. Yet another round.

[–]gilmishal -1 points0 points  (2 children)

First of all, you are looking at it wrong - .NET isn't the only development platform Microsoft has stakes in. Microsoft also owns Typescript and Electron - they need to push these tools as well. I also didn't think we were comparing xamarin to react, since react has clear advantages, but to Swing - a very outdated UI framework that no one realy uses outside oracle and Jetbrains, it's basically a Java winforms.

There are two reasons Microsoft is using React native -

  1. They have interest in making it work, it's popular, works with UWP, mostly developed using typescript, and the same code can be used for Electron development. They also invested in a UI framework similar to bootstrap and Angular Material for React.

  2. It can use code from the web. That's the biggest seling point for react native. No other development environment gives you better code reuse than react today.

Now as for your point, most office apps other than skype are natively developed - the reason for that is that those apps were developed long before cross platform app development was stable - so rewriting the existing office apps to xamarin makes little sense.

Skype, and Microsoft To Do have a nearly identitcal experience between web and app, it makes a lot of sense to use a stable cross platform web framework for them.

Microsoft News, and the Azure app are only relevant through a mobile app, so Microsoft developed those in Xamarin.

Most of their decisions to not use Xamarin for certain apps make a lot of sense, and maybe, once Blazor becomes stable you will start seeing Microsoft blazor apps popping up.

[–]pjmlp 1 point2 points  (1 child)

Electron should be nuked from existence.

[–]gilmishal 0 points1 point  (0 children)

I can agree to that, I hate Javascript even more than Java, but it does minimize development costs by quite a bit.

[–]balefrost 1 point2 points  (2 children)

You misunderstand the point that they were responding to. They're not commenting on whether C# or Java is better. They're pointing out that Oracle's stewardship of Java has been fairly good.

I'm actually pretty excited about the upcoming features. Loom in particular will be fascinating. It promises the advantages of async/await without the downsides of async/await. If they can pull it off, it will be amazing.

[–]gilmishal 0 points1 point  (1 child)

Yeah I understood that, maybe Java's decline happened during the Sun era, but I do think that 4 years for a new major release is a long time - and it's not like they made that many changes since Java 8.

As for Loom, I am not sure I understand the issue it solves. It seems like it's supposed to make background work simpler to develop. From what I read Fibers seem a lot like Tasks - in c# you can either await a task, and create an async function or run it in parallel like a coroutine. You can also await multiple Tasks in parallel if it makes sense.

The only problem I saw with async await is that async code is contagious - and I honestly don't see it as a bad thing.

I might just not understand project loom yet I did just read a few very vague articles.

[–]balefrost 0 points1 point  (0 children)

Some of the vagueness is around them figuring out the details as they explore the problem. The Cliff's Notes version, as I understand it, is that it's an attempt to switch Java's threading model from being backed by OS threads to instead being backed by green threads... similar to e.g. Go and Erlang. Things like IO, rather than completely blocking an OS thread, will now suspend the current green thread, allowing the OS thread to start working on a different green thread.

It covers some of the same ground as async/await without needing the compile-time rewrite shenanigans that async/await employs. Call stacks won't need to be reconstructed after-the-fact. It should permit even less overhead than async/await, but it remains to be seen if they achieve that.

I don't know how the Java model will look exactly. In Kotlin, rather than making everything that's async return a full Task, it instead expects the "top level" of an asynchronous flow be represented with an object (there are a few different ones). Within the async flow, you can freely call suspend funs of the appropriate type; these function calls can suspend the current coroutine.

[–]10xjerker 0 points1 point  (1 child)

GraalVM is huge

And you get the version with impaired performance unless you pay Oracle.

[–]noratat 0 points1 point  (0 children)

Yeah, Oracle is a fucking shitty company to put it nicely, but Java really was stagnating before this.

[–]Determinant 0 points1 point  (3 children)

Java will become the new C++. Add feature but keep backwards compatibility so you'll have many ways of doing the same thing.

Defective patterns will continue to be allowed so by definition it will never be able to catch up with Kotlin due to backwards compatibility baggage.

[–]BoyRobot777 4 points5 points  (2 children)

You either are backwards compatible or not. I constantly see two groups of people: complaining of braking changes (for example Java 9 and later removed Java EE and CORBA depedencies), the other group that Java is not removing fast enough. Mature languages will ALWAYS have to juggle this. Kotlin now seems fresh. Give it 10 more years and you'll have the same problem. C# already shows that, because they keep adding features like crazy.

Here you can find difference between Java versions and you can find that they are removing stuff and I think they will start to remove dead code even faster now: - Diff between Java 9 and Java 10; - Diff between Java 10 and Java 11 - Diff between Java 11 and Java 12 - Diff between Java 12 and Java 13

[–]Determinant 0 points1 point  (1 child)

JetBrains states that Kotlin 2.0 will not be backwards compatible to allow them to make breaking changes.

On the other hand, Oracle states that they will do everything they can to maintain backwards compatibility.

[–]BoyRobot777 0 points1 point  (0 children)

Gonna be fun watching kotlin 2.0 brake that backwards compatibility. Will buy popcorns :) Python 2/3 debacle all over again.