Java Philosophy

[Wildemar Wildenburger]

Perl, Python, Ruby, C, C++ do not have a GUI toolkit
as part of the standard library - though several
extensions are available.
[snip]
Java includes a JVM to ensure portability even of
GUI applications. While Python plus a GUI-Toolkit
might also run on several platforms, it is not known
how long such a combination will be available in the
future. A C-program on Win32 surely is not that portable.

Python has the tcl/tk bindings in its standard library, so, just like
java, it ships with a GUI that looks equally ugly and alien on all
platforms


/W
(Yes, I know, there's the "native" L&F for Gnome and Win, but that never
felt completely right to me. Also: Grain of Salt! Just in case.)

 

[John W. Kennedy]

I'm rather partial to a C++-like
Thing<Whatever> foo(arg1, arg2, etc);
myself.

That's not merely syntax; it's a major functional change -- allowing
objects to be allocated on the stack instead of the heap. And that means
all kinds of other problems. What are to be the semantics of:

heapObject = stackObject;

for example? Soon you'll be defining copy constructors and
God-only-knows-what-else C++isms, not to mention references pointing to
dead stack frames.

 

[Bent C Dalager]

That's not merely syntax; it's a major functional change -- allowing
objects to be allocated on the stack instead of the heap.

In Java, it would be only syntax, since the programmer already doesn't
care where objects get allocated. It would be up to the JIT, as
always, to determine how to do the actual allocation.

A a();
would simply be shorthand for
A a = new A();

Cheers,
Bent D

 

[Lew]

There is also a cost associated with it, in terms of development
time and therefore the number of alternatives that can be
investigated. Developers who have used languages with duck or
optional typing are familiar with the very different style of
programming such languages support.

That being said, the typing wars are easily found elsewhere on
Usenet and I have no urge to start that battle here. Suffice to say,
a good developer will consider both the costs and benefits of any
language feature.

Like I said,

 

[Lew]

I am not one of them. »new« just annoys me.

But let's wait. Possibly someone here comes
up with a good reason for it.

It makes it much easier to tell constructors from methods at a glance.

 

[John W. Kennedy]

In Java, it would be only syntax,

Every C++ or Delphi user trying to learn Java would curse your name forever.

since the programmer already doesn't
care where objects get allocated.

Only in the sense that Java gives no option at present; all objects are
on the heap, period. But if objects /could/ be allocated on both the
heap and the stack, it would make all the difference in the world.

 

[Lew]

Only in the sense that Java gives no option at present; all objects are
on the heap, period. But if objects /could/ be allocated on both the
heap and the stack, it would make all the difference in the world.

That's not strictly true. Many times the optimizer will allocate on the
stack; it just doesn't admit it to the programmer.

 

[Bent C Dalager]

Every C++ or Delphi user trying to learn Java would curse your name forever.

I have thick skin, I could take it

Only in the sense that Java gives no option at present; all objects are
on the heap, period. But if objects /could/ be allocated on both the
heap and the stack, it would make all the difference in the world.

This would be such a fundamental change to the language it is unlikely
to ever happen. Such decisions are best left to the JIT.

Cheers,
Bent D

 

[Patricia Shanahan]

That's not strictly true. Many times the optimizer will allocate on the
stack; it just doesn't admit it to the programmer.

This should be looked at as an issue of object lifetime, rather than
physical location. Currently, ignoring details of finalizers, Java
objects live from the time they are created until they become unreferenced.

I think the stack suggestion should be read as a proposal for Java
objects whose lifetime is the lifetime of a specific variable,
regardless of references.

Is there any way to do it that does not lead to issues with dangling
pointers to an object that no longer exists?

Patricia

 

[Roedy Green]

* type safety of the language and runtime environment
* garbage collection
* easy multithreading
* easy networking
* extensive standard libraries as well as EE and 3rd party options
* runtime optimization
* cross-platform (let's not forget J2ME and Android for embedded VM's)
* backwards compatible source, standard API (excepting a very slow
deprecation process), and compiled form
* alternate languages running on JVM (Scala, JRuby, Jython, BeanShell,
Rhyno/ECMAScript, etc.)
* Java source compiled to non-JVM environments (GWT, Android)

I don't know if it is a sufficiently rare feature to single out, but
Java has nice facilities for plug in code. You can define interfaces
and then plug in various different implementations of it at run time
that did not even exist at compile time. I have had to kludge this
feature in other languages in various ways.

The cross-platform is much stronger than usual. Not only do programs
run on different platforms, they don't even have to be recompiled, AND
they give the exact same results. I am so happy the way Java nailed
down the precise size of primitives and the precise way arithmetic has
to work. Unless you use your own native code, apps are cross-platform
automatically. In many other languages, getting that effect is
difficult and requires intimate knowledge of all the target platforms.

 

[steen]

It makes it much easier to tell constructors from methods at a glance.

I think I would take that statement one step further.

"It makes it possible to tell constructors from methods."

How about the following (someone guess the output if Java didn't use
the word
"new" and people didn't care about the naming conventions (which some
people don't)) :

public class Thing {
public static void main(String[] args) {
Thing t = Thang();
}

private static void Thang() {
System.out.println("Boo");
}
}

public class Thang {
public Thang() {
System.out.println("Bah");
}
}

/Steen

 

[steen]

It makes it much easier to tell constructors from methods at a glance.

I think I would take that statement one step further.

"It makes it possible to tell constructors from methods."

How about the following (someone guess the output if Java didn't use
the word
"new" and people didn't care about the naming conventions (which some
people don't)) :

public class Thing {
public static void main(String[] args) {
Thing t = Thang();
}

private static void Thang() {
System.out.println("Boo");
}

}

public class Thang {
public Thang() {
System.out.println("Bah");
}

}

/Steen

Apart from the ClassCastException which I just realized after
rereading my post, but I'm sure you get my point..

/Steen

 

[John W. Kennedy]

That's not strictly true. Many times the optimizer will allocate on the
stack; it just doesn't admit it to the programmer.

It will do it only if the optimizer can detect that there is no semantic
difference -- that the object will die when the block is exited.

Which is cool; it takes a big bite out of one of Java's biggest
intrinsic performance problems. But, as I say, only where it makes no
semantic difference.