Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder1.xlned.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!217.73.144.44.MISMATCH!ecngs!feeder.ecngs.de!Xl.tags.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local2.nntp.ams.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 28 Jul 2014 07:32:10 -0500 From: "Chris Uppal" Newsgroups: comp.lang.java.programmer References: <38c5efcc-315c-4b8d-a478-89e352af7143@googlegroups.com> Subject: Re: Java blunders Date: Mon, 28 Jul 2014 13:33:17 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Message-ID: Lines: 31 X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-ZLg/XlqtXIxTIK5o9AbQ1ve3TNpz3Lh1juEekO9xmxQoXRZ2OTo9v8ZQTXtRyvW9ARaZZ/ejN2znlwO!hNewaon2yveHBx+0iF219/MxWWWscHBrcJVkRSufOhEqNMws/yZzJ07kH6iVmWK6s6QbmsqS3A== X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 2869 Xref: csiph.com comp.lang.java.programmer:29390 Joshua Cranmer ?? wrote: > You are making some presumptions here that I don't think are entirely > true. The problem with I/O is, in part, there's no one-size-fits-all > solution. Recursive descent parsers, for example, often really need > blocking, "synchronous" [1] I/O to make them readable and maintainable. > Many servers might care about zero-copy file-to-network streams, which > requires different infrastructure. A database would rather just treat an > entire file as a large block of memory (perhaps with detailed hints to > kernel prefetching and page table management). Sometimes people want > combinations of these approaches. I think that most of the cases you mention would be handled perfectly well by normal method based syntax. After all there's no reason to use the same style of design or notation for such completely different kinds of IO. One exception is stream handling, which would -- IMO -- benefit from deeper support in the language. But still done at library level (and hence "supported" by making the language more expressive), if only because there are at least two styles of stream handling, Push and Pull, and it's not clear which is "better". The other case I can think of is where you want to "map" a file into memory in the style of memmap() -- but not necessarily restricting yourself to OS-supplied features. In such cases it would be most natural to present the mapped data as if it were a large byte[] array. Again Java lacks the expressivity to support that. -- chris