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 benefit
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 devs
>
> The code base o
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 ch
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 objects) and it works pret
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' e
> "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 c
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 read-write-lock."
>
> Agree, the imp
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 f
Hello Jungtaek,
I agree that it's relatively easy to run Zeppelin with JDK 8 because
Zeppelin is not linked with another project directly. But as you told, it
bothers admin or system engineer, sometimes it's impossible for some
reasons. Thus personally, we should keep backward compatibility.
On W
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 chanc
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 som
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 a
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 Guice DI.
>
> After we h
13 matches
Mail list logo