![]() The 'legacy code' that you're thinking of that you don't want to break was written after any of these problems could have been fixed.Hi everyone, welcome to the January edition of Visual Studio Code Java update! Since this is our first blog post of the new year, we are going to look back on highlights of 2021 and take a look at our roadmap for 2022! We also have some exciting feature updates so let us get started. I'm sick of the 'backward compatibility' at all costs. Synchronised blocks don't compose: synchronised get() and synchronised set() do not become synchronised getThenSet() If I submit a list as a parameter or accept a list as a parameter, who else has mutated or will mutate that list. No way to avoid mutation in order to avoid non-local reasoning about state. Let's say the language designers for some reason didn't put takeWhile into Stream. Wait - better than forgetting about it: include cancel() on the class but make it a no-op. Wait for a multiple futures? Write a for-loop. What do you do with Sets: Union? Intersect? Nope, write them yourself. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.īizarre omissions from the standard library. Null drives a big hole through whatever you try to achieve with the type system. I'm not going to try to pipe input through several stages of "java -jar myUtil.jar", even if I bother to clear the hurdles of trying to find and configure the right maven plugin to build a "fat" jar. I use the termal and I make binaries for my use. But if you're not aware of them (or stuck with an older legacy codebase like a lot of people are) they can be major headaches that can just be avoided by using a more modern language. Almost every single one has some form of workaround for it. None of these it should be noted are deal breakers or reasons why you shouldn't use the language. At runtime, there are no generic types kept, meaning it is technically possible to break the generic typing of an object. Smarter people than me can probably give you more detail on this, but generics were grafted on to the language long after it was introduced, and it shows. Most people are now forced to use some json serialization, but the old serialization format is still lurking in the background to ensnare less knowledgeable programmers. Java has built in binary serialization support that ended up being a massive security hole. No one still uses it like this, with most method creating an `Object lock` as a synchronization primitive. Java built in synchronization primitive is based upon an older model of concurrency whose name I cant remember but it involves every object basically being able to maintain internal consistency with it's own state. You can mostly fix this with annotations, but those your team using them very consistently, and are not supported by most java libraries. Swift and Kotlin have first class support for these, which are meant to minimize or reduce the number of null pointers in your code. ![]() There's nothing really wrong with it, but it's core design is pretty outdated in ways that are difficult to fix without putting together a totally new language. ![]() And with all the built in refactoring and tooling there is now, it is really a full circle and you don't exactly need anything else.Įdit: it is also worth pointing out that adding Resharper to VS2022 makes it a lot nicer, but in my book that is basically the same as using Rider because then most of the refactoring is taken away from the Microsoft IDE's engine and goes though the same/similar path as it does in Rider (as Rider uses the Resharper Engine too.) But from the very first version of Android Studio, it all seemed coherent. That might have just been with how immature the Android tooling was back then. With Android development (which to be fair I mainly do on the side), I remember Eclipse being reasonably hard to get set up. I spent a long time ignoring JetBrains, but once I started to use Rider (and Android Studio) I realised how much better they were in general. ![]() I guess VSCode seems to march to its own drum and some of how it integrates things is really clunky still. got better recently (the C# Plugin is now a full on full Microsoft first party offering), but VSCode is still less like an IDE, more like a code editor. Visual Studio 2022 is pretty buggy recently, especially for mobile, which is the bulk of what I do recently. Rider is hands down better at refactoring and generally having features "out of the box". So - I'm not a Java programmer, but I do a lot of C# in Visual Studio 2022, Visual Studio Code and JetBrains Rider (which is built on the InteliJ engine), so I guess I have a unique perspective.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |