Who uses Java?

[Mark Thornton]

ps: OpenOffice is not written in Java, but C++. You cannot use Java to
get that kind of responsiveness.

Yes you can (at least with current JVM), though it isn't always as easy
to get great performance as we might wish.

The origins of OpenOffice predate Java.

Mark Thornton

 

[Lasse Reichstein Nielsen]

Is Java not tied to Sun in practice?

Nope. Recently they even released the source as GPL, but before
that other compagnies have created their own implementation
(at least JRocket from BEA and IBM's JDK's).

Further, there are many implementations of the J2EE specification,
from free to very expensive, depending on your needs and funds.

Does "J2EE" imply anything beyond "written in Java" in this context?

Written for the Java 2 Enterprise Edition platform. Java is not just
a language. It's also a family of target platforms. The J2EE platform
is an enterprise server standard: http://java.sun.com/j2ee/overview.html

/L

 

[Ramon F Herrera]

Yes you can (at least with current JVM), though it isn't always as easy
to get great performance as we might wish.

The origins of OpenOffice predate Java.

Mark Thornton

[I wrote:]

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

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

However, if you need to handle OOo programmatically, you don't even
need the SDK, all you need is Java.

-RFH

 

[Arne Vajhøj]

I see. So Java is used predominantly in large companies for database work
and (guessing) intranet web services. Presumably that might be anything
from software to run vets practices to airline ticket reservation systems
and so forth?

Java is used for many things. But that type of business app is
a very common usage of Java.

Not just intranet - also internet.

The term "database work" is misleading in the sense that databases are
used for almost any persisting. Java, .NET, PHP, Python or whatever -
databases are usually involved in some way.

What are the relevant keywords for web GUIs?

Servlet, JSP, Struts, JSF, JSR168.

Arne

 

[Arne Vajhøj]

That's interesting. I hadn't thought that being cross-platform would be an
advantage for servers. Is that because you don't want to be tied to MS?

It is a freedom to be able to choose Windows, Linux, Solaris depending
on what the external customer or the internal operations prefer.

Are
there any Linux-only competitors?

Not that I am aware of. Linux and Unix are too close to that being
likely.

Arne

 

[Arne Vajhøj]

Is recompilation really that much of a problem?

No, but converting C/C++ or Cobol source code to run on a new
platform can be major work.

Arne

 

[Arne Vajhøj]

Today the car manufacturer has to hire programmers that know Java and
only Java. No responsible manager or engineer will place a line of
Microsoft code in a car (or airplane, or operating room, or space
vehicle).
http://en.wikipedia.org/wiki/Ford_Sync

ps: OpenOffice is not written in Java, but C++. You cannot use Java to
get that kind of responsiveness.

Most of OOo is written in C++ - but the database, the wordprocessing
wizards and some filters are written in Java. There are even a bit
of Python in it.

Arne

 

[Jon Harrop]

This sounds a bit like using YACC (and similar programs) to generate a
compilers from a grammar specification, or using a hardware description
language (Verilog, etc.) to create new chips.

Exactly, yes.

I've never thought about trying to solve general purpose programming
problems with a tool like that.

I consulted for XenSource (now part of Citrix) a couple of years ago and we
built a compiler to generate XML-RPC interfaces for the entire
XenEnterprise API for several different languages all at once. Java was the
second language supported, after OCaml.

The reason was essentially that XenSource have an incredibly competent
software engineering team and, in particular, a lot of compiler experts.
All of their high-level code, used to remote control Xen hosts, is written
in OCaml and OCaml was bred for compiler writing. So they worked compilers
into their code whenever possible and the results were incredibly
impressive: three people maintaining millions of lines of code written in
half a dozen completely different programming languages.

So I've taken a leaf out of their book and started doing the same thing for
numerical and visualization libraries.

Do you mind if I ask what language and tool you use for your high-level
definitions and auto-generation? Is it something entirely in house or
did you derive if from some external product?

The definitions are written in an OCaml-like language. This is parsed using
OCaml's macro system and an OCaml code generator spits out OCaml, C#, F#
etc. We could target Java if I put enough effort in but first-class
functions would have to be compiled into some kind of OO design pattern,
which could get ugly for users.

