The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1) versioning -- difficult to know which version to run and what functionality I will have -- this is especially after Oracle took over and then it split even more with the OpenJDK and all that nonsense. It's quite difficult. Along with versioning it is difficult to find tools that feel like they are "official". For instance, I am attempting to use JCov (java coverage tool) and it is supposed to be the "official" but very poorly or not documented at all.
2) UI Framework - Oh boy. I remember the original was something like AWT, right? Then JavaFX (but never caught on fully). 3rd party stuff, and controls that are instantly recognizable that they weren't Windows controls. It was all so confusing and there were better options (C#, Visual Studio and MFC, etc).
3) Java Applets they used applets to introduce Java and it was supposed to be gee-whiz. I was like, "a plugin...?? that fails a lot in my browser...?? and needs to be updated constantly...??? which MS doesn't like to support ???" That intro to Java kind of killed it.
After that it felt like a slow cumbersome thing with no direct line to components without lots of management. So, over to C#, which was easy.
Much of this isn't "fair" to Java, but it is the perception.
I worked with a customer who implemented a serious, corporate-wide Manufacturing Control System using Java. I worked with them on systems at four sites - San Jose, CA; Szenzhen, China; Mainz, Germany; and a place in Thailand I have forgotten the name of. The MCS was used with Windows, AIX, Linux, MacOS, and a few others I can't remember. We used sockets as our interface and there were no problems with it all. I don't even know what OS the systems we directly interfaced with ran on because we didn't need to. That was a few employers ago so I have forgotten some details now. The systems were used in the manufacturing of disk drives and dealt with making the disks themselves. Assembly happened at other sites and we did a few of those systems too.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Nothing really, as long as you remain inside its walled garden.
I had a few interactions with Java, all of them ending in pain and tears because at some point I needed step out of the Virtual Machine.
I fondly remember discovering that the byte type is signed (why, really why ???) and spending a few days debugging my hardware to figure out in the end that Java was to blame.
Or the magical moment when one of the gazilion DLLs needed by an over engineered project had a bug. I simply fixed the bug and recompiled the source and build the DLL again. Something none of the over Java experts were even aware it was possible.
And of course, how can I forget when I relied on the Java standard String library only to find out that the target where the program ran had an incomplete (but still announced as 100% compatible) implementation of that library. What can be more fun than writing your own standard library functions ?
A bit more serious, there is nothing wrong with Java. It is widely used, and in most cases it is good enough. I was just an unfortunate victim of the attempt to using Java in the embedded world, where it most definitively is not right an appropriate tool.
It is your view because you are a programmer, ask Ops.
As mentioned above, versioning. Tell me another software with so many different version number referencing the same thing.
Versioning 2.0 : Have you found your version number? Then here is another error message for you: class can not be loaded because it is version 52 but your JVM supports only up to version 51.
Well, disk space was cheap THEN, so maybe it was not an issue that a 4th digit upgrade installed the full thing in a new directory. Or at least it was not a problem till someone set the JAVA_HOME to one of them, and yum removed the other one...
The usual Java software customizable to an amazing degree via command line switches and config files, but very slow to start up, because it has to read all those small XML files.
Config 2.0: The main selling point of one commercial Tomcat clone is that you don't have to hunt tens of config files to set up the thing.
Yes, 'journalism' is in quotes, because that's being very generous - and I just couldn't think of anything else to call it. Suggestions welcome!
A couple of days back ZDNet published an articled, entitled: "What is Agile software development? Everything you need to know about delivering better code, faster". So what's my gripe?
* Agile must have been around for nearly 20 years by now, so this isn't news.
* The article is a one minute read, so I don't think it covers everything we need to know.
* It's just regurgitating stuff that's been said a million times already.
* Without making any effort to show proof, it repeats the Agile marketing mantra: "better code, faster". See sub-rant below!
I'm guessing what happened is:
ZDNet Editor: "Guys we don't have any stuff for our site today". Mark The Trainee: "I've heard of this thing called 'Agile'. Should I do something on that?". ZDNet Editor: "Ermmmmmm, anyone else got anything?". Everyone else: Carries on playing PacMan [They are 20 years behind!] ZDNet Editor: "OK Mark, that will have to do!"
Yes, I want proof that we get "better code, faster". Did anyone ever actually put this claim to the test? I'd like to see two teams, develop exactly the same application. One using Agile, the other using their chosen, non-Agile, methodology - e.g. Waterfall. Record the man-hours taken and have them, independently, code reviewed and tested. Yes, I'm a sceptic. About, pretty much, everything. Is that a bad thing?
So many writers/bloggers just don't understand the subject and continually repeat wrong information and hype -- and it becomes a sad sad cycle.
On the other hand... v1 is never good. But by v3 things start to get good -- because you have user feedback. So getting to v3 faster is a good thing.
And Agile is all about getting that user feedback sooner rather than later.
But Agile will not magically make v1 good.
Of course, you may also irritate your early-adopters by constantly changing the app on them, so maintaining a dialogue with them important.
Per subrant: "Agile" was developed for managements needs and not that of developers. A lot of rapid piece (of shyte) to present so they never attend a meeting empty-handed. I'll stop lest I extend your subrant.
Journalism? "These days", all you have are talking heads on TV/Radio/other-latest-online-incarnations. There scripts are written by the crop of ignoramus' that the school system has been turning out for some while, now. No one checks anything. No one knows anything. And, to a substantial extent, catering to their audience, no one cares about anything . . . . . . . except, of course, not having a signal for their hand-held impediment and thus not getting texts and tweets.
Actually, . . . . nah, another rant is brewing . . . above is enough.
Without making any effort to show proof, it repeats the Agile marketing mantra: "better code, faster".
Is that like the new world order's slogan, "Build back better"?
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
this is not aimed at programers or even Business Analysts or even Programming Team Managers. It is aimed at upper bees who are always 20 years behind. Which is why we end up with paired programming and Agile rooms.
To err is human to really elephant it up you need a computer