Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Uyl16-0003QQ-HF for bitcoin-development@lists.sourceforge.net; Mon, 15 Jul 2013 15:48:48 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.49 as permitted sender) client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f49.google.com; Received: from mail-oa0-f49.google.com ([209.85.219.49]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Uyl14-0004jk-OR for bitcoin-development@lists.sourceforge.net; Mon, 15 Jul 2013 15:48:48 +0000 Received: by mail-oa0-f49.google.com with SMTP id n9so15758103oag.36 for ; Mon, 15 Jul 2013 08:48:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.41.37 with SMTP id c5mr43552352oel.43.1373903321312; Mon, 15 Jul 2013 08:48:41 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Mon, 15 Jul 2013 08:48:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 17:48:41 +0200 X-Google-Sender-Auth: FS2iKXXn7zmRA_Xpk90SH_55mnk Message-ID: From: Mike Hearn To: Wendell Content-Type: multipart/alternative; boundary=089e013a09646c362d04e18ecb94 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Uyl14-0004jk-OR Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:48:48 -0000 --089e013a09646c362d04e18ecb94 Content-Type: text/plain; charset=UTF-8 Oracle provide an OSX JVM and will do so for the forseeable future, it's also open source, so the community could carry on if they stopped. The primary problem with the Oracle JVM is lack of retina support for Swing, but if you'd write a Cocoa UI yourself then it doesn't matter of course as Java won't handle any GUI stuff. Retina support for JavaFX2 (the current-gen gui toolkit) is available in Java 8 so it's definitely being actively developed, it's not abandoned or anything. So the question then becomes, which is better: a) Take bitcoinj completely out of the Java world via native compilation or transpilation to C++ b) Embed the JVM and link the two worlds together? (b) is much less ambitious, especially if you're OK with writing a bit of Java code to keep the interface thin. Basically the Java side calls into your app when interesting user-visible things happen, like new transactions appearing, then your GUI can call into the java side to send money. There are auto-translators that make the glue work easy, like https://code.google.com/p/javacpp/. You probably wouldn't want to expose the entire bitcoinj API that way because it's very large, but the code needed to bring up a wallet app is very small. I knocked one up this weekend in about one evenings worth of coding, completed with nice animations. The interfaces you'd need are basically some Objective-C++ methods that receive information from the Bitcoin side, like the balance having changed, a list of transactions, etc, and then a callback into the Java side to send money. If you look at the javacpp site you can see example code for making calls both ways. If I were in your shoes, I'd go for (b) because it is the most well trodden path and will let you achieve the best user visible results quickly. The JVM can be bundled with your app and stripped down if you're worried about download size. If it's unclear how the code would look, let me know and I'll try and knock up a really simple prototype. There's also (a). I'm investigating transpilation for a few reasons, one of which is to do with a private project. I'm working with the author of j2c: https://code.google.com/a/eclipselabs.org/p/j2c/. It's a rather sophisticated transpiler that converts Java to clean, readable C++11 that looks much like code a human would write. It's complete enough to transpile the entire standard Java class library, including all the GUI toolkits and other things - so, pretty amazing piece of code. However it's incomplete because where the Java code calls native methods (that would be provided by the JVM) it just spits out stubs you're expected to fill out yourself, for starting threads and so on. As there's no JVM it's just like using a C++ library that is missing a "portability layer". I'm working on this myself and don't really need much help at the moment, I'm just making steady progress towards getting something up and running. I can let you know once I reach some interesting milestones. The point of this is that whilst you don't need access to most of the API to write a wallet app, I'd like to make every kind of app easy from C++, not just GUI wallets. Then the compile-to-C++ approach is much more appealing, even though it's also more work. On Mon, Jul 15, 2013 at 4:39 PM, Wendell wrote: > Hi Mike, > > You are absolutely right about the synchronize time, it's one of our main > frustration points right now and we clearly won't deliver the kind of user > experience we want, without fixing this. Actually we were thinking of > extending Jeff Garzik's picocoin as time permits, but the plan is far from > concrete at the moment. > > What you say about trans-piling bitcoinj is _really_ appealing. We > discounted Java simply because an OS X JVM is no longer guaranteed, but > otherwise bitcoinj is ideal for our purposes. How can we assist or > otherwise accelerate such an effort? > > -w > > On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote: > > > That's great! I'm all for more wallets, especially user friendly UIs. > > > > However being based on bitcoind means it will take a very long time to > synchronize for new users. We know a lot of users drop out. The best fix > for this is SPV mode. Do you have any plans in this direction? > > > > So far, the only SPV mode implementation I know about is bitcoinj. I am > experimenting with trans-piling bitcoinj to C++ to make it usable from > Objective-C++ exactly with your use case in mind. > > --089e013a09646c362d04e18ecb94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oracle provide an OSX JVM and will do so for the forseeabl= e future, it's also open source, so the community could carry on if the= y stopped. The primary problem with the Oracle JVM is lack of retina suppor= t for Swing, but if you'd write a Cocoa UI yourself then it doesn't= matter of course as Java won't handle any GUI stuff. Retina support fo= r JavaFX2 (the current-gen gui toolkit) is available in Java 8 so it's = definitely being actively developed, it's not abandoned or anything.
So the question then becomes, which is better:
a) Take bitcoinj completely out of the Java world via native co= mpilation or transpilation to C++
b) Embed the JVM and link the t= wo worlds together?

