Who uses Java?

[Arved Sandstrom]

Oh, I know. It's just that the customers still want J2EE
Personally, I'd love to switch to EJB3, JavaEE 5 and Java 5+, but
that's only now beginning to happen now.

So would I. In my geographic area if a J2EE project comes up the odds
are still better than even that it'll be a J2EE 1.4 project using EJB 2.x,
and one still has to be prepared to code to servlets and JSP without the
benefit of a framework. Adoption of Java 5+ isn't too bad, though.

AHS

 

[Ramon F Herrera]

[I wrote:]

OpenOffice is not written in Java, but C++.

Actually, I just downloaded the source code. It is written in C.

I checked OOo 2.3.1 core source. It has:

280 .c files
8459 .cxx files + 167 .cpp files
3756 .java files
23 .py files

The C++ is good enough.

Arne

I stand corrected, Arne. It turns out that the source code that I
downloaded was only a small fraction.

The moral of the story if that for some applications (such as OOo) it
doesn't make sense to use Java BUT you should still write it with one
of the multi-platform GUI toolkits:

- wxWidgets
- Qt
- the one from GNU, which sucks.


I wrote a GUI application that handles large TIFF files, in Java. Due
to several factor (such as performance) I am now rewriting the whole
thing from scratch, using the original Java version as a prototype.
Going back to the OP: this is yet another important use of Java.

-Ramon

 

[Roger Lindsjö]

So where is Java used in industry?

Where I work we use Java to serve content to mobile devices. This
includes designing a "portal", content ingestion and adaptation for the
devices (screen size etc).

We also use it for building MMSC and SMSC.

Java is also used to build the GUIs for managing these applications, and
they are usually distributed and launched with Java Webstart.

 

[Andrea Francia]

Maybe I should be more precise and say this: "Java doesn't allow
you to shoot yourself in the foot by mistakenly accessing
arbitrary machine addresses."

Or maybe I should just say that Java doesn't have C-style pointers.
You can't do things like finding out that two instances of some type
are stored contiguously in memory, then add 1 to the pointer of
the first and use it to access the second. You can't treat memory
as a gigantic BCPL-style series of cells, all of which you can
attempt to access, even though the attempt may lead to a
catastrophic crash.

Or maybe I should just say that, unlike many other languages, you
have no means of creating a reference that is visible but invalid.

Or simply we can say that Java doesn't have pointer arithmetic.

 

[Logan Shaw]

Or simply we can say that Java doesn't have pointer arithmetic.

Well, it's a bit off-topic to continue this too long, but I'm
not sure all pointer-related ills come from pointer arithmetic.

For example, does this C code contain any pointer arithmetic?

char* p = 0;
*p = 65;

And yet, it's hardly free of problems. I suppose you could call
it pointer arithmetic when you assign a constant, but I generally
think of arithmetic as involving operators. Also, consider fun
stuff like:

typedef union {
char* p;
int i;
} U;

U u;

char c = 65;

u.p = &c;
u.i = 12345;
*(u.p) = 66;

No pointer arithmetic, but it still dumps core.

By the way, I should amend my statement that Java doesn't allow
you to create references that aren't valid. I was wrong about
that: of course it does -- it allows null references. It's just
that if you dereference them, an exception is thrown, which is
a whole lot nicer than leaving the behavior undefined like in
certain other languages whose names I won't mention.

- Logan

 

[Lew]

Well, it's a bit off-topic to continue this too long, but I'm
not sure all pointer-related ills come from pointer arithmetic.

For example, does this C code contain any pointer arithmetic?

char* p = 0;
*p = 65;

And yet, it's hardly free of problems. I suppose you could call
it pointer arithmetic when you assign a constant, but I generally

This isn't pointer arithmetic, nor is Java immune to this particular bug:

char [] p = null;
p[0] = 'A';

think of arithmetic as involving operators. Also, consider fun
stuff like:

typedef union {
char* p;
int i;
} U;

U u;

char c = 65;

u.p = &c;
u.i = 12345;
*(u.p) = 66;

