Live data from Hacker News

Microsoft’s Ready to Contribute to OpenJDK

mail.openjdk.java.net

31–40 of 58 posts

Re: Microsoft’s Ready to Contribute to OpenJDK

#31
post #18

Please MS, increase development resources behind net and c# instead. It will benefit Java more than direct Java development - competition will give Java more motivation to grow.

You say that as if they are somehow being sparing in their support of C# and .NET, which is clearly not true. What specifically do you see as lacking on that front?

I can't remember the last time they contributed anything significant to the .net standard library. Yes, they added a json serializer. In 2019, was about time. They ported some of those library to .net standard (but only some, even with .net standard 3 there are lots of small refactorings that are required to make my libraries run).

They are adding to the language, which is a mixed blessing, it is helping in some aspects, but also making the syntax even more complicated to a beginer. But the standard libraries are rather stale and would deserve a lot more love.

Re: Microsoft’s Ready to Contribute to OpenJDK

#32
post #23

Microsoft's apparently not ready to use line breaks. Seriously, people that write lines like that... just... why. What email client is even allowing it?

Actually, it's probably text/plain; format=flowed, which any sane email client would display as appropriately wrapped for the viewport size. It's generally the best way to send plain text emails.

The problem here is the mailing list archive viewer, which is displaying it in a non-wrapping context, instead of letting the text wrap appropriate. It's using a

 instead of a , in other words.

Re: Microsoft’s Ready to Contribute to OpenJDK

#33
post #23

Microsoft's apparently not ready to use line breaks. Seriously, people that write lines like that... just... why. What email client is even allowing it?

Why put in hard breaks when pretty much any email client should support soft/flexible line wrapping? Seems more like an issue with the linked site to me.

format=flowed is a reasonable middle-ground: https://joeclark.org/ffaq.html

Re: Microsoft’s Ready to Contribute to OpenJDK

#35
post #26
post #16

Earlier quoted context omitted.

J++ might get a bad rap in hindsight, but back in the day, it was amazing. The editor was liquid smooth, performance wise, and the compiler was at least a dozen times faster than the JDK Java compiler. It was like the Jikes compiler before Jikes. I recall using Visual J++ and its compiler to do "pure Java" development back then and it was a delight. I only moved to Eclipse later because Eclipse had a deeper understan…

I think Eclipse is probably still slower on modern hardware than Visual J++ was in 1999-2000, which was the last time I used it. The first commercial Java project I worked on we used Visual J++. It was a great environment at the time, there was very little else available if I remember correctly. Sun had something which was horrible. Eclipse is so bad I think those of us who have been in the Java camp for years/decade…

Agreed. It may be true that Eclipse on a Ryzen 9 doesn't feel as responsive as Visual J++ on a Pentium III. J++ was just that much faster than Eclipse. Then again, for my usage, the J++ environment was not much more than a syntax-colored text editor with project files and a method and field browser.

Like I said, when Eclipse arrived a few years later, it provided a lot of utility that J++ did not, and obviously that utility has value. But I think both of us look back fondly on J++ because we know that had it not been cut short, it could have evolved into something different and possibly even better than what we know as Java today. It seems plausible that in an alternate history where J++ kept evolving, I'd be more satisfied with the state of the art.

Re: Microsoft’s Ready to Contribute to OpenJDK

#36
post #31
post #18

Earlier quoted context omitted.

You say that as if they are somehow being sparing in their support of C# and .NET, which is clearly not true. What specifically do you see as lacking on that front?

I can't remember the last time they contributed anything significant to the .net standard library. Yes, they added a json serializer. In 2019, was about time. They ported some of those library to .net standard (but only some, even with .net standard 3 there are lots of small refactorings that are required to make my libraries run). They are adding to the language, which is a mixed blessing, it is helping in some aspe…

It's possible there will be more after .net 5 is released, but I think the current trend is to keep languages' standard libraries small, anyway, though. If you look at languages like python, the standard library is incredibly crufty, so it might be better if .net just deprecates stuff and people use other packages.

Re: Microsoft’s Ready to Contribute to OpenJDK

#38
post #18

Please MS, increase development resources behind net and c# instead. It will benefit Java more than direct Java development - competition will give Java more motivation to grow.

You say that as if they are somehow being sparing in their support of C# and .NET, which is clearly not true. What specifically do you see as lacking on that front?

The speed of development, the scope and quality of new language features has dropped significantly ever since Hejlsberg left C#.

C# with .Net should compete with Go and rust these days, fight for the mindshare of developers.

Re: Microsoft’s Ready to Contribute to OpenJDK

#39

Please MS, increase development resources behind net and c# instead. It will benefit Java more than direct Java development - competition will give Java more motivation to grow.

F# would get my vote for resources over C# and Java

So much potential wasted by subpar tooling. Although I earn money as a C# developer and F# should be the logical choice, I am still studying OCaml right now.

Re: Microsoft’s Ready to Contribute to OpenJDK

#40

I like the direction the "new" Microsoft is going! Hopefully they'll behave themselves this time (re: Visual J++, etc)

Behave? J++ was Mike's ahead of sun, hence the lawsuit. Their jitter beat sun's

J++ had extensions that were not portable -- in clear violation of the binding license agreement that Microsoft would not add anything to the java.* or javax.* namespaces.

Hence the lawsuit.

Microsoft could have added any Microsoft or Windows goodies they wanted -- as long as they didn't try to make it appear that these extensions were part of the Java platform and would run anywhere. There's nothing wrong with Java code that only works on some systems. But not if you're making a version of Java and building those extensions in, especially in a way that tricks developers into using them because they appear to be part of the Java base. Then later the developer discovers their program only runs on Windows.

Post reply on HN