(b) is much less ambitious, especially if you're OK= with writing a bit of Java code to keep the interface thin. Basically the = Java side calls into your app when interesting user-visible things happen, = like new transactions appearing, then your GUI can call into the java side = to send money. There are auto-translators that make the glue work easy, lik= e=C2=A0https://code.google.c= om/p/javacpp/. You probably wouldn't want to expose the entire bitc= oinj API that way because it's very large, but the code needed to bring= up a wallet app is very small. I knocked one up this weekend in about one = evenings worth of coding, completed with nice animations. The interfaces yo= u'd need are basically some Objective-C++ methods that receive informat= ion from the Bitcoin side, like the balance having changed, a list of trans= actions, etc, and then a callback into the Java side to send money. If you = look at the javacpp site you can see example code for making calls both way= s.

If I were in your shoes, I'd go for (b) because it = is the most well trodden path and will let you achieve the best user visibl= e results quickly. The JVM can be bundled with your app and stripped down i= f you're worried about download size.=C2=A0

If it's unclear how the code would look, let me kno= w and I'll try and knock up a really simple prototype.

There's also (a). I'm investigating transpilation for a fe= w reasons, one of which is to do with a private project. I'm working wi= th the author of j2c:=C2=A0https://code.google.com/a/eclipselabs.org/p/j2c/. It's= a rather sophisticated transpiler that converts Java to clean, readable C+= +11 that looks much like code a human would write. It's complete enough= to transpile the entire standard Java class library, including all the GUI= toolkits and other things - so, pretty amazing piece of code. However it&#= 39;s incomplete because where the Java code calls native methods (that woul= d be provided by the JVM) it just spits out stubs you're expected to fi= ll out yourself, for starting threads and so on. As there's no JVM it&#= 39;s just like using a C++ library that is missing a "portability laye= r".

I'm working on this myself and don't really nee= d much help at the moment, I'm just making steady progress towards gett= ing something up and running. I can let you know once I reach some interest= ing milestones. The point of this is that whilst you don't need access = to most of the API to write a wallet app, I'd like to make every kind o= f app easy from C++, not just GUI wallets. Then the compile-to-C++ approach= is much more appealing, even though it's also more work.





On Mon, Jul 15, 2013 at 4:39 PM, Wend= ell <w@grabhive.com> wrote:
Hi Mike,

You are absolutely right about the synchronize time, it's one of our ma= in frustration points right now and we clearly won't deliver the kind o= f user experience we want, without fixing this. Actually we were thinking o= f extending Jeff Garzik's picocoin as time permits, but the plan is far= from concrete at the moment.

What you say about trans-piling bitcoinj is _really_ appealing. We discount= ed Java simply because an OS X JVM is no longer guaranteed, but otherwise b= itcoinj is ideal for our purposes. How can we assist or otherwise accelerat= e such an effort?

-w

On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:

> That's great! I'm all for more wallets, especially user friend= ly UIs.
>
> However being based on bitcoind means it will take a very long time to= synchronize for new users. We know a lot of users drop out. The best fix f= or this is SPV mode. Do you have any plans in this direction?
>
> So far, the only SPV mode implementation I know about is bitcoinj. I a= m experimenting with trans-piling bitcoinj to C++ to make it usable from Ob= jective-C++ exactly with your use case in mind.


--089e013a09646c362d04e18ecb94--