No pointer arithmetic, but it still dumps core.

Java doesn't have unions. This isn't just a pointer bug but a union bug.

By the way, I should amend my statement that Java doesn't allow
you to create references that aren't valid. I was wrong about
that: of course it does -- it allows null references. It's just
that if you dereference them, an exception is thrown, which is
a whole lot nicer than leaving the behavior undefined like in
certain other languages whose names I won't mention.

And this is the strength of Java. It can't completely prevent you from making
bugs, but it can help you some when you do.

 

[Stefan Ram]

For example, does this C code contain any pointer arithmetic?
char* p = 0;
*p = 65;

This is not valid C code.

»Among the invalid values for dereferencing a pointer by
the unary * operator are a null pointer, [...]«

ISO/IEC 9899:1999 (E)

In C, a pointer used shall always refer to an object (just as
in Java):

»The behavior is undefined in the following circumstances:

[...]

An object is referred to outside of its lifetime

The value of a pointer to an object whose lifetime has
ended is used

[...]

An lvalue does not designate an object when evaluated«

(The null pointer does never refer to an object.)

»[...]

The operand of the unary * operator has an invalid value«

ISO/IEC 9899:1999 (E)

When you go beyond the limits of the language, you can do this
in the Java world as well (via JNI).

~~

The meaning of »object« in C is different from the meaning of
»object« in Java.

When someone uses »object« in this newsgroup, he uses it in
the sense of the Java Language Specification, Third Edition,
not in the sense of ISO/IEC 9899:1999 (E).

For the same reason, for a Java programmer, it is not that
relevant, what »pointer« means in ISO/IEC 9899:1999 (E).

Well, it's a bit off-topic

But we know that the Java Language Specification, Third
Edition calls »reference values« »pointers«. This wording does
matter for a Java programmer, while ISO/IEC 9899:1999 (E) does
not matter for a Java programmer.

 

[Logan Shaw]

But we know that the Java Language Specification, Third
Edition calls »reference values« »pointers«. This wording does
matter for a Java programmer, while ISO/IEC 9899:1999 (E) does
not matter for a Java programmer.

Certainly the wording does matter for a Java programmer, if the
Java programmer also writes other languages (such as C). In the
particular context in which you originally brought this up, I was
comparing Java to other languages, saying that it has strengths
that make it a good choice for server-side programming. When the
context is a comparison of languages, why should the JLS definition
of "pointer" be the only relevant one?

For what it's worth, I agree that the sentence "Java does not have
pointers" is false if you interpret as "Java does not have pointers
in any sense of the word". But it's true if you interpret it as
"Java does not have pointers in the sense of the word relevant
in the current context" (where the context is a comparison to
other languages which have a different variety of pointers).

- Logan

 

[Stefan Ram]

For what it's worth, I agree that the sentence "Java does not have
pointers" is false if you interpret as "Java does not have pointers
in any sense of the word".

When assertions about Java are made, I usually interpret the
terms using the Java Language Specification, Third Edition.

Therefore, to me, »Java does not have pointers.« is false
because I interpret the words »Java« and »pointers« in the
sense of of the Java Language Specification, Third Edition,
which says that reference values are pointers.

Common terms, such as »variable« or »object«, have different
meaning in Java Language Specification, Third Edition than in
ISO/IEC 9899:1999 (E). This shows that even such common terms
simply do not have a meaning independent of a language or
specification.

When discussing Java or when discussing in the newsgroup
»comp.lang.java.programmer«, I have no reason to use the
terminology of ISO/IEC 9899:1999 (E), so I use the terminology
of Java Language Specification, Third Edition. At least, I try.

 

[Logan Shaw]

Common terms, such as »variable« or »object«, have different
meaning in Java Language Specification, Third Edition than in
ISO/IEC 9899:1999 (E). This shows that even such common terms
simply do not have a meaning independent of a language or
specification.

You are right that such common terms don't have a meaning which
is fixed and independent of all context. (Nor do many words.)

