Shiv Swaminathan

Ranch Hand
+ Follow
since Jul 21, 2010
Shiv likes ...
Eclipse IDE Java Spring
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
8
Received in last 30 days
0
Total given
3
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Shiv Swaminathan

@Baba

Leaky Abstraction is an anti pattern. Actually its an anti-Service Facade pattern in Java world. I will just outline a little bit on this and give some references for more reading:

When abstractions prove to be a problem then they are considered leaky.
For eg: In case of a Service Facade, it acts as an abstract layer between presentation and business logic/data. It hides the complexity, makes a single point of entry, loosely couples ...blaah blaah blaah ...all good things about abstraction. But for certain cases this abstract layer might prove to be unnecessary, like when you know the client or presentation tier objects are directly related to your server side data objects say the persistent domain objects (PDO), the transformation is unnecessary, and when the user action in the presentation tier decides when their PDO changes are stored and when not, the business logic cannot be expressed in service-oriented manner, with self-contained, atomic and independent services, and further more, if combining PDO's to create a single client object view becomes very complex, the abstraction through the service facade becomes leaky, causing unwanted complexity and performance overhead. In this case we can expose the PDO's directly to the presentation layer, following the guidelines of a Gateway pattern which is a manifestation of Leaky abstraction.

There are other conceptual examples of leaky abstractions in www.joelonsoftware.com/articles/LeakyAbstractions.html

Refer to Adam Bien's "Real World Java EE Patterns, Rethinking Best Practices", PDO and Gateway pattern.

Remember leaky abstractions apply only for certain usecases, and if they are not applied rightly, they also have drawbacks. (Check Gateway disadvantages in Adam Bien book).

Manuel Petermann wrote:

Shiv Swaminathan wrote:
But it will be good to have both single catch and multiple catch exception argument to be treated in a consistent way...



Problem being if you would allow that, you would make assignment of objects inconsistent, which I think is far more important.



Can you please elaborate on this point...I feel a little lost...
Thank you @Mikalai and @Esteban for your guidance.
Finally I took the upgrade exam and your tips and guidance were very helpful.
My experience/thoughts...for the future exam takers:

1. Be by the exam objectives (except that you have some additional J2EE core patterns to read)
2. Mark Cade and Humphrey Sheil's guide for Java EE 5 is your Bible (I saw some questions from his book's 'Review Your Progress' sections also, but his guide is definitely needed)
3. Adam Bien's Rethinking Java Patterns book a must for Design Patterns (mostly concentrate on the chapter on Infrastructure Patterns and Utilities)
4. Deepak Alur's Core J2EE's Patterns book, you need to know the Presentation tier patterns. I did not see questions on patterns related to other tiers, though some choices had some business tier patterns.
5. Anti-patterns Hot Potato, Leaky Abstractions and Golden Hammer - especially look for scenarios where this can happen - in business tier, web tier or... and is it during messaging or persisting or... 'Bitter Java' and 'Bitter EJB' books can help reference some of these anti-patterns
6. Read through security well, where to apply and how to achieve for an application/system, and also know the different level of security you can provide for application, like message level, transport level and which one provides end-end security, and how are they related to underlying layer, and must know the web application security issues like XSS and SQL Injection, man in the middle, DoS kinds...and how to mitigate them..
7. Go through the JEE 6 Tutorial - at a high level on concepts for webservices, JPA, transactions etc and their applicability..., no need for code or spec.
8. When to use JAX-WS and when to go for JAX-RS, same way for combination of these with Stateful or Stateless scenarios
9. JMS and JCA applicability and when to use these technologies and when to go for webservices...
10. When to go for web-centric or when to go for EJB centric applications
11. The QoS elements against the 2 or 3 tier applications, like making a application 2-tier vs 3 tier, what are the kind of loss or gains you get on performance, maintainability, manageability etc...

No questions on UML and there were no exhibits.
There are some questions which were not clear...and some questions has unclear answer options...

Read the questions well and answer...Time yourself and try to finish within 2 hours and use the last 1/2 hour for reviewing...I could review only last 10 minutes and I had a bunch of questions marked for review (almost all ;) ...I could review only few of them...

All the Best!!!


I agree @Mike!

But it will be good to have both single catch and multiple catch exception argument to be treated in a consistent way...
@Ernest - Good Explanation and I did experiment a little more based on your explanation. Thanks a ton, I read your response the first thing my morning and it was more refreshing than my morning coffee
Did not get a chance to reply early...

For the current complication technique as @Ivan says, this is perfect analysis - Current Java Compiler does not know which type of exception we are creating within the multiple catch block, if we want to make a reassignment to the exception argument.

Following code for single catch block compiled..



I was not able to assign any other type of Exception object to 'ex' other than its declared type IOException or a subclass of IOException like FileNotFoundException...
This explains your case on how the compiler could do type referencing at compile time for single catch and a reason for the argument not kept as final here.

May be Java should in the future enhance its compiler to identify the exception types in multiple catch block and not make the exception argument final.
Compiler should check against all exception types instead of making this workaround. When it knows to do for single exception hierarchy why not for one more in the expression...

So I think this drawback of generics is yet to be addressed in future releases...
@Mikalai, Thank you for the guidelines.
@Mikalai, can you please detail us a little more on your experience:

How different is it from Java EE5?
What kind of preparation do you recommend? (References, materials...etc..)
Yes, I too recommend StarUML if you are looking for a free tool to do your assignments or for personal use. It great abd serves the purpose.

Enterprise wide, I liked Rational Rose, its licensed and if your organizations has it that's also a cool tool for UML diagrams with lots of other features.
Any Pointers...help!!!

Though Generics is a great feature of Java 5, we had to also make sure that we follow some coding standards to avoid the disadvantages provided by generics. (There are places where Java compiler could not identify erroneous type erasure until run-time)

For details/examples refer the following articles:
http://www.anicehumble.com/2012/05/java-generic-type-erasure-advantages.html
http://www.ibm.com/developerworks/java/library/j-jtp01255/index.html

Does the Diamond Syntax Type Inference for Generics also have the same kind of issues hidden within or has the compiler improved to identify these errors?

Looks like it has been fixed in later versions, and even if you are using a JDK 1.6 version which has this issue, you might have to configure some custom setting for Code Cache flushing to avoid this exception, because looks like the default code cache memory allocation and the default flushing is not sufficient for your scenario.

I found this article to be a good start to help identify your code cache flushing needs which can avoid your exception:
http://blogs.atlassian.com/2012/05/codecache-is-full-compiler-has-been-disabled/
Yes that's exactly what I meant could be a possible action during a custom exception handling... meaning trying to add some more stack trace elements...

But what still puzzles me is:

(Though I understand that there might not be a need to do reassignments to the exception parameter inside the catch block)

why is the exception parameter not final for a single exception catch block and why is it final for multiple catch exception block.
From a parameter sense I don't sense/context, there is no difference between these two scenarios.

Or am I still missing some connecting piece here.
Thank you. I'm eager to read the book.

Thank you to Jeff for the Book.
Thank you To the Ranch team for the promo.
My Bad! I thought SQLException was also extending IOException...

Thank you @Mohamed.