Re: Yup

> Is it the JDK, the JRE, the Java SE, the JERK...(may not have got the spelling of that last one right)

Er.. so the reason you dislike Java is that you couldn't read the download page to work out if you needed just the JRE or the JDK... you've been doing sys admin for how long?

Re: Yup

You need a degree for that? Really!

Oh the decline of the West. And people then complain when they are outsourced and cold on the street, having spent all the money on a fake degree.

Re: Absolutely

>"requires Java version 6 update 24 or newer" would include version 7. Apparently not.

Another one that dislikes Java because of not reading.. update 24 or newer of Java 6.

And really this isn't different to any other language: Major releases break stuff .. some release of glibc broke a bunch of apps that were using memcpy or something incorrectly. Are all C/C++ applications bad now? are they bad languages? In the Ruby and Python world major updates seem to change the language enough to break a good percentage of the software written those language and Linux distros spend huge amounts of time transitioning versions of those languages/runtimes... If anything Java doesn't change enough.

Re: Absolutely ("not reading")

>It was written as "Java 6 Update 24 or newer."

Keep your pants on Steve. Surely as a "sys admin" it is your job to know this stuff? Not being involved in coding does not mean you are excused from knowing that Java 7 is incompatible with some stuff. If anything as a "sys admin" it's your job to know this stuff.. why do your machines have Java 7 on them when you have software that doesn't work with it? I think that fact is even mentioned in the bits of text on Oracles download sites. If I read "Java 6 Update 24" or newer I would take that as meaning Java 6 update ??

>reasonable assumption that the developer would have at least checked the app with

>Java 7 and included a note that it did not work.

Again, you're the sys admin.. it's your job to be managing applications.

>In fact, it turns out that this particular app wouldn't work with any Java 6 update past 26 either.

Sounds like a badly written app. Who's choice was it to use that app?

>If this were the only developer who'd done this, I'd chalk it up to a bad vendor and be done. But every >"enterprise" Java app I've seen has a similarly narrow range of version/update parameters.

Really? Can you name them? The only issues I've had with some Java apps in the last few years are issues with OpenJDK and some issues with the Android SDK not liking Java 7 ... There are some really old crufty apps from the Java 1.5 or 5 that are totally broken (mainly down to native code in DLLs that doesn't work anymore).

>You claim that this happens with all languages/platforms (in fact you seem to conflate language and >platform a lot), but I manage systems written in

Languages like PHP etc are a platform/runtime.. did you not notice that PHP doesn't generate standalone machine code?

>C, C++,

So you've never had an issue with really old legacy code built against really old versions of libraries that aren't installable on any sanely recent version of the OS you're deploying on? You should tell the glibc guys that they don't need to support workarounds for software that was linked against older versions and save them some work.

>PHP,

Yeah, the migration between php3 -> php4 didn't break any software at all did it? And what about php4->php5? Suhosin reveals a lot about how good PHP's runtime is..

>JS,

JS doesn't have all of those cross browser issues that libraries like jQuery aim to solve then?

>> It seems endemic to Java.

blah blah blah

>>If Java changed more frequently, as you'd apparently prefer,

>>we'd probably have to ban it altogether in our organization

>>as the proliferation of specific versions needed and the consequent

>>rash of security holes would make it almost impossible to administer.

You mean you blindly install the latest versions of stuff (like the fast moving version I would like) instead of "stable" versions.. do you have any policy on rolling out software? Most of the problems you have seem to be from not having a sane deployment procedure.

@Daniel

Daniel you must be a joy to work with. You are condescending and discount the possibility that others' experiences could have some real basis, putting it all down to their stupidity and incompetence. The typical arrogant zero social skills techie, best kept away from customers and preferably from the payroll.

My heart sinks when an app contains a JVM directory, or when I have to install an Oracle RPM just because it's the only Java version officially supported by the vendor - even if OpenJDK would work just as well. A bundled JVM is an admission of defeat in itself, for some reason I've never seen PHP, Perl or Python bundled with an application.

Java = "Have 12 gigs of RAM and don' run in a VM or suffer dreadful performance".

Re: @Daniel

>Daniel you must be a joy to work with.

Well, I've actually done sys admin and if anything I was the person the common folk got on with the best so ner ner.

Being a sys admin doesn't mean you have an excuse not to know "techie" stuff. Is sys admin a non-techie job now? As a sys admin it's your job to know how software versions interact, keep tabs on what is installed, keep deployments in check.... did you by any chance end up and stay in sys admin because you didn't get on well with coding?

>My heart sinks when an app contains a JVM directory, or when I have to install an

> Oracle RPM just because it's the only Java version officially supported by the vendor

How are applications that ship with a JRE Java's fault? How is Oracle not supporting standard Java distributions Java's fault? Why doesn't your OS allow multiple JRE/JDKs like Debian does?

>even if OpenJDK would work just as well. A bundled JVM is an admission of

> defeat in itself, for some reason

Maybe developers don't trust sys admins? From the comments from other sys admins it's apparent that 1: you guys can't read enough to work out the difference between the JRE and JDK and 2: Don't keep good enough tabs on the release cycles of major software components to manage major version migrations... anyone would have thought that was your job!