Therefore, as a reader or listener, in order to communicate
effectively, one must ascertain the intended context, and
interpret the word in light of that context. This is a
fundamental part of human communication, which is not
mathematically precise but which instead requires the
application of insight about context (as well as other things,
like pragmatics) in order to apprehend the meaning.

Likewise, from the other side, the writer/speaker should make a
strong effort to make this process as easy as possible by not
introducing unnecessary ambiguities or other difficulties, to
the extent this is practical and doesn't interfere with other
concerns (like brevity).

When discussing Java or when discussing in the newsgroup
»comp.lang.java.programmer«, I have no reason to use the
terminology of ISO/IEC 9899:1999 (E), so I use the terminology
of Java Language Specification, Third Edition.

I, on the other hand, did have a reason to use the terminology
of a context other than the JLS: I was making a comparison.
I recognize that a Java-centric interpretation of terms should
be given some extra priority in any Java-centric forum, but I
wouldn't go so far as to say that only Java meanings for words
should be used.


Having said all that, I suppose this is enough discussion for me
on this particular point. I think we have both explained our
views quite clearly, and I can't imagine much can be gained by
discussing it further, and I have no particular desire to do
things which aren't gainful.

- Logan

 

[Lasse Reichstein Nielsen]

When assertions about Java are made, I usually interpret the
terms using the Java Language Specification, Third Edition.

Therefore, to me, »Java does not have pointers.« is false
because I interpret the words »Java« and »pointers« in the
sense of of the Java Language Specification, Third Edition,
which says that reference values are pointers.

I disagree that it says that. The entire quote is:

"The reference values (often just references) are pointers to these
objects, and a special null reference, which refers to no object."

If somebody said "There are towns connected by roads with road
signs. Road signs are pointers to towns", then I won't agree that it
implies "roads have pointers" where "pointers" means anything
specific.

It's explanatory text, using common words with their common meaning,
not formal definitions using defined words.

Common terms, such as »variable« or »object«, have different
meaning in Java Language Specification, Third Edition than in
ISO/IEC 9899:1999 (E). This shows that even such common terms
simply do not have a meaning independent of a language or
specification.

When discussing Java or when discussing in the newsgroup
»comp.lang.java.programmer«, I have no reason to use the
terminology of ISO/IEC 9899:1999 (E), so I use the terminology
of Java Language Specification, Third Edition. At least, I try.

First, I disagree that "pointer" is part of that terminology.

Second, discussing the specification only in terms of its own
definitions is vacuous. Sure we can say that Java has pointers,
where pointers is defined as what Java has, but that doesn't
*tell* us anything.

/L

 

[Lew]

Second, discussing the specification only in terms of its own
definitions is vacuous. Sure we can say that Java has pointers,
where pointers is defined as what Java has, but that doesn't
*tell* us anything.

The problem is that when people say, "Java does[n't] have pointers," they
don't specify which meaning of "pointers" is involved.

Strictly speaking, Java does have pointers, in that variables point to the
objects that they reference. Colloquially speaking, Java does not have
pointers as a language element as such. It certainly doesn't have calculable
pointers, which is how most programmers mean the term. (I.e., there is no
pointer arithmetic, "taking the address" of a variable, etc.)

Both views are important. It's important to understand Java's pointers "in
terms of its own definitions"; this is not "vacuous" at all. Many aspects of
Java's behavior are so much more easily explained when one thinks of
references as pointers.

However, the fact that Java's own idea of a pointer excludes most of what we
think of as pointer behavior is also important. We need to be vitally aware
that Java does not have (C-style) pointers.

 

[Roedy Green]

So where is Java used in industry?

the University of Calgary is using it to model hearts so that
physicians can visually climb into a heart they are about to operate
on and have a look around watching it work, sort of a real life
Fantastic Voyage.

 

[Lew]

the University of Calgary is using it to model hearts so that
physicians can visually climb into a heart they are about to operate
on and have a look around watching it work, sort of a real life
Fantastic Voyage.

Kaiser Permanente runs their website on Java tech. Looks like they use
Struts. Well, they are a .org.