rian bron wrote:Its ok that the clock has non private variable fields because i set it this way
Campbell and Junilu have already pointed out your use of non-private variables.
Let's say you have a class that describes the characteristics of a cat. Something like this (note that I have left out some code, such as import statements, for brevity):
What is to stop a malicious programmer like me to come along and write this (again, some statements left out for brevity):
I have passed completely absurd cat data to your class, but because you have exposed instance variables and no logic to validate what I have passed, your class happily accepts the values. Obviously this is an extremely basic example, but take that same risk of exposure and consider the consequences if the same coding style was applied to a critical system, such as a machine in a hospital that monitors a patient's vital signs, and someone were to hack into the hospitals' systems and make changes.
As you probably know, or have heard or learned, this falls under Encapsulation, which, in essence,
describes the ability of an object to hide its data and methods from the rest of the world and is one of the fundamental principles of object-oriented programming
Source: Overview of Java
When applied to real-world situations it gives you an appreciation of the benefits of encapsulation.
One thing I have personally learned over the years with programming is, just because code "works" does not necessarily mean it is the right way to do it.
This does not resolve your problem, but I felt it was important to reply. Cheers.