Finding Java Thread Leaks with JDK Flight Recorder and a Bit of SQL
morling.dev
morling.dev
Gunnar has used it in some cool ways. Not just https://github.com/moditect/jfr-analytics, which he showcases in this post, but also https://github.com/moditect/jfrunit
Also, when already paid for MSDN license which includes VS, why pay for Rider?
I believe a lot of companies are not directly paying for MSDN licenses, but retrieve them for free through a Microsoft partnership and by fulfilling conditions to obtain silver and gold competencies. I think this is the case for a lot of smaller companies.
Microsoft however is changing their partnership conditions by focusing more and more on Azure. To be able to stay a partner with similar benefits, you basically need to generate more and more revenue on Azure for Microsoft. Something that will not be doable for a lot of smaller companies in my opinion. And this also depends a lot on the focus of the company, whether it is a pure software development shop or also a reseller of Azure services.
Besides that, .net development is no longer necessarily windows development. My current team consists of 6 people. 1 uses Linux, 2 use OS X, 3 use Windows. We use Rider, Webstorm and Datagrip. We develop .net backends that run on a Linux app service plan. The front end is in Angular. The database is postgresql.
A lot of the .net developers in our company asked to use Rider instead of the VS they get through an MSDN license. Most of them are Windows users. Some people clearly think Rider is superior to VS, myself included…
And even so, plenty of Microsoft products like Dynamics, SharePoint, VS, SQL Server CLR, are yet to make the transition to .NET Core.
So when doing UNIX workloads, we rather use languages what were created and grew up on that environment.
Visual Studio for .NET, Eclipse for Java, VSCode for node/devops (any of them for C++ workloads if needed as well), are basically how things go over here.
[0] - To be fair, Java is also having its Python 2 / 3 moment with anything beyond Java 8. Finally got to deploy Java 11 LTS into production (hurray!).
I think you are right. I worked, and still assist, on a couple of big projects that are built on .NET Framework. I recently pushed to have those upgraded to the latest .NET Framework version, latest version of their libraries, and have the csproj-files upgraded to the new style. Those projects are all WCF, they use NetTcp, they use transaction flow over WCF, some use WCF-msmq. There is a big dependency on distributed transactions over service boundaries, sql server and queues, and on WCF. It would be a major effort to rewrite those to run on .NET Core without distributed transactions and over HTTP APIs.
Those systems have been running just fine for over 10 years, are deployed on-prem and are only used internally on the company network. As long as .NET Framework is supported, there is no value in a rewrite to .NET Core for the business.
In the company where I work, we actually do C# on .NET Framework (maintenance, support) + Core (all new projects), Java, Delphi, and Angular + TypeScript for frontends. We use a lot of the JetBrains tools: IntelliJ IDEA for Java development, WebStorm for frontend development. We used to use Visual Studio + ReSharper for C# development and since Rider came out, a lot of people moved to that.
I'm also not sure what you mean by "REPL" as I tend to think of that as a language feature, not an IDE feature (most read-eval-print-loops are done through a terminal, which Rider has).
Rider also has coverage and automatic unit tests (and it's sibling product Resharper had it for years before Visual Studio added it).
"Architecture tooling" could be a quite broad category, but as far as where I've used Jetbrains products in this sense, they can automatically build class diagrams and the like from your code, and even export them to PlantUML if you want.
Jetbrains also offers an IDE that can handle C++ just fine - https://www.jetbrains.com/clion/. I don't know how well it handles WinRT, but I'll admit I've never had the need to develop or deploy a WinRT application. I do know that they've started building in MAUI integration [2].
I'll confess I don't use Dynamics, or know what SQL Server SP is, but Rider has great Database tooling built in. I've never had a problem connecting to MS SQL Server, SQLite, Postgres, or MySQL databases with it.
> Also, when already paid for MSDN license which includes VS, why pay for Rider?
I guess this question is aggressively asking why someone would choose Rider if they already have Visual Studio Enterprise, and beyond it's great tooling, the main benefits for me are the great code completion, the snappiness of the UI (you can use the editor before it has loaded the AST), and how rare crashes are with it (and it has seemingly gotten even rarer in the last few months, I can't remember it crashing). Beyond that, if you have to choose between the two, an Enterprise MSDN license is $6k/yr [0], and a commercial Rider license + the other Jetbrains C# tools is $470/yr [1]. The former is usually a difficult question with your manager and/or purchasing, while the latter hardly raises an eyebrow.
[0] https://www.microsoft.com/en-us/d/visual-studio-enterprise-s...
[1] https://www.jetbrains.com/rider/buy/#commercial
[2] https://blog.jetbrains.com/dotnet/2022/08/02/rider-2022-2-re...
The one thing is that everyone on your team probably uses Visual Studio or has a license if you’re a .NET shop, that may not be true of Rider or ReSharper. Your manager is already convinced of the need for VS. (I just bought my own JetBrains Toolbox because I had a coupon, but my company will pay for ReSharper if we want it)
SQL Server Stored Procedures, which can be written in .NET, as SQL Server hosts the CLR. This includes the whole debugging and deployment stuff.
Architecture tooling means Enterprise Architect level not basic PlantUML stuff.
MSDN licenses are always part of Windows development workshops, the only question is choosing between professional or enterprise.
So anything JetBrains is always extra.
Also, having tooling to address/fix the many issues Java has isn't really that good in the first place.
That's incredibly useful. We have a strict policy of all threads and pools being named, but sometimes default named threads sneak in making it difficult to figure out where the thread is used for.
Set<File> s = new HashSet<File>();
s.add( new File( "c:/temp" ) );
s.add( new File( "c:/temp" ) );
System.out.println( s.size() );
The C# code:
ISet<FileInfo> s = new HashSet<FileInfo>();
s.Add( new FileInfo( "c:/temp" ) );
s.Add( new FileInfo( "c:/temp" ) );
Console.WriteLine( s.Count );
They are line-for-line identical. IMO, Java prints the correct result. C# may have reasons for this behaviour, but when you're looking at the code, it's not obvious that two FileInfo objects for the same paths are not equal.
When I wrote KeenWrite[0], I chose Java because of all the reasons you mentioned, plus JavaFX. JavaFX is one of the richest cross-platform GUI libraries available for desktop applications, although it does have quirks.
---
On a tangent, is there a reason why FileInfo does not override `Equals`?
E.g.:
var f = new FileInfo("image.jpg");
var set = new HashSet<FileInfo> { f };
f.MoveTo("image2.jpg");
Console.WriteLine(set.Contains(f)); // Would be false (sometimes)Here's another:
string path = "/tmp/filename.txt";
FileInfo f = new FileInfo( path );
File.CreateText( path ).Dispose();
Assert.True( f.Exists );
f.Delete();
Assert.False( f.Exists );
My expectation is that if I put two things that are identical---for all intents and purposes---into a set, only one copy is added to the set. Likewise, upon deleting a file, I expect that testing for its existence always returns false. Both of these expectations are based on my mental models for math and file systems.
I haven't tested the behaviour of caching file states in Java, but I suspect it will return false if the file is deleted. Point being, in my limited time with C#, I've found it to violate the principle of least astonishment in ways that Java does not.
Doesn't Java also have things that use reference equality? Arrays?
Yes. There are inconsistencies all over the place. In fact, OPs example of java.io.File is ironic, because that object had a number of issues and was somewhat replaced by java.nio.file.Path [1].
Even outside of that, file equality in general is fraught with a lot of subtlety. For example, should java.io.File equality be case sensitive or insensitive?
[1]https://docs.oracle.com/javase/tutorial/essential/io/legacy....
The language is completely closed and controlled by a single commercial software company and there is no community process involved in its evolution and design. I had believed that this business model of programming language design/ownership died decades ago when everyone abandoned all the bespoke commercial languages/IDEs of the 1980s and early 1990s. The way Jetbrains have scuppered the attempt to provide a reasonable vscode plugin feels like reliving the 1990s where the single company providing the language spec, compilers, IDE and tooling for "their" language and aggressively prevented others from providing alternative tools and compilers.
Also compile times are horrendous - even with modern hardware, the compiler barely seems to be able to manage much more than a few 1000 lines/sec. Again, my age means I remember decades ago when compilers/IDEs advertised their performance in terms of 100,000s of lines per second. This means edit/compile/debug workflow is very painful once your project grows to non-toy sizes.
I also grew to dislike the ethos of the "community" which basically seemed to involve condescension and passive aggressive responses to to any questions regarding the design of language features particularly by Jetbrains employees.
Kotlin is undoubtably a more "modern" feeling of development than Java (or C++ for example) but I'm not sure such vendor lock-in is worth it given many other languages are catching up (including Java) or exceed it. Also I used C# for about a year subsequently and realised that Kotlin stole most of its best features from C#. Languages like Rust, Zig, Swift, etc. are just as "modern".
All in all there are less resources on Kotlin but too many things they want to do. Not only are they building the language but they have to reinvent everything because they don't work on Multiplatform.
It used to be simple - a better Java (so it claims). Now I'm not so sure what the direction is.
I ask because the JVM is an amazing bit of technology that has been battle tested for decades. Would be hard to beat I would think.
- Data classes can become JVM records with the @JvmRecord annotation and some additional type constraints.
- Inline classes will certainly become Valhalla value types (hence the required @JvmInline annotation).
- Nullable types are supported with compile-time checks and additional runtime checks inserted by the compiler at time-of-use, and if Valhalla adds a nullability marker to the bytecode, Kotlin can support it.
- Coroutines/structured-concurrency already uses Executors under the hood, so it's likely that we'll have Loom thread support without any changes to the coroutines APIs (though the standard dispatchers will need to use virtual threads themselves). Coroutines themselves are CPS-transforms of ordinary code and don't need VM support.
- Tail-call elimination is supported by transforming to trampolines, something which the JVM will probably never support until Java needs it.
For example syntactic cooperative coroutines vs preemptive coroutines provided by the VM. Kotlin is now stuck with the colored function problem and has the stack trace issues that the Java team is able to avoid by not only being able to change the language.
That being said, I think they're both fine languages with different goals.
We attach a hawtio.io jvm agent to every single prod jvm we run and query the agent using telegraph. (If you don’t do this by the way, you should!) I noticed in the GUI portion of hawtio, it slows you to start/stop a jfr recording, but I’ve never messed with it
But I don't see any real "anti" comments, only valid criticism and I say that as a Java dev myself. It does have its wrinkles. But for it's age and popularity it's still a pretty good language.
In the first dot.com boom, a lot of people worked for tech companies, and Microsoft was the Google|Apple back then. Their corporate culture was dog-eat-dog nonsense, but it trickled down through the industry... and of course at the time Java was super super popular, even though _it really sucked_ back then (not so much now, it's quite awesome).
One of the most _hated_ positions was "The Architect" who usually rose to the top via floating on top of a bubble of attrition; so rather than being promoted because you're good at leadership or a great person that's fun to be around or a technically savvy and loved to teach... these architects were ignorant egotistical maniacal dictators that got promoted merely because everyone else quit. They turned static analysis tools into weapons of war. They made arbitrary standards that really didn't work for anyone, rather than trying to work for someone. Everything had to be over-engineered (sound familiar? If not, look at today's SPAs) with AbstractFactoryProducerMethodProducerImplInterfaces. I worked at a lot of these companies, and it just wasn't a fun time to be in software development.
Rather than people seeing the reality that Poor Leadership and zero charisma as the root cause, somehow people arrived at Java was the core problem.
A lot of the things were good in their intention; for instance, having the whole company use tabs instead of spaces (or vice versa) and having a universal code formatter have the potential to increase communication. But instead, it was just executed poorly at nearly every shop and the vast majority of the problems got turned into Dilbert comics.
But yeah, Java.