Synchronization good, synchronized methods bad

I've been preoccupied lately with the problem of synchronization.

Synchronization in java relies on a cool concept of acquiring a lock, then performing some action, all of this, of course, in the context of multiple threads working with the same data.
It took me a while to get what "the lock" was, so I'll just sum it up in code:

int myCoolNumber = 0;
Object myCoolLock =new Object();

A lock is merely a concept, not really some obscure class in some magical package. It's only role is to exist, thus a java.lang.Object will suffice.

Now, suppose that what you want to do is to increment the value of myCoolNumber. If you're not familiar with threads, I'll be the one to bring the bad news: you can't just increment a variable like myCoolNumber++, because you will lose counts.
A good analogy to explain why, without going into details is this: if you've got multiple people working on a project, if they are not aware of that their colleagues are working on, they might do the same thing. This is especially bad when it's crucial to know what the others did (like how many times the myCoolNumber was incremented.

So what you do is this:

synchronized ( myCoolLock){
myCoolNumber++
}

This is called a synchronized block. That's everything you need to ensure you will never lose counts, if some method in some thread wants to increment myCoolNumber.
This approach makes sure that no other threads can increment myCoolNumber at the same time (no data-races)


Now why synchronized blocks are a good thing whereas synchronized methods are bad?

We have this:

class foo{
int myCoolNumber=0;
public synchronized void incrementAndMore(){
myCoolNumber++;
//some other code;
}
}

A synchronized method uses the same mechanism as the synchronized block, BUT whereas for the synchronized block you have control over the lock of a specific field, the intrinsic lock of a synchronized method is the "this" reference.

Now it's obvious that by acquiring the intrinsic lock of the object itself, you block access to that object while the method executes. In other words, the price payed for making sure the myCoolNumber field is thread safe is giving up the advantages of parallel processing in the first place.
This can be all good and toasty if you don't really have more than 1 field for which thread safety is an issue, but when you have to deal with multiple fields, synchronized blocks might be the better option.

JUnit - testing module

Found this great article
http://www.vogella.de/articles/JUnit/article.html
that exemplifies the use of JUnit. it's a tool for testing classes, that i never understood or indeed learned :P

I'll look into this later and make some comments on it.

The Java Collections Framework - a summary

Seems like when talking Java, there's a cooler approach to solving problems related to lots of similar data objects, other than the good old arrays.

Java 2 introduces the Collections Framework.

My experience with learning it (not mastering it though) is summed up like this: It sounds far more scary than it is. It is based on 3 concepts that anyone will get, as soon as they're presented. Quite important concepts though, they are: interfaces, implementations and algorithms.

I sure as hell didn't need anyone presenting me anything more than this, but it seems everyone's so zealous, you just can't get that good piece of info that you actually need.

Anyway, the interfaces are:

Collection - the generic interface - check it in the javadoc.

Set - it's a collection that doesn't support duplicates.

List - does allow duplicates.

Map - a collection of type (key : value)

The implementations for them are many, and i won't go into details about them, because they have confused me, and all the decisions i ever needed to make about them were easy once i knew what's up with the 4 interfaces.

Some things you need to know, specified by the creators of the Java collections framework is this: mutability is better used only if extremely necessary. if you just want to read stuff from your collections, make them immutable with the methods provided with the methods provided by the algorithms.

And finally, the algorithms for the collections (the sorting, the ordering, creating sub-sets, generating special collections) you will find in the classes

Collections

Arrays

Have fun with the collections!

Here's an excellent far more in-depth 44 page article describing the JCF
Here's the uml for the whole thing

What's the "new" reserved word for in the first place?

This idea came to me today, that i don't see any actual need for the new keyword.

It's used to invoke the the code for creating an object, along with its constructor... but do we actually need it?

Why is "return new Integer(i)"
any more intelligible than
"return Integer(i)"?

Maybe its use has something to do with readability... perhaps it's good because it makes it stupidly obvious that you're not just calling a normal method.

But is it worth the cost of writing a whole nother 4 characters just to make something more obvious?
Well i guess i wouldn't want to guess through source code what "Scraps scraps= Patches(3,4)" means, even if it's a standard to have all your classes named with an initial capital letter.
Is patches a factory method, is is a regular, or is it a constructor....

Yeah, i'd surely put in the effort of writing 4 extra letters for the visibility.

Scala and Ceylon vs Java - ups, downs and awkward design flaws

I am not trained as a computer scientist. All the Java I know, I have learned on my own, ignoring my social life Friday evenings, for quite a few months.

I am the kind of guy that before buying, really goes on a research spree. I did the same before learning some Java, and I'm doing it now, while learning.

What i mean by research is trying to find the best language there is to learn. Google taught me soon enough that the concept of the perfect language to learn is just like the concept of a perfect woman (or a perfect man for that matter) - having some faults is simply always a part of the deal.

But that's not to say that there can't be anything "better" in some way than Java. People complain about the lack of modern features that the language has, like the lack of support for language modularity, lack of support for functions and higher level functions, the awful java.io package, the messed-up synchronized word, the intrinsically inextensible nature of some constructs (the switches, loops and basically all the reserved words), the complex nature of some packages that try to solve some problems that "maybe" shouldn't be problems at all (java.util.concurrent), etc.

So Java came out in the early 90's. One would ask himself what stopped other people from developing another language that's comparably efficient (or more so), and that allows programmers to focus on truly useful design patterns to solving problems, rather than trying to convince java to let you solve a simple problem?

For this reason i had a look at some 2 newer languages that were hoping to become a "java killer". One of them is Scala, another is Ceylon.

Admittedly, Ceylon we've only made acquaintance with Ceylon this year, and a compiler isn't even out by the time i'm writing this. However the grammar of the language is there for both of them.
Also, i'm not gonna go into C# for now. I know next to nothing about it, mostly some syntax, so I think i look noobish enough just talking about these other 2.

First, Scala:

Now the guys at Twitter seem to like it.
Here is an interview with 3 Twitter developers.
They were working with Ruby on Rails, and found Scala great for threads, type safety, features and closures.
All purpose intended, Scala seems to be a successful attempt at dethroning Java (not that it was developed for the sole purpose of dethroning Java, but as the world programming community develops, as new and old ideas are tested in practice rather than just theory, and as older languages simply can't keep up the pace, they inevitably get replaced)

I've looked over the features of Scala, and my personal impressions are:
At first glance, the structure of the language is very unfamiliar (i have a Pascal - C++ - Java background). Sure, Scala runs on the JVM, but that doesn't mean the code and the concepts resemble.
Another silli thing about Scala is that whenever trying to cook up your own function, what you'll be doing is actually extending a template of a function already defined in the language. Doesn't sound too bad, right? Want me to get to the silly part? ok.
There are in the Scala language about 30 definitions like this
Function()
Function(Arg1)
Function(Arg1, Arg2)
Function(Arg1,Arg2,Arg3)

and on and on.... so you realize that Scala doesn't have something as basic as varargs. and EVERYBODY loves varargs. You just can't drop that feature and expect people to not give you a thumbs down. This isn't 1980's anymore.

Scala has that very nice feature of allowing you to "name" blocks of code, and to set parameters to them. "but hey, that's what methods are for in java".... yes and no.
"yes"- of course, for the obvious reasons.
"no" - because java limits your imagination. What i mean by this is, if you've ever wanted to add an ActionListener, as an annonymous inner class AND to pass an argument to that class, let's say a reference to something that needed to be updated, you know what i mean.
It's stupidly annoying to do without having to write another convenience class, that maybe you're never going to use again.

Those things called "closures" are planned for java 1.8. But since there's yet no such thing even as java 1.7 (official release), one has to give a thumbs down to someone.

All in all Scala has been developing for some 5 years or so, and seems promising enough. Twitter loves it, and that's a big plus, but it's very bad for your name to create a language with one of the most loved features taken out. Also since it's alien enough compared to java, that doesn't make for a nice advertisement for the language. We'll see how it develops over the next years

Now onto Ceylon:
Since it hasn't yet been released, but only showed through the incubator glass, much of what i'm going to say will simply be guesses.
Reading through a presentation about Ceylon given by its creator, Gavin King, in China this year, the language seems to promise a lot. Gavin King claims to have designed the language using all the lessons from Java, the good ones and the bad ones.

Now with all the fuss about this, I would expect them to both deliver, and not mess up in new and never before discovered ways... and in both of those cases they have.
I won't go that much into the language. Seems to be less verbose than Java, seems to deliver what it promises. You can have blocks of code like this
repeat(3)
perform(){
//something something
}

which reads like this: repeat 3 times this anonymous function that i'll just write here and you can call it "perform" if you wish, but doesn't really matter.... so just do what it says 3 times.

which is awesome. the perform() function can receive arguments, which means you can create new functions on top of the old. It specifically doesn't support lambda functions, and even if i "kinna" know what those are (i'd like to say hello to my friend wiki), i can't say i have any experience using them. I hear they're good though.

With all the concern for learning from java, I feel like they made an embarrassing mistake though.
Do you know those little convenience methods called "getters"? I'm sure you know and like them. They are so easy to grasp as concepts.

The made them look like this
apple.getColor
Whereas in java they look like this
apple.getColor()

Can you spot the difference?
There's no distinction between a getter and a field. I find that very awkward for people who have to maintain the code, or understand code that's not their own.
The old java way of calling methods with parentheses at the end had a purpose: that you'd know how to differentiate between a field and a method, so that you don't try to change the value of a method, and so that it's more transparent to you what you're doing.
Sure, it's not a big thing. you can make every getter have a standard name like "getPizza", but still, i think fighting verbosity went too far.

Anyways this is my review on the 2 languages. I will of course at some point, like everyone programming, try to learn some new language and test it out. I'll most likely try these 2 as they promise big. I'd just have loved it it they didn't make any aesthetic mistakes that any noob can spot. I had to learn a lot of java to figure out where its mistakes are, but only had to look 5 minutes at the structure of these 2 languages to find annoying stuff.