Java Course

[vin_petrol]

Well, the course was pretty good. My Java knowledge turned out to be very patchy. I've never really learnt it per se - just had to do things like write one significant program (an image database loader), or go on a course about JBuilder (without actually knowing Java at all - that was bizarre). So I can very vaguely write Java, but I had no actual 'overview' of the language. For example, I had no idea there were these things called 'Interfaces'. That aspect of the language had completely passed me by!

There were about 20 people on the course, all *cough* fairly mature. Clearly, with higher education establishments churning out Java programmers these days anyone learning it *now* must be a more *ahem* 'established' programmer. Very mixed ability. Some people had no OO experience - there were a couple of COBOL programmers on the course - so they were grappling with learning that for the first time. I was sat at the front with a C++ programmer and we were the class swots, finishing all the exercises first.

I had to do some Swing though. Ooh, I hate GUIs. I used to like them about 12 years ago, but I really can't be arsed with them now. As far as I'm concerned, a set of command line options and some logger output is all you need! :-)

I actually dislike Java a lot less now, but that's really because I now know where all the dubious bits are! "Everything is a primitive or a class ... er, except for Strings, which occupy a curious nether-realm between the two - a kind of 'special' class glued into the language." "Never access an instance field directly ... er, apart from when you're finding out the length of an array when we let you access the 'length' field."
Then there's the lovely inconsistent naming in the methods. Take (for example) the File class. You get a file's name with "getName". You get its path with "getPath". You get its length with "getLength" ... er, no ... "length". I suppose that's so that method call is consistent with accessing the 'length' field of an array - LOL.
I also like the way version 1.5 *finally* added 'printf', mostly 'cos people have been moaning at Sun to add it ever since 1.0. Rather like the way 1.4 had 'Perl' regexes added to it. I actually had to _not_ write a Java program back when Orange was using 1.3 as standard, simply because the Java regexes back at that point were laughably crap.

I suppose my real dislike of Java is mostly because "Perl culture" is just so 'irreverent'. The Perl Journal used to be full of fun things like Perl poetry and obfuscated Perl competitions. Any Java magazine is full of stuff about how you can do an enterprise Java banking or accounting system. It's just NOT FUN!

I suspect that Larry Wall and myself would get on well if we met. He partly wrote Perl due to annoying limitations in 'sed' and 'awk' he encountered. I hit the same limitations myself when using those tools in the early 90s. The first serious Perl program I wrote took mere minutes to write, to do something I knew would have taken me hours to work out in some bastard combination of C, sed and awk.

So I think I just have a 'Perl' brain. The culture of Perl ("There's More Than One Way To Do It", "a Perl script is correct if it gets the job done before your boss fires you") is a "good fit" for the way my brain works, and Java culture is far more serious and just isn't.

Comments

[steer.livejournal.com]

Java is terribly inconsistent in the way it does things. It's not grubby in the way that perl is but it's certainly a little dirty.

There are really fun things about Java though -- for example the VM thing works on lots of stuff so you can code things for quite a wide class of devices (phones spring to mind). It has the GUI stuff and you can make whizzy applets in web pages.

Irritations: Code you've written will probably not compile on the next compiler release and code you've compiled may not run on the next run-time release.

[a-crow.livejournal.com]

I am not one to shout about things normally .. but the idea you can write once and use on any phone is laughable :P

Mobile companies employ teams of people to port to each device they are that different.

By different I mean:
- different screen sizes
- different amounts of heap
- different keyboards codes and support of multiple keys at once
- different CPU/graphics/rms speed
- different extra phone specific libraries (which are on some phones the only way to do things like, run the application full screen).
- different sound formats and api's
- different levels of implementation of the midp1.0 or midp2.0 spec they all Claim to implement .. but don't really.
- different bugs in the implementation, like Image.createImage leaking memory on all nokia phones
- different VM support for garage collection (nokia phones do not compact during compaction).

... the list goes on :P

That said, the midp2.0 spec is being followed more closely than the midp1.0 spec and phone are getting more samey .. just not enough to be useful yet :)

[cyberspice.livejournal.com]

Java is a little hacky on occasions. Arrays have a length property *not* method so leave off the brackets. Strings are proper objects but the only way not to have nasty C style strings is to have them as a core part of the language. An Enumerator doesn't enumerate, it iterates. Inconsistency of method naming as you've pointed out.

