Jack Tol

Greenhorn
+ Follow
since Oct 27, 2009
Jack likes ...
Android Java Ubuntu
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jack Tol

Hello,

I'm currently preparing for the JPA2 exam. Seeing as there are no books for this certification in particular, I'm reading Pro JPA2.

Could anyone tell me which chapters are absolutely necessary for the certification? (Are all chapters necessary?)

Thanks!
Hi Puja,

The fact why LinkedList is good for fast insertion/deletion and ArrayList is good for fast iteration/retrieval lies in the way they are implemented.

ArrayList
The ArrayList saves elements in a normal array. This means it can access elements by array[index_number]. When deleting elements, the ArrayList moves all elements after the current index, one index to the left. With many elements this takes some time. The same goes for inserting elements at a specific index: all elements >= than the index get moved one to the right.

To handle increasing number of elements, the backing array sometimes needs to grow. When this is necessary all elements in the current array get moved to a bigger array. This happens, if necessary, when you add elements. This takes some extra time.

LinkedList
A LinkedList on the other hand saves its element in an entirely different way. Each element in an LinkedList, keeps a reference to the element before and after it in the List. So you get sort of a chain. Like:
Element 1 <--> Element 2 <--> Element 3 <--> Element 4

Now, when you remove an element, say Element 2, Element 1 will refer to Element 3 as its next element, and Element 3 will refer to Element 1 as its element before. This results in:
Element 1 <--> Element 3 <--> Element 4

