Take this all w/ a big ol' helping of "I may not know what the
hell I'm talking about in all cases, but this is my personal
opinion" and call me in the morning.
Calvin Austin wrote:
>
> would help you become more productive. Which bugs, like
> the international keyboard bug are causing problems for you.
1) Issues with the rpm packages:
a) What's the deal w/ the name of the file and the package
name not matching?
Annoying and not how every other rpm I've seen works. I
install package file
j2se-1.3-whatever. Do a rpm -ql j2se to see what files are
in it and find that
the package hasn't been installed. Turns out the actual
'package' name is in
fact 'jdk'???
b) As a continuation of 'a', could we break those packages
out? Maybe 'j2se-jre' with
the actual runtime, 'j2se-jdk' with the devel stuff,
'j2se-demos' with the demos.
c) The dependencies are wrong for the package. 'grep' is
required by .java_wrapper.
libX11 is required as well as libstdc++ (actually its
libstdc++-libc6.1-1.so.2.
By the way, The correct libstdc++ requires compat-libstdc++
on redhat 7.0.
Apparently the c++ thing only came into play with hotspot.
2) Sun is supposedlly set to adopt Gnome as the eventual default
desktop for solaris.
How about getting rid of motif for the jdk AWT now? At least
for linux, but there's no
reason it wouldn't work for both. Default to gtk+ for linux
and the solaris default
can change whenever sun actually switches. There are
apparently solaris users that
run Gnome already who would probably also appreciate it. I
would say a Qt implementation
for the KDE people would be nice also.
3) Bug 4191980
(http://developer.java.sun.com/developer/bugParade/bugs/4191980.html).
It's amazing that this has been around since 1.1.6 (probably
earlier). Sadly, if
the jdk was in fact Free Software this would have easily been
fixed. Don't mention
the Sun open source license (I don't remember what it's called
today). That's more
of a lock-in than Microsoft. At least they just lock you into
using there software
by not being compatible with other software. Sun wants people
to effectively lock
themselves into using only the Sun implementation. There
attempt at blocking
'forking' basically would appear to block creating or working
on another implementation.
Kaffe for instance. Or blocking real innovation by allowing
someone to say, "hey,
these people are completely off base with their impl, I could
make the JVM 100x faster
by doing X" and then release it under the GPL. they're
already tainted. I think the
shortcoming is basically that Sun is trying to create this
"community" which seems to
be on only a product by product basis when the real community
already exists which is
the software developer community. small pond, largest pond.
I think some of the fears of forking of the java platform could
have been averted by not having the API be an ever expanding
blob. There doesn't have to be an API for everything.
Especially when there's not a consistent design or pattern across
all APIs. They might as well be defined by different companies
in some instances. The java 2 standard edition API is huge.
Personally, as a developer, I would like to see more focus placed
on a Java Core API or something as the main focus point for
compatibility. Probably simliar to the Personal Java API.
Actually, maybe 2 levels one at the JVM bytecode level (Does this
JVM properly run the core java langauge?) and then a second level
w/ the AWT, networking, io, etc. I don't have time to learn and
evaluate every API that comes down the pipe. I, probably like
many others, have developed custom APIs that our company uses.
Mostly b/c they just don't/didn't exist at the time of need.
However, we maintain compatibility at some level. I'm not saying
all APIs are bad. JDBC and Servlets as clear winners. Though
they could use improvement. (I'm personally a little
dissappointed in the direction the servlet API is taking.)
just my $0.02, although I think it got close to $0.50;^)
jason
--
Jason Gilbert | http://home.hiwaay.net/~gilbertj/
--
I wish I could make the garbage collector thread in my
brain less aggressive.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
