Alexandre Leveille

Greenhorn
+ Follow
since Jan 26, 2013
Alexandre likes ...
Android VI Editor Java
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alexandre Leveille

Thank you for your answers. I still think these questions are really subject to a debate, but I should be good to understand what they expect on the exam.
I'm wondering the same. The book says three hours, where as my appointment lasts only 2.5 hours.

I am worried because I miss a lot of questions that I know due to stupid mistakes when going fast
I have difficulties with these two questions from OCP Java SE 6 Programmer Practice Exams from Bert Bates and Kathy Sierra :

1. Coupling.

Code extract:

Choices (not all shown):
B. Class is well encapsulated
C. The setCity is an example of loose coupling

I said B and C. The study guide says B only. I don't get it. Doesn't having a good encapsulation (private variable and using a setter to modify the state of the object) promote loose coupling??. What is wrong here?



2. Encapsulation

Pseud-code:

Choices (not all shown):
A. These classes appear to have low cohesion
E. These classes appear to have weak encapsulation
F. These classes appear to have strong encapsulation

I said A and F. The guide says A and E. Given that there is a get and a set method, as well as other methods to modify the state of these objects, I was thinking as these classes being encapsulated. Anyway, they certainly appear to, given the pseudo-code. Again, what is wrong here?
Hello Amritendu,

The Java EE 6 Enterprise Architect Certification is a multi-step process where you have to take an exam and complete an assignment and an essay. I would like to know how the book deals with these three completely different tasks and how it helps the reader to prepare himself/herself to these assessments.

Sincerely,
Alexandre
First: you should be able to do this on Windows except that you will use the character ";" instead of ":" to delimit classpath entries.

Also I would give you one tip: make two versions of the Kit class. For instance, in the jar, package the class with a return "jar " + a + b and in the class file use a return "class " + a + b. To do so, create and compile the first version of the class, then create the jar file with this .class file. When you have your jar file, modify the .java file so it returns something else.

Next, on with the classpath basics:
. means current directory. If your current directory is test, and you look for UseKit.class, then the . will allow you to look in the current directory and find UseKit.class
: is used to delimit classpath entries on Unix & al. Use ; on Windows. For instance, use ".;com;tst" to look into the current directory and inside com and tst.
Also have a look at wikipedia.
When specifying a directory, class files inside that directory are used, but jar files won't. Jar files must be explicitly specified ("named").


Now for your questions:

a. java UseKit abc
Will cause a runtime exception, args[1] and args[2] are out of bound.


b. java -classpath com:. UseKit a b c
Will try to find te required classes inside the com directory first and then will try to find them in current directory "."

Heres, what the JVM will do:
1- The JVM looks for UseKit.class in the com directory - no such file
2- The JVM looks for UseKit.class in the current directory - class found
3- UseKit.class imports pkg.UseKit.
4- The JVM looks for pkg/Kit.class in the com directory - the subdirectory pkg does not exists.
5- The JVM looks for pkg/Kit.class in the current directory - the subdirectory pkg does exists and contains Kit.class - class found

The JVM now have everything it needs : ./UseKit.class and ./pkg/Kit.class and will give you the desired output.


c. java -classpath com/KitJar.jar UseKit a b c
Will try to find to required classes inside the Kit.jar file in the com directory.

Heres, what the JVM will do:
1- The JVM looks for UseKit.class in the KitJar.jar file - no such file
2- No more entry in the classpath, the JVM throws a java.lang.NoClassDefFoundError: UseKit


d. java -classpath com/KitJar.jar:. UseKit a b c
Will try to find to required classes inside the Kit.jar file in the com directory and then will try to find them in current directory "."

1- The JVM looks for UseKit.class in the KitJar.jar file - no such file
2- The JVM looks for UseKit.class in the current directory - class found
3- UseKit.class imports pkg.UseKit.
4- The JVM looks for pkg/Kit.class in the KitJar.tar file - in the KitJar.jar the subdirectory pkg does exists and contains Kit.class - class found

The JVM now have everything it needs : ./UseKit.class and ./com/KitJar.jar/pkg/Kit.class and will give you the desired output



Here's what you need to remember:
- The JVM will try to find its classes in each of the directory and jar file specified in the class *in the order they are specified in the classpath*
- The jar files need to be explicitly named in the classpath. If you want to use A.jar and B.jar, you MUST see them in the classpath.
- packages are "translated" to directory. The class com.java.Example must be inside "com/java". Your classpath must contains the folder *above* the com directory. The logic is simple: by positioning itself in the directory "above" com, the JVM will find the com folder, then the java folder, then the Example.class file.
- When no classpath is specified, the default classpath is used. This default classpath is in the environment variable $CLASSPATH on Unix and %CLASSPATH% on Windows.

