+1 for java 1.7 -----Original Message----- From: Laszlo Hornyak [mailto:laszlo.horn...@gmail.com] Sent: Wednesday, January 8, 2014 4:50 AM To: dev@cloudstack.apache.org Subject: Re: [Proposal] Switch to Java 7
+1 for java 1.7 and resource blocks, it will help to simplify On Tue, Jan 7, 2014 at 11:50 PM, Hugo Trippaers <trip...@gmail.com> wrote: > 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.y...@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" <w...@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/tryResourc > eCl > >>> 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(jobI > >>> d); > >>> > >>> return new VmStateSyncOutcome((VmWorkJobVO)result[0], > >>> VirtualMachine.PowerState.PowerOn, vm.getId(), null); > >>> } > >>> > >>> > >>> Kelven > >>> > > > -- EOF
