I don't strictly disagree, but one of the reasons for abstraction like this is to enable your own development team to change the implementation without having to change the API. I may be wrong, but my sense is that this has been a motivating factor for the Java2D team.
Once you allow developers to peek under the hood, then they start optimizing their code using the low-level components and bypassing the abstractions you've created. Then when you make changes to the underlying objects and their interactions, it breaks everyone's applications because they relied on those interactions. To make a gross generalization, to me this is the difference between thinking like a C/C++ developer versus a Java developer. Java builds in so many abstractions, from garbage collection to Swing to stuff like managed images. In my opinion, C++ development generally exposes more of the underlying workings of the components. That's not to say one or the other is objectively better, obviously every tool has its use, but I'm giving a reason why a system developer might not want to expose the inner implementation of their system. That's just my take when trying to see it from the other side. Mike > -----Original Message----- > From: Discussion list for Java 2D API > [mailto:[EMAIL PROTECTED] On Behalf Of Ken Warner > Sent: Thursday, September 11, 2008 12:54 PM > To: [EMAIL PROTECTED] > Subject: Re: [JAVA2D] Dynamics of acceleration of > BufferedImages ("managed images") > > Dmitri Trembovetski wrote: > > That's the idea. The developer shouldn't be worrying about > this stuff, > it should work for most cases. For those cases where the user needs > tweaking or resource management there are APIs like > setAcceleratedPriority > and the like. > > ------ > > That's exactly the kind of stuff what a real programmer > should be worrying about. And what if someone (like me or > the author of this thread) run into a case where it doesn't > quite work the way we want it to? We're screwed because we > can't get to the foundation classes to fix the problem. > > Give us the primitives and let us figure out how to use them. > You (the Java Dev Team) are trying to do too good a job. > > The first accessible layer should be the primitives (well > documented) and then you can layer higher level API's on top > for accessabliity and ease of use for less accomplished programmers. > > High level API's as you've implemented in Java2D are really > useful and make the job a whole lot easier. But there are > times when you really need the low level stuff at your finger > tips so you *CAN* change stuff. > > ============================================================== > ============= > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body of the message "signoff JAVA2D-INTEREST". > For general help, send email to [EMAIL PROTECTED] and > include in the body of the message "help". > > mailgw3.lmco.com with ESMTP id m8BH4ZcP017142; Thu, 11 Sep > 2008 13:04:35 -0400 (EDT) > Received: from swjscmail2.sun.com (swjscmail2.Sun.COM [192.18.99.108]) > by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP > id m8BGtCvR019976; > Thu, 11 Sep 2008 16:55:29 GMT > Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) > by swjscmail2.sun.com (8.11.7p3+Sun/8.11.7) with ESMTP > id m8BGsFj05970; > Thu, 11 Sep 2008 10:54:15 -0600 (MDT) > Received: by JAVA.SUN.COM (LISTSERV-TCP/IP release 15.0) with > spool id 2358172 > for [EMAIL PROTECTED]; Thu, 11 Sep 2008 > 10:54:32 -0600 > Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM > [192.18.98.34]) by > swjscmail1.java.sun.com (Postfix) with ESMTP id > AEE023A82E for > <[EMAIL PROTECTED]>; Thu, 11 Sep 2008 > 10:54:31 -0600 (MDT) > Received: from relay23.sun.com (relay23.sun.com > [192.12.251.54] (may be > forged)) by brmea-mail-3.sun.com > (8.13.6+Sun/8.12.9) with ESMTP id > m8BGojCC016809 for <[EMAIL PROTECTED]>; > Thu, 11 Sep 2008 > 16:54:57 GMT > Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] > [150.143.232.70]) > by relay23i.sun.com with ESMTP id BT-MMP-3418417 for > [EMAIL PROTECTED]; Thu, 11 Sep 2008 16:54:56 Z > Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by > mms24es.mms.us.syntegra.com with ESMTP id > BT-MMP-111927369 for > [EMAIL PROTECTED]; Thu, 11 Sep 2008 16:54:56 Z > Received: from vms173003pub.verizon.net ([206.46.173.3] > [206.46.173.3]) by > relay21i.sun.com with ESMTP id BT-MMP-5067960 for > [EMAIL PROTECTED]; Thu, 11 Sep 2008 16:54:55 Z > Received: from [192.168.1.47] ([71.105.40.117]) by > vms173003.mailsrvcs.net (Sun > Java System Messaging Server 6.2-6.01 (built Apr 3 > 2006)) with > ESMTPA id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED]; Thu, 11 Sep 2008 > 11:51:52 -0500 (CDT) > References: > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > Reply-To: Ken Warner <[EMAIL PROTECTED]> > Sender: Discussion list for Java 2D API <[EMAIL PROTECTED]> > Subject: Re: [JAVA2D] Dynamics of acceleration of > BufferedImages ("managed images") > To: [EMAIL PROTECTED] > User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) > X-Accept-Language: en-us, en > X-Antispam: No, score=0.0/5.0, > scanned in 0.056sec at (localhost [127.0.0.1]) by > smf-spamd v1.3.1 > - http://smfs.sf.net/ > X-Brightmail-Tracker: AAAAAA== > X-MessageGate-spam: 120 > X-Original-To: [EMAIL PROTECTED] > > Dmitri Trembovetski wrote: > > That's the idea. The developer shouldn't be worrying about > this stuff, > it should work for most cases. For those cases where the user needs > tweaking or resource management there are APIs like > setAcceleratedPriority > and the like. > > ------ > > That's exactly the kind of stuff what a real programmer > should be worrying about. And what if someone (like me or > the author of this thread) run into a case where it doesn't > quite work the way we want it to? We're sc > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
