|
|
|
| Authored by: Anonymous on Friday, April 20 2012 @ 10:41 AM EDT |
| For a prime example of not good API. [ Reply to This | Parent | # ]
|
| |
| Authored by: hardmath on Friday, April 20 2012 @ 11:07 AM EDT |
At some point we Groklarwinians will have to delve into the
history and
procedures of the JCP, particularly the JSPA
(Java Specification
Participation Agreement) and the role
of the two EC's
(Executive Committees, one for Java SE
and EE, the other for Java ME
specifications).
For now let's note that the formalized process of
requesting, developing and maintaining Java specifications
has been a
community effort since 1998. Java the
Language was introduced in 1995, and its
platform packages are the
mechanism by which Java evolves as
a standard language.
So the difficulty
of designing APIs in this context is not
just the general one in doing good OO
(object-oriented)
design, but the compounded problems of managing backward
compatibility/deprecation of interfaces and making design
decisions that
almost everyone can live with.
The Core APIs have a lot of "burn-in" at this
point, and
most of the effort in recent years has been on more
specialized
interfaces. For example,
Java
Swing was added to the JFC (Java Foundational Classes)
to provide GUI
support in Java desktop applications,
somethat that was originally addressed by
AWT
(Abstract Window Toolkit).
The earlier approach was quite "platform
dependent", while
Swing is written in Java and to that extent platform
independent. However Swing relies on and extends lower-
level AWT
components.
---
Do the arithmetic or be doomed to talk nonsense. --
John McCarthy (1927-2011) [ Reply to This | Parent | # ]
|
| |
| Authored by: jpvlsmv on Friday, April 20 2012 @ 11:22 AM EDT |
Steve Jobs is credited with saying that a good design is not when there's
nothing left to add, but when there's nothing left to take away. (hence the
single button on the iPod)
Good APIs are like that- it's not just that the API has everything anybody could
possibly want to do with the programming language, it's when the API is
"just enough" to make anything possible and relatively easy.
This impacts the SSO of an API only in the "selection" part- the
Structure and Organization is almost entirely determined by the natural
interactions between the selected elements.
--Joe[ Reply to This | Parent | # ]
|
- Jobs was not first - Authored by: Anonymous on Friday, April 20 2012 @ 11:56 AM EDT
- Cite? - Authored by: Anonymous on Friday, April 20 2012 @ 03:04 PM EDT
- Cite? - Authored by: Anonymous on Saturday, April 21 2012 @ 02:23 AM EDT
- API Design is hard - Authored by: Anonymous on Friday, April 20 2012 @ 03:54 PM EDT
- Right - Authored by: jpvlsmv on Friday, April 20 2012 @ 08:22 PM EDT
| |
| Authored by: darrellb on Friday, April 20 2012 @ 11:59 AM EDT |
You generally have one shot at an API -- once it's released and
people are using it, you can't change the rules without breaking the code
everyone has already developed. Which is the main reason that all
implementations of the Java APIs use the same structure, organization, and
sequence. The API Specification dictates. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 12:08 PM EDT |
Be up a while trying to read through a ton of stuff and
saw the Judge's orders: And read the following:
"For the 37 accused API packages,..."
I did not think a software package could be "accused"
of anything since it is inanimate object.
Any rate maybe lack of sleep but it came across as
funny.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 03:18 PM EDT |
An example that comes to mind here is how Intel deals with
licensing it's IPP libraries (http://software.intel.com/en-
us/articles/intel-ipp/ ). When you buy a license, you get
the right to distribute the library with your program, but
there are restrictions on distributing the header (and on
who can compile against it). My understanding, is that
there is a layer between the the public interface and the
actual function calls to the libraries, and that is what
makes this license kosher.
The fact that they are going to these lengths to separate
the API from the implementation suggests Intel does not
believe Oracle's position.
I also recall reading something about tactics for separating
your API from you implementation in c/c++ that give people a
usable header with out revealing anything about your
internal data structures.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 05:02 PM EDT |
It is easy to write an API. It is hard to write an API that
you will not regret in a few months, if anyone uses it. Very
much like a contract.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 08:23 PM EDT |
Programs come and go but API's are forever.
Once developers use your API you often can't change it with out breaking their
program. When there are 10,000 such programs you just live with whatever you've
done. A program with a bug you fix. An API with a limitation you're stuck with.
Java API's have an additional burden compared to Microsoft or even UNIX. They
endeavor to be useful on many operating systems, not just one, and over an
extreme spread of hardware, smart cards to mainframes. Not even Linux attempts
this.
Good Java API's are general enough to be very portable but not so general that
the power of the underlying system cannot still shine through. This is a tough
balancing act.
A good API makes it easy for the application developer to build without forcing
big, slow, or tricky underlying implementation.
I could go on. Certainly developing a good API is ten times as hard as building
the implementation. [ Reply to This | Parent | # ]
|
|
|
|
|
