"Patrol 403 investigating reports of open source activity"
That was the best part.
Javapocalypse
71–80 of 129 posts
Re: Javapocalypse
#72This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…
The standard method for getting around this in the java world is to create 'sane' libraries (in the case of android http, something like http://loopj.com/android-async-http/ ) and then just use the library. The strong point of Java is just how many libraries there are - you often don't need to touch the actual built in Java APIs. On the server side (non-android) this has gone even further through the use of new annot…
Yep, that's what I ended up using, and it works very well. I especially like the interface (well, by Java standards).
Re: Javapocalypse
#73Earlier quoted context omitted.
The reason is that Java is designed for enterprise, where "I know which exceptions are likely to become a problem and which aren't" cannot be trusted. With giant code bases and mediocre developers you kind of need to have checked exceptions or you'll have exceptions popping up in the most unexpected places. (I'm a Python dev and hate Java)
Unfortunately, mediocre developers are perfectly capable of learning to either catch and silently ignore checked exceptions (checked exceptions actually promote this habit, which can be successfully used in other languages with exceptions) or rethrow them as runtime exceptions. The good thing is - newer java libraries use unchecked exceptions in the vast majority of their APIs.
When I come across exceptions that get silently "eaten" I want to throw the dev out of a window. I've lost days of my life tracking down inscrutable bugs only to find something like this: catch ( Exception e ) { /eat it/ }
Re: Javapocalypse
#74The sad irony is that it is the termination of COBOL that could actually bring society to its knees. If Java died, it wouldn't take long for all that code to be rewritten in Go. But how many COBOL programmers do you know?
Oh, it's worse than that.
I took three years of it in community college and could probably pick it up again in a hurry. If I did pick it up again, I could probably easily double my current (very reasonable) salary.
But I'll be damned if I go back to writing COBOL, and I know a great many programmers like myself who feel the same way. And (modesty aside for a second here) they tend to be the better programmers.
So you're left with the "for-the-paycheque" programmers writing COBOL, and the programmers who couldn't find a job they cared about more.
That's who's going to be rewriting all those mission-critical COBOL apps once people want to start expanding into more modern languages.
Re: Javapocalypse
#75Earlier quoted context omitted.
Great and fair summary. But what do you mean by lack of type (...) polymorphism?
Type inference = the compiler being able to figure out what types your variables, function arguments, and return values are without you having to explicitly tell it. Polymorphism = the ability to write one function that works for multiple types. So for example, if you want to implement a sorting algorithm, you can write one function that is capable of sorting ints, floats, doubles, chars, and Strings. Java doesn't ha…
It's not quite fair to say Java lacks polymorphism, it just doesn't extend to primitive types.
Re: Javapocalypse
#76Earlier quoted context omitted.
Yeah, this is the argument I got tired of and why I jumped ship out of developing in Java for over a decade: "Java is pretty painful, but don't worry.. the tools are so good you don't have to write much code."
This blows my mind and this may be the reason I have so many problems dealing with frameworks of any kind. If I am writing live code, I...want to write code. I don't want something to do it for me. If its in a language I am comfortable with I can generally write it more effectively than a tool in a toolbox and know how to fix it when it breaks. Maybe I am just a control freak.
No, you're normal. Couple things though: The knowing how to fix it when it breaks isn't a real problem in my experience with Java... the stuff that tools tend to generate for you is so boilerplate there's not much mystery there, so I never felt abstracted from the meat of the programs, really.
The Java language, while I was using it, was very slow to change or evolve. Tools, on the other hand, didn't suffer from the bike-shedding and lack of leadership, so they evolved quickly to solve the pragmatic problems they could solve. When I decided to look around and choose a language to re-invest myself in I looked very closely at leadership.. Who the BDFL was (and whether one existed), how the language was evolving, and what the values of the community were. That meant more to me than syntax, though of course they're related.
Sort of like "watch the player, not the ball" advice you get in soccer.
Re: Javapocalypse
#77Earlier quoted context omitted.
Did you pull in a library to do the HTTP work or just use the raw HttpURLConnection? I agree checked exceptions are annoying, though I have kind of grown to like them since they force me to think about failure cases. You're going to hate this answer, but honestly, after you do Java for awhile the lines of code just become noise you don't notice... it's like reading and writing XML by hand; kinda sucks, but eventually…
I used this in the end: http://loopj.com/android-async-http/ , it exposes an interface that does not make me shudder, and I am guessing that is a very good thing. I should read about checked exceptions more, I don't currently understand the difference between checked and unchecked. I don't hate that answer, I was just hoping it wouldn't come to that :P Getting used to a language to get one's job done is fine, but it'…
A checked exception is one that the compiler forces you to write a check for. An unchecked exception ("the good kind") is one that you could write a check for if you want to.
You probably want to have at least one exception "catch" block somewhere, such as within a message/event handler loop, but checked exceptions force you to write the error catch at the place where a routine is called, and MANY such checks for other calls, rather than at one place at the top of an operation.
While this might make sense in a GUI/AWT/Swing app, it does not make sense in a batch processing app (or web app). In that case, there is no user to get a dialog box, you simply log "it did not work due to ..." and move on. Checked exceptions make you write a bunch of extra code.
Re: Javapocalypse
#78Earlier quoted context omitted.
We have collected all the previous videos at the "videos-tab" on the web page as well: http://jz13.java.no/videos.html There are some great talks from last year's conference there as well, many of them in English. The one by Tim Berglund about Git is great!
Jesus, Mary, and Joseph. That was the best video for ANY computer topic I've ever seen. HILARIOUS. I'm going to be smiling the rest of the day.
Especially the very end. Stephen with his pole!
Re: Javapocalypse
#79The sad irony is that it is the termination of COBOL that could actually bring society to its knees. If Java died, it wouldn't take long for all that code to be rewritten in Go. But how many COBOL programmers do you know?
"...If Java died, it wouldn't take long for all that code to be rewritten in Go..."
Guy...
You don't just rewrite code that's been through the FDA approval process. It doesn't work like that. If you want to replace a java or c based medical imaging viewer... you can... but you have to prove it won't kill anybody. Or make any doctors cut off the left leg instead of the right one because a transform is flipped due to a DICOM attribute being interpreted incorrectly. Or that RTP calculations are still correct, and the PET/CT fusion is registering correctly. You can't get Radiation dosage calculations wrong by even a tiny amount.
And you have to prove all of that to the FDA and sign thousands of sheets of documentation swearing to it. And the standard fine print in that documentation makes you criminally liable if a bug is found.
And that's just 1 tiny industry that java is used in.
Multiply that difficulty by every life and death or money based industry and you begin to get an idea of what a monumental task getting rid of java would be. Think oil extraction and exploration systems... uh... no excuses there... they MUST work. Think industrial control systems... software for nuclear facilities, or even software for a simple coal based energy plant, can't just be thrown together. People in a city or area depend on these facilities to meet their energy needs.
Maybe I'm misunderstanding you... what is your definition of "wouldn't take long"?
Re: Javapocalypse
#80Earlier quoted context omitted.
I used this in the end: http://loopj.com/android-async-http/ , it exposes an interface that does not make me shudder, and I am guessing that is a very good thing. I should read about checked exceptions more, I don't currently understand the difference between checked and unchecked. I don't hate that answer, I was just hoping it wouldn't come to that :P Getting used to a language to get one's job done is fine, but it'…
A checked exception is one that the compiler forces you to write a check for. An unchecked exception ("the good kind") is one that you could write a check for if you want to. You probably want to have at least one exception "catch" block somewhere, such as within a message/event handler loop, but checked exceptions force you to write the error catch at the place where a routine is called, and MANY such checks for oth…
I see, thanks. I have to say I'm not a big fan of checked exceptions, but it is what it is... Thanks for the information!