So when deleting an element, this results in only two operations:
  • Change Element 1's next reference to Element 3
  • Change Element 3's next reference to Element 1

  • This makes deletion very fast in LinkedList. You don't have to move all elements beyond it like with an ArrayList. The same goes for inserting elements at a specific index:
  • Let the element before refer to the inserted element as its next element
  • Let the element after refer to the inserted element as its previous element

  • Faster again. However, when traversing and retrieving specific elements, you have to go through the elements one by one. So when you want to get element 4, the following happens:
  • Get first element's next element
  • Get second element's next element
  • Get third element's next element and return it

  • (This is just an illustration. In reality the List will traverse backwards when (size of list / 2) <= index. Starting with the last element.)

    In this case ArrayList would be faster, as it can access the element directly in the array.

    Ikpefua Jacob-Obinyan wrote:Now according to the JLS, I just found out that there are circumstances where static members can be inherited please checkout this LINK when you are there, go to section 8.1.3 it says quote

    Inner classes may INHERIT STATIC MEMBERS that are not compile-time constants even though they may not declare them


    If the Java Language Specification says this, there is every logic in what I said, which I will repeat here. Quote

    static members are in a 'sense' inherited, but NOT that same 'strong sense' that instance variables and methods are.


    When you use the keyword 'extends' it means 'inheritance' and if as a result you have access to static members of the superclass it is 'more or less' in the context of inheritance.
    This is my point of view.

    Regards

    Ikpefua.



    Nice finding . I didn't know statics were inherited in inner classes. That's something new to look into .

    However, I still believe that no form of inheritance of statics apply to top-level classes, as evident by the warning messages you got earlier. It's just the compiler translating your statements to Class.staticName.

    Ikpefua Jacob-Obinyan wrote:Jack...Thanks for your argument, now what I can confirm at the moment is that static members are in a 'sense' inherited, but NOT that same 'strong sense' that instance variables and methods are.
    An evidence is that you CANNOT 'override' a static method, however it CAN be 'redifined'.

    Now as a result of what you said, I am convinced that if we are asked in the exams the answer should be that static members are NOT inherited or else otherwise proven.

    The compiler indication dissappears from my program if you do this:



    Indeed, that's the right way to access statics , via its class instead of via an indirect reference to the class.

    However, the reason why you can't override a static method is because the JVM wouldn't know what to do. A static method implies that you don't need an instance of the class to access it. If it were possible to override a static method with an instance method, then what? The class which overrides would advertise indirectly that static method X is available. But you just made this an instance method, so no accessing without an instance.. A bad situation indeed.

    "Overriden" in this context seems to imply inheritance, but to my idea this isn't true. It just implies that it isn't possible to use a name due to a conflict with another defined name. Maybe another name for "overriden" would be more appropriate in this context.

    Please correct me when I'm wrong.

    Ikpefua Jacob-Obinyan wrote:@Jack can you please post your complete code here, lets see why it provoked a compiler error?

    Another thing I want to CLARIFY is that polymorphism (in terms of inherited members 'usage') ONLY works with instance 'non-static' methods, NOTHING more. I am sure that is where the confusion is, because it will look like inherited static members were NOT inherited in the first place.



    @Ikpefua, I have pasted your code in Eclipse.

    Please also see this topic.
    My bad. In my previous post I said, this.i would give an error, but it is a warning.

    However, static members are not inherited. When you look at the code you gave, you will see two warning messages:

    The static field Jack.i should be accessed in a static way
    The static method go() from the type Jack should be accessed in a static way


    In your case the compiler just translated your calls to Jack.i and Jack.go(). Nothing was inherited.
    The same goes for static variables. After all, static methods and variables belong to a specific class.

    As with static methods, you can call a static variable of a superclass directly:

    The compiler takes care of selecting the static variable in the superclass.

    But when you use:

    it will give a error warning, seeing as i is not a part of the B class.
    The code:

    Gives a compile error because you're casting m to float. So the statement becomes m (float) + 5.7 (double) = double.

    There are two ways to accomplish what you want:

    Or

    The garbage collector will call the finalize method for a particular object once. It doesn't matter whether you have called the finalize method yourself or not.

    So in your case: yes, the garbage collector will call the finalize method.
    I don't know the real reasons why #3 does not work, but I foresee problems if #3 were to work.

    In the following case:

    You always know that fitShort is passed a short, seeing as s is of type short.

    However, if the code were to allow:

    This could cause problems with your code. What if you had these method declarations:

    The code wouldn't know what method to execute because of ambiguity.
    There is a relationship such as is-like-a yes. It has a subtle difference with is-a.

    Is-a
    An is-a relationship denotes a relationship where a class inherits from another class (subclassing). So when: class A extends class B, B is-a A.

    Is-like-a
    An is-like-a relationship denotes a relationship where a class implements an interface. So when: class MyClass implements MyInterface, MyClass is-like-a MyInterface.

    Most of the time they're both just called is-a relationships though.
    This is an error in the question. You indeed have the provide the jar in a classpath. See this topic for more detail.

    jishnu dasgupta wrote:hi All,

    Just dont want to confuse every one, but isnt a an object reference pointing to an Array of int. so When a =b, doesnt it means that a now points to the array {2,3,1,0}, so when the 3 rd position value is retrieved, which is 0, shouldnt the return value be 2???



    You are indeed right that the 3rd position retrieved. The value however is retrieved from the array before the assignment of (a=b). The reason for this is that array a is evaluated before the expression (a=b). So you get the 3rd position from how array a originally was. In this case it returns 1.

    Matloob Hussain wrote:

    Ikpefua Jacob-Obinyan wrote:
    javac -d ..\..\classes .\.\.\wickedlysmart\MyClass.java



    Hi Ikpefua,

    You used .\.\.\wickedlysmart\MyClass.jave to get java file. Could you please explain the use of .\ three times.



    I'm not exactly sure why the .\.\.\ is used, but the following works for me in your situation:
    javac -d ../../classes/ wickedlysmart/MyClass.java

    ../../classes gets you to myProject/classes as explained in my previous reply, and you can select class MyClass.java for compilation with wickedlysmart/MyClass.java, seeing as your current working directory is myProject/source/com.

    My first reply contained an error in selecting MyClass.java for compilation (com/wickedlysmart/MyClass.java,) my apologies for this. This reply was incorrect because your current working directory is myProject/source/com. From this folder you get to MyClass.java with just wickedlysmart/MyClass.java.

    Ikpefua Jacob-Obinyan wrote:

    Jack Tol wrote:To go two directories up you'd use: javac -d ../../classes com/wickedlysmart/MyCass.java.



    Hello Jack, what you have said is to go ONE directory up and NOT two directories up because the first "." dot refers to the current directory, to go two directories up, you need one more dot.



    Hi Ikpefua,

    How do you mean?

    When the target destination is: myProject/classes
    And current path is: myProject/source/com

    .. would take you to the path: myProject/source
    ../.. would take you to the path myProject
    and ../../classes would take you to the path myProject/classes, the destination directory.

    Please do note that my previous reply was: twodots/twodots/classes.