cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donal Lafferty <donal.laffe...@citrix.com>
Subject RE: [Proposal] Switch to Java 7
Date Wed, 08 Jan 2014 10:28:54 GMT
+1 - used Java 7 for Hyper-V work.  Only annoying bit was back porting to 6 for master merge.

DL


> -----Original Message-----
> From: Hugo Trippaers [mailto:trippie@gmail.com]
> Sent: 07 January 2014 22:50
> To: dev@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: [Proposal] Switch to Java 7
> 
> I would be in favor as well. In addition to the already discussed reasons, I
> think it would be good to try to get our users to a well maintained version of
> Java. From a security point of view 1.6 is not a smart choice any more.
> 
> Upgrading to Jdk 7 could also trigger an upgrade to tomcat 7. Best practice
> indicates that t6 should be used with Jdk 16 and T7 with Jdk 17. I didn't check
> yet if t7 is available in our supported distros atm.
> 
> Anyway I would propose to bump the version of CS to 5 when we do this, so
> we clearly indicate to our users that something serious has changed. Some of
> our users will have to upgrade components outside the CS scope (Jdk) and I
> think that warrants a major version bump.
> 
> Cheers,
> 
> Hugo
> 
> Verstuurd vanaf mijn iPad
> 
> > Op 7 jan. 2014 om 23:38 heeft Kelven Yang <kelven.yang@citrix.com> het
> volgende geschreven:
> >
> > +1 for switching to Java 7 in CloudStack 4.4.
> >
> > Kelven
> >
> >> On 1/6/14, 10:27 PM, "Wido den Hollander" <wido@widodh.nl> wrote:
> >>
> >> Just to repeat what has been discussed some time ago.
> >>
> >> All the current Long Term Support distributions have Java 7 available.
> >>
> >> RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have
> >> Java 7 available.
> >>
> >> I don't see a problem in switching to Java 7 with CloudStack 4.4 or
> >> 4.5
> >>
> >> Wido
> >>
> >>> On 01/07/2014 12:18 AM, Kelven Yang 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/tryResourceCl
> >>> ose.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
> >>>
> >
Mime
View raw message