We also have a cross-platform hardware-accelerated vector graphics library.
The original uses OpenGL but I am current porting it to Windows
Presentation Foundation.

Thinking about this a bit more, with auto-generation, you could skip the
whole Java compilation step and just go directly to JVM byte codes.

That is possible but probably harder. We can also go via Scala or OCamlJava.
The latter is an obvious choice because it compiles our existing code with
zero changes to JVM bytecode. I'm not sure how interoperable it would be
though, and we would be wanting to sell the generated code to Java
programmers.

This might also allow you to easily provide features that Java doesn't
support directly, for example features that Java requires you use a
separate tool like AspectJ. Then just write your "veneer" in hand-coded
Java.

Yes. There is certainly a lot of potential for such things.

 

[Jon Harrop]

No, but converting C/C++ or Cobol source code to run on a new
platform can be major work.

Right.

 

[Arne Vajhøj]

[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

 

[Jon Harrop]

Just because you can do something doesn't mean you really want to spend
your time that way. Java allows you to spend your time on something more
productive than retargeting your code and maintaining the veneer you
mentioned in another post. In Java you have one code base to develop and
maintain.

That doesn't work in our case because our target market is programmers
rather than end users. If we dropped support for all other languages we
would lose everyone except Java programmers, i.e. we would lose 80% of our
potential target market. Also, it would be extremely cumbersome to maintain
the code as Java source rather than its high-level definition.

 

[Logan Shaw]

That's interesting. I hadn't thought that being cross-platform would be an
advantage for servers.

Well, it can be. It can also be an advantage for developers who
want to run the code locally on their machine. They can choose
any OS that supports Java and do their development on that. That
means less having to login to some server somewhere just to try
something out. Also, if you switch architectures on a server app,
which tends to happen over time, cross-platform Java code has
the advantage that you do not need to do two builds of everything
during the transition period. And if you have a lot of servers,
or just a lot of software, the transition period can be fairly
long in some cases.

There are also some other reasons that Java appeals on servers.
One is that Java makes threads and networking relatively easy.
Another is that Java has bounds checking on arrays, no pointers,
a bytecode verifier, and a consistent using exceptions for error
handling, and that means that sometimes errors don't lead to the
entire server app crashing where it would with some other
platforms. Other languages certainly have some of these features,
but Java has, IMHO, a good mix of them that relatively few
other languages can match.

- Logan

 

[Stefan Ram]

no pointers,

»(...) reference values (...) are pointers«

JLS3, 4.3.1.

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1

 

[Lew]

I think around 90% of all computing is large companies with database
work. It doesn't matter if you are programming Cobol, BASIC, C, C++,
Java, C# or what. That's where (approximately) 90% of the jobs are. By
comparison, everything else is a niche application, with the possible
exception of Microsoft OS and desktop applications.

True, but there is a saying, "Serve the classes, dine with the masses. Serve
the masses, dine with the classes." Microsoft showed that you can get rich by
turning a million-dollar product, the computer OS, into a one-hundred dollar
product. In fact, they made those of us who work on (multi-)million-dollar
software projects better off - the increase in personal computers led to an
increase in large-scale computing and the sophistication of its deployment.

The number of customers for a million-dollar product will be much smaller than
the number for an equivalent ten-thousand-dollar, or one-thousand-dollar
product, to whit, custom software services. Assuming someone can figure out
how to deliver quality custom software at a price the masses, at least the
business masses, will accept.

This requires a breakthrough of about 100:1 in productivity compared to how
the large companies and government agencies do software and I.T. The trick is
to maintain the level of stability and reliability that a slower approach is
thought to ensure.

Java is certainly a candidate for the kind of robust, secure and stable
systems the big guns crave. Because of its large API and inherent basis in
the network and concurrency, one can do a great deal without inventing a lot,
if one invests the time to learn this massive, overwhelming API. However,
Java has yet to bring enterprise programming to the masses, because heretofore
Java enterprise programming was as clunky and behemoth as its results were
reliable and scalable.

But, lo! The new generation of Java, with yet more to learn, has grown wings,
and learned to mix DNA with scripting and web templating. Some wizards have
incanted, "Dependency injection!", and called forth the Spring of Nimbleness.
JavaEE 5 has polished JSTL, EL and JSF to a high gloss, allowing rapid
development with yet solid architecture. EJB 3 and JPA (Hibernate, OpenJPA)
make back-end and database interaction much slicker, and disguise the worst of
the caching and optimization issues. Glassfish, Geronimo and Glassfish are
capable of managing the application service and PostgreSQL certainly is up to
the database requirements.

Since Java is now integrated with suitable frameworks from the front JSes and
JSPs to the back JDBCs, it bids fair to become the /lingua franca/ of network
and enterprise development down to even small or moderate-size businesses,
i.e., everywhere. If it all doesn't turn out to be too much all at once for
anyone to master.

If the new nimbleness brings Java into manageability, I predict a massive
increase in its use.

Then there's Micro Edition ...

_* References *_

Java today:
<http://java.sun.com/>
<http://java.sun.com/javase/6/>
<http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/beta2.html>

EJB 3 <http://java.sun.com/javaee/5/docs/tutorial/doc/bnblr.html>
EL <http://java.sun.com/products/jsp/reference/techart/unifiedEL.html>
Geronimo <http://geronimo.apache.org/>
Glassfish <https://glassfish.dev.java.net/>
Hibernate <http://www.hibernate.org/>
JavaEE <http://java.sun.com/javaee/>
JavaME <http://java.sun.com/javame/index.jsp>
JBoss <http://labs.jboss.com/>
JDBC <http://java.sun.com/javase/technologies/database/index.jsp>
JPA <http://java.sun.com/javaee/5/docs/tutorial/doc/bnbpy.html>
JS <http://java.sun.com/javascript/>
JSF <http://java.sun.com/javaee/javaserverfaces/>
JSP <http://java.sun.com/products/jsp/>
JSTL <http://java.sun.com/products/jsp/jstl/>
OpenJPA <http://openjpa.apache.org/>
PostgreSQL <http://www.postgresql.org/>
PostgreSQL JDBC <http://jdbc.postgresql.org/>
Spring <http://www.springframework.org/>

IDEs:
Eclipse <http://www.eclipse.org/>
NetBeans <http://www.netbeans.org/>

 

[Lew]

Right.

Much like writing a JVM for a new platform can be major work.

 

[Lew]

Written for the Java 2 Enterprise Edition platform. Java is not just
a language. It's also a family of target platforms. The J2EE platform
is an enterprise server standard: http://java.sun.com/j2ee/overview.html

Though, of course, these days Sun prefers to call it "Java EE", reserving
"J2EE" for earlier versions.

With version 5 of the Java Platform, Enterprise Edition (Java EE,
formerly referred to as J2EE), ...
[t]he Java EE 5 platform introduces a simplified programming model
and eliminates much of the boilerplate that earlier releases required.

 

[Logan Shaw]

»(...) reference values (...) are pointers«

JLS3, 4.3.1.

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1

OK, they're pointers, but they're pointers without the dangers of
more traditional pointers.

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.

Anyway, the term "pointers", like many words, has multiple meanings
depending on context, and hopefully it was clear from context what
sense I meant.

- Logan

 

[Logan Shaw]

Much like writing a JVM for a new platform can be major work.

.... work which has already been done, in many cases. Though
certainly not ALL cases.

- Logan

 

[Lasse Reichstein Nielsen]

»(...) reference values (...) are pointers«

JLS3, 4.3.1.

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1

Quote the context, please:

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

They are not saying references are Pointers. They are saying that
references *point* to objects.

Java does not have pointers, in the sense typically meant by that word,
and as exemplified by pointers in C and C++.

/L 'no pointers!'

 

[Lasse Reichstein Nielsen]

Though, of course, these days Sun prefers to call it "Java EE",
reserving "J2EE" for earlier versions.
<http://java.sun.com/developer/technicalArticles/J2EE/intro_ee5/>

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.

/L