>I've never seen PHP, Perl or Python bundled with an application.

I've seen old machines kept around to run some PHP4 thingy that doesn't work on PHP5.. I've seen containers and VMs with standalone Ruby installs because the stable versions package with the OS aren't new enough to run some app. Python has systems for creating containers to avoid runtime/library version mismash issues..

I almost took a job this week building a VM to house some legacy app that only runs on some crufy version of PHP on some stoneage version of Redhat. The client was prepared to go to the point of back porting vmware's video driver to the ancient kernel it was running rather than fix the app.. this shit is so common and there isn't a language/runtime/platform in the world that doesn't have these issues. As a sys admin it's your job to manage it. If you don't like that maybe you should do something else?

>Java = "Have 12 gigs of RAM and don' run in a VM or suffer dreadful performance".

And there you go showing your bias and ignorance.

Re: @Daniel

>My heart sinks when an app contains a JVM directory,

Another point..

if that makes your hear sink you would literally shit your pants if you had to manage something like Xilinx's ISE. I think it has a JRE, TCL and C parts half ported from Windows with winelib. I think it's statically linked in places and ships with a complete set of all the runtime libraries it depends on... and even better it installs a complete 32bit and 64bit set of everything! Of course this is all Java's fault and has nothing to do with the TCL stuff or statically linked C stuff it's shipping with.

Re: @Daniel

> And there you go showing your bias and ignorance.

I'm biased because I've run into the same issue repeatedly in a short period of time. Application A is dog slow, vendor documentation says "don't run in a VM, it cannot perform well". Try out application B, it won't even run properly in the VM. Evaluate application C, requirements say 4-12G RAM needed. Competing application C2 runs on hundreds of megabytes of RAM. I guess seeing a pattern emerge makes me ignorant.

I've seen Java apps that run well, I've worked on developing "enterprisey" products that had a Java core. As an administrator I just find that deploying and maintaining Java apps is a pain in comparison. Yes it's my job and it's what I have to do, but the complaints are still valid. I'd complain if I had to work with Windows 3.11.

BTW, Python 2.x is always backward compatible - unlike Java judging from the comment above. You can install Python 2.7 and apps written for 2.2 will run perfectly well. Virtualenv is handy for developers but I wouldn't use it in production. You can easily have multiple Python installs in parallel, eg. Python 2.6 in addition to the default 2.4.

Ya don't mess with the CRAAAAAAAAZY VASEY!

Long time no see!

It sounds like you spoke to some kind of careers advisor or looked up what the job description was?

I didn't look up my job role. I didn't speak to a careers advisor. I didn't aim to become a Systems Administrator. I just wanted to work with computers - as sad as that sounds.

It was a natural progression for me to take my scripting and computing skills I learned as a kid into work with me. "Whinging users" always turned up at the helpdesk (I didn't go to Uni, started at the bottom) with the same problems, so I scripted the responses as far as possible.

I realised I could write scripts to do all sorts of stuff, if only I knew what language I needed to write in and what stuff I wanted to do what. No one told me I'd need to, or had to. I just did it. With a smile because I enjoy it.

Every time I changed job I learned a new way of doing things, new languages, new operating systems. I didn't care what the job was, or even what the role required me to do, it was how I did it that mattered.

The benefit is, as I had scripted most of my tasks, I could get on with the fun stuff.

Like playing with storage, or networking, or reading The Reg and talking to you.

Re: Too much time writing boilerplate getter/setter code…

The point of getters and setters is to provide encapsulation. If you decide to rename the internal field, it does not break every other class which uses and/or updates that value. They also control HOW you permit access to those fields, e.g., synchronisation can be handled in the class, invalid values can be overridden, related fields can be updated at the same time so as to keep the object internally consistent, changes can be logged in the one place.

Trying to write C-like code in Java will always be an exercise in frustration. Just as trying to write Java-like code in C is.

Re: Too much time writing boilerplate getter/setter code…

Rule number one of Object Orientated programming: You NEVER expose the internals of an object. Rather, you provide explicit methods to retrieve them and alter them. That way, it does not matter if -- or rather, when -- you subsequently alter the design of the object fundamentally, as long as your methods continue to behave the same way as they always did.

Sure, in Perl, you could do

$customer->{_contact_count} += 1; # leading underscore indicates private property

and it would work; but for the time it would take you to write some extra methods, you could better write

$customer->set_contact_count($customer->get_contact_count + 1);

or even, if you're going to write an awful lot of stuff things like this,

$customer->update_contact_count(+1); # unary + used to improve readability.

And when you re-design the object a few years down the line, eliminating the _contact_count internal property altogether because you don't need it, the code still works.

If you find yourself writing and rewriting the same "getting and setting" code over and over again, you're doing your inheritance wrong.

Re: Programming is embedded in another career as much as it is in devices

Bill Gates was twenty years ahead of you. Visual Basic for Applications, the language used in a million Excel macros on Wall Street. Programming for the masses.

When the full story of the 2008 financial crash comes out, we'll probably learn that some intern at Lehman Brothers made a typo in a macro. It was only a matter of time in a language with ' as a comment marker...