Hidden features of java

[Lew]

Depends on what is meant by "Java".

If Java == the Java standard,

That's how I construed it.

then it is indeed hard to talk about
hidden features and sun.* classes are not part of Java.

I agree with that.

If Java == SUN's Java implementation, then there are lots
of stuff that is not documented.

Since there are other implementations, I don't think it's fair to completely
equate Java with Sun's implementation.

If IBM's Java doesn't include sun.misc.Unsafe, then I'd say that that
demonstrates that that class is not part of Java.

If one could conceive of an implementation of the Java API (itself not exactly
part of Java) that doesn't use that class, then that also demonstrates that it
isn't part of Java.

It's pretty clear that one could implement the Java API without that class,
ergo it's not a feature of Java per se but only of a particular
implementation, and therefore not a candidate for a "feature of Java" at all,
much less a hidden one.

 

[Arved Sandstrom]

True, once, but I'll bet a nawful lot of Java folks haven't been
(explicitly) playing with RMI lately. Besides, I didn't include those.

Anyway, the point is that APIs contain fundamental classes and methods,
not necessarily widely-popular ones. The problem isn't whether the API
is too big, but whether it's big enough.

I wouldn't use the word "fundamental", not in the dictionary sense of
"essential", "necessary", "pertaining to the foundation or basis", or
"of great significance". A lot of the APIs are useful but not
fundamental, IMO.

I guess it depends on where you draw the line in the sand. As an
example, I don't consider Swing to be fundamental in any of the above
senses, because clearly a lot of Java developers - and not just
dilettantes - don't need Swing at all. That Swing happens to be very
useful to a minority of Java developers doesn't make it "fundamental".

