From Java to Java EE (through C# .NET)

You assume yourself writes every line of the appli...

2009-10-29T14:54:10.030+01:00

You assume yourself writes every line of the application.

What if different layers are written by different developers. Don't you need to test each component as one single unit?

Actually, I felt the same about the "waste code" and this is what brought me to your blog. But on the other hand, it seems to me that you are talking about some mix between UNIT and INTEGRATION test.

I hate UML. Its stupid and people that love it too...

2009-08-04T22:18:42.303+02:00

I hate UML. Its stupid and people that love it too much act like assholes.

Thanks Artem!

2009-07-20T12:54:04.573+02:00

Thanks Artem!

Nice presentation. Good luck with establishng the ...

2009-07-20T12:23:08.081+02:00

Nice presentation. Good luck with establishng the local group!

Hi Przemysław, Nice work. I'm looking around for...

2009-06-26T01:48:38.483+02:00

Hi Przemysław,

Nice work. I'm looking around for JFreechar with Ajax. Would you mind sharing the details of your implementation? and may be source code?

Take care.
s

I can't say I've ever been writing Transact-Sql or...

2009-06-16T17:39:58.106+02:00

I can't say I've ever been writing Transact-Sql or PL/SQL and felt the need to use the Decorator pattern or anything else really OO. My feeling has always been that OO and databases don't mix. The relational model is, I think, too sophisticated to ever being manipulated in an OO way. Look at Microsoft Linq (language-integrated query), for example. It's not OO so much as it is functional and generic, and these are two paradigms that are completely independent of OO. In fact, generics were basically a rebellion against OO.
Of course, I have worked on projects where we claimed to use OO and we also had a database, but there was always a great deal of awkwardness at the seams, and this is one reason I've never really embraced the concept of OO.

Awesome :-)

2009-06-10T12:54:38.644+02:00

Awesome :-)

Hi, I have checked you Web EMS Admin tool and I t...

2009-05-22T14:27:40.439+02:00

Hi,

I have checked you Web EMS Admin tool and I think it's great. I'm one of those who are fed up (extremely) with the console-base admin tool that comes with EMS.

I was wondering what other features does the tool have, what other commands are implemented and if it's available to use and/or download. Alternatively I would appreciate if you could provide access to the full version to evaluate it's capabilities.

Great job. Thanks in advance.

Eduardo Sanchez-Ros

Knowing tools is not the main thing a professional...

2009-05-21T12:07:12.097+02:00

Knowing tools is not the main thing a professional needs, but I never saw a professional who wouldn't know his tools and wouldn't have his very own set of tools he masters.

What brilliant solution! Many thanks ;)

2009-05-08T11:23:00.000+02:00

What brilliant solution!

Many thanks ;)

There is a difference between creating new thread ...

2009-04-19T22:39:00.000+02:00

There is a difference between creating new thread and letting thread pool to handle the runnable. In first case, you are invoking explicit memory synchronization barrier, in second it is not really guaranteed (might be implementation dependent I think).

In Sun JDK implementation, I think it will work even with executor pool. Worker class is doing the runLock.lock(); before execution of actual Runnable starts (so it is loading state from common memory). Caller thread on the other hand is synchronizing in submit, which is calling execute, which is calling addIfUnderCorePoolSize, which will flush there with unlock before using the thread to run the runnable OR offering it to blocking queue from which Worker thread will retrieve it, also creating synchronization point.

I'm not sure if this is possible to create Executor service which would allow for different behaviour and still be compatible with all the specs - but it is also not clearly specified that memory is synchronized before passing data to worker threads. In such case, it is always better to stay on the safe side. In fact, it is always better to stay on the safe side, even in example you gave here, because it reduces amount of magic dependencies in code and allows nasty surprises when code is later refactored by somebody else. Plus final fields make things easier to understand even in single threaded code ;)

Easiest example of need for final is non-synchronized static variable which is pointing to some singleton-like data. If you don't care about possible multiple initializations, you can do lazy initialization of it from calling thread if needed. In such case, some other thread running 'later' might see null and will initialize it again - but it is not an issue. What it the issue is that if you use non-final fields in it, it can see a reference to the 'singleton', but still half-initialized/null contents, even if you initialized it fully before assigning to static variable.

"@Shantany & Ram - you're partially right :) I for...

2009-04-19T21:31:00.000+02:00

"@Shantany & Ram - you're partially right :) I forgot to add very important detail that it's safe only fore reads i.e. when we assume map.put(...) statement will never occur."

If you never intended to make your map modifiable, the example makes absolutely no sense. I agree with abby that there was not a problem to begin with that you are trying to solve with your immutable class.

abies is entirely correct. The JLS specifies that ...

2009-04-18T23:15:00.000+02:00

abies is entirely correct. The JLS specifies that on Thread.start() happens before any other action on that thread. Thus, with or without final in, the new Thread will see the correct data for SomeClass. Since SomeClass and the Thread are constructed on the Main thread before the call to start() happens, then I would be interested to know how you think a NullPointerException can happen on the newly spawned Thread.

You sound resonable and this is the reason why I h...

2009-04-18T19:36:00.000+02:00

You sound resonable and this is the reason why I have to confront your opinion with this comment: http://java2jee.blogspot.com/2008/11/java-concurrency-is-easy-combining.html?showComment=1226948760000#c4144762493589566546

Any ideas? Does it make a difference when you create new thread and when you submit your task to the executore service?

