Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

java.nio.*

0 views
Skip to first unread message

ak

unread,
Aug 21, 2003, 5:19:15 AM8/21/03
to
am I the only one to say that the java.nio. is bullshit?

i have been trying to write some code using it to transfer file over the
net.

small file it is ok, big file -- problematic.

java.lang.OutOfMemoryError
at java.nio.Bits.reserveMemory(Unknown Source)
at java.nio.DirectByteBuffer.<init>(Unknown Source)
at java.nio.ByteBuffer.allocateDirect(Unknown Source)
at sun.nio.ch.Util.getTemporaryDirectBuffer(Unknown Source)


S. Balk

unread,
Aug 21, 2003, 5:39:21 AM8/21/03
to
> am I the only one to say that the java.nio. is bullshit?

am I the only one to say that the way you use the java.nio. is bullshit?

ok... you are trying to put a large file in memory, and the memory turns out
it isn't big enough. that's no problematic, that's what you should expect.


Thomas Weidenfeller

unread,
Aug 21, 2003, 6:03:58 AM8/21/03
to
"S. Balk" <s.b...@hccnet.n0spam.nl> writes:
> am I the only one to say that the way you use the java.nio. is bullshit?

No :-)

Followup set to a more appropriate group.

/Thomas

Tor Iver Wilhelmsen

unread,
Aug 21, 2003, 12:26:51 PM8/21/03
to
"ak" <a...@me.com> writes:

> java.lang.OutOfMemoryError
> at java.nio.Bits.reserveMemory(Unknown Source)
> at java.nio.DirectByteBuffer.<init>(Unknown Source)
> at java.nio.ByteBuffer.allocateDirect(Unknown Source)
> at sun.nio.ch.Util.getTemporaryDirectBuffer(Unknown Source)

What is your heap setting? You did remember to pass a large enough
value to the -Xmx option when running you app, yes?

Jordan Zimmerman

unread,
Aug 21, 2003, 12:46:48 PM8/21/03
to
There are bugs with nio in the 1.4.2 release. You need to go back to 1.4.1
or wait for a fix. Check the Bug Parade.

--
Jordan Zimmerman
http://www.jordanzimmerman.com

iksrazal

unread,
Aug 21, 2003, 2:12:51 PM8/21/03
to
"ak" <a...@me.com> wrote in message news:<3f448e86$1...@news.tm.net.my>...

Two things:

1) This most likely is a heap problem. Try something like:

java -Xmx128m

Try both sides if neccesary.

2) The real advantage of nio is for sockets - previously you needed
one thread per connection.

iksrazal

Brian S O'Neill

unread,
Aug 23, 2003, 2:17:34 AM8/23/03
to
I've played around with both the nio file APIs and socket APIs. Though
functional, they are buggy and much harder to use than they really need to
be. For memory mapped file I/O, I wrote my own simple native interface that
uses good ol' byte arrays. It's much simpler to use and I found it to be
faster too. For sockets I took the same approach, again with the same
approach. Easier and faster.

The problem with nio is that it is way overdesigned and imposes special
restrictions on how it is to be used. ByteBuffers, while convient when
writing certain kinds of applications, is a total PITA for anything else.
Try to implement a database or persistent hashtable using nio memory mapped
files. You'll find that sometimes the auto-moving cursor in the ByteBuffers
isn't the desired behavior. Try profiling the app and you'll see tons of
temporary objects being created as well as other useless work being
performed. ByteBuffers should have been designed as a higher level API. Byte
arrays offer much more flexibility.

In my opinion, nio is only good at writing only one application: a web
server. Open FileChannel, read chunks into direct ByteBuffer, flip, spew
contents out a SocketChannel. Even then, it won't scale that well on
platforms that support asyc socket I/O that has advanced beyond the
select/poll model.

It's also a pity that they rewrote the old socket API to use nio internally.
My applications that rely on the old sockets crash under load when running
all versions of jdk1.4. Jdk1.3.x is stable.

Whille nio is better than nothing, don't expect anything better to ever come
bundled with the jdk. We're stuck with it for the remaining lifetime of the
Java platform, and it sucks.


"ak" <a...@me.com> wrote in message news:3f448e86$1...@news.tm.net.my...

Jordan Zimmerman

unread,
Aug 24, 2003, 1:33:02 PM8/24/03
to
"Brian S O'Neill" <bron...@earthlink.net> wrote in message
news:2GD1b.1$Jh...@newsread4.news.pas.earthlink.net...

> I've played around with both the nio file APIs and socket APIs. Though
> functional, they are buggy and much harder to use than they really need to
> be.

I agree completely with this. Prior to 1.4, the Java libraries have been,
mostly, very clean and simple. The NIO package looks like it was written by
committee. It is very hard to know how to correctly use the library.
ByteBuffers are a burden.

Roedy Green

unread,
Aug 24, 2003, 2:03:47 PM8/24/03
to
On Sun, 24 Aug 2003 10:33:02 -0700, "Jordan Zimmerman"
<jor...@altura.com> wrote or quoted :

>ByteBuffers
Is the point of ByteBuffers to deal with endian issues?
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Thomas G. Marshall

unread,
Sep 17, 2003, 10:50:44 PM9/17/03
to
iksrazal <iksr...@terra.com.br> horrified us with:

...[snippity doo dah]...

> 2) The real advantage of nio is for sockets - previously you needed
> one thread per connection.

No, the real advantage of nio is in not having to use the ridiculous
decorator pattern x levels deep. It was both slow /and/ confusing. nio
fixes all that.


0 new messages