To me Java collections are fundamental, and JAX-WS is not. java.util.*
(or the lion's share of it) is fundamental; javax.lang.instrument.*
isn't. And so forth.

You used the term "widely popular". Using the definition of "popular" as
"suited to or intended for the general masses", I'd advance the argument
that a fundamental API _is_ popular. Maybe not directly, but in the
sense that I would find it difficult or impractical to consider writing
most any non-trivial Java application without having "fundamental" Java
APIs at my disposal (including therefore APIs that support the ones I
use directly). And when I say "I", I mean your general purpose Java
programmer, not me specifically.

There may be some differences of opinion around this one.

AHS

 

[Tom Anderson]

That's how I construed it.


I agree with that.


Since there are other implementations, I don't think it's fair to completely
equate Java with Sun's implementation.

If IBM's Java doesn't include sun.misc.Unsafe, then I'd say that that
demonstrates that that class is not part of Java.

IBM's java does include sun.misc.Unsafe. So doesn Google's Dalvik, as used
on Android. I don't know about any other implementations.

If one could conceive of an implementation of the Java API (itself not
exactly part of Java) that doesn't use that class, then that also
demonstrates that it isn't part of Java.

It's pretty clear that one could implement the Java API without that
class, ergo it's not a feature of Java per se but only of a particular
implementation, and therefore not a candidate for a "feature of Java" at
all, much less a hidden one.

I think that's chicanery. It's not a feature of java-the-language, but it
is a feature of java-the-implementation, for at least three values of
implementation. Since it's the implementation that is actually used to
build and run sofware, not the language, it counts as a feature.

Indeed, if there was a feature of the language that was not implemented in
any implementation - the pre-reform memory model, for instance - would you
call that a feature of java? I don't see doing that could be of any value
to anyone.

tom

 

[Arne Vajhøj]

IBM's java does include sun.misc.Unsafe. So doesn Google's Dalvik, as
used on Android. I don't know about any other implementations.

BEA (now Oracle) JRockit, Oracle (old), Apache Harmony, Apple for
MacSO X, HP for HP-UX, HP for OpenVMS etc..

Some of them are probably based on SUN and may (or may not have)
the SUN classes.

I think that's chicanery. It's not a feature of java-the-language, but
it is a feature of java-the-implementation, for at least three values of
implementation. Since it's the implementation that is actually used to
build and run sofware, not the language, it counts as a feature.

No.

It is essential to distinguish between the standard and the
implementation.

Arne

 

[Lew]

I wouldn't use the word "fundamental", not in the dictionary sense of
"essential", "necessary", "pertaining to the foundation or basis", or
"of great significance". A lot of the APIs are useful but not
fundamental, IMO.

You are mistaken, judging by the examples you provided. Sure, some APIs
might've snuck in that are not fundamental, but for the most part the java.**
and javax.** are fundamental.

I note that <http://en.wiktionary.org/wiki/fundamental> gives a usage example
of, "essential part, as, the fundamentals of linear algebra." The fact that
linear algebra's fundamentals don't directly apply to planar geometry doesn't
make them not fundamentals of maths.

You are confusing "universal" with "fundamental".

I guess it depends on where you draw the line in the sand. As an
example, I don't consider Swing to be fundamental in any of the above
senses, because clearly a lot of Java developers - and not just
dilettantes - don't need Swing at all. That Swing happens to be very
useful to a minority of Java developers doesn't make it "fundamental".

Swing is fundamental, if you happen to be doing GUI programming.

You are confusing "universal" with "fundamental".

To me Java collections are fundamental, and JAX-WS is not. java.util.*

JAX-WS is fundamental, if you're programming web services.

(or the lion's share of it) is fundamental; javax.lang.instrument.*
isn't. And so forth.

javax.lang.instrument is fundamental, if you're instrumenting code.

You used the term "widely popular". Using the definition of "popular" as
"suited to or intended for the general masses", I'd advance the argument
that a fundamental API _is_ popular. Maybe not directly, but in the

Nope.

Anyway, you are too focused on the extremely literal definition of
"fundamental". I'm willing to change my point to accommodate. Let's say that
the APIs are there to provide useful classes for commonly-conceived uses of
the language. Again, it is not a question of wide use - when you need a
particular functionality like a GUI textbox or a web-service locator, it is
extremely useful to have such a (fundamental for that purpose) class already
written, tested and optimized in API. Just because you personally aren't
writing GUIs doesn't mean you should deprive those who are.

sense that I would find it difficult or impractical to consider writing
most any non-trivial Java application without having "fundamental" Java
APIs at my disposal (including therefore APIs that support the ones I
use directly). And when I say "I", I mean your general purpose Java
programmer, not me specifically.

There may be some differences of opinion around this one.

I disagree that the API should be the home only for APIs that apply to "most
any non-trivial Java application". The "most any" part is a mistake. The
APIs are there to help the general population of Java programmers, who have
diverse and often divergent needs. You are not required to use the whole API
in your whole life, much less "most any" app, and they are not required to
restrict the API to only that functionality you want.

The idea is that generally, for "most any Java application" you write, there
should be some class or classes in the API that will help you, not that all
classes there will help you. By that standard, the standard Java API is
(mostly) a winner.

 

[Arved Sandstrom]

[ SNIP ]

I disagree that the API should be the home only for APIs that apply to
"most any non-trivial Java application". The "most any" part is a
mistake. The APIs are there to help the general population of Java
programmers, who have diverse and often divergent needs. You are not
required to use the whole API in your whole life, much less "most any"
app, and they are not required to restrict the API to only that
functionality you want.

The idea is that generally, for "most any Java application" you write,
there should be some class or classes in the API that will help you, not
that all classes there will help you. By that standard, the standard
Java API is (mostly) a winner.

You've clearly identified the major difference in opinion regarding what
goes into the JDK and what does not - should "fundamental" mean more
"universally (or broadly) essential" or "essential for a specific purpose".

The folks wishing to make JDK 7 modular want to do that for a variety of
reasons. One significant reason is that the provision of so many classes
in the JDK has meant that people use a lot of them when they write code.
There is a great deal of coupling. Mark Reinhold in his blog
(http://blogs.sun.com/mr/entry/massive_monolithic_jdk) comments that a
simple "Hello World" program loads and initializes over 300 classes,
which is insane. Or as my own immediate example, consider how much stuff
a programmer loads up into their program when they wish to do some
trivial logging and use the java.util.logging API.

IOW, everyone says reduce coupling, but the JDK has encouraged the opposite.

Reinhold has also said that if a developer wishes to program to the
sound API(s), he or she loads the sound module. If he or she needs
SWing, he or she can load the Swing module.

I agree with Reinhold.

AHS

 

[Tom Anderson]

BEA (now Oracle) JRockit, Oracle (old), Apache Harmony, Apple for
MacSO X, HP for HP-UX, HP for OpenVMS etc..

Some of them are probably based on SUN and may (or may not have) the SUN
classes.

I know Apple's is.

No.

It is essential to distinguish between the standard and the
implementation.

I do distinguish between them, right there in that last paragraph. My
point is that we work with the implementation, not the standard.

tom

 

[Martin Gregorie]

I know Apple's is.


I do distinguish between them, right there in that last paragraph. My
point is that we work with the implementation, not the standard.

Yep, and that's what makes porting ANSI C to systems with different
compilers such a headache.

 

[Arne Vajhøj]

I do distinguish between them, right there in that last paragraph. My
point is that we work with the implementation, not the standard.

1) It is important to use the terms "Java" and "SUN Java" to distinguish
properly between them.

2) I hope that most people actually code towards Java and not towards
SUN Java even though they may use SUN Java.

Arne

 

[Tom Anderson]

1) It is important to use the terms "Java" and "SUN Java" to distinguish
properly between them.