Sorry to be nitpicking, but multithreading program...

2009-04-18T13:25:00.000+02:00

Sorry to be nitpicking, but multithreading programming is about details:

"Look - in the code I provided I create new thread together with creating the object of SimpleClass."

No, you are creating new thread after SimpleClass has finished initialization. Even that doesn't matter so much, as it is the 'start' method which is really spawning a new execution thread, which is called even after Thread constructor.

From
http://gee.cs.oswego.edu/dl/cpj/jmm.html

"Thread.start has the same memory effects as a lock release by the thread calling start, followed by a lock acquire by the started thread."

On lock release, thread view of data is flushed to common memory. On lock acquire, thread view of data is synced from common memory. This means, that anything put in code of calling thread before .start is called will be fully visible to new thread. As SimpleClass is fully finishes initialization even without final keyword, it will be visible to spawned thread.

Only tricky part with thread creation is if you spawn a new thread from constructor of the object and let 'this' pointer escape to the new thread. In such case, you are out of luck even if final keyword is used.

I think that
http://moonbase.rydia.net/mental/blog/programming/java/the-java-memory-model-for-programmers
got it right in the small table in the middle of the post. You can see there
Writes up to and including…
a call to Thread.start
...are made visible to…
the newly started thread.

You may want to browse the rest of the cases to get better understanding of the relations between threads.

ERRATA: when we assume map.put(...) statement will...

2009-04-18T12:19:00.000+02:00

ERRATA: when we assume map.put(...) statement will never occur AFTER the object is created. On the other hand preProcessMap() can do whathever reads and writes it likes because until the constructor is finished final fields are safe to modify.

@Shantany & Ram - you're partially right :) I forg...

2009-04-18T11:30:00.000+02:00

@Shantany & Ram - you're partially right :) I forgot to add very important detail that it's safe only fore reads i.e. when we assume map.put(...) statement will never occur.

@abies - synchronization of start() method only guarantees that "It is never legal to start a thread more than once." not that the initialization of the object in another thread will finishe before starting this thread. Look - in the code I provided I create new thread together with creating the object of SimpleClass. You cannot be sure what will be done first because the second thread is being created.

Thread.start is synchronized. Before that new thre...

2009-04-18T08:38:00.000+02:00

Thread.start is synchronized. Before that new thread is not existing, so it cannot have a copy of old memory from before that moment.

I think that your particular example will work perfectly well without final keyword.

Which clearly shows that concurrency is NOT easy ;)

Agree with Shantanu, it is too simplistic to assum...

2009-04-18T07:47:00.000+02:00

Agree with Shantanu, it is too simplistic to assume final is be all and end all for being thread safe.

It will be safer to say synchronized is what makes things thread safe.

Of course that comes with a cost. We can reduce the cost by reducing the scope of synchronization through some strategies.

Using the appropriate concurrent utils in jdk5+ is one way to achieve this.

Using thread local variables is another.

Limiting all modifications of shared object to a dedicated thread is yet another.

Ensuring every thread has its own copy of data to work on is yet another - maybe this is truly what you wanted to get at here.

Remember that a completely immutable object is not very useful for most processing purposes.

This one is a really bad example. What if you acci...

2009-04-18T05:50:00.000+02:00

This one is a really bad example. What if you accidentally write a map.put(...) statement in the code somewhere? Or what if a maintenance programmer does that?

final is fine for primitives. But for objects you need immutable data types (e.g. Collections.unmodifiableMap(...)).

I agree. (I feel the same frustration when buildi...

2009-03-26T15:11:00.000+01:00

I agree. (I feel the same frustration when building web pages and trying to code presentation logic via nested tags -- no matter how rich in features the tag library may be. Fortunately, some newer web frameworks let you code your presentation logic in plain old Java. I just wish they were part of the standard tool set.)

I wonder whether Oracle's subset of Java retained the object-oriented capability.

@first anonymous commenterI'm very glad that datab...

2009-03-26T09:32:00.000+01:00

@first anonymous commenter
I'm very glad that databases have a language of sorts, like T-SQL, that allows me to perform some manipulations before retrieving the code. All kinds of complex gathering, sorting and filtering are very inefficient if you first have to retrieve all the data for that.

Of course, premature optimization is the root of all evil. We have written applications that serve thousands of clients a day, that do not use any stored procedures (or any caching for what that matters). However, saying that an RDBMS should not provide 'ifs' and 'fors' is just ignorant.

You've got an excellent point. But I didn't really...

2009-03-26T09:06:00.000+01:00

You've got an excellent point. But I didn't really mean SQL language but the language for stored procedures i.e. writing business logic on top of the underlying data.

As you pointed out (I totally agree with you) this language is meant to gather data. That would be fine but if DB providers allow developers to put business logic directly on DB servers the languages they provide should be better - that was my point.

Just to be clear - I'm generally big anti-fan of stored procedures but anyway I'm open enough to see their usage in some particular cases.

Cheers!

SQL means Structured Query Language, it should nei...

2009-03-26T07:53:00.000+01:00

SQL means Structured Query Language, it should neither have ifs or fors because this language is meant to gather data, process them and then pass this result to a real programming language when something else needs to be done.

But some company never seems to have understand that and I have seen tons of business rules written in SQL that should have been written somewhere else.

I would like to share with "Urbi et Orbi" another ...

2009-02-17T08:36:00.000+01:00

I would like to share with "Urbi et Orbi" another important thing I've just realized: 2*2 = 4!!!!