In most cases, the principles you've outlined are completely valid.
But there are programming problems that are best solved by a
*STUDIED USE* of the foundation primitives.
Yes, a less experienced programmer can really muck things up
by random changes in the foundation API's. I've seen it happen.
In fact even Java releases cycle through that problem.
But those kinds of problems are self curing. You can't sell
software that won't run.
There is a real psychological bias in development teams (not just
the Java team) that thinks nobody else is technically capable.
Common human nature -- our tribe is the only tribe etc. But
in fact, there are a lot of really good programmers in the World
who can cope with and even improve Java even at the lowest levels.
I'm not advocating Open Source -- or as I like to refer to it Open Sores
programming. That's one can'o'worms I don't want to get tangled up
in. But no team -- no matter how technically skilled they are -- can
anticipate *EVERY* need and encapsulate a universal solution. Just
can't happen.
Give us the primitives and layer the higher levels of abstraction
on top and let us decide how to use them. One characteristic of
maturity is the willingness to allow others responsibility for
their own actions. Let us grow with you...
Nidel, Mike wrote:
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".
===========================================================================
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".
