java.net contains the basic networking abstractions, so I'd say
that it's as "core" to Java as "socket.h" is "core" to C.
So
that's "not at all"? The socket.h interface is not even part of the C standard,
and many parts of the C library that are part of the standard are not what I'd
call "core".
C is a bit of a bad analogy anyway, as none of the
standard libraries are required by the language itself. Quite unlike Java.
With C, a literal string is simply an array of characters, which does not depend
on any libraries. With Java, a literal string is an object of type
java.lang.string.
--- Do not meddle in the affairs of Wizards, for it
makes them soggy and hard to light. [ Reply to This | Parent | # ]
|
java.nio augmented java.io. The book on it was that the buffering was more
intelligently done than with java.io. The language api expanded with the new
package, but the io interface did not change. Based on its timing, I think nio
was really motivated by the dual core processor architectures emerging in the
server market. It was the new io, hence the name. Is java.net a
core
package? I dislike being coy, but it depends on what one means by core.
Am I
directly using java.net classes in the code I've written (personal utilities,
java server pages servlets, desktop client/server applications with a database
backend)? Very rarely. I did something a couple of weeks back that reads a file
on the internet to verify that the user has the latest version and that
required an
import of java.net.URL. I would guess that the database connection
and the java
server page servlets generate java.net.* objects as an
implementation detail that
the interface hides from me. So without it, I
couldn't write those programs. As
the network has become more important,
java.net has increased its value. In
1996, when an external modem connected one
to compuserve and the CAT5
network jack was not standard, I could see a case
that java.net was not core
back then. Object dependencies in java are
represented by a graph
rather than a tree. There may be cycles: Class A refers
to B refers to C refers to
D
which refers to A. In java, classes are organized
into packages, so class B is
broken if the package containing class C is
removed. A workaround may be to
eliminate all the methods of class B that uses
class C objects as an input or
output. The set of written programs that compile
and run is now decreased, but
are there still lots of programs that will still
run? Yes. java.io and java.lang
are definitely core. Without the java.io
package and without java.lang.System, a
program would have no inputs or
outputs. java.lang.Object is the superclass of
all classes and provides
elementary methods of identification and
equality and display, hashCode(),
equals(), and toString() respectively.
But could Sun have put the the io
classes in the java.lang package back in
the 90s? Sure.
The organization of
the classes into packages was arbitrary, though I think
Sun's engineers did
their best to come up with a sensible approach. But, once a
class became part
of a package, that class had to stay in the package or
existing programs would
break. In that sense, everything becomes core,
because the removal of any of
java's current 166 packages means somebody
out there is going to have a bad day
and have to spend hours recoding around
the new omission. [ Reply to This | Parent | # ]
|