Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Bt – BitTorrent library in Java 8

github.com

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Show HN: Bt – BitTorrent library in Java 8

#61

Post by nunobrito »

Hello, thank you for writing the library.

On my context it is useful for downloading large files without depending on a single point of failure or fixed location.

Have a question in regards to the example syntax:

client.startAsync(state -> { if (state.getPiecesRemaining() == 0) { client.stop(); } }, 1000).join();

This is a feature from newer Java syntax that I'm not yet familiar enough with lambdas to understand in full what is happening.

Perhaps I can ask for an example that replaces the "->" into the older Java syntax? I know this would likely come at the cost of a few extra lines, it would certainly ease a lot for many developers looking at the example. Many thanks.

Re: Show HN: Bt – BitTorrent library in Java 8

#62

Post by rena-anju »

gigatexal wrote: post #21

Man this looks slick, going to give it a shot. Love the ability to be able to download a magnet link from the CLI and not worry about what some fancy GUI is doing in the background cuz I am paranoid.

What things that makes you paranoid can a "fancy GUI" do in the background that an application with a CLI cannot also do in the background?

Re: Show HN: Bt – BitTorrent library in Java 8

#63

Post by train_robber »

nunobrito wrote: post #61

Hello, thank you for writing the library. On my context it is useful for downloading large files without depending on a single point of failure or fixed location. Have a question in regards to the example syntax: client.startAsync(state -> { if (state.getPiecesRemaining() == 0) { client.stop(); } }, 1000).join(); This is a feature from newer Java syntax that I'm not yet familiar enough with lambdas to understand in f…

In the older syntax, something like this:

  client.startAsync(new Consumer {
	void accept(TorrentSessionState state) {
		if (state.getPiecesRemaining() == 0) { 
			client.stop(); 
		}
	}
  }, 1000).join();

Re: Show HN: Bt – BitTorrent library in Java 8

#65

Post by atomashpolskiy »

the8472 wrote: post #59
atomashpolskiy wrote: post #55

Earlier quoted context omitted.

It makes sense, what would you advise in case of big files that don't fit into memory (or when it's undesirable to use big amounts of RAM, and speed can be sacrificed)? Maybe caching should be disabled by default but with the option to turn it on if the user wants it?

you can memory-map files in chunks and keep references to the mapped buffers or evict them once a certain limit is reached. note that mapped buffers are not necessarily backed by RAM, they act more like swap space, except it goes straight to the original file instead of a swap partition. the downside is that anything reading from the buffer can unpredictably incur IO overhead if there's memory pressure and the OS dec…

So, something like LRU cache of MappedByteBuffers, one buffer per chunk (i.e. "piece")? I wonder what queueing strategy would look like, just enqueue a couple of subsequent pieces when one is requested and loaded?

Re: Show HN: Bt – BitTorrent library in Java 8

#66

Post by atomashpolskiy »

ikurei wrote: post #64

Not very familiar with the Java world yet. I've heard Android now supports at least some features from Java 8, but would this library work in an Android app?

I guess not. There is a ticket for backporting this project to Java 7 or RxJava (https://github.com/atomashpolskiy/bt/issues/7), but I personally think it's not worth it.

Re: Show HN: Bt – BitTorrent library in Java 8

#67

Post by atomashpolskiy »

djhworld wrote: post #60

Really like the approach around using Guice as a central point for hooking your own code into the system. Will look forward to reading through the code later!

Thanks! God bless IoC, it saves my ass each time I make some silly design choice

Re: Show HN: Bt – BitTorrent library in Java 8

#68

Post by readittwice »

pjmlp wrote: post #51
weberc2 wrote: post #14

Earlier quoted context omitted.

Good to know, but 1-2 seconds is still very slow compared to a native app. I have an 8MB Go CLI application that can startup and print its help in .05 seconds, and even that is probably slow compared to a C or Rust equivalent.

Any savy Java developer knows how to AOT compile to native code, if that really matters. There are plenty of JDKs that support it, and even Oracle is finally adding support for it with Java 9, initially only for Linux x64. By Java 10 timeframe no one that only knows about OpenJDK and not the several other JDKs can state that Java starts slow vs C, because both will be AOT compiled to native code, loading native .so f…

From what I've seen Java/JVM AOT won't produce binary executables but shared libraries that will be loaded on startup by the JVM. When I first read about Java AOT-compilation I expected it to produce real executables that's why I think this is important to mention. But please correct me if I am wrong. So if this is true even with AOT compilation you still need the JVM as dependency (although I think you can get a minimal JVM in under 10MB). It also seems that the AOT compiled code needs to be recompiled on Java updates. Although I quite like Java and the JVM, I still wouldn't choose Java for writing simple command line tools.

Nevertheless it is quite useful for improving startup for tools like Gradle or server applications. But sure, I also don't expect Java startup performance to be a problem in the mid- to long-run.

Re: Show HN: Bt – BitTorrent library in Java 8

#69

Post by the8472 »

the8472 wrote: post #59
atomashpolskiy wrote: post #55

Earlier quoted context omitted.

It makes sense, what would you advise in case of big files that don't fit into memory (or when it's undesirable to use big amounts of RAM, and speed can be sacrificed)? Maybe caching should be disabled by default but with the option to turn it on if the user wants it?

you can memory-map files in chunks and keep references to the mapped buffers or evict them once a certain limit is reached. note that mapped buffers are not necessarily backed by RAM, they act more like swap space, except it goes straight to the original file instead of a swap partition. the downside is that anything reading from the buffer can unpredictably incur IO overhead if there's memory pressure and the OS dec…

> java doesn't have an api to check residency of buffers.

Too late to edit now, but I misremembered that part. I think the issue was that isLoaded was not entirely reliable.

Re: Show HN: Bt – BitTorrent library in Java 8

#70

Post by the8472 »

atomashpolskiy wrote: post #65
the8472 wrote: post #59

Earlier quoted context omitted.

you can memory-map files in chunks and keep references to the mapped buffers or evict them once a certain limit is reached. note that mapped buffers are not necessarily backed by RAM, they act more like swap space, except it goes straight to the original file instead of a swap partition. the downside is that anything reading from the buffer can unpredictably incur IO overhead if there's memory pressure and the OS dec…

So, something like LRU cache of MappedByteBuffers, one buffer per chunk (i.e. "piece")? I wonder what queueing strategy would look like, just enqueue a couple of subsequent pieces when one is requested and loaded?

Start simple, then heap on optimizations if there are latency or throughput issues.
Post reply on HN