The programmer's bible are Sun's guidelines for java coding style (http://java.sun.com/docs/codeconv/ ). Some rules may not seem very reasonable but they are. If they cause a real pain on you (like 80-characters lines), ignore them. But remember even this one is backed by some reasons (e.g., 80-character console terminals).

Every file has the following header:

/* 
   Mobile and Embedded Applications Group 
     Warsaw University of Technology
    http://cygnus.tele.pw.edu.pl/osa/ 

   File: 
   Author: 
   Date: 
*/ 

JavaDoc is used (with descriptions and other details).

When importing files use specific names rather than wildcards, e.g.:

import org.open_service_access.cc.gccs._IpAppCallImplBase; 
import org.open_service_access.cc.gccs.TpCallReport; 
import org.open_service_access.cc.gccs.TpCallEndedReport; 
import org.open_service_access.cc.gccs.TpCallInfoReport; 

import org.open_service_access.cc.gccs.*; 

OSA/Parlay header files are self-descriptive - no need to overcomment them. However, groups of files and non-OSA/Parlay ones should probably be commented, e.g.:

/* Ericsson's stuff, used to simpify the program */ 
import com.ericsson.parlay.application.serviceprovision.*; 
import com.ericsson.tracedebug.*; 

/* CORBA stuff - always included when CORBA is in use */ 
import org.omg.CORBA.*; 
/* CORBA naming services */ 
import org.omg.CosNaming.*; 

/* OSA Framework (not used in other modules) */ 
import org.open_service_access.fw_client.discovery.IpServiceDiscovery; 
import org.open_service_access.TpService; 
import org.open_service_access.IpInterface; 
import org.open_service_access.TpGeneralException; 

/* Call Control / User Interaction (only service managers) */ 
import org.open_service_access.cc.gccs.IpCallControlManager; 
import org.open_service_access.ui.IpUIManager; 

Using OSA/Parlay-defined constants, in Java - static variables defined in classes. Never use pure numbers (It should be obvious I guess), e.g.:

plan = TpAddressPlan.P_ADDRESS_PLAN_E164;
screen = TpAddressScreening.P_ADDRESS_SCREENING_USER_VERIFIED_PASSED; 
present = TpAddressPresentation.P_ADDRESS_PRESENTATION_ALLOWED; 
if(p == P_EVENT_GCCS_ADDRESS_ANALYSED_EVENT.value) { /* ... */ } 

plan = 2;
screen = 1; 
present = 0; 
if(p == 3) { /* ... */ } 

When calling OSA/Parlay methods (esp. multi-parameter ones) every single parameter must be described (what the parameter means). In most cases we do not describe arguments (the parametr's values). Example:

uiCall.UICallRef. sendInfoReq(
	uiCall.UserInteractionSessionID, // UI session ID 
	uiInfo, // Information to be sent (here: announcement ID) 
	new String(""), 	// string to be sent to user
	 new TpUIVariableInfo[0], // extra information (not needed in most cases)
	1,  // how many times should be the announcement played?
	P_UI_FINAL_REQUEST.value , 	// q: what should happen to UICall after playing the announcement 
						// a: it will be released (P_UI_FINAL_REQUEST)
	assignment // a returned ID to be stored HERE 
); 

All the classes which are going to be shared among programmers, and developed by the Mobile and Embedded Applications Group will get the prefix "Z". Just Z (namely, Zet).

Specific project classes' names should be easily distinguishable from the rest. A prefix should help, e.g. prefix: mDate would generate the following classes: mDateDatabaseconnection, mDateMainThread, mDateLogic, ..

OSA/Parlay interfeces-derived classes. My suggestion is to drop the "Ip" prefix: IpAppCall -> AppCall, IpAppUICall -> AppUICall, etc..

But if the class implementing OSA/Parlay interfaces has either much broader functionality or there are many such derived classes, it probably should be renamed, IpAppCall -> PersonalAppCall; IpAppCall -> CorporateAppCall