Hi, I tried to reply to your message, see below.
On Wed, 2020-06-10 at 11:19 +0300, Eugen Stan wrote: > Hello Matthieu, > > La 09.06.2020 15:46, Matthieu Baechler a scris: > > My experience with Scala is the opposite: you can write code that > > express the problem you are solving instead of a lot of boiler > > plate > > that divert the reader from the intent. > > > > I'm not saying Scala is perfect but I would not say it's more > > complex > > than Java (no checked exception, support for immutable > > datastructure, > > easy separation of infrastructure and data, no primitive mess, easy > > data type definition, etc). > There are immutable collections since Java 9 > https://docs.oracle.com/javase/9/core/creating-immutable-lists-sets-and-maps.htm#JSCOR-GUID-202D195E-6E18-41F6-90C0-7423B2C9B381 The thing about immutable datastructure is not to throw at runtime but to know by the type that data won't change. Sadly they didn't choose that solution in the JDK and it makes these Lists almost useless. > > > Some of the other you mentioned are coming to Java as well. Slower > for > sure. > > JDK 15 (release in september) comes with text blocks, records (second > preview), sealed classes preview, pattern matching preview etc. > > IMO in 1 year they will be mainline and just hopefully that will be > the > next Java LTS ( september 2021). > > I do believe (and hope) value types are going to come in the next 2 > years. Let's see if my predictions are accurate :). > > https://openjdk.java.net/projects/jdk/15/ > > The benefits of having that in Java is the bigger ecosystem. It does > look like a lot of languages will lose some of their appeal. I agree with all that but I've been sell java 8 lambdas years before we finally can use it and I see this pattern again: for sure the next LTS will be great, but we are talking about at least 2 years before adoption in James if we are optimistic and 10 years later than Scala. Why should we use a lagging language when a better and mature one is just here, ready to be used? > > Depending on what is the 'core', I may agree. However scala stdlib > > is > > like the jdk: do you see the jdk as a too-big dependency? We have > > to > > balance number of dependencies with not re-implementing everything > > (with more bugs) from scratch. > > > I'm mostly referring to libraries. Having a library bring a > dependency > like scala is a no-no on my part. Agree. However I don't see much libraries into James code base (I mean valuable parts that can be used in any other project). > Ideally the lower parts of James should not bring any dependencies. > Guava is also big and I would like to see that gone as well. > > It's not reasonable to bring 1+MB of data for 2-3 classes like > Preconditions and immutables. Especially since most of that is > available > in the newer JDK. You should look closer to what we use in Guava. JDK doesn't provide immutable datastructure as good as Guava. Agree that Precondition is not worth it. However, Range, Cache, FileBackedInputStream and a lot of others are really valuable and it would be a waste to try to re- implement similar features to avoid that dependency. > There are a lot of projects that use James libraries. Asking them to > bring an extra 5.6 MB for scala is also not reasonable. I'm not aware of that, please tell me which projects! > (I checked the size of this: > https://search.maven.org/artifact/org.scala-lang/scala-library/2.13.2/jar > . I might be wrong.) > > I mean the James libraries have less then a few K of data and bring > in > 10 MB of extra dependencies that we can avoid by being mindful about > our > choices. > > Those classes take disk space, take time to load and process, take > memory and also maintenance on the security side - something else to > worry about. > > I would also like to see some native images for James with GraalVM. > Again things add up. > > I'm going to stop ranting about that for now because I do want to see > other languages use James. > > > I do think it's very valuable to consume James libraries from other > languages and to build applications on top of James. > > Using multiple programing paradigmes will improve our API and > developer > reach. > > I would like to write mailets in Clojure for example and make James > more > appealing in the Clojure community. > > And of course I won't stop anyone for adding a new library in their > own > preferred language to James. > > > Depending on what you define as being James, the goal is opposite > > as > > what is done currently. James intent is to store things in RDBMS or > > distributed datastores, we can't do that without dependencies. > > > > From what I understand you would at least want a central part of > > James > > to keep dependencies to the minimum. The ADR we wrote is about > > writing > > components and extensions in Scala. So I don't think it opposes > > this > > vision as component are swap-able, having one in Scala should not > > be a > > problem. What do you think? > > Yes the central part of James that we should keep dependency free are > the libraries. > > The pieces of James that tend to be reused by other people in their > projects. > > If we want a broad reach, we need to make as few assumptions and use > the > least amount of dependencies as we can. For now we assumed James is not used much that way and focused on James being a good mail server. However, prove us wrong and we'll reconsider that aspect of the project. > For extending James - bring as much examples as possible in as many > languages as possible. > > I am all for extending and having implementations in other languages. > > We should be mindful that software is easy to write and hard to > maintain. Maintenance is going to fall on the whole team. Doing maintenance on James for 5 or 6 years, I know what you mean. > > I can build James in less than 3 minutes and my computer is slower > > than > > yours. Most of the time is spent in Maven and not in actual code > > compilation. > > > > Here you compare the time our testsuite takes to run to compile C > > code > > to a binary: it's not a fair comparison. > > I'm sold :). Please share with me how. I ran "mvn clean package > -DskipTests" and it took 10 min. > > [INFO] BUILD SUCCESS > [INFO] Total time: 10:40 min Just add `-T 1C` to have parallel build that uses all your cores. > > Not exactly: when using a tool that prevent us from writing a lot > > of > > code, it actually removes complexity. All technologies are not > > equivalent: some are better in some cases and help keeping code > > simple, > > etc. > > > > I would give a single example here: do you think splitting strings > > for > > doing protocol parsing is less complex than using a typesafe PEG > > parser > > library? In the later case: we can stick to ABNF grammar and > > everything > > is obvious at the cost of learning the tool. In the former case: it > > looks like raw Java so people feel at home but the grammar is lost > > and > > it's probably very buggy. > > Have you tried finding an alternative implementation in Java for > grammars? Yes, it's what we used actually: parboild 1 for Java. > I agree, all tools are not born equal. Like I said above I am open to > adding alternative implementations in new languages. > > The users can choose based on the features which one they use. > > Please keep in mind that each piece will add overhead: > > - more time to build for everyone in the project Relying on dependencies instead of having our own implementations actually reduce build time. It's not as simple. > - extra things to take care of during release, bug triaging, > maintenance > when API's are changed. > > I'm asking for the sake of discussion: > > How do you think we should handle a case when we need to change an > API. > An implementation, written in another language needs to be updated > but > the original maintainer is not here/not responsive and we don't know > the > specific language / tool well enough ? We are not including several niche languages here: most of the current active developers know enough Scala to be able to adapt to an API change for now. The downside is a higher entry-level for a developer that want to change an important API. However, most java developer would have some difficulties with the James code: look at how we use lambda for example or how hard it is to implement reactive code. What we try very hard to do is: make the easy things easy. I mean, writing a mailet should be easy, writing a Mailbox Listener should be easy. Even writing an implementation of the Mailbox API is probably not very hard given we provide a very easy way to test the implemetation for free. However a modern mail-server is not something anyone will be able to contribute from day one and we should use the best tools when dealing with these parts. > > > As somebody who write code for this project, I'm probably more > > willing > > to use modern tool. It's very usual: users want things to be stable > > because they don't want to work for keeping their service online. > > Developers want things that make their work easier or funnier. > > > > It's one reason I asked to the community and I'm glad you > > answered. > > > > I didn't changed my mind (yet) but at least I evaluated my opinion > > against others and it's always valuable. Thank you for the time you > > took to write that answer. > > I'm also glad you opened the discussion. I'm also glad you did not > change your mind. It's not my intention. We need to find solutions on > how to do this in a way that has a small impact on the others. > > The only way we can do that is by having a discussion. > > On my part I can say this (as a conclusion): > > - I will be very resistant to adding dependencies to James libraries. > It's my default. Also to James Apps, but less so. > - I will do my best to remove dependencies from those libraries (and > I > hope you will support me) Not sure yet what they are but I suspect I agree. > > - I support consuming James libraries from other languages - with > examples > > - I support extending James API's in other languages and/or tools - > with > the caveat that we will have to maintain or drop that if no one steps > in > to maintain it > > - I support adding NEW implementations for protocols, API's / > libraries > in other languages - with the caveat of maintenance. This should be > justified since it will dilute our development efforts. > Thank you for your long and detailed response. -- Matthieu Baechler <matth...@apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