Hope this helps.

it compiles because compiler sees it as class Y extends X<Object>



No, it works to maintain backward compatibility.

You just created the classes S and V, but most of the time you'll have to deal with legacy code.

For example, last year you downloaded ms-util.jar from Microsoft.com. They had this awesome class S that did a lot of thing:


You decided on your project to extend that class to add some functionality:



Everything is fine, right? No generics so it is simple ;)

However, some Monday morning, a user reports a bug with your application. You investigate a bit and you find that the bug is in the class S... but you are in luck, it has been fixed in the latest version of ms-util.jar. So you head to Microsoft.com and download the newest version of ms-util.jar.

When you open (and decompile) the new ms-util.jar, here's what you find:


Microsoft has changed their classes to use generics. Awesome.... but will it break your code? Remember, your class V that extends S does not use generics and even pass a non-typed list to their methods!!

Sun made it that your old code (class V) would continue to compile. If they hadn't, you would have needed to recode all your classes!
This has nothing to do with generics.

And although it is possible to compare two different classes that one extends another, it is possible to do something even more twisted than that.

Kathy Sierra & Bert Bates - Chp 7 Generics and Collections p.576 wrote:We've talked a lot about sorting by natural order and using Comparators to sort.The last rule you'll need to burn in is that, whenever you want to sort an array
or a collection, the elements inside must all be mutually comparable. In other words, if you have an Object[] and you put Cat and Dog objects into it, you won't be able to sort it. In general, objects of different types should be considered NOT mutually comparable, unless specifically stated otherwise.



That means it's a bad idea to compare Cat and Dog, but you could do it.

Here's an example of two totally different classes, mutually comparable:



Output is:
[Alexandre, Audi A3, Ford F-150, Glenn, Honda Fit, Michael, Sebastian, Wolkswagen Rabbit]

There you have it
Hi again,

doNumber (int... dn) will be matched by new int[] {1, 2 ,3} and
doNumber (Integer... dn) will be matched by new Integer[] {0,0,0,0}

That is because the var-args will be matched by arrays of the same type. This ensure backward compatibility with old code using arrays to pass multiple values and the new APIs expecting var-args. In order to do this, the Java guys made it so that where an array is used, it will match a var-args of the same type.

In order to fully understand just how similar arrays and var-args are, type the following code in your editor and it won't compile. javac will complain that doNumbers(Integer[]) is there twice.


Now since doNumbers(Integer[] dn) is almost the same as doNumbers(Integer... dn), you should see why this is considered a better match than the generic doNumbers(Object... dn)
Hi!

1) 2L is a long and java won't automatically cast down a long to an int because there's a possible loss of precision (even though in this case, the number 2 can very well fit inside an int). What Java can do however is auto-box your long literal to a Long object. This Long object is holding the value 2, and match the arguments list for doNumber (Object dn).

Quoting Katty Sierra and Bert Bates, Chapter 3 Using Wrapper Classes and Boxing, page 249:

In every case, when an exact match isn't found, the JVM uses the method with the smallest argument that is wider than the parameter.



2) int[]{1, 2 , 3 ,4} could match doNumber (Object dn): just comment doNumber (int... dn) and it will do so!

But the method doNumber (int... dn) is considered a more direct match. That is because var-args were created to address the problem that passing an arbitrary number of values required arrays.

With the arrival of var-args, many API methods that accepted a number of arguments via an array have been changed to use var-args.
Eg.: MessageFormat.format(String pattern, Object[] arguments) is now format(String pattern, Object... arguments).

Therefore, an Array can be used where a var-args is expected, but an arbitrary number of arguments cannot be used where an Array is expected, preserving the compatibility with legacy code and APIs.

3) new Integer[3] is instantiating an Array of Integers (new Integer[]{0,0,0}). It then matchs doNumber (Integer... dn) for the same reason int[]{1, 2 , 3 ,4} matches doNumber (int... dn).
As Deepak said, the JVM will use the "closest" variable. If you shadow the member's variable with a local variable, you'll see just how the JVM resolves which variable it uses. Also comment the lines 2, 5 and/or 20 in the below code to get a better understanding of the difference between no prefix (just "i"), this.i and super.i.


Hi Dante,

To complete John's answer, have a look at the following code (inspired from Java 6 API):





Another example in-between the last one and your case is:




So as you can see, the regex in the split is used as the delimiter to split your string. Everything in-between this delimiter will be returned in the array, but the delimiter itself is excluded.