[CentOS] bug submission justified for distribution of obsolete java software?
m.roth at 5-cent.us
m.roth at 5-cent.us
Tue Jan 10 18:02:44 UTC 2012
Les Mikesell wrote:
> On Tue, Jan 10, 2012 at 10:32 AM, <m.roth at 5-cent.us> wrote:
>>>>> Would someone advise whether the distribution of an obsolete version
>>>>> of java should be reported as a bug;
>>>> One *could* argue that Java is a bug, being a) so error-prone, b) so
>>>> vulnerable to attack, and c) so huge and slow, and shouldn't be
>>> But you'd be wrong on all counts. I'd argue the opposite - that you
>>> should only be allowed to use languages that work across CPU types and
>>> OS's so as to never be locked into a monopolistic single vendor.
>> No, I wouldn't. You argue wrongly. For one, by your first sentence, you
>> deny all of my arguments, with no reasons for that denial.
> The reasons are obvious. Java is common on phones, so there goes the
> 'huge' argument. OpenNMS can monitor thousands of nodes, so it's not
Really? And how much memory is in them? And is it optimized for the
phones? Is it a subset of the full JVM?
> slow. It's not more or less vulnerable to attack than anything else,
> so why even mention it?
Based on the reports, more vulnerable. And every bloody java app I've had
to deal with ranges from acceptable to sloooowww.
>> As someone who's worked more as a programmer than an admin, and both
>> for a long time, in a lot of languages, I see almost all java
>> programs as huge.
>> I also know that *if* you write your code correctly, the code will
>> compile and run on pretty much anything, unless you're writing
>> windowing-system specific stuff.
> That's if you know every quirk of every target system - and have all
> the associated compilers, and take the time to compile on all of them.
Hah. You mean like gcc, that runs on everything I've ever heard of?
>> Then there's java, that in everything I read from the mid-nineties
>> through the mid-oughts, was presented as being free from memory
>> errors, etc, etc, but as one huge counter-example, just about every
>> time I see a tomcat app crash, the stack traces are 150-200 calls
>> deep, and there are, indeed, memory errors.
> You can write badly in any language, can't you? And why bring up old
> versions? You can take just about anything you were running in the
Old versions? Only if you want to call crashes last year, on the current
openjdk or Sun java on an updated CentOS "old".
> 90's up to maybe a few months ago and realize now that it had horrible
> bugs. Unless maybe it was written by Donald Knuth...
I dunno 'bout that. A lot of the C code or the perl, esp. if I, or people
I respected based on evidence had anything to do with, did maintenance on
it, didn't have more bugs than crap written today. (Btw, have you seen the
report today on slashdot, about the FBI's Sentinel case management system,
that LockMart was writing using Agile methodology, is way behind and
>> Further, it's nothing more than a re-imagining (as they say) of Pascal
>> p-code (quick: what other language besides java used the command
> That's a good thing, now that (a) processes are fast enough that you
> don't care about the interpreter speed and (b) there are techniques to
> use native libraries anywhere it does matter.
Sorry, but I've run into a lot of sites that are dog-slow, and it's *not*
>> The difference between recompile and run on a vm that's
>> compiled for that machine is? Oh, right, it is, in effect, another layer
>> that sits on top of the o/s, like a pseudo-os, or windowing system.
> Yes, if you don't like language abstractions you could code in
> assembly for a particular CPU.
That's a non-sequiteur. All compilers can do that... but except for things
like device drivers, very few folks have ever touched assembly.
>> I can go on... but I really need to get around to writing my article to
>> be entitled, "The Failure of OOP in General, and Java in Particular".
> There's something to be said for functional programming and message
> passing instead of objects in these days of distributed and multi-cpu
> systems, but nobody really thinks that way.
A friend who worked for (was it ArcInfo? Or Autocad?) back in the late
seventies, or maybe it was early eighties, told me they were early
adopters of OOP, and they had an orientation talk, and were handed cheat
sheets: method == function, message passing == parameter passing, etc.
More information about the CentOS