List of wishes and questions.

List of stuff i'd like there to be, and philosophical questions relating said things.

• Eclipse, debug mode, change values of variables on the fly.
• Dynamic breakpoints (conditional breakpoints that depend on other debugging evaluations)
• Scripting language for debugging ((previous wish)++)
• Professional debugging book

JMX and java.lang.instrument

gotta check those things out.

Weblogic mysql connectorJ classpath

problems?

go to %WL_HOME%\user_projects\domains\\bin\setDomainEnv.cmd

add these 2 lines at the end

set MYSQL_CLASSPATH=%WL_HOME%\server\lib\mysql-connector-java-5.1.18-bin.jar

set CLASSPATH=%MYSQL_CLASSPATH%;%JAVA_HOME%\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;%CLASSPATH

3 XDoclet 1.2.3 bugs

Came across 2 bugs in XDoclet 1.2.3,

figured out the work-around.

1: Generics:

-Doesn't know that.

--Workaround: You will have to parameterize the generated methods/classes yourself.

---How-To: Since the only class you Modify with XDoclet is (are) the XxxBean class, which is translated into the Xxx (and XxxLocal) interface(s) in the YYYClient, just make it so that the Xxx and XxxLocal interfaces contain the method signatures of your XxxBean class.... as EJB's should do.

---Observation: This is safe to do, since your XxxBean in the YYY project and the Xxx in the YYYClient project classes are the only ones that keep record of your methods.

2: Messed-up generation:

-Sometimes, it generates an extra (incomplete) interface in the wrong project

--Workaround: just delete the interface.

---Observation: This is safe to do because it appears the deployment descriptors and all the generated interfaces are intact and functional.

3: "List", and "Class":

-Once a reference to java.util.List is included, the bug specified at section 2 happens.... Ima guess this happens on a whole lot of other classes...Ima also guess any class that can be made generic is gonna make XDoclet act this way.

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