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/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 >>> >
