Yeah, I see it screwed up my Java code too, bleh. Anyway, you shouldn't have issues with Java and generics WRT that sort of type safety. There's never a need to explicitly cast, unless of course for whatever oddball reason you create something like List<? Extends Foo> and I frankly have never found a reason to do that.
You've been able to supply a comparator to a sort, or to a collection with a concept of order, forever. I mean if I were to paste in an example it would seem a little clunky by comparison to Ruby, since it would require a bit of extra declaration, but its the same basic thing. I've got an entire order matching engine core class that utilizes this concept to implement multiple different selection criteria for orders. And nobody uses a loop for this sort of thing, you use currying, even in Java. Or at least you simply call a method that returns a list of results that match your criteria in some preferred order.
I don't do a lot of anonymous class boilerplate, but then I don't write a ton of UIs in Java either. Outside of that particular use-case its not all that common. When I do have inner classes they are generally non-trivial, at which point a couple extra lines of boilerplate is a wash really.
There's nothing wrong with Lambdas, but they're overhyped, and they can lead to some very unclear code.
I don't think your example of type erasure is even relevant.
ArrayList myStrings = new ArrayList();... String tmp = (String)myStrings.get(0);
Isn't even good Java, the compiler WILL issue a warning about it. Your IDE should flag it as non-typesafe code too.
List mystrings = new ArrayList(); String tmp = myStrings.get(0);
This would be the proper way to code this. There's no issue with type erasure here, although you CAN devise some dubious uses of a generic collection where C# or C++ would throw an error EARLIER during execution than Java will. Its hardly a huge big issue. If you use unsafe constructs or reflection to invoke generic methods, well, you may get what you deserved!
What cracks me up are Java accessors and mutators that don't do any thing other than store and retrieve a value.
public void setIdiocy(SomeType idiot) { this.idiot=idiot; }
Just make the fields public, it is the same thing.
No it isn't, and your failure to understand the difference betrays your lack of experience with maintaining large code bases over time in the face of constant refactoring. A public field exposes the implementation of the class, a public getter/setter does not. Maybe it doesn't matter to you today, but I code with a decade from now in mind, and the trivial overhead of small extra abstractions is worth it. Now, C#'s "it looks like a field but its really an accessor" is OK, but it can confuse the uninitiated. I prefer overall a lack of these sorts of features, it doesn't take being burned twice to eat up all the benefits such a thing will ever produce.
That's the best analogy here. Sooner or later you get a bit too complacent, and then BANG! Every system is flawed as long as it has humans in it. What we need are robot police and prison guards, errrrr overlords! Yeah! lol.
People are being imprisoned for essentially 'made up' reasons, yes. For instance you might be one of a certain unfortunate minority who is constantly pulled over by the cops basically for every conceivable excuse. Now if you were me (a WASP) you might get a warning for your tail light being burned out (as I did a while back by a cop who was very polite). If you're not so fortunate you're getting tossed against the fender of your car, beat up side the head, and when you object you're tossed in jail for 'resisting arrest' or some variation thereof. Now, after a couple weeks, when your job is good and set sail, etc. You will come up before a judge, who will not only give you 30 days, but charge you about $1000 for "court system costs" and when you obviously can't pay them, you'll spend literally an unlimited amount of time in prison until you're so lucky as to have someone cough up the money (Oh, and on top of that a prison housing fee, meanwhile you get to do prison labor for $1 a day which some business profits off of).
If you doubt me, do a little research, this is literally the standard operating procedure in most of the US today. Even black children are incarcerated like this and put in debt bondage to the state, though the charges will be school-related (delinquency, assault for talking back to a teacher, etc). Welcome to Prison World!
Eh, no simple correspondence here. I mean, sure there are a couple of forms that correspond pretty closely to some entities in the management UI that we use, but there's a lot of rather complex logic and many of these entities are used in a number of different processes. Its just that Java, and certainly JavaEE, heavily encourages the 'DTO' or 'Bean' model where entities are generally containers and if they have logic its purely related to things like interrelated properties, consistency, etc.
I don't find your characterization of Java to be that accurate, but what you find 'irritating' may be far different from what bothers me. I want simple regular syntax that doesn't offer a ton of alternatives. That leads to consistent maintainable code. Making things explicit also leads to more thorough and comprehensive testing and documentation. I have LOADS of 500 line class files that implement complex business logic. I need them to be intelligible to anyone that looks at them, not models of clever syntax that manage to get trimmed down to 425 lines, but are less clear. I am happy with conciseness, its good, but its not always the primary goal.
Well, at any rate, I think the notion that.NET is 'in decline' is probably dubious at best. I don't know where its going, but it hardly seems likely that MS is about to abandon the whole technology. I WOULD say however that MS's hold on the 'back room' is pretty tenuous these days. They never really won the argument as to overall value proposition of Windows in the server room over *nix. They have virtually no penetration in the OSS server space, and Mono really went no place there either. Its a pretty hard sell to suggest a.NET/IIS based line-of-business solution to larger IT organizations these days. The more sophisticated shops just stick with Java and the smaller ones tend to either utilize some tool specific to their vertical or built PHP apps or something.
I think that pretty well explains MS's push with open sourcing a lot of stuff, and getting behind.NET both on every client device and on every server platform. The dream of the total end-to-end dominance of Windows was a LONG time dying, but its finally dead. Its an interesting situation. Java hasn't exactly penetrated the client side space in a consistent way either, so there's plenty of room for each toolset to try to differentiate itself.
The bigger question might be whether Oracle really cares enough about Java to keep playing this game. They've done a lot, but OTOH they're basically selling database server licenses, with OAS as a sideline that supports the consulting side of the company. Even if they stopped supporting Java it wouldn't really impact their core business that much, at least in the near-term. MS OTOH is in a more ambiguous position. Its not even clear what their core business is going forward. MS Office? SQL Server? MSVS/dev tools? I don't think they know...
I wouldn't say Java is utterly consistent. Its pretty generic though, and I like that. If you know C you can pretty well understand the flow of code in a Java method, and if you have a general understanding of OOP then you will pretty much understand Java. I think the same can be said for C#.
Frankly I was considering using a scripting language to write some test driver code. I figured it would be a little less tedious and easier, but what I found was that with a modern IDE it just wasn't worth the bother. Yeah, I could make my test harness a little simpler, and in theory I could even edit it without recompiling, but it was just plain easier to write the stuff in Java, its just not that hard to code in.
I mean there are very definite use cases for scripting, but its not like the old days where it was much easier than coding in a compiled language.
I think the problem is that you can make a higher quality product using Qt, but it IS more expensive. Writing C# code, or Java line-of-business stuff is just more cost-effective when the use cases are very specific. I mean I wouldn't write some one-off program to manage some tiddly business process somewhere in C++/Qt because nobody cares if it has to run on a Windows box, and nobody cares if it is fast, small, or even all that reliable. So a vast array of stuff exists in these environments.
Then there's super high-reliability stuff, like most of the code I write. It has to handle 400 million transactions in a week and never crash, never miss one, etc. It certainly COULD be written in C++, but the hunt for stupid programming errors you can't make in Java just makes it more costly. Its also easier to train a Java/C# guy to a level where he can do decent work.
Removing getters and setters matters? pfff, right. If you have logic in your value entities in general its a bad thing, so why do you even look at these files? Mine were all generated automagically 10+ years ago by some Hibernate tool. Once in a while I add a constructor, tweak an.equals() method, etc. A few have get/set methods that include some logic (caching some expensive to calculate value or somesuch) but I could care less. I mean, really, if you want to avoid getters and setters in Java, just declare your fields to be public, it works fine, except of course for the lack of information hiding, which is of course ALSO the problem with C#'s set/get notation. If I make something a calculated value, it changes the consumer's syntax, potentially. Its also a bit unclear to people when you start mixing pure value fields with calculated ones and using the same syntax that they expect to be reserved for one of those.
I don't think C# is BAD, I just think its much vaunted 'advances' over Java are at best minor tweaks, and Java does some things better than C# too. It would be great if we had the best of both in one, but it isn't happening, so really its 6 of one and half-dozen of the other.
Personally I think QT beats the pants off any other UI toolkit on any platform, but that's just me. I'd kill to have something that good in Java (IBM reputedly built QT bindings for SWT, but they were never released for whatever reason, assuming they really even existed).
What happens if you need to store a date before 1970? What if you need a date with more resolution than a millisecond?
But I never ever ever will. I know my problem domain. If I was writing code that was going to be used to measure picoseconds, then by gosh I'd use a different scaling. Since nobody will ever give a crud to more than a millisecond in my problem domain you would be asking me to carry a large amount of crap baggage around my code for some non-existing fairytale use case. Same for dates prior to 1970, I'm not doing archaeology here, I'm doing financial transactions. I will never see any date prior to NOW() ever again...
Also, perhaps operator overloading can be misused, but it comes in really handy when you have a class that actually represents a number. You probably don't want to start overriding the plus operator for objects that store XML documents or twitter messages, but that doesn't mean the feature shouldn't exist at all.
Eh, in my quite large amount of programming experience I've seen lots of quite ugly misuses of operator overloads. It MIGHT make some decimal arithmetic slightly cleaner, but I'd most likely have to surround the '+' with extra guards, check rounding and possible precision issues anyway, etc, so it wouldn't gain me very much. Maybe there are cases, in a math package or something, where it might be handy. I'm perfectly happy with the decision to not support it, as I benefit from that everyday in knowing what exactly '+' does and not having to worry about it. Again, its the real gain vs the hypothetical gain. IMHO KISS is the best policy.
And perhaps you should do some reading about the.Net decimal data type. It has 28 significant digits. That means that even if you need 8 decimal places (like for bitcoin) you still have enough digits left over to represent extremely large numbers. Basically it has enough range to cover just about every financial transaction most coders are likely to deal with. Most databases (all) have a decimal data type for storing binary coded decimal information. The programming language you're using should also support them.
And it does, with individually settable precision, rounding, and scaling. Its really quite good. Yes, you must perforce use the object method call notation to do your math, but you'd have to do that anyway for anything very complex, and its not like stopPx.add(orderMarkdown).setScale(inst.get("PRICEDIGITS") is that horrendous, or appears 1000's of times in code. So everything I need to do IS supported in a way that's usually reasonably clear and concise. If I generate an SQL query with a DECIMAL(M,N) valued column I get the corresponding BigDecimal representation, all nice and neat!
I don't understand the fetish with LOC. All that crap that you bemoan is just crap that's generated by the IDE, or often not really needed at all if you know what you're doing. Nor is it true that C# is free of all that jazz either. You still have to define your classes and for any specific design pattern it is going to be pretty much the same classes, subclasses, etc.
If you are constantly implementing generics then you're doing it wrong IMHO. Implementation of generics should be VERY rare. I wrote and continue to extend and maintain a very complex and large Java code-base. There are maybe at most 6 generic classes in there, and I'd say 3 of them were probably mistakes that you'll only encounter if you dig deep into some very specific code. The others work fine.
While I don't have any beef against list comprehensions or whatnot they're just loops. There's nothing special about them, or lambda's either really. Its a perfectly valid stylistic choice to avoid the implicit nature of such things and simply write for(String value : props.values()) {... } or whatever.
AWT and Swing are both obsolete and aimed at the same niche as JavaFX (though in all fairness you will use a number of Swing APIs in pretty much any UI project). AWT and Swing were never intended to be 'run anywhere' UIs, they were just intended to be 'if you have Java you have this API' UIs. The whole reason Oracle sued Google over Android is that they've been breaking that. As for SWT (IBM's Eclipse GUI toolkit) it can in principle work anywhere there are bindings to the underlying UI toolkit (it is a thin wrapper), but it hasn't proven to be super popular aside from corporate applications built on top of the Eclipse core (RCP). I think Google's motivation was to simply have the best and most convenient UI toolkit for the Android platform. Swing was built to work with desktops, it would have had to be totally reworked ANYWAY to adapt to the modern age.
So, in essence, Java is in no worse a pickle than.NET, who's existing UI toolkits were also poorly adapted to mobile devices, fractured (GTK+ vs WFC/WinForms), etc. Xamarin hopes to unify that, good luck to them. It could be as well done in Java as.NET frankly.
Well, considering that iOS is only supported through a 'compile to binary' option, that's not quite as clean and easy as you make it out to be. You can also compile Java to binary BTW, and presumably execute it on an iOS device. Eclipse and GIT will give you all the tooling you need to push your code around between various platforms. Its really pretty much a tossup. I think Java has focused more on back-end and Xamarin is making a play for strictly the user-facing app side of things, but they're both broadly capable of doing the same things.
Well, you have your opinion, I've written millions of lines of Java code now, and I have my opinion. I don't really hate C#/.NET, there's just no reason to go with them when Java is already there and does the job quite well thank you!
As for Xamarin, we shall see. Xamarin.iOS is sort of a bastard, your application has to be compiled down to static machine code to meet Apple's requirements. So it isn't really any more '.NET' than GNU's Java compiler is, which can also produce executables (and presumably can target iOS though I don't know of anyone bothering to do that). Of course Java on Android is also 'weird', but at least its still bytecode, even if it isn't java-compliant bytecode.
Honestly I don't know how much of a difference any of this makes. If I were building a TRUE 'run it anywhere' codebase I'd use C++ and QT, it really does run ANYWHERE, including windows, OS-X, iOS, Android, and basically just about any other OS that has any sort of GUI.
Actually Java ON THE DESKTOP has no more security implications than any code written in any other language. Worst case it does something nasty, and Java does NOT sandbox your primary application thread or any of its spawn unless you specifically configure it to do so. So DESKTOP Java is a non-issue.
As for web-browser Java plugins, those are just like all other plugins. They've proven to be open to a number of exploits. If you wouldn't use Flash or Silverlight why would you expect to be able to use Java? I mean I wish Oracle would FIX these issues, but my guess is every piece of web-exposed code in existence is riddled with an endless supply of these security holes, not just plugins.
On the SERVER side there's again no issue, Java is no more or less a security problem than any other application running on your server, all of which you presumably have locked down, vetted heavily, and watch carefully.
There's really no special particular 'Java' security issue. Using.NET, Node.js etc etc etc won't particularly make you more secure on the server-side, and for the rest Java is the same as anything else too. Welcome to the world.
Yeah, that's the problem. You never know what sort of bad code you're calling in some library. You can try to use only the latest and greatest stuff, but that comes with a price too, and a lot of really critical functionality only exists in really old code that will probably never get cleaned up.
The other problem is that for people like me, who have done only limited amounts of C++ coding, the language is especially treacherous. Its great that it HAS ways to do things 'right', but it also has ever evil bad way to do it wrong, and learning the difference really does take years.
Doesn't seem like that big a deal to me. First of all, EVERYTHING, has some sort of scaling limitation, so if you are going to use the multiply trick, then just use a BIG number, one that will never be an issue.
I hate operator overloading, and this is a point in favor of Java, they eschewed things of little value that add lots of coder overhead to sort out when they go wrong. The code base I maintain is financial code, handling transactions, and even more special than that it has to work in every currency and handle precision that varies from 2 to 7 decimal places (and that has to be configurable everywhere for each flavor of transaction and account). I don't know if this could even be handled by a BCD data type or not. Its not simply a matter of scaling, there are complexities around how different numbers are rounded, cumulative error, etc. These can be handled using BigDecimal and some additional bookkeeping, but even if C#'s decimal type would work, it would only save a pretty small amount of code. Its quite possible it wouldn't work anyway.
I'm just not sure why people have problems with dates. I made an architectural decision a LONG time back, every date is a long milliseconds of Unix epoch, and never looked back. Client software can do whatever it wants with that. Javascript has a perfectly fine function to render that right into the browser's locale, and Java clients will format it by default into the local time format for output. My feeling is that the vast majority of date problems people have are because their data architecture is poorly chosen. In the few cases where you find yourself forced to say parse some random junk from some file, use GregorianCalendar, it works quite nicely and along with DateFormat you're mostly pretty much set. If you work with some horrible old code that tries to make the old Date object do the right thing, meh, well, we all bear the crosses of ancient mistakes.
Now, don't get me wrong. In think MS took a good look at Java and made a few minor improvements. OTOH a lot of their libraries kinda suck too, so its a bit of a tossup. If we could take the both of best worlds I'd be thrilled. Whatever the result was, it just has to compile my millions of $ worth of existing code...;)
Yeah, yeah. We've heard this before. Back in the day, people were saying the same things about those new-fangled "for" and "while" loops. After all, we want our code to be comprehensible! A loop doesn't do anything for me that I can't do with a goto, and at least I can see instantly, "yep, that's a control flow transfer!".
Oh, good lord, its not even close to the same thing, there's nothing AT ALL obtuse about:
for(String value : props.values()) {.... do something, which can easily be a call to another method, and probably should, lambda or not....
}
I mean its fine to make realistic arguments, but calling for and while loops "just like goto" is preposterous.
Meanwhile, people have embraced the new tools (which are the majority outside of the Java land - even the C++ guys have and use lambdas now), and they became idiomatic, and standard libraries were upgraded to rely on them - making them both more powerful and easier to read. As it happens, I use both C# and C++, and it's a rare day at work that I don't use a lambda anywhere. Looking at other people's [quality] code, it's mostly similar. And guess what? It's all still perfectly readable, so long as you take some time and learn how it works. In most cases, in fact, it's more readable than the code that it replaced, and more maintainable to boot (because DRY).
"Its fashionable so you should do it too" is not an argument, its lazy. I am constantly, and always have been constantly, lauded for the extremely fine quality of code that I write. I refactor constantly and have many years of experience reusing and refactoring code. I don't know of ANY significant benefit in terms of code reuse of features that are present in C# and missing in Java. I could write the gospel on code reuse, believe me.
If you don't have first-class functions in a language, you'll be doing a lot of of DRY for that reason alone (yes, you can use anon classes instead, but no-one actually does because it's so verbose it defeats the point). If I have to explain how and why that works, then you should probably go read some FP tutorial.
Oh, good grief! I use these things all the time. They are quite explicit and you have the choice to use anonymous, inner, or outer classes, which is often quite nice and in more complicated UIs is what you often want to do anyway. Its just not a big deal, and there's again no impact on DRY unless you have some sort of incredibly lazy coders that should be kicked off the project or something.
It's kinda like the iOS app store. Sure, it has 3 million apps, but in practice you need maybe 30 for any particular case, and 300 across everything. I won't dispute that Java has more libraries, but pretty much any mainstream language/platform these days, including.NET, has all the libraries that matter, for the simple reason that all of them have a fairly large community that will write or wrap one if they need it. I don't recall ever running into a situation where I couldn't find a library to do something that I needed to do, in any popular language.
Well, mostly this is true. There's often a greater range of choices with Java libraries, which CAN be quite nice. In terms of larger assemblies of code there's MUCH more variety. Part of the reason being that Java didn't try to nail things like enterprise architecture down in the core system nearly as much. There are easily 8 different free high-quality containers for instance, many different persistence tools, etc..NET tends to have what MS provided, or else a port of one or two of what is available in Java. Sometimes that's for the best, other times maybe not so much.
Truthfully, procedural static highly typed OO languages were mostly perfected long before Java or C# got on the scene. Anything that has been added in the last 10 years is trivial compared to the huge advances of the 80's and 90's. I mean I
Perhaps, but that begs the "why not just go with Java?" question, since it supports both Android and every desktop OS (and lets face it NOTHING runs on both iOS and everything else, that's a pipe dream, unless you want to do QT stuff, which is great, but begs ANOTHER question, "why not just use QT/C++?").
And you know what? We don't use any of that stuff, because we want our code to be COMPREHENSIBLE. Lambdas don't do anything for me that I can't do with a loop, and at least I can see instantly "Yep, that's a loop!" For the very few cases where it might be helpful, that's great, but its really VERY few cases. I have yet to write one.
Java's generics are fine. They do the most important part of being generics perfectly well. Again, the things that you seem to want of them are things that negatively impact maintainability in most cases. Truthfully you are VERY rarely going to want to design your own generics. I've done it 5 or 6 times in the last 10 years, and at least 2-3 of those times were probably not good ideas. Consuming generics is great though.
As for DRY... I'm at a loss why anyone would think that you'd repeat yourself in Java. There are all sorts of tools for avoiding that. I've got a million line code base, nothing that shouldn't be repeated is repeated. Application logic exists in one place, everything is highly modular, and I don't find it any more verbose than any other statically typed strict OO language. I think MS certainly looked carefully at Java and in some very minor ways improved on the syntax, but at worst the difference is small, and with Java's vast arrays of libraries, frameworks, and tools, its hard to beat. Chances are MUCH higher you'll end up doing more work in C# simply because you can't find exactly the tool you need. You might write 5 lines less application code, in theory, but you'll end up implementing some whole library that I got for free off apache.org.
Could be. I use Eclipse because it does what I need it to do. There are definitely other toolsets out there that are really good. IntelliJ has a huge rep nowadays. NetBeans is really no slouch either. Still, for enterprise development Eclipse is a workhorse. There are plugins to do everything under the Sun. Many of them are kinda less than perfect, but they work, and there's tight integration with pretty much every OSS or 'community' sort of workflow tool you would ever want.
I don't think MS is going to 'stop supporting'.NET. Hell, Visual FoxPro 9 SP2 was released as late as 2007 and there were hotfixes released as late as 2010. Granted, MS hasn't really supported it in a big way in about 10 years, but it was a LOOOOONNNNNGGGGG time 'dying', and there are still quite a few users.
Even if.NET were to follow VFP its going to have active support for AT LEAST the next 10 years. Given that MS has no other similar product or reason to ditch this one in favor of another, as well as various active ongoing technology programs that build on the.NET CLR it hardly seems likely to fade very fast.
I think what MS has determined is that their boundless enthusiasm for managed code was a bit over-the-top. It makes sense as an approach for 'apps' and less-demanding or 'internal use' type applications. I think they've also realized that the real value of such an environment is in Java's niche, as a high performance platform-agnostic host for business logic. Unfortunately for them they'll never displace Java in that niche. That boat has sailed.
Still, MS itself will in all probability continue to write.NET applications. C++ is a great language, but it takes a huge amount of effort to deal with memory management issues and such crap. C++ is also a language filled with lots of pitfalls. It is incredibly easy to write bad C++ code, and you really need to study the language itself for a few years just to be a truly competent coder. Frankly I just stick to Java, but if I was a.NET guy I'd just stick with that. Why not?
I wonder about HTML5/Javascript. Personally I think Javascript is another terrible language. We're kind of stuck with it, but between the terribleness of HTML, the terribleness of the DOM, and the terribleness of JS writing UIs in that environment really is a pretty awful and expensive process. We've found that with JavaFX (and no doubt other equally good toolsets) we can write a UI in 1/2 or 1/3 of the time it takes to do the same quality of work in HTML/JS. While it is certainly not going anywhere in the near future I have to see this whole paradigm as ripe to fall. MS may think they've hitched their wagon to the final answer, but IMHO something much better will come along before too much longer.
Slashdot Mirror
Yeah, I see it screwed up my Java code too, bleh. Anyway, you shouldn't have issues with Java and generics WRT that sort of type safety. There's never a need to explicitly cast, unless of course for whatever oddball reason you create something like List<? Extends Foo> and I frankly have never found a reason to do that.
You've been able to supply a comparator to a sort, or to a collection with a concept of order, forever. I mean if I were to paste in an example it would seem a little clunky by comparison to Ruby, since it would require a bit of extra declaration, but its the same basic thing. I've got an entire order matching engine core class that utilizes this concept to implement multiple different selection criteria for orders. And nobody uses a loop for this sort of thing, you use currying, even in Java. Or at least you simply call a method that returns a list of results that match your criteria in some preferred order.
I don't do a lot of anonymous class boilerplate, but then I don't write a ton of UIs in Java either. Outside of that particular use-case its not all that common. When I do have inner classes they are generally non-trivial, at which point a couple extra lines of boilerplate is a wash really.
There's nothing wrong with Lambdas, but they're overhyped, and they can lead to some very unclear code.
I don't think your example of type erasure is even relevant.
ArrayList myStrings = new ArrayList();
String tmp = (String)myStrings.get(0);
Isn't even good Java, the compiler WILL issue a warning about it. Your IDE should flag it as non-typesafe code too.
List mystrings = new ArrayList();
String tmp = myStrings.get(0);
This would be the proper way to code this. There's no issue with type erasure here, although you CAN devise some dubious uses of a generic collection where C# or C++ would throw an error EARLIER during execution than Java will. Its hardly a huge big issue. If you use unsafe constructs or reflection to invoke generic methods, well, you may get what you deserved!
What cracks me up are Java accessors and mutators that don't do any thing other than store and retrieve a value.
public void setIdiocy(SomeType idiot) {
this.idiot=idiot;
}
Just make the fields public, it is the same thing.
No it isn't, and your failure to understand the difference betrays your lack of experience with maintaining large code bases over time in the face of constant refactoring. A public field exposes the implementation of the class, a public getter/setter does not. Maybe it doesn't matter to you today, but I code with a decade from now in mind, and the trivial overhead of small extra abstractions is worth it. Now, C#'s "it looks like a field but its really an accessor" is OK, but it can confuse the uninitiated. I prefer overall a lack of these sorts of features, it doesn't take being burned twice to eat up all the benefits such a thing will ever produce.
That's the best analogy here. Sooner or later you get a bit too complacent, and then BANG! Every system is flawed as long as it has humans in it. What we need are robot police and prison guards, errrrr overlords! Yeah! lol.
People are being imprisoned for essentially 'made up' reasons, yes. For instance you might be one of a certain unfortunate minority who is constantly pulled over by the cops basically for every conceivable excuse. Now if you were me (a WASP) you might get a warning for your tail light being burned out (as I did a while back by a cop who was very polite). If you're not so fortunate you're getting tossed against the fender of your car, beat up side the head, and when you object you're tossed in jail for 'resisting arrest' or some variation thereof. Now, after a couple weeks, when your job is good and set sail, etc. You will come up before a judge, who will not only give you 30 days, but charge you about $1000 for "court system costs" and when you obviously can't pay them, you'll spend literally an unlimited amount of time in prison until you're so lucky as to have someone cough up the money (Oh, and on top of that a prison housing fee, meanwhile you get to do prison labor for $1 a day which some business profits off of).
If you doubt me, do a little research, this is literally the standard operating procedure in most of the US today. Even black children are incarcerated like this and put in debt bondage to the state, though the charges will be school-related (delinquency, assault for talking back to a teacher, etc). Welcome to Prison World!
Eh, no simple correspondence here. I mean, sure there are a couple of forms that correspond pretty closely to some entities in the management UI that we use, but there's a lot of rather complex logic and many of these entities are used in a number of different processes. Its just that Java, and certainly JavaEE, heavily encourages the 'DTO' or 'Bean' model where entities are generally containers and if they have logic its purely related to things like interrelated properties, consistency, etc.
I don't find your characterization of Java to be that accurate, but what you find 'irritating' may be far different from what bothers me. I want simple regular syntax that doesn't offer a ton of alternatives. That leads to consistent maintainable code. Making things explicit also leads to more thorough and comprehensive testing and documentation. I have LOADS of 500 line class files that implement complex business logic. I need them to be intelligible to anyone that looks at them, not models of clever syntax that manage to get trimmed down to 425 lines, but are less clear. I am happy with conciseness, its good, but its not always the primary goal.
Well, at any rate, I think the notion that .NET is 'in decline' is probably dubious at best. I don't know where its going, but it hardly seems likely that MS is about to abandon the whole technology. I WOULD say however that MS's hold on the 'back room' is pretty tenuous these days. They never really won the argument as to overall value proposition of Windows in the server room over *nix. They have virtually no penetration in the OSS server space, and Mono really went no place there either. Its a pretty hard sell to suggest a .NET/IIS based line-of-business solution to larger IT organizations these days. The more sophisticated shops just stick with Java and the smaller ones tend to either utilize some tool specific to their vertical or built PHP apps or something.
I think that pretty well explains MS's push with open sourcing a lot of stuff, and getting behind .NET both on every client device and on every server platform. The dream of the total end-to-end dominance of Windows was a LONG time dying, but its finally dead. Its an interesting situation. Java hasn't exactly penetrated the client side space in a consistent way either, so there's plenty of room for each toolset to try to differentiate itself.
The bigger question might be whether Oracle really cares enough about Java to keep playing this game. They've done a lot, but OTOH they're basically selling database server licenses, with OAS as a sideline that supports the consulting side of the company. Even if they stopped supporting Java it wouldn't really impact their core business that much, at least in the near-term. MS OTOH is in a more ambiguous position. Its not even clear what their core business is going forward. MS Office? SQL Server? MSVS/dev tools? I don't think they know...
I wouldn't say Java is utterly consistent. Its pretty generic though, and I like that. If you know C you can pretty well understand the flow of code in a Java method, and if you have a general understanding of OOP then you will pretty much understand Java. I think the same can be said for C#.
Frankly I was considering using a scripting language to write some test driver code. I figured it would be a little less tedious and easier, but what I found was that with a modern IDE it just wasn't worth the bother. Yeah, I could make my test harness a little simpler, and in theory I could even edit it without recompiling, but it was just plain easier to write the stuff in Java, its just not that hard to code in.
I mean there are very definite use cases for scripting, but its not like the old days where it was much easier than coding in a compiled language.
I think the problem is that you can make a higher quality product using Qt, but it IS more expensive. Writing C# code, or Java line-of-business stuff is just more cost-effective when the use cases are very specific. I mean I wouldn't write some one-off program to manage some tiddly business process somewhere in C++/Qt because nobody cares if it has to run on a Windows box, and nobody cares if it is fast, small, or even all that reliable. So a vast array of stuff exists in these environments.
Then there's super high-reliability stuff, like most of the code I write. It has to handle 400 million transactions in a week and never crash, never miss one, etc. It certainly COULD be written in C++, but the hunt for stupid programming errors you can't make in Java just makes it more costly. Its also easier to train a Java/C# guy to a level where he can do decent work.
Removing getters and setters matters? pfff, right. If you have logic in your value entities in general its a bad thing, so why do you even look at these files? Mine were all generated automagically 10+ years ago by some Hibernate tool. Once in a while I add a constructor, tweak an .equals() method, etc. A few have get/set methods that include some logic (caching some expensive to calculate value or somesuch) but I could care less. I mean, really, if you want to avoid getters and setters in Java, just declare your fields to be public, it works fine, except of course for the lack of information hiding, which is of course ALSO the problem with C#'s set/get notation. If I make something a calculated value, it changes the consumer's syntax, potentially. Its also a bit unclear to people when you start mixing pure value fields with calculated ones and using the same syntax that they expect to be reserved for one of those.
I don't think C# is BAD, I just think its much vaunted 'advances' over Java are at best minor tweaks, and Java does some things better than C# too. It would be great if we had the best of both in one, but it isn't happening, so really its 6 of one and half-dozen of the other.
Personally I think QT beats the pants off any other UI toolkit on any platform, but that's just me. I'd kill to have something that good in Java (IBM reputedly built QT bindings for SWT, but they were never released for whatever reason, assuming they really even existed).
What happens if you need to store a date before 1970? What if you need a date with more resolution than a millisecond?
But I never ever ever will. I know my problem domain. If I was writing code that was going to be used to measure picoseconds, then by gosh I'd use a different scaling. Since nobody will ever give a crud to more than a millisecond in my problem domain you would be asking me to carry a large amount of crap baggage around my code for some non-existing fairytale use case. Same for dates prior to 1970, I'm not doing archaeology here, I'm doing financial transactions. I will never see any date prior to NOW() ever again...
Also, perhaps operator overloading can be misused, but it comes in really handy when you have a class that actually represents a number. You probably don't want to start overriding the plus operator for objects that store XML documents or twitter messages, but that doesn't mean the feature shouldn't exist at all.
Eh, in my quite large amount of programming experience I've seen lots of quite ugly misuses of operator overloads. It MIGHT make some decimal arithmetic slightly cleaner, but I'd most likely have to surround the '+' with extra guards, check rounding and possible precision issues anyway, etc, so it wouldn't gain me very much. Maybe there are cases, in a math package or something, where it might be handy. I'm perfectly happy with the decision to not support it, as I benefit from that everyday in knowing what exactly '+' does and not having to worry about it. Again, its the real gain vs the hypothetical gain. IMHO KISS is the best policy.
And perhaps you should do some reading about the .Net decimal data type. It has 28 significant digits. That means that even if you need 8 decimal places (like for bitcoin) you still have enough digits left over to represent extremely large numbers. Basically it has enough range to cover just about every financial transaction most coders are likely to deal with. Most databases (all) have a decimal data type for storing binary coded decimal information. The programming language you're using should also support them.
And it does, with individually settable precision, rounding, and scaling. Its really quite good. Yes, you must perforce use the object method call notation to do your math, but you'd have to do that anyway for anything very complex, and its not like stopPx.add(orderMarkdown).setScale(inst.get("PRICEDIGITS") is that horrendous, or appears 1000's of times in code. So everything I need to do IS supported in a way that's usually reasonably clear and concise. If I generate an SQL query with a DECIMAL(M,N) valued column I get the corresponding BigDecimal representation, all nice and neat!
I don't understand the fetish with LOC. All that crap that you bemoan is just crap that's generated by the IDE, or often not really needed at all if you know what you're doing. Nor is it true that C# is free of all that jazz either. You still have to define your classes and for any specific design pattern it is going to be pretty much the same classes, subclasses, etc.
If you are constantly implementing generics then you're doing it wrong IMHO. Implementation of generics should be VERY rare. I wrote and continue to extend and maintain a very complex and large Java code-base. There are maybe at most 6 generic classes in there, and I'd say 3 of them were probably mistakes that you'll only encounter if you dig deep into some very specific code. The others work fine.
While I don't have any beef against list comprehensions or whatnot they're just loops. There's nothing special about them, or lambda's either really. Its a perfectly valid stylistic choice to avoid the implicit nature of such things and simply write for(String value : props.values()) { ... } or whatever.
AWT and Swing are both obsolete and aimed at the same niche as JavaFX (though in all fairness you will use a number of Swing APIs in pretty much any UI project). AWT and Swing were never intended to be 'run anywhere' UIs, they were just intended to be 'if you have Java you have this API' UIs. The whole reason Oracle sued Google over Android is that they've been breaking that. As for SWT (IBM's Eclipse GUI toolkit) it can in principle work anywhere there are bindings to the underlying UI toolkit (it is a thin wrapper), but it hasn't proven to be super popular aside from corporate applications built on top of the Eclipse core (RCP). I think Google's motivation was to simply have the best and most convenient UI toolkit for the Android platform. Swing was built to work with desktops, it would have had to be totally reworked ANYWAY to adapt to the modern age.
So, in essence, Java is in no worse a pickle than .NET, who's existing UI toolkits were also poorly adapted to mobile devices, fractured (GTK+ vs WFC/WinForms), etc. Xamarin hopes to unify that, good luck to them. It could be as well done in Java as .NET frankly.
Well, considering that iOS is only supported through a 'compile to binary' option, that's not quite as clean and easy as you make it out to be. You can also compile Java to binary BTW, and presumably execute it on an iOS device. Eclipse and GIT will give you all the tooling you need to push your code around between various platforms. Its really pretty much a tossup. I think Java has focused more on back-end and Xamarin is making a play for strictly the user-facing app side of things, but they're both broadly capable of doing the same things.
Well, you have your opinion, I've written millions of lines of Java code now, and I have my opinion. I don't really hate C#/.NET, there's just no reason to go with them when Java is already there and does the job quite well thank you!
As for Xamarin, we shall see. Xamarin.iOS is sort of a bastard, your application has to be compiled down to static machine code to meet Apple's requirements. So it isn't really any more '.NET' than GNU's Java compiler is, which can also produce executables (and presumably can target iOS though I don't know of anyone bothering to do that). Of course Java on Android is also 'weird', but at least its still bytecode, even if it isn't java-compliant bytecode.
Honestly I don't know how much of a difference any of this makes. If I were building a TRUE 'run it anywhere' codebase I'd use C++ and QT, it really does run ANYWHERE, including windows, OS-X, iOS, Android, and basically just about any other OS that has any sort of GUI.
Actually Java ON THE DESKTOP has no more security implications than any code written in any other language. Worst case it does something nasty, and Java does NOT sandbox your primary application thread or any of its spawn unless you specifically configure it to do so. So DESKTOP Java is a non-issue.
As for web-browser Java plugins, those are just like all other plugins. They've proven to be open to a number of exploits. If you wouldn't use Flash or Silverlight why would you expect to be able to use Java? I mean I wish Oracle would FIX these issues, but my guess is every piece of web-exposed code in existence is riddled with an endless supply of these security holes, not just plugins.
On the SERVER side there's again no issue, Java is no more or less a security problem than any other application running on your server, all of which you presumably have locked down, vetted heavily, and watch carefully.
There's really no special particular 'Java' security issue. Using .NET, Node.js etc etc etc won't particularly make you more secure on the server-side, and for the rest Java is the same as anything else too. Welcome to the world.
Yeah, that's the problem. You never know what sort of bad code you're calling in some library. You can try to use only the latest and greatest stuff, but that comes with a price too, and a lot of really critical functionality only exists in really old code that will probably never get cleaned up.
The other problem is that for people like me, who have done only limited amounts of C++ coding, the language is especially treacherous. Its great that it HAS ways to do things 'right', but it also has ever evil bad way to do it wrong, and learning the difference really does take years.
Doesn't seem like that big a deal to me. First of all, EVERYTHING, has some sort of scaling limitation, so if you are going to use the multiply trick, then just use a BIG number, one that will never be an issue.
I hate operator overloading, and this is a point in favor of Java, they eschewed things of little value that add lots of coder overhead to sort out when they go wrong. The code base I maintain is financial code, handling transactions, and even more special than that it has to work in every currency and handle precision that varies from 2 to 7 decimal places (and that has to be configurable everywhere for each flavor of transaction and account). I don't know if this could even be handled by a BCD data type or not. Its not simply a matter of scaling, there are complexities around how different numbers are rounded, cumulative error, etc. These can be handled using BigDecimal and some additional bookkeeping, but even if C#'s decimal type would work, it would only save a pretty small amount of code. Its quite possible it wouldn't work anyway.
I'm just not sure why people have problems with dates. I made an architectural decision a LONG time back, every date is a long milliseconds of Unix epoch, and never looked back. Client software can do whatever it wants with that. Javascript has a perfectly fine function to render that right into the browser's locale, and Java clients will format it by default into the local time format for output. My feeling is that the vast majority of date problems people have are because their data architecture is poorly chosen. In the few cases where you find yourself forced to say parse some random junk from some file, use GregorianCalendar, it works quite nicely and along with DateFormat you're mostly pretty much set. If you work with some horrible old code that tries to make the old Date object do the right thing, meh, well, we all bear the crosses of ancient mistakes.
Now, don't get me wrong. In think MS took a good look at Java and made a few minor improvements. OTOH a lot of their libraries kinda suck too, so its a bit of a tossup. If we could take the both of best worlds I'd be thrilled. Whatever the result was, it just has to compile my millions of $ worth of existing code... ;)
Yeah, yeah. We've heard this before. Back in the day, people were saying the same things about those new-fangled "for" and "while" loops. After all, we want our code to be comprehensible! A loop doesn't do anything for me that I can't do with a goto, and at least I can see instantly, "yep, that's a control flow transfer!".
Oh, good lord, its not even close to the same thing, there's nothing AT ALL obtuse about: for(String value : props.values()) { .... do something, which can easily be a call to another method, and probably should, lambda or not....
}
I mean its fine to make realistic arguments, but calling for and while loops "just like goto" is preposterous.
Meanwhile, people have embraced the new tools (which are the majority outside of the Java land - even the C++ guys have and use lambdas now), and they became idiomatic, and standard libraries were upgraded to rely on them - making them both more powerful and easier to read. As it happens, I use both C# and C++, and it's a rare day at work that I don't use a lambda anywhere. Looking at other people's [quality] code, it's mostly similar. And guess what? It's all still perfectly readable, so long as you take some time and learn how it works. In most cases, in fact, it's more readable than the code that it replaced, and more maintainable to boot (because DRY).
"Its fashionable so you should do it too" is not an argument, its lazy. I am constantly, and always have been constantly, lauded for the extremely fine quality of code that I write. I refactor constantly and have many years of experience reusing and refactoring code. I don't know of ANY significant benefit in terms of code reuse of features that are present in C# and missing in Java. I could write the gospel on code reuse, believe me.
If you don't have first-class functions in a language, you'll be doing a lot of of DRY for that reason alone (yes, you can use anon classes instead, but no-one actually does because it's so verbose it defeats the point). If I have to explain how and why that works, then you should probably go read some FP tutorial.
Oh, good grief! I use these things all the time. They are quite explicit and you have the choice to use anonymous, inner, or outer classes, which is often quite nice and in more complicated UIs is what you often want to do anyway. Its just not a big deal, and there's again no impact on DRY unless you have some sort of incredibly lazy coders that should be kicked off the project or something.
It's kinda like the iOS app store. Sure, it has 3 million apps, but in practice you need maybe 30 for any particular case, and 300 across everything. I won't dispute that Java has more libraries, but pretty much any mainstream language/platform these days, including .NET, has all the libraries that matter, for the simple reason that all of them have a fairly large community that will write or wrap one if they need it. I don't recall ever running into a situation where I couldn't find a library to do something that I needed to do, in any popular language.
Well, mostly this is true. There's often a greater range of choices with Java libraries, which CAN be quite nice. In terms of larger assemblies of code there's MUCH more variety. Part of the reason being that Java didn't try to nail things like enterprise architecture down in the core system nearly as much. There are easily 8 different free high-quality containers for instance, many different persistence tools, etc. .NET tends to have what MS provided, or else a port of one or two of what is available in Java. Sometimes that's for the best, other times maybe not so much.
Truthfully, procedural static highly typed OO languages were mostly perfected long before Java or C# got on the scene. Anything that has been added in the last 10 years is trivial compared to the huge advances of the 80's and 90's. I mean I
Perhaps, but that begs the "why not just go with Java?" question, since it supports both Android and every desktop OS (and lets face it NOTHING runs on both iOS and everything else, that's a pipe dream, unless you want to do QT stuff, which is great, but begs ANOTHER question, "why not just use QT/C++?").
And you know what? We don't use any of that stuff, because we want our code to be COMPREHENSIBLE. Lambdas don't do anything for me that I can't do with a loop, and at least I can see instantly "Yep, that's a loop!" For the very few cases where it might be helpful, that's great, but its really VERY few cases. I have yet to write one.
Java's generics are fine. They do the most important part of being generics perfectly well. Again, the things that you seem to want of them are things that negatively impact maintainability in most cases. Truthfully you are VERY rarely going to want to design your own generics. I've done it 5 or 6 times in the last 10 years, and at least 2-3 of those times were probably not good ideas. Consuming generics is great though.
As for DRY... I'm at a loss why anyone would think that you'd repeat yourself in Java. There are all sorts of tools for avoiding that. I've got a million line code base, nothing that shouldn't be repeated is repeated. Application logic exists in one place, everything is highly modular, and I don't find it any more verbose than any other statically typed strict OO language. I think MS certainly looked carefully at Java and in some very minor ways improved on the syntax, but at worst the difference is small, and with Java's vast arrays of libraries, frameworks, and tools, its hard to beat. Chances are MUCH higher you'll end up doing more work in C# simply because you can't find exactly the tool you need. You might write 5 lines less application code, in theory, but you'll end up implementing some whole library that I got for free off apache.org.
Could be. I use Eclipse because it does what I need it to do. There are definitely other toolsets out there that are really good. IntelliJ has a huge rep nowadays. NetBeans is really no slouch either. Still, for enterprise development Eclipse is a workhorse. There are plugins to do everything under the Sun. Many of them are kinda less than perfect, but they work, and there's tight integration with pretty much every OSS or 'community' sort of workflow tool you would ever want.
I don't think MS is going to 'stop supporting' .NET. Hell, Visual FoxPro 9 SP2 was released as late as 2007 and there were hotfixes released as late as 2010. Granted, MS hasn't really supported it in a big way in about 10 years, but it was a LOOOOONNNNNGGGGG time 'dying', and there are still quite a few users.
Even if .NET were to follow VFP its going to have active support for AT LEAST the next 10 years. Given that MS has no other similar product or reason to ditch this one in favor of another, as well as various active ongoing technology programs that build on the .NET CLR it hardly seems likely to fade very fast.
I think what MS has determined is that their boundless enthusiasm for managed code was a bit over-the-top. It makes sense as an approach for 'apps' and less-demanding or 'internal use' type applications. I think they've also realized that the real value of such an environment is in Java's niche, as a high performance platform-agnostic host for business logic. Unfortunately for them they'll never displace Java in that niche. That boat has sailed.
Still, MS itself will in all probability continue to write .NET applications. C++ is a great language, but it takes a huge amount of effort to deal with memory management issues and such crap. C++ is also a language filled with lots of pitfalls. It is incredibly easy to write bad C++ code, and you really need to study the language itself for a few years just to be a truly competent coder. Frankly I just stick to Java, but if I was a .NET guy I'd just stick with that. Why not?
I wonder about HTML5/Javascript. Personally I think Javascript is another terrible language. We're kind of stuck with it, but between the terribleness of HTML, the terribleness of the DOM, and the terribleness of JS writing UIs in that environment really is a pretty awful and expensive process. We've found that with JavaFX (and no doubt other equally good toolsets) we can write a UI in 1/2 or 1/3 of the time it takes to do the same quality of work in HTML/JS. While it is certainly not going anywhere in the near future I have to see this whole paradigm as ripe to fall. MS may think they've hitched their wagon to the final answer, but IMHO something much better will come along before too much longer.
Maybe, but you can do this in Eclipse these days too, in Java. Its not really all that unique.
You'll be aged out of the developer pool, so who cares? ;)