But in other areas it's a lot better than C++ because you know what's going to happen. Everything other than primitive types are passed by reference. In C++ everything is passed by value (which can cause errors if you don't have the appropriate copy constructor) unless a method takes a reference (and the only way you can tell is by reading the prototype in its header). Package level protecting is useful and it means you don't have to fart around with friend methods and classes. And on the whole it's write once run anywhere.

I don't have a problem with not keeping my Java 'pure'. I've been programming it since version 1.0 and for much of the time at Cardiff it was Java front ends on C++ back ends to run equipement. Our latest US product has it's main application written in Java and I've been trying to push the company to use as much Java as possible as it's the only way to have truely reuseable code. It will also reduce the impact of bad OO programmers which we unfortunately have many of.

I'm not sure about serious but Java is more 'academic' in so much as it tends to encourage you (force you) to use software engineering methods. But then OO does that anyway. If I'm developing a new abstraction I'll sit down and model it in a UML modeler first. The programming is merely the implementation of the design.

One of the things that attacted me to Java was that it's designers obviously knew patterns and anti-patterns and software components which is essential in large designs.

One of the things that has disappointed me about Java is how it has bloated over the years and how they have given in to popular request, even when those requests are plainly wrong. printf() is a nasty function from the seventies. It should be killed off.

[steer.livejournal.com]

I prefer C++ for a serious project to be honest because it gives you control. The problem with Java for me is that in C++ I know exactly what is done -- this calls a constructor which will later call a destructor. It's a high lurning curve but once grokked it's comprehensible. On the other hand, with Java you never know when it will choose to delete an object.

Java is sweet though and it is easy to work with.

I disagree on printf though -- I know it's fashionable to dismiss formatted output but Java and C++ are pretty ghastly to work with in that extent. C++ is egregious because its output formatting is stateful -- I am not sure about Java.

I want to be able to say in one line "give me this double printed to five digits of precision with no more than two after the decimal". In both C++ and Java this is so complex that I have to look it up every time. In C++ you have to write the equivalent of:

i_want_my_output_as (5,2);
print_my_number(number);

There's always the danger of something like this.

i_want_my_output_as (5,2);
/*lots of other code*/
call_to_routine_which_changes_output_format(); /*Added by later coder*/
print_my_number(number);

printf is certainly preferable in this sense to C++ for outputting numeric data. I suspect Java has the same thing but am not sure.

The objections to printf that I know are two-fold: aesthetic ("formatted output specifiers are so seventies") and typesafety ("It does not check that the variable given matches the format"). The first I am happy(ish) to ignore and the second is annoying but a good coder checks it anyway.

printf is, in some circumstances, better than the alternatives.

[minusbat.livejournal.com]

"It does not check that the variable given matches the format"

Methinks you need a more modern compiler!

[a-crow.livejournal.com]

printf also allows me to write binary files in awk with great ease.

Attempting to do it any other way ran into badness and wrongness.

printf was the only way I could get perl to write binary files, but then thats probably just my lack of perl skills :)

[vin_petrol]

printf was the only way I could get perl to write binary files, but then thats probably just my lack of perl skills :)

I suspect so. Perl has no problems whatsoever using the basic 'print' command to write binary data. The only 'gotcha' can be the behaviour of the "\n" construct in the Windows realm (which is output as a carriage return/line feed combination). You get round this by saying the file is in "binary mode". I don't think that particular problem is specific to Perl (I'm sure I encountered much the same thing with C many years ago), but rather specific to Windows.

[steer.livejournal.com]

IMHO outputting the CR/LF for \n is actually the correct behaviour for a windows system.

[vin_petrol]

Yeh, you're absolutely right. I suspect what I was thinking of was the behaviour when a string contains a linefeed *byte* (which is the 'proper' EOL character, as any fule kno). If a string (somehow or other) in Windows Perl contains 0x0A, when it is output it gets 0x0C stuffed in front of it, whether you like it or not. You have to set 'binmode' to stop this happening.

A quick test under windows:

  $a = "\x41\x41\x0A\x42\x42";
  print $a;

run that under Windows and send the output to a file ... yup, the file is 6 byes in length, with a 0x0C automagically inserted before the 0x0A.

It's a gotcha 'cos under Unix Perl can throw binary strings around with wreckless abandon, but this leads to odd results if they contain 0x0A under Windows.

[steer.livejournal.com]

Oh, just bloody don't. The compiler on which I teach C is Microsoft Visual C++. Yes, yes, I fucking know. It's the only supported compiler on the system.

sprintf

[greynolds.livejournal.com]

Another unfashinalble technolgy, but sometimes a lot easier than messing around with ostringstream and all the rest.

Re: sprintf

[steer.livejournal.com]

Sure -- but snprintf please :-)

Re: sprintf

[greynolds.livejournal.com]

Ok you got me - buffer overflow is my professional nickname

[a-crow.livejournal.com]

Anyone know a tool to inline functions in java ?

proguard doesn't seem to do it.

I ask because I have quite a few java methods that are only
called once in one place and I would like the compiler to
inline them, but it of course doesn't .. that would be far too
clever for the javac :P

[sara-lou.livejournal.com]

I've just sent off for an application form for a web systems developer at Bath Uni, where knowledge of java would be "an advantage". I'm not even going to bother opening the envelope when it arrives now...

Java (and .net too)

[greynolds.livejournal.com]

I was learning a bit of Java, and thought it was ok. Then I looked at the jobs you could get with it - all required an alphabet soup of technologies to achieve something that seemed apallingly dull. Then I had a look at .net. Same old story.
So my current toy project is written using wxWidgets/C++ using gcc on cygwin. And emacs of course!
I tried to move into the 21st century - I really did. But the IDEs (well eclipse) sucked much more than 'old faithful' so back I slide to 1995. Oh well.

Re: Java (and .net too)

[vin_petrol]

something that seemed apallingly dull

That's it! Java seems to be the language used for Dull Things. Everytime I see something advocating it, they seem to think that telling me I can do an Enterprise Database Online Banking Back End Order Processing system this is going to convince me it's a Cool Language.

Hmmm. Maybe this is capturing the idea that whatever I do for the rest of my career, it should be based around the overall work itself, and not the technologies used. Which, to an extent, is what has happened. I've (very vaguely) been involved in what could loosely be described as "text-based information processing and publication" since about 1991.