Aaron Anders

Originally posted by Marco Tedone:

I can't see the beginning of the transaction (i.e. ut.begin() )

UHHHHH! i forget to call ut.begin()!!!

the code works well on JBoss 3.2.3.

thanks for your reminding!

according to the sequence diagram on Applying Enterprise JavaBeans, 2nd ed. page 213

"After invoking methods on an entity bean, the client attempts to commit the transaction by invoking the commit method on the UserTransaction interface" (which operates on a CMP)

i think it implies that CMP + Session Facade w/ BMT is allowed, so i've done an little experiment...

Session Facade's <transaction-type> = Bean

code listing simplified as below:

UserTransaction ut = ctx.getUserTransaction(); InitialContext initCtx = new InitialContext(); Context myEnv = (Context)initCtx.lookup("java:comp/env"); CMPLocalHome home = (CMPLocalHome) myEnv.lookup("ejb/SomeEJB"); CMPLocal proxy = home.findByPrimaryKey("1"); System.out.println("$" + proxy.getBalance()); // shows $10 proxy.setBalance(20); ut.rollback(); // exception

with JBoss 3.2.3, execution results in "java.lang.IllegalStateException: No transaction." on the ut.rollback() line, and the balance field becomes $20

is there anything wrong with the code?
[ August 08, 2004: Message edited by: Aaron Anders ]

thanks for posting the exam details!
i've a few questions regarding the exam objectives
- does the exam leave out BMP implementations? (or will the exam contain any BMP based code listing?)
- will the exam cover CMP 1.1 (EJB Spec chapter 14)? or solely on CMP 2.0?

Also I would like to know that is there any time limit in terms of months after the SCJP exam that I am eligible for the SCWCD exam.
No, you can take it anytime you want

what about the 2 year expiration date? can you still take SCWCD/SCJD exam 2 years later with your expired SCJP certificate?
i'm confused on what's the intention behind the decision on SCJP 2 year expiration date after 2002/08/30

plz refer to the rephased statement:
(e.g. if you return inside finally, the exception originally thrown at try block will be neglected and function will be returned normally, also uncaught exceptions thrown inside finalizer are always ignored)
what i'm saying is situation like:
class Test { public static void main(String [] args) { try { throw new RuntimeException(); } finally { return; } } }
it's weird at the 1st sight that program runs smoothly without displaying RuntimeException, but that's default behavior of finally block
HTH
[ February 09, 2003: Message edited by: Aaron Anders ]

Originally posted by Sri Sri:
Aaron,
i know the difference between finally and finalize. I was asking what you meant when you said the exceptions thrown in finally will not be thrown ?
I guess it is finalize...because as far as i know ...
if there are exceptions thrown in finally, then you need to catch them using nested try-catch block inside the finally block or you have to declare the exception thrown in finally block in method declaration.
On the other hand, finalize method is called when the object is about to be GCed for the first time. If the object is resurrected from the finalize method, then finalize method is not called again...also... if there are exception thrown in finalize method, they dont really matter.
I thought you mixed up finally and finalize in your code......thats why I asked the question...
Thanks
Sri
[ February 09, 2003: Message edited by: Sri Sri ]

i may rephrase the statement as
(e.g. if you return inside finally, the exception originally thrown at try block will be neglected and function will be returned normally, also uncaught exceptions thrown inside finalizer are always ignored)
as C++ doesn't have finally block, C++ programmer may be surprised that finally will suppress the exception thrown at corresponding try block, but for Java/C# programmers, this behavior seems natural
JLS 12.6 states that "If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates.", i think it can be interpreted as the statement above
[ February 09, 2003: Message edited by: Aaron Anders ]

Originally posted by Sri Sri:

Aaron, I am just confused, was it "finally" or "finalize" that you meant? i am sure it was a typo
Sri

"finally" is a keyword used for exception handling
"finalizer" means the gc-related method protected void finalize() throws Throwable
[ February 09, 2003: Message edited by: Aaron Anders ]

Originally posted by Dan Culache:
Thanks Dan, that I knew but I thought he really meant "constructors". This was my point, the way to differentiate between a constructor and a method with the same name is the fact the constructor doesn't have a return value. But I thought he might have come upon some weird scenario... If not then I'm not sure you cannot do the same in C++ since C++ has basically the same overloading rules.
BTW your mock exam is great. Perfectly suited for overconfident folks like I am

ctor with return value is not allowed in C++
on my GCC 3.2, compilation results in error "return type specification for constructor invalid"
VC7's error message is a bit more comprehensible, "error C2380: type(s) preceding 'Test' (constructor with return type, or illegal redefinition of current class-name?)"
[ February 09, 2003: Message edited by: Aaron Anders ]

woo! i've passed SCJP 1.4 exam today, a BIG thank you to Dan for such a thought-provoking mock exam!
besides a thank you message, i'd like to point out a few java features that are foreign to C++ programmers, hope it helps...

pay SPECIAL attention to all runtime-related features, namely threading and gc

both are platform dependent, also gc generally guarantees NOTHING

threading is supported at grammatical level: synchronized keyword, plus lots of build-in methods

threading is also supported at runtime level: in C++, if main() is finished then program terminates, but in Java, even if main() is finished other threads will keep executing until all non-daemon threads finish execution

wait()/notify()/notifyAll() are introduced (solely, i think) for solving producer/consumer problems

for gc, understand how finally will affect program flow (e.g. if you return inside finally, the exception thown will be neglected and function will be returned normally, also exceptions thown inside finalizer are always ignored) and understand when will object be eligible to gc (e.g. string literals never get gc-ed)

also be careful for some special language features, to name a few

parameter passing mechanism is fixed, you'll be surprised that you can't even swap 2 ints in Java

rules on operator evalulations (e.g. i=i++; issue)

special treatment on "special classes", including String and arrays (e.g. "".equals(null) is legal in Java)

finals are constants, but blank finals are NOT (e.g. you can't use blank final as case label)

function overloading holds even among inheritance relationships

Java provides implicit overloaded operator + and += for String class (in C++, you can't "add" 2 string literals because they're considered as 2 char *)

Java doesn't support explicit operator overloading, so make-sense usages such as Integer+Integer are not allowed

constructor with return value is a legitimate member function

special static/instance initializer syntax and behavior (ref to JLS 8.3.2)

because every member function is virtual by default, so upon instance initialization, base class's constructor will invoke derived class's member function even though derived class hasn't fully initialized yet

downcasting is allowed even on array of object references

all collection classes store elements as Object, so they can't store any primitive type (at least before Java officially support C# style boxing/unboxing mechanism)

STL containers are type compatible with arrays, but this is not the case in Java... so Java provides 2 separate classes, java.util.Collections and java.util.Arrays, to perform algorithms

Java does have preprocessor it translate unicode sequences to corresponding character literals (e.g. '\u000a' trap)

assertions are always compiled to bytecode (you can't filter them out), you can only turn them off at runtime (which is default)

Java implements assertions via AssertionError class, i.e. comply with exception handling mechanism

Cheers!
SCJP 1.4 (95%)
[ February 09, 2003: Message edited by: Aaron Anders ]

uh, oh...
i'm confused the question with the rule "you can't overload with same signature but different on return type"
so, the answer provided is correct.
thanks for replying!

hello folks,

question: An overloading method must have a diferent parameter list and same return type as that of the overloaded method.
answer: false
explanation: There is no restriction on the return type. If the parameters are different then the methods are totally different (other than the name) so their return types can be anything.

well... isn't it violate the rule of overloading if the return type is different?
so, is the answer "true"?

Consider the following lines of code...
System.out.println(null + true); //1
System.out.println(true + null); //2
System.out.println(null + null); //3
Which of the following statements are correct?

answer: None of the 3 lines will compile.
why? as it compiles fine on my JDK 1.4.1_01
is the handling of null compiler-dependent?

Question 10
a. Each element must be unique.
b. Duplicate elements must not replace old elements.
c. Elements are not key/value pairs.
d. Accessing an element is almost as fast as performing the same operation on an array.
Which of these classes provides the specified features?
a. LinkedList
b. TreeMap
c. TreeSet
d. HashMap
e. HashSet
f. LinkedHashMap
g. LinkedHashSet
h. Hashtable
i. None of the above
answer: (e) HashSet

i wonder why (g) LinkedHashSet isn't correct answer...
according to TIJ 3rd ed., "traversal is cheaper with LinkedHashSet (than HashSet) because of the linked list", so LinkedHashSet fulfills all 4 requirements, or not?

A class C has legal implementations of the equals and hashCode methods. On Monday, an instance of the class is created and the hashCode method is invoked. On Tuesday the program is loaded again and an instance of class C is created containing the same data that was loaded on Monday. If the hashCode method is invoked after restarting the program on Tuesday then the hashCode method must return the same integer value that was returned on Monday. (answer is false)

but why? is it
- because C may have members that store date/time related information?
or
- because the question didn't state that the 2 objects are equal?

may i summarize the rules on casting...
- upcasting doesn't need explicit cast
- casting from one parent to other parent needs explicit cast
- downcasting needs explicit cast, but may result in runtime error
- casting to sibling is illegal
[ January 21, 2003: Message edited by: Aaron Anders ]