373 karma · joined December 26, 2019
Also I think inlining would typically increase the total size of output rather than decrease it.
Also applets were too slow to start with Sun's implementation of the day while wasm works reasonably well in all browsers from day one. That matters a lot for adoption.
JVM improved but applets missed their chance. You only get one.
Or how about C# Source Generators that were introduced just few years ago and are stuck on .NET Standard 2.0 because of Visual Studio using .NET framework?
There is a lot of actively developed software out there either built in .NET or using it to provide extensibility that is now stuck as you can't add support for .NET Core without breaking all existing plugins.
The only alternative is complete redesign with out-of-process architecture which is not going to be compatible and might be inappropriate in some scenarios.
BTW mailing lists can work great for guest visitors who don't want to subscribe. They can also work great for teams who don't want guests.
The problem is openjdk mailman allows guest posting and lies about guests posts awaiting moderation. Had they simply disabled guest posting and said up-front that you must subscribe and send rejection notice to guests I would be perfectly fine with that.
Mailman sucks worse than even Google Groups and in this case it's also poorly configured.
PS. To add to frustration, LastPass (I know it's shit but don't have time to migrate) somehow can't deal with Mailman signups - it will generate but won't save passwords.
This is fine but removes only about 10% of the pain of mandatory exception handling inside typical lambda.
Nothing short of making exceptions transparent to lambda receivers will cut it for me.
> Kotlin is using an annotation to disambiguate between Java style records and Kotlin style records
This is inherent risk of building on top of something you don't control. Don't really see this as fair comparison. It's a known design constraint. The only way to avoid it is to not build on top of Java or not adding any features on top of Java.
> To give another example with C#, there has been a lot of recent discussion about finding potential alternatives to their async-await concurrency model. They cite the level of effort it takes to maintain the async await style code and the costs that come from this.
I had a very different take-away. They did PoC with virtual threads and decided it's not worth the switch now and async-await that they have is good enough.
https://github.com/dotnet/runtimelab/issues/2398
> Some of the languages it gets compared too aren't even that old yet.
C# is more than old enough to drink and Scala just had its 20th birthday this weekend :) Java is only 4 years older than C#.
I will admit the system works if its goal is to prevent wasting OpenJDK devs time on repetitive topics.
I was going to ask one such potentially repetitive question (can't tell without search) but waiting for non-existent moderator to approve my message successfully drained any energy I had for this :)
Just an idea - maybe you can use CodeQL?
The transition to .NET core is indeed rather painful but it's just Microsoft's choice. Things were dropped/backwards compatibility broken mostly to simplify runtime but I saw nothing that couldn't have been emulated with some modest effort.
Also they could've easily softened the transition by continuing development of .NET Standard a bit longer and allowing side by side hosting of 4.x and Core in same process as that seemed to be the plan in the beginning. I guess they don't care.
Don't think like Java is a good example of that, more like the anti-example. Plenty of more sophisticated languages move way faster without negative effects on long term progress (C#, Kotlin, to some extent Scala)
> A well designed feature becomes easy to extend. A poorly designed one is easy to extend initially, but becomes far more difficult in the long run.
Most of Java problems come down to unfortunate design choices in the past. E.g. checked exceptions vs lambdas
The alternative is to write this code by hand which isn't any better.
I'm surprised there isn't an option to send your request via post mail.
Also other community-hostile behaviors of Java/OpenJDK project:
- mailing lists have no search function and block search engines/crawlers by returning 403 (apparently robots.txt is not enough!)
- can't post to mailing list without subscribing despite information that such messages will just need to be approved by moderator (they never are)
GA workflows are basically yaml lists of docker container names to run. I thought it would've been trivial to emulate. At least much easier than any other system.
Seems very intuitive to me (and same as C#).
It also hinders adoption of new features as people will prefer to maintain consistency in their codebases.
I haven't used personally but curious if it has some shortcomings they don't mention.
That's because unlike other shells where piping just passes through binary stream, Powershell is based around the concept of piping streams of .NET objects so it will try to parse output of one native command into a list of .NET strings, one for each line, and then print them out to input of another command. Not only making it extremely slow but also changing new lines \n to \r\n and maybe other special characters.
I don't think it's in the path by default so if some program like npm calls exec("rm") it's still going to fail I think.
It pins goroutine until it is explicitly released ensuring that multiple native calls will remain on the same platform thread and nothing else is going to use it. This is critical for namespace manipulation on Linux.
Java only pins for duration of native call and synchronized blocks.
It looks like Java does not offer equivalent API? For now could be achieved with synchronized but if synchronized will be changed in the future to not pin it would break.
This is how GraalVM and OpenJ9 achieve instant startup of Java programs.
Unfortunately it doesn't look like they are planning to support ports directly in UNC paths.
But seems to have devolved into generic state synchronization library these days.
DAV is arguably easier than p9 since everything has HTTP libraries and most people know it.
PS. Loopback driver is not 3rd party.
There are some guides online about it.
NET USE F: \\localhost\foo /TCPPORT:1234
Another idea: publish as inheritable POM for Maven and Gradle convention plugin so that people don't need to copy all that boilerplate (with some refactoring to make it reusable)