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

I have to agree with your review of this book - it...

2010-02-17T17:29:14.532+01:00

I have to agree with your review of this book - it really is very good and is one of those rare resources that every serious java application developer should have have on hand. Better understanding how the tools and standards that one uses actually work never hurts. The title of the book, more likely chosen by the publisher to grab attention, is a bit misleading. While Tomcat 6 is used in the book because of its open and available source code, this book is really about examining how the Java EE, servlet, and other related web specifications are implemented in practice as revealed in the Tomcat reference implementation. Kudos to the author for what was obviously an enormous effort!

Thanks. I prefer having a proof and I found it mys...

2010-02-07T09:25:36.351+01:00

Thanks. I prefer having a proof and I found it myself: http://www.oracle.com/technology/community/sun-oracle-community-continuity.html (question "Will there be a JavaOne in 2010?")

JavaOne will be kind of separate conference but "co-located with Oracle Develop during Oracle OpenWorld in San Francisco from September 19-23, 2010".

It is official ;)

2010-02-06T21:54:36.106+01:00

It is official ;)

Thanks for the info. It's still kind of unofficial...

2010-02-04T10:36:13.584+01:00

Thanks for the info. It's still kind of unofficial (the link you sent does not come from Oracle domain) but it might be possible.

I think that Oracle still waits for people to register early to see if it makes sense to make JavaOne as separate conference.

It is going to happen this year in conjunction wit...

2010-02-03T20:54:39.346+01:00

It is going to happen this year in conjunction with Oracle OpenWorld

http://www.devsource.com/c/a/Architecture/JavaOne-2010-Conference-Is-Set-for-September/

Good question Tiklup. Check the previous article....

2010-01-16T10:53:24.208+01:00

Good question Tiklup.

Check the previous article. Basically servers/server/id from MAVEN_HOME/conf/settings.xml maps to distributionManagement/repository/id in your pom.xml.

Details in the previous article.

But I don't understand what server id is about? Do...

2010-01-15T20:51:39.278+01:00

But I don't understand what server id is about? Does it correlate to the repository ids?

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:53.780+02:00

What brilliant solution!

Many thanks ;)

There is a difference between creating new thread ...

2009-04-19T22:39:45.408+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:55.406+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:12.128+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:37.467+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:26.438+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.707+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:48.696+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:04.208+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 ;)