 Okay, hi everyone! Okay, I didn't think it was so emotional to talk about Java, but I hope it's okay for everybody else. So, I hope it will be okay, because I see it's a bit too large, but... Yeah, maybe we can just... Is it better to... Ah, I see. Yeah, I should be okay. Like that should be okay. Okay, so, hi again everyone! And I'm going to talk today about smart contracts in Java, and what I've been doing lately. So, just to give a context of who I am, where I come from. So, I'm on a functional programming and type system lover. I like my types. I like the compiler working for me. I'm really into distributed system, and this is actually what brought me to Ethereum. I was working on a distributed open data application. I was looking for a way to have distributed metadata management system with a provenance verification. And while looking for it, I discovered Ethereum about a year and so ago, and that made me a blockchain addict, because it was so great. Suddenly you can do all this security and proof, and just amazing. And what I want is a strong Java community on Ethereum. I think that us the Java people are a bit alone in all the Ethereum stuff, and it would be nice to come along and do awesome applications together. So, what is this library and why it exists? So, as I said, when I started to try to do stuff with Ethereum, I looked at EthereumJ for any Java guys who tried it. It's great, but it's not so easy to use. It was really hard to set up. It's really hard to connect to a network. Really hard to have a keeper on it. It was really frustrating. And so I started to build on that, trying to build stuff with it. It became slowly my personal learning tool. I learned a lot with this library on Ethereum, how it works, the internals, how you create your transaction, and so on and so forth. And so it became more and more important for me to help other people trying to experiment with Ethereum and doing dApps on it. So, what is this ETH contract API? So, it's more of an integration library. It's a way to have in your Java some smart contracts as a service. Same way you have red services or I don't know which services that you know in the Java world, then you can have smart contracts as well. With an emphasis on the type safety, so that the compiler helps you and works for you, and the easy integration, so that you shouldn't have to think about, okay, what are the kind of types that you have in Solidity and how do they translate in Java to be automatic? So, I've been working on it for quite some time and today what you can already do is that your smart contract is represented by an interface, a Java interface, that will be validated against the ABI, so that the parameters input and output are correct and work with it. All the communication is abstracted away, it means that you don't need to think about how to set up your node or how to connect on RPC, all these things. You will have a provider to connect to it and then you simply use it, you don't have to think about it. Because I was working with existing networks, there is predefined providers for the EtherCAN testnet, the modern testnet and the mainnet. It's fully non-blocking, so you don't have to do all the synchronization, whether your transaction has been mine or anything, you get a future back and then when it's done, it's done, and as much as possible implicit data conversion. So, let's see some codes of how does it work and how you do something on it. So, basically you create your environment here, so it's this Ethereum passe, and then you get your key. Of course, because I don't know if you guys have done something on EtherCAN, but they are using always this spring wallet, so you don't really have a KISO, but you can use the same concept to take your KISO from this, so you would have to give the KISO ID here and give the password afterwards. And then you start your Ethereum network or environment. You read your Solidity code you want to work against. In this case, I published a contract, but you don't have to. You can also simply use the existing address. And then you create the proxy object, and then you use it. Here, for example, I've created a function called register. This is another project I'm working on to have a distributed app store. So here you would publish your new app and the way to get it with the checksum to make sure that when people don't know it, they don't know the right stuff. And here you will have the interface. So I'm not going to show the exact interface, but I will show another one and explain a little bit the convention of how an interface has to be written. So basically, the rule is like that. If you give back a completable future, it means that it won't be a constant call, but one that will create a transaction and you define what kind of value you want to get in return. If it's void, it's a fire and forget. It means that you want to create a transaction but you don't really care when it's going to happen. And otherwise, you have all the constant calls. And here, as I said, there is this implicit conversion. So string is string. You can also have the arrays we get you list. And if you have your own return type, it will take all the parameters that you get back, find the constructor and if there is one matching, we create the object. So this way, all these things that can be sometimes frustrating that you cannot return struct and that you have to make them back again, here it's done automatically. And so where do I want to go with this array? The biggest dream would be that it's compatible with Android. You don't think that doing mobile apps could be really, really cool. Better error handling because I've been doing that for not so long, some errors are still silent. It is not that good. Sometimes also tricky to find them. The usual suspect, better documentation so that people can jump on it even faster. Easier setup and configuration, especially with the configuration ETMJ. It can be a bit tricky, so I'd like to help people do that. And whatever you need. I mean, I start already talking with a lot of developers. People have great ideas, different needs also. Sometimes you do an application that will be mobile. Some people will do data analysis. Some people will do any other business needs that they would have in their company, big or small. And so the vision of this library is that it has to be focused on ease of use. It should be easy for anyone, even if he doesn't have a PhD in Ethereum. Meaning if he is not really versing it, he doesn't understand all the mining process and everything should be still able to use it and always open to ideas. Always interesting to see how people use the system in different ways, different needs, different ideas. And so my dream is that a lot of projects are coding in the GVM and we should help them use the Ethereum to do that. And a lot of companies are using Java and we should help them do that as well, use Ethereum. And I know that a lot of developers love the GVM and they also love Ethereum. We need to help them join the club and have fun with all of us. And for that I will try to create a Java community. I would like to have more and more Java developers come, do DApps, do things in the Ethereum community in Ethereum ecosystem and do things together. And for that I know it's always, if you try to do something at work, always look at the licensing so licensing should be as friendly as possible for people to do stuff with it. And my dream is to see many companies being small to adapt Ethereum because of all the work we will do together. And for that we need you, we need the developers to do stuff on it. We need feedback for people who will try the library to try it, to tell me what is good, what is bad, what should be changed, what is missing, so on and so forth. Actually creating DApps, I think that's the best way to understand how everything works is to actually do something. So the thing is done in Java but actually I'm a Scala lover so I can guarantee you it works with Scala as well. And the Acti talk about it, show it to everyone. I think it's something that the livelier we're going to get, more productive and we're going to be together. As a note there will be a next event at the end of November, 20th to 27th, the DAPAC in Berlin. It will be a two day long event where people can both find out about new technologies and also try and write some apps. I will be there, there will be also other projects there that will show what they're doing and show how you can play with them. Xenia is here, you can ask her everything if you want to know anything else on that. And to finish, all the users suspect how to contact me if you want to follow, write, send issues, or try something, please feel free. I try to be friendly, I hope I will be. So thank you very much. Are there any questions? How tightly are you going to EthereumJ? Like I said we use RPC in between, because there's no light line for EthereumJ. Yeah, so right now it's working mainly on EthereumJ and I started our branch to work with Web3J, which is an RPC implementation in Java. And the idea is that for anyone using the library it shouldn't make any difference. So they can still use this interface to talk to the smart contracts, just so happened that it goes through the RPC and out through the node. So this is some limitation because today there's some stuff that are not coming back from the RPC, for example the return value is not available if it's through a transaction with the RPC, but otherwise it would be totally transparent. Do you use it on production cookie? No, right now there's not in production but hopefully there will be a lot of project in production. So no, it is written in Java, the reason is that so that as many people as possible can use it, but yeah, I'm a Scala lover, if I could have written that in Scala I would have. Okay, yes? The contract interfaces, do you need to provide them or is the system capable of generating them? So you have to provide them. The main reason it is done like that, for example Web 3J they have generators to do that. The reason I prefer that you define them is that you can define what kind of value you are expecting and then the conversion will take place. That when it's generated you cannot. So are you basically implementing on Ethereum what this is doing on their own blockchain or how does it differentiate? No, not really because here solidity is still here, I mean on the Ethereum part I haven't changed anything. Here it's the integration part that is different. Let's say that it's more an alternative to Web 3JS kind of. Today usually people will integrate with that and here it's another way in Java that I think is also nice because you have all the job like you are in your environment with a type system that you don't have to integrate with Web 3JS. One more question. On the slide there is a code. There are a lot of requests for Web 3JS. What? On the slide there is a code. Yes. There is a user method. Web 3JS. So here is just an example. I'm working on this decentralized app store and the idea is that you have your organization and you can publish their way to get it. So here would be like the HTTP, like the URL to download the application. The idea is that you can put HTTP and then you can put IPFS and put Pitter and whatever you want. But it's always the same checksum to make sure that we are talking always about the same binary. Yes. And the node which is connected is an RPC node. So the question is about the nodes. The backend is... The idea is that the backend is abstracted away. So the backend can be RPC if you choose it to be. But for example today it's an actual node using EthereumJ. So you have an actual node that is syncing locally. But you can choose which one you want, depending on your needs.