Since Sun (which is not all-caps, despite being an acronym) is behind the
standard as well as the main implementation, i don't think those are good
names. You could call them 'Java' and 'the Sun JDK', if you like.

2) I hope that most people actually code towards Java and not towards
SUN Java even though they may use SUN Java.

Yes, that's good advice. But it doesn't stop common features of the main
implementations from being features, even if they aren't in the standard.

tom

 

[Lew]

Since Sun (which is not all-caps, despite being an acronym) is behind
the standard as well as the main implementation, i don't think those are
good names. You could call them 'Java' and 'the Sun JDK', if you like.

And the first-person singular pronoun "I" in English is all caps. Man who
lives in glass house shouldn't throw stones.

 

[Tom Anderson]

And the first-person singular pronoun "I" in English is all caps.

All cap, you mean.

Man who lives in glass house shouldn't throw stones.

I'll refer to myself how i like. But i would suggest people refer to Sun
how Sun likes. Only seems polite.

tom

 

[Lew]

All cap, you mean.
Cute.

I'll refer to myself how i like. But i would suggest people refer to Sun
how Sun likes. Only seems polite.

You are abusing the English language, not referring to yourself. "I" is not
your name (nor is "i"), but a word in the language used universally beyond
your idiolectic usage.

The word "I" is not yours personally to abuse as you like. I have no problem
that you spell your name "tom", thus seemingly flouting the rule for proper
nouns, but your position with respect to a standard word in the English
language is objectionable.

 

[Arne Vajhøj]

Since Sun (which is not all-caps, despite being an acronym) is behind
the standard as well as the main implementation, i don't think those are
good names. You could call them 'Java' and 'the Sun JDK', if you like.

I could.

But industry standard is to refer to SUN Java, IBM Java etc..

Yes, that's good advice. But it doesn't stop common features of the main
implementations from being features, even if they aren't in the standard.

But they are not features of Java.

They are features of a Java implementation - features that should
not be used.

Arne

 

[Robert Klemme]

I have written a post about hidden feature of java on my blog.
I am not a super programmer but yes tried to compile come list of
hidden feature or you can feature not known by most of the people.

I will highly thankfull to you if you contribute to the post by
provide in feature you might now in java that you think can be
"hidden".
Link of the post is mentioned below

Link to the post : http://thegeekhead.blogspot.com/2009/06/hidden-features-of-java.html

Are you trying to get some page or ad hits? You did not even care to
format the code properly...

Not much to add to other comments other than maybe that
getClass().getResourceAsStream(...) is a much shorter form which
achieves the same than your last bit of code - and it's not even new:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getResourceAsStream(java.lang.String)

Cheers

robert

 

[Roedy Green]

Since Sun (which is not all-caps, despite being an acronym)

Stanford University Network
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Deer hunting would be fine sport, if only the deer had guns."
~ William S. Gilbert of Gilbert and Sullivan

 

[charlesbos73]

I have written a post about hidden feature of java on my blog.

If you're interested in things like nondeterministic behaviors
(fun with finalizers anyone?) and all the
"but-it's-in-the-spec-look-at-section-x-y-z" gotchas,
you'll enjoy books like "Effective Java" and "Java puzzlers".

The very fact that there's a 300 page books (and online add-ons)
dedicated to Java puzzling weirdities speaks volume.

Anyway to me the most "hidden" feature of Java is that it
actually is an OO language, yet it actually encourages and
facilitates both procedural-style and goto-style programming.

A guestimate would be that 99% of all Java programs out there
are actually just C programs in a Java shell.

The presence of equals() in the Object class is, to me, the
most broken thing in Java.

It is fundamentally incompatible with real OO modeling,
unless you decide not to use equals() at all.

Most programmers don't realize it, because they don't realize
they're actually doing procedural programming (and they're
perfectly happy with the non-OO or ultra-limited OO they're
doing and the way their hashcode() and equals() work with
the convenient collections).

In addition to using Java in a procedural way, they painfully
waste time doing plumbing and fixing the OO/RDB impedance
mismatch.

To me the most "hidden" feature of Java is that it's actually
possible to do OO programming in Java.

But that is something you'll hardly ever find.

Yet anyone who has done OOA->OOD->OOP has hit these pretty
nasty Java limitations: the presence of equals() in the
Object class and the fact that most collections depends
on it is a huge flaw. This is to me one of the biggest
programming language SNAFU of all times.

Once again, people are not doing OO in Java: they're doing
procedural ORM plumbing.

By the great Joshua Bloch:

J.B.: There is no way to extend an instantiable class and add
J.B.: a value component while preserving the equals contract,
J.B.: unless you are willing to forgo the benefits of object-oriented
J.B.: abstraction.

And as he hints, it's impossible to obey the equals contract
unless you forgo the benefits of OO. But once again, most
Java programmers are clueless about OO (they think they do
OO, but they're using Java in a procedural, goto-style way
to do ORM plumbing and they mistake "structure" for "OO").

http://www.artima.com/lejava/articles/equality.html

Of course you can "fix" things manually, but you still
have to deal with the fact that all the collections won't
take your fix into account.

 

[Arved Sandstrom]

charlesbos73 wrote:
[ SNIP ]

The presence of equals() in the Object class is, to me, the
most broken thing in Java.

It is fundamentally incompatible with real OO modeling,
unless you decide not to use equals() at all.

Most programmers don't realize it, because they don't realize
they're actually doing procedural programming (and they're
perfectly happy with the non-OO or ultra-limited OO they're
doing and the way their hashcode() and equals() work with
the convenient collections).

In addition to using Java in a procedural way, they painfully
waste time doing plumbing and fixing the OO/RDB impedance
mismatch.

To me the most "hidden" feature of Java is that it's actually
possible to do OO programming in Java.

But that is something you'll hardly ever find.

Yet anyone who has done OOA->OOD->OOP has hit these pretty
nasty Java limitations: the presence of equals() in the
Object class and the fact that most collections depends
on it is a huge flaw. This is to me one of the biggest
programming language SNAFU of all times.

Once again, people are not doing OO in Java: they're doing
procedural ORM plumbing.

By the great Joshua Bloch:

J.B.: There is no way to extend an instantiable class and add
J.B.: a value component while preserving the equals contract,
J.B.: unless you are willing to forgo the benefits of object-oriented
J.B.: abstraction.

And as he hints, it's impossible to obey the equals contract
unless you forgo the benefits of OO. But once again, most
Java programmers are clueless about OO (they think they do
OO, but they're using Java in a procedural, goto-style way
to do ORM plumbing and they mistake "structure" for "OO").

http://www.artima.com/lejava/articles/equality.html

Of course you can "fix" things manually, but you still
have to deal with the fact that all the collections won't
take your fix into account.

I think somewhere along the way you either read the wrong articles, or
you read some half-decent articles and misunderstood them, or you're
just not grokking OOP, or all of the previous.

For starters, if you find object equality and identity, and more to the
point, the ability to define what equality is for a given object class,
to *not* be OOP, you should go out and tell all the language designers
that they are stunned and don't know what they're doing. You can start
with Eiffel and Smalltalk, and move on from there.

Maybe you should re-read the section of Effective Java where Joshua
Bloch talks about specifically what you quoted. He is _not_ saying that
object equality is broken. What he _is_ saying that you ought to be
careful when defining it. He didn't "hint" anything, and he did *not*
say that it's impossible to obey the equals contract unless you forgo
the benefits of OO...you said that, he did not.

You should also be aware that this issue with object equality is an
issue with _all_ OOP languages (ones that permit inheritance anyhow).

As for your usual rants about most Java programmers writing procedural
ORM "plumbing", well, read up on the difference between procedural and
imperative. I suppose if someone were to go apeshit with static methods
it would be quite procedural, but I'm happy to report that most Java
programmers don't do this. Now, if you have a general objection to
someone writing two sequenced statements, I'd love to see the code
you're working on...

AHS