Java 7 is preferred for Apache Hadoop but not required http://wiki.apache.org/hadoop/HadoopJavaVersions (I was looking to see if other OSS projects had migrated)
-- Chiradeep > On Jan 6, 2014, at 6:16 PM, "Ryan Lei" <ryan...@cht.com.tw> wrote: > > There was yet another similar discussion a half-year ago: > http://markmail.org/thread/ap6v46r3mdsgdszp > > ------------------------------------------------------------------------------------------- > Yu-Heng (Ryan) Lei, Associate Researcher > Cloud Computing Dept, Chunghwa Telecom Labs > ryan...@cht.com.tw or ryanlei750...@gmail.com > > > > On Tue, Jan 7, 2014 at 7:34 AM, Chiradeep Vittal < > chiradeep.vit...@citrix.com> wrote: > >> Yes, there was another discussion here: >> http://markmail.org/thread/uf6bxab6u4z4fmrp >> >> >> >>> On 1/6/14 3:18 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote: >>> >>> Java 7 has been around for some time now. I strongly suggest CloudStack >>> to adopt Java 7 as early as possible, the reason I feel like to raise the >>> issue is from the some of practicing with the new DB transaction pattern, >>> as following example shows. The new Transaction pattern uses anonymous >>> class to beautify the code structure, but in the mean time, it will >>> introduce a couple runtime costs >>> >>> 1. Anonymous class introduces a ³captured context², information >>> exchange between the containing context and the anonymous class >>> implementation context has either to go through with mutable passed-in >>> parameter or returned result object, in the following example, without >>> changing basic Transaction framework, I have to exchange through returned >>> result with an un-typed array. This has a few implications at run time, >>> basically with each call of the method, it will generate two objects to >>> the heap. Depends on how frequently the involved method will be called, >>> it may introduce quite a burden to java GC process >>> 2. Anonymous class captured context also means that there will be more >>> hidden classes be generated, since each appearance of the anonymous class >>> implementation will have a distance copy of its own as hidden class, it >>> will generally increase our permanent heap usage, which is already pretty >>> huge with current CloudStack code base. >>> >>> Java 7 has a language level support to address the issues in a cheaper >>> way that our current DB Transaction code pattern is trying to solve. >> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClo >>> se.html. So, time to adopt Java 7? >>> >>> public Outcome<VirtualMachine> startVmThroughJobQueue(final String >>> vmUuid, >>> final Map<VirtualMachineProfile.Param, Object> params, >>> final DeploymentPlan planToDeploy) { >>> >>> final CallContext context = CallContext.current(); >>> final User callingUser = context.getCallingUser(); >>> final Account callingAccount = context.getCallingAccount(); >>> >>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid); >>> >>> >>> Object[] result = Transaction.execute(new >>> TransactionCallback<Object[]>() { >>> @Override >>> public Object[] doInTransaction(TransactionStatus status) { >>> VmWorkJobVO workJob = null; >>> >>> _vmDao.lockRow(vm.getId(), true); >>> List<VmWorkJobVO> pendingWorkJobs = >>> _workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance, >>> vm.getId(), VmWorkStart.class.getName()); >>> >>> if (pendingWorkJobs.size() > 0) { >>> assert (pendingWorkJobs.size() == 1); >>> workJob = pendingWorkJobs.get(0); >>> } else { >>> workJob = new VmWorkJobVO(context.getContextId()); >>> >>> >>> workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER); >>> workJob.setCmd(VmWorkStart.class.getName()); >>> >>> workJob.setAccountId(callingAccount.getId()); >>> workJob.setUserId(callingUser.getId()); >>> workJob.setStep(VmWorkJobVO.Step.Starting); >>> workJob.setVmType(vm.getType()); >>> workJob.setVmInstanceId(vm.getId()); >>> >>> workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId()); >>> >>> // save work context info (there are some duplications) >>> VmWorkStart workInfo = new >>> VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(), >>> VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER); >>> workInfo.setPlan(planToDeploy); >>> workInfo.setParams(params); >>> workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo)); >>> >>> _jobMgr.submitAsyncJob(workJob, >>> VmWorkConstants.VM_WORK_QUEUE, vm.getId()); >>> } >>> >>> return new Object[] {workJob, new Long(workJob.getId())}; >>> } >>> }); >>> >>> final long jobId = (Long)result[1]; >>> AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId); >>> >>> return new VmStateSyncOutcome((VmWorkJobVO)result[0], >>> VirtualMachine.PowerState.PowerOn, vm.getId(), null); >>> } >>> >>> >>> Kelven >> >>
