Microsoft’s Ready to Contribute to OpenJDK(mail.openjdk.java.net)
mail.openjdk.java.net
Microsoft’s Ready to Contribute to OpenJDK
https://mail.openjdk.java.net/pipermail/discuss/2019-October/005173.html
57 comments
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.
Microsoft doesn’t have to pull resources from anything to put them on Java. It’s like if Jeff Bezos is buying a car and you say “please spend the money on a boat instead”
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.
C# with .Net should compete with Go and rust these days, fight for the mindshare of developers.
I don't understand your concern.
I think Mads Torgersen & co. are doing a wonderful job.
We've had a new version of C# with each new (recent at least) release of Visual Studio.
Did you have issues with the quality of new features? I'm really puzzled by your comment.
I think Mads Torgersen & co. are doing a wonderful job.
We've had a new version of C# with each new (recent at least) release of Visual Studio.
Did you have issues with the quality of new features? I'm really puzzled by your comment.
What I meant is that most of the recent C# additions are merely syntactic sugar that does not increase developer productivity in a significant way, does not boost the expressiveness of the language, sometimes even decreases the readability of the code. That's in contrast to things like generics and li q.
Besides apart from C# there's also CLR and Jit that could use more love. It is well known that jvm is a better vm than CLR. Most of the CLR speed comes from using references to value types but somewhat as an afterthought and without tools that C++ provides (readonly gives you muh less power that const reference).
Besides apart from C# there's also CLR and Jit that could use more love. It is well known that jvm is a better vm than CLR. Most of the CLR speed comes from using references to value types but somewhat as an afterthought and without tools that C++ provides (readonly gives you muh less power that const reference).
This is somewhat a strange take.
Apart from Borrow Checker which is a recent invention, all programming languages features, as far as I am concern has been done previously in one way or another. There is only so many language features you can fit in on a languages like C# which is soon to be 20 years old. It is a sign of maturity. And C# in itself is already very modern compared to Java.
Most of the JVM performance improvement came from many Enterprise customers absolutely pushing the limit to a point where performance of JVM today would be unthinkable 10 - 20 years ago. It is the work a hundreds of millions if not billions over the past two decade. And it is not like Microsoft are not doing research on how to speed it up.
Apart from Borrow Checker which is a recent invention, all programming languages features, as far as I am concern has been done previously in one way or another. There is only so many language features you can fit in on a languages like C# which is soon to be 20 years old. It is a sign of maturity. And C# in itself is already very modern compared to Java.
Most of the JVM performance improvement came from many Enterprise customers absolutely pushing the limit to a point where performance of JVM today would be unthinkable 10 - 20 years ago. It is the work a hundreds of millions if not billions over the past two decade. And it is not like Microsoft are not doing research on how to speed it up.
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.
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.
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.
I like the direction the "new" Microsoft is going! Hopefully they'll behave themselves this time (re: Visual J++, etc)
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 understanding of the Java language and was able to do fancy things like traverse a call stack from static code analysis. Eclipse was considerably slower in UI and responsiveness, especially on hardware of the time, but that utility made up for it.
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 understanding of the Java language and was able to do fancy things like traverse a call stack from static code analysis. Eclipse was considerably slower in UI and responsiveness, especially on hardware of the time, but that utility made up for it.
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/decades/whole career have lost sight of just how much better the MS tools were/are.
I don't even remember feeling as much frustration towards VC++ in the 1990s as I do with Eclipse today.
It's too easy to forget Mac wasn't even an option back then. OSX didn't start to become viable till 2003-2004.
I've officially been doing Java 20 years now... part of me really wants to jump the fence and go work on Windows stuff. I jumped the fence to work on Python 6 years ago. But it was "Python being used for stuff Java is 10x better for" and got tired of it after a year. Python is 10x better than Java for lots of things.. but not for giant enterprise systems IMO.
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/decades/whole career have lost sight of just how much better the MS tools were/are.
I don't even remember feeling as much frustration towards VC++ in the 1990s as I do with Eclipse today.
It's too easy to forget Mac wasn't even an option back then. OSX didn't start to become viable till 2003-2004.
I've officially been doing Java 20 years now... part of me really wants to jump the fence and go work on Windows stuff. I jumped the fence to work on Python 6 years ago. But it was "Python being used for stuff Java is 10x better for" and got tired of it after a year. Python is 10x better than Java for lots of things.. but not for giant enterprise systems IMO.
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.
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.
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.
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.
Sorry I didn't clarify. You're right about the states reason and legal reason but in reality the problem was j++ bring better
I have to disagree. Sun sued Microsoft because Sun's entire motivation in Java was to keep Java portable. So much so that it was in the contract. It was a private contract dispute between two companies. A civil matter. Not a state criminal matter.
>> As many of you may know, Microsoft and its subsidiaries are heavily dependent on Java in many aspects, and also offers Java runtimes in its Microsoft Azure cloud to its customers.
Anyone know details on how MS uses Java outside of hosted runtimes?
Anyone know details on how MS uses Java outside of hosted runtimes?
Hi, I'm the PM for Java at Microsoft. You can see this slide I presented at MS Ignite couple months ago:
https://twitter.com/chanezon/status/1192140812718657536
Happy to point you to the presentation if you are interested.
But in short, we use Java at some places like (there's probably more):
- Azure runtimes for end-users (App Service, Functions)
- Azure runtimes for other services (Azure HDInsight aka Big Data)
- LinkedIn backend
- Yammer backend
- Mojang Minecraft
- SQL Server Big Data Connectors (JVM is embedded in the DB)
- Internal Android and Xamarin development
Best, Bruno
https://twitter.com/chanezon/status/1192140812718657536
Happy to point you to the presentation if you are interested.
But in short, we use Java at some places like (there's probably more):
- Azure runtimes for end-users (App Service, Functions)
- Azure runtimes for other services (Azure HDInsight aka Big Data)
- LinkedIn backend
- Yammer backend
- Mojang Minecraft
- SQL Server Big Data Connectors (JVM is embedded in the DB)
- Internal Android and Xamarin development
Best, Bruno
I imagine that C# is used less and less within Azure's infrastructure and embracing other languages such as Java where appropriate. This would go well beyond direct Java runtime support. C# cannot compete with the Java ecosystem for open source cloud management software. Just take a glance at Apache projects and see how strongly Java is represented there. I imagine that Microsoft is investing heavily in Python as well.
I'm mystified as well. I worked at Microsoft for seven years and never once heard any mention of Java. Maybe it's in the acquisitions? (GitHub, LinkedIn, etc.)
It is for azure to ensure java runs smoothly there. Similar to how they pushed code to the linux kernel years ago so linux and hyper-v would play nice together.
Being mystified about the value of Java to Microsoft suggests that you lead a somewhat insulated life in software development.
Github is Ruby
LinkedIn is Java
LinkedIn is Java
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?
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 <pre> instead of a <pre style="white-space: pre-wrap">, in other words.
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 <pre> instead of a <pre style="white-space: pre-wrap">, in other words.
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.
Seems more like an issue with the linked site to me.
format=flowed is a reasonable middle-ground: https://joeclark.org/ffaq.html
[deleted]
Email clients that autowrap text.
Line breaks are hard.
But <format=flowed> has been causing problems for years. https://joeclark.org/ffaq.html
But <format=flowed> has been causing problems for years. https://joeclark.org/ffaq.html
Cool, looks according to post submission this actually happened end of October.
How did it go so far? Anyone know more?
How did it go so far? Anyone know more?
So far we have submitted couple patches [1][2] that we felt were good opportunities to learn how contributions flow into OpenJDK, and we are now starting to experiment with JFR and other GCs like Shenandoah. As we progress, we may find other fixes and enhancements that we aim at upstreaming as well.
If you have further questions, I'd be happy to take them.
Best,
Bruno Borges,
PM for Java at Microsoft
[1] https://hg.openjdk.java.net/jdk/jdk/rev/aebd72de84b0
[2] https://hg.openjdk.java.net/jdk/jdk/rev/c6e474ae266b
[3] https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-... (still under review)
[4] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev... (ongoing discussion)
If you have further questions, I'd be happy to take them.
Best,
Bruno Borges,
PM for Java at Microsoft
[1] https://hg.openjdk.java.net/jdk/jdk/rev/aebd72de84b0
[2] https://hg.openjdk.java.net/jdk/jdk/rev/c6e474ae266b
[3] https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-... (still under review)
[4] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev... (ongoing discussion)
Sic transit gloria mundi :^)
https://en.m.wikipedia.org/wiki/Microsoft_Java_Virtual_Machi...
https://en.m.wikipedia.org/wiki/Microsoft_Java_Virtual_Machi...
Is it safe to assume this doesn't include Graal because while it is shipped with OpenJDK, AFAIK it's not a part of the project?
Hypothetical Question: Is it at all possible to eventually merge Java and C# back into a single language? Say in 2030 ?
Not likely.
Something more likely. Two things.
Make dot NET a truly first class citizen on other platforms. Including the ecosystem of C# and dot NET libraries. Some of this may be difficult due to the long time that dot NET has been Windows only. There would have to be a clear boundary between APIs and features of the runtime and libraries that are only available on Windows. I think Microsoft is already making moves in this direction. But I don't keep up with it.
Make Java a truly first class citizen on Windows.
Something more likely. Two things.
Make dot NET a truly first class citizen on other platforms. Including the ecosystem of C# and dot NET libraries. Some of this may be difficult due to the long time that dot NET has been Windows only. There would have to be a clear boundary between APIs and features of the runtime and libraries that are only available on Windows. I think Microsoft is already making moves in this direction. But I don't keep up with it.
Make Java a truly first class citizen on Windows.
I'd say not or at least they'd have to abstract for different runtimes
.NET/Core and JVM have quite diverged I would think
.NET/Core and JVM have quite diverged I would think
No. Why would anyone do that? Maybe C# could be moved to the JVM, that could make some sense, but unlikely.
Funnily enough I was thinking an almost identical thing this morning. We had IKVM [0] for.NET, which if I understood it correctly allowed Java to run on the CLR (I probably misunderstood this).
I'm not entirely sure why Microsoft don't build something official to run Java code on the CLR/.NET, is it a technical or legal limitation, or simply that there's no business need?
[0]: https://www.ikvm.net/
I'm not entirely sure why Microsoft don't build something official to run Java code on the CLR/.NET, is it a technical or legal limitation, or simply that there's no business need?
[0]: https://www.ikvm.net/
It would be huge if they implemented a way to run java libraries from .NET. Be it ikvm or something else. This would immediately open up huge amounts of very interesting libraries to .NET. For example Bouncy Castle or Lucene. Years ago I worked on a document search app. Wrote it in .NET but then almost all interesting libraries were in Java exclusively or with an outdated .NET port. Being able to use the up to date java libraries would have been huge. This experience alone makes me reluctant to use .NET. The Java ecosystem is just much broader.
It seems Microsoft is doing .net Java introp:
https://github.com/dotnet/csharplang/issues/2517
An active fork of IKVM can be found here: https://github.com/jessielesbian/ikvm
Also re: using Java with .NET, there's also their Java Interop project which is used with Xamarin: https://github.com/xamarin/java.interop
Also re: using Java with .NET, there's also their Java Interop project which is used with Xamarin: https://github.com/xamarin/java.interop
Not without an enormous amount of breaking changes. The severity of them would be so high that no C# or Java programmer could ever convert their existing code.
What would they contribute?
cool
If Anders Hejlsberg is not a part of this effort, then meh. If he is, then wow.
why would he part of it?
He's basically the living legend of programming language design, having designed _three_ successful programming languages (TurboPascal, C# and TypeScript). If he's allowed to tweak Java to his liking, it might actually at some point catch up to what C# was 15 years ago, and maybe even get proper generics.