I can completely empathize with your need for IntelliSense. In fact, when I've had the need to switch to Visual Studio (+ReSharper) and to VS Code (with ample plugins), I've always had the feeling: where is my IntelliSense. That's to say, those of Visual Studio and VS Code at their best, are rather limited compared to what IntelliJ (community and ultimate editon alike) feature out of the box. It's unfortunate that you need to work with a lesser editor for your studies, but do keep in mind that if you were forced to C# in a plain-text editor, that would also not have any bearing on the value of C# as a language or development environment.
Linq is indeed one of the (few) things that the C# environment has done much better that Java (streams in Java are indeed more verbose). With proper intellisense though, writing that code isn't any more effort than writing Linq queries. As with anything: in a professional setting, leveraging your IDE's capabilities is a must; you're not there to write characters, you're there to implement logic, and your IDE tends to be better at low-level logic than you are.
As to explicit type declarations, that's where we can easily get into philosophical discussions. An important part of OOP and its design patterns, is developing against interfaces. Though it saves some characters, var makes you not base yourself on interfaces, and (imo, though YMMV) more easily leads to procedural rather than OOP code.
With regard to upcase and lowercase types:
There's primitive int and a boxed/object Integer
There's a primitive boolean and a boxed/object Boolean
There's no primite string, because it's inherently a collection of characters and therefore an object
Same here as with the other things you mentioned: what you see in your academic course doesn't necessary reflect the whole of Java (it's a bit perplexing that they've not mentioned boxed Integer vs unboxed int.)
With regard to explicit getters and setters, the C# approach does save some characters, but in doing that bypasses the whole point of encapsulations, since there is no real difference with working directly with the fields themselves. For pure DTOs in Java, perhaps have a look at project Lombok which reduces the boilerplate code far beyond C#'s approach (though again, the amount characters are mostly irrelevant when you have a good IDE to lean on).
Good luck with the rest of your course(s) and hope this helps a bit :).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I can completely empathize with your need for IntelliSense. In fact, when I've had the need to switch to Visual Studio (+ReSharper) and to VS Code (with ample plugins), I've always had the feeling: where is my IntelliSense. That's to say, those of Visual Studio and VS Code at their best, are rather limited compared to what IntelliJ (community and ultimate editon alike) feature out of the box. It's unfortunate that you need to work with a lesser editor for your studies, but do keep in mind that if you were forced to C# in a plain-text editor, that would also not have any bearing on the value of C# as a language or development environment.
Linq is indeed one of the (few) things that the C# environment has done much better that Java (streams in Java are indeed more verbose). With proper intellisense though, writing that code isn't any more effort than writing Linq queries. As with anything: in a professional setting, leveraging your IDE's capabilities is a must; you're not there to write characters, you're there to implement logic, and your IDE tends to be better at low-level logic than you are.
As to explicit type declarations, that's where we can easily get into philosophical discussions. An important part of OOP and its design patterns, is developing against interfaces. Though it saves some characters,
varmakes you not base yourself on interfaces, and (imo, though YMMV) more easily leads to procedural rather than OOP code.With regard to upcase and lowercase types:
With regard to explicit getters and setters, the C# approach does save some characters, but in doing that bypasses the whole point of encapsulations, since there is no real difference with working directly with the fields themselves. For pure DTOs in Java, perhaps have a look at project Lombok which reduces the boilerplate code far beyond C#'s approach (though again, the amount characters are mostly irrelevant when you have a good IDE to lean on).
Good luck with the rest of your course(s) and hope this helps a bit :).