|
|
|
| Authored by: lwoggardner on Monday, April 30 2012 @ 05:01 AM EDT |
| The chart is just the concept although parts of it are
embedded in the
documentation.
The package hiearchy java.nio.channels is indeed laid out in
source (and javadoc) form in a directory as
java/nio/channels.
Best way to
see this is to look at the javadoc for
SocketChannel where you
will see the URL contains
"java/nio/channels".
You'll also see at the top of that page the c
lass inheritance hierarchy going
all the way back to Object which matches
the chart (except
that you'll note that Object is actually in the java.lang
package rather than java.nio.channels.)
These two hierarchies are
independent dimensions which
they've confusingly tried to represent in one tree
structure. I think they are just saying that both the
inheritance hierarchy
and package structures are part of the
SSO.
This SSO is found in tangibly
expressed form in the
source code, and also in the bytecode and javadoc
derived
from the source. Nearly identical package and class
hierarchies
(structure & organisation) will exist in the Dalvik source,
bytecode and
documentation for the subset of Java that
Google deemed required for Android. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, April 30 2012 @ 05:32 AM EDT |
They are conflating the idea of an inheritance graph
which is what Oracle listed, with SSO of the source code
They are not quite the same thing though they bear some superficially
similarity.
This (I believe) is visible somewhere in the source code for Android itself ,
it is not in the SDK (except maybe in binary form buried in a zipped up jar
file)
Broadly speaking it would bear the same structure, up to the point of
implementation, as the documentation, and where in the reference documentation
you see the HTML files
e.g
<SDKROOT>/android-sdk-linux_x86/docs/reference/java/nio/channels/Channels.
html
In the android source code you see the implementation
(note this is not the SDK, this is Android itself)
<ANDROIDROOT>/<sourcecode>/java/nio/channels/Channels.java
is the "compilable code" equivalent where you can see the names the
comments, the declarations and the implementing source code.
For an example of what that might look like you can go here
http://webcache.googleusercontent.com/search?q=cache:BPJEYsfaBfkJ:source-android
.frandroid.com/libcore/luni/src/main/java/java/nio/channels/Channels.java+&c
d=1&hl=en&ct=clnk&gl=uk&client=firefox-a
As an interesting side note while we are here, it is also worth taking a look at
the source code for Channel.java,
(as Opposed to Channels.java) which goes to some of the discussion about
merger/interface in java etc.....
I reproduce "the compilable code" here, for review/critique, this is
taken from source code under Apache 2.0 license, is a minimal quote, names are
not protected, and I believe this is fair use. I'm sure that this post will get
killed if its not.
package java.nio.channels;
import java.io.Closeable;
import java.io.IOException;
public interface Channel extends Closeable {
public boolean isOpen();
public void close() throws IOException;
}
This for me is where the worry is, all of this is functional /name, there is no
content anywhere in contrast with Channels.java which where the names/SSO vanish
under the weight of implementation.
Conversely, you cannot change one letter otherwise it is no longer the Channel
Interface, it is a different interface.
Note the use of 'import', this saves having to use the fully qualified package
name in front of the name every time you type the name. so you see 'extends
Closeable' rather than 'extends java.io.Closeable'.
Of course if JUdge Alsup sticks to his guns, and he has been pretty immovable as
well as keen to make the point to the jury via direct witness
questioning/direction what he's referring to when he says...
names are unprotected
then the above code reads...
package redacted;
import redacted;
import redacted;
public interface redacted extends redacted {
public boolean redacted
public void redacted throws redacted
}
how do you decide that?
Anyway, after hearing the Jury verdict, the Judge is deciding the issue on SSO,
the Jury only decides a) if it constitutes copying, b) would if be fair use
And as far as I can tell the document stuff is never going to stand up to
scrutiny.
as for what is compared to what, I left a post in the previous thread that
analyses the jury instructions which I think answers that question (if you can
follow it)
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, April 30 2012 @ 09:26 AM EDT |
While its true that multiple dots in a filename or directory name works just
fine, that's not normally how Java packages are stored.
They make a subfolder for each dot, e.g.:
C:java_stuffjavaniochannelsOverlappingFileLockException.java
The java compiler javac knows how to look in the proper subdirectories for
to find the classes you import. So does the Java VM's default classloader.
A .JAR file (Java ARchive) is just a zip file with the same kind of structure;
inside the .jar is a "java" subdirectory, and inside that is an
"nio"
subdirectory, etc.[ Reply to This | Parent | # ]
|
| |
| Authored by: Ian Al on Monday, April 30 2012 @ 12:39 PM EDT |
Can you see copying of SSO from a copyright work to a Google work?
If they have conflated inheritance with directory is that something that one can
see fixed in a medium or is it something you deduced as an idea from all the
documents and files, put together?
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
|
|
|
|
