Re: Refactor time !

Thanks for taking care! On Sun, Oct 9, 2016 at 4:05 PM DuyHai Doan wrote: > I have created a JIRA epic to track down all the task: > https://issues.apache.org/jira/browse/ZEPPELIN-1525 > > I think I would start by the synchronize blocks and then move onto Eric's > PR for

Re: Refactor time !

I have created a JIRA epic to track down all the task: https://issues.apache.org/jira/browse/ZEPPELIN-1525 I think I would start by the synchronize blocks and then move onto Eric's PR for Guice DI. After we have a DI mechanism, it will be much easier to inject thread pools for thread management

Re: Refactor time !

On 04/10/16 12:54, Anthony Corbacho wrote: You made my day, this is the kind of email i really like !! I think its a great idea and i am willing to spend sometime on it. I also want to move to a DI (guice) architecture , let me know what you think about it. A PR is opened for Guice DI. If

Re: Refactor time !

Hi Jongyoul, I strongly agree that changing requirement of JDK version is definitely breaking change. May be better to treat it to separate issue. I just think it's good food for thought, not meant to do it now. If Zeppelin project plans to have major version (1.0.0 finally), that would be a

Re: Refactor time !

I also think there's also many places to use old version of JDK in production. But unlike library projects, Zeppelin doesn't become dependency of other projects, so no need to consider other projects and also users' own projects, which greatly lowers the barrier. Installing JDK/JRE 8 and using it

Re: Refactor time !

Hello, Concerning JDK, I mean it, too. In production level, it may be hard to change it. On Wed, Oct 5, 2016 at 3:36 PM, DuyHai Doan wrote: > > "Concerning #2, Zeppelin's backend has a lot of map and the map has > mutable states. Thus we should also think of

Re: Refactor time !

> "Concerning #2, Zeppelin's backend has a lot of map and the map has mutable states. Thus we should also think of read-write-lock." Agree, the impl of ConcurrentHashMap deals with this by splitting the internal map into buckets and the access to each bucket is synchronized so that if you have 2

Re: Refactor time !

Thanks for starting this thread. Concerning #2, Zeppelin's backend has a lot of map and the map has mutable states. Thus we should also think of read-write-lock. Personally, moving to Java8 is very attractive but we divide it with others because upgrading to the version of JDK influences users'

Re: Refactor time !

I think about the abuse of @Inject and circular deps, it is just matter of education. On Tue, Oct 4, 2016 at 8:05 PM, DuyHai Doan wrote: > About DI I have no strong opinion on the topic. > > I have coded frameworks with just manual DI (through constructor and > context

Re: Refactor time !

About DI I have no strong opinion on the topic. I have coded frameworks with just manual DI (through constructor and context objects) and it works pretty well, even for a big project, as long as the context objects have meaningfull names Using DI frameworks like Spring or Guice is also a valid

Re: Refactor time !

You made my day, this is the kind of email i really like !! I think its a great idea and i am willing to spend sometime on it. I also want to move to a DI (guice) architecture , let me know what you think about it. On Tuesday, 4 October 2016, DuyHai Doan wrote: > Hello

Refactor time !

Hello devs The code base of Zeppelin has grown very fast in the last 12 months and it's great. It means that we have more and more contributors. However, to make the project maintainable at long term, we need regular code refactoring. I have some ideas to share with you 1) Use Java 8 to