Assignment No. 4 PTT 2011

(C) 2011 — Software Languages Team, University of Koblenz-Landau


The PTT course

Check-in deadline

May 27, 2011 (End Of Day, Koblenz timezone)

Variation 1


Employee mentoring with Hibernate


Start from 101implementation:hibernate. Add the mentoring feature to the implementation such that employees can have an associated mentor. Only the navigation from mentee to mentor is needed. Further, implement functionality for checking mentoring constraints such that nobody is mentoring her- or himself, and no couple of employees is mutually mentoring each other; see the feature's description again for details.

Hints: You need to extend the Employee class and the corresponding mapping file Employee.hbm.xml. In the mapping file, you need to leverage a "unidirectional many-to-one association" (from employees to employees for the mentoring relationship, that is). This is something that was not previously illustrated with the Hibernate example in the lecture, but it is pretty straightforward; see the relevant Hibernate documentation. Accordingly, you need a getter and a setter for the mentor on the Employee class. The constraint checking functionality needs to traverse a given company for employees and check something of the following kind for each encountered employee:

    public static boolean check(Employee employee) {
        return (    employee.getMentor() == null
                ||  employee.getMentor() != employee 
                && (employee.getMentor().getMentor() == null
                ||  employee.getMentor().getMentor() != employee));    

Variation 2


Cutting salaries with reflection


Start from 101implementation:javaComposition. Suppose you want to implement the cut operation in a way that it is robust to many changes that could be possibly applied to the object model for companies. To this end, you could use Java's introspection to traverse objects in the implementation of cut. That is, you would be looking for employees on which you modify the salary. Such an implementation would be very robust indeed because the reflection-based object traversal would deal with arbitrary object models. That is, you could change the structure of companies, and the cutting implementation would continue to be correct.

Hints: start from the code of the object dumper that was discussed in the lecture. You wouldn't generate any output though. Instead your traversal would be looking for objects of the Employee class on which to update the salary. The code for the object dumper drilled into public fields of an object using the following API members:


In contrast, the object model for 101implementation:javaComposition uses private fields, and so you need to drill into methods that are getters using the following API members:


You need to have a special case for lists because the getters of lists are not directly useful to traverse lists. Rather you need to traverse lists (of employee and departments) by a regular for-loop. You need to determine lists by an instance-of test.