Sun To Give StarOffice Java Flavor

ilovestuff writes "Sun Microsystems is building a Java-based development kit for its StarOffice software to help corporate programmers customise desktop applications, a move that better pits it against Microsoft's dominant Office. The software development kit will be available in the middle of next year as part of a minor upgrade to the business version of Sun's StarOffice 6.0, said Joerg Heilig, director of engineering for StarOffice at Sun."

Re:Java?

[thumperward]

He's experimenting with an intellectual troll. Essentially he's hoping to be modded up as insightful despite deliberately posting a lot of rubbish, and / or to be agree with by people who are actually being serious.

As an aside, I've discovered that doing these kind of post reviews in topics while logged in is a good way of making sure my karma stays in the 'average user' category. although i suspect my fun will be over soon as I should be on about 1 by now.

- Chris

Re:Java?

[Anonymous Coward]

1) It's big and slow. Very big. Very slow. Java apps/applets aren't usable on my P2 266

Please hold while I bang my head on my desk.

First, let me point out a few things (in numbered list format since you're into that kind of thing):

1) Applets are not Java. Indeed, Applets are written in Java, but they are just one method (arguably the silliest method) of executing Java code. You've got to think that if you wrote a bloated GUI C program (and most Java Applets are bloated GUI code), downloaded it over the internet each time you wrote it and then had to wait for a (usually out of date) runtime environment to run the code, its going to be slow.

So we agree that Applets are a bad idea. Fine, most impartial Java developers will concede that fact. But like I said, Applets are just an execution model, and one that most Java developer don't ever think about using.

2) Have you tried a well designed Java based application running in a modern Java Runtime Environment (something like Eclipse [eclipse.org] on one of IBMs JREs would be a good test). Have you done any profiling on server side Java code (i.e. a Servlet based web application?).

Guess what, it's not so slow! Sure, it's typically not as fast as native C code, but C code isn't typically as fast as optimized Assembly either, and I don't see everyone programming in that anymore. In a web application (Java's real strength) where the the run time environment is already loaded into memory and so is the Java code, request are actually downright snappy!

3) There are good Java applications, there a bad Java applications. There are good C programs, there are bad C programs. Most people seem to see one bad example of a Java app and get the "Java sucks" tunnel vision. I wish I had the kind of job where I could afford to be so ignorant. Then I'd only need to browse SourceForge for an hour before deciding that every single language sucks at everything.

2) It has the worst marketing and learning curve in the history of computer programing. All those acronyms above are real. Sun's J2EE "platform" -- platform? what the fuck is a platform? -- is used as a generic term by PHBs everywhere. To anyone that hasn't taken courses on Java, it's meaningless.

You want a little cheese with your whine?

That's like me saying "Whah whah! I don't know what C++ STL is!" without bothering to pick up a book or doing a Google search. Do some reading you lazy bastard! Not everything in life is going to be spoonfead to you! If acronyms are too hard for you, bookmark one of the many Java glossaries that are out there. [mindprod.com]

The "Java Platform" is simply a set of classes (APIs, Frameworks, whatever you want to call them) and an environment to run programs which use these classes. These provided classes do things as simple as type conversion and data structures, and as complex as network I/O and cryptography, and as useful as parsing HTTP requests and working with relational databases. Lots of good stuff in there.

So Java programming involves writing code which uses these built in classes, using the classes you wrote yourself, classes other people wrote, etc. (just like any other language).

So for example you could write code that responds to an HTTP request (such classes are known as Servlets) and stores some information in a database. You then just set up this Servlet to run in a J2EE Server (like Apache Tomcat [apache.org]) and point your browser to the appropriate URL and voila, it responds to the HTTP request and it can just as easily return and HTTP/HTML response back to the browser (did you notice there aren't any Applets involved here?).

"What's the point, I can do that in C?" you say? Well, aside from the general utility of all the built in classes (they really are quite rich) the advantage is that you can write your Java code on whatever machine you like (say that NT box you're forced to use at work, or your Linux box at home) and when you're done you can deploy it to whatever machine type you want (say that big Solaris server your company has laying around, or your buddies Windows 98 machine, whatever) and it works. No porting, no messing around.

That may not sound like a big deal to the average home user, but to a company with a sea of developers who are already on Windows machines and they want ot target a UNIX production environment, it's a big advantage. Is it possible to do this in C/C++? Of course it is? It's not neary as easy though, and if you give developers the chance to screw something up, you know what happens next.

Long story short, Java is a tool, and tools are always good at some things and bad at others. I wouldn't want my Kernel written in Java just like I wouldn't want a web application I have to maintain written in Assembly. Learn about the tools objectively and apply them where it makes sense.

Re:Java?

[RAMMS+EIN]

Good argumentation. One point though. You seem to suggest that Applets are not a primary application (no pun intended) for Java. In my opinion, Java Applets should be one of the main strengths of Java. Platform independence is a necessity for software intended to be embedded in webpages. JavaScript and Java are the two main alternatives here. JavaScript, intended as a scripting language for the enhancement of webpages, lacks the features necessary for writing full applications. Java is plagued by Virtual Machine incompatibilities (mostly thanks to MicroSoft), and the general bloat and slowness of Java virtual machines. There are opportunities here. Big opportunities. Java has the edge here, as it is the only widely adopted language for webpage-embedded software. It's a pity that Java sucks so hard at what it's best at (better than any competing language).

Re:Java?

[Randolpho]

2) Have you tried a well designed Java based application running in a modern Java Runtime Environment (something like Eclipse [eclipse.org] on one of IBMs JREs would be a good test). Have you done any profiling on server side Java code (i.e. a Servlet based web application?).

I'd just like to point out that the speed of Eclipse has little to do with Java itself and everything to do with the fact that it's written using SWT rather than Swing or AWT.

Re:Java?

[Randolpho]

SWT is more like AWT in that, rather than use actual JAVA code to draw things like windows, buttons, pulldown-menus, text fields, and the like, SWT (like AWT) will make a call to a native OS function that renders that widget for it.

SWT is different from AWT in that it does not try to adhere to the least-common-denominator principle -- is like Swing in that regard because it has more GUI widgets that can be added to the program.

SWT is unlike Swing, however, in that rather than using Java to draw the widget and listen for inputs, SWT merely tells the OS to do it for the program and handles anything the OS reports back. Because the code for handling that widget is optimized compiled code for the operating system, there is a massive net speedup in GUI interactivity.

SWT would probably be unnecessary if Sun would just put out a VM that handles the "power" of Java threads in a much better way.

Re:Java?

[bwt]

Java is a very nice OO language. Because of this, there is an extremely large body of existing class libraries that have names that are often abbreviated to acronyms. If you think the "learning curve" is too big, then by all means, use another language and start from scatch.

Java's slowness is often maligned, but java actually stacks up pretty well if you look at objective benchmarks. In Bagley's Language Shootout, java was 9th of 30 languages tested on linux. It does use a lot of memory, but only because of the overhead associated with the JVM runtime. Of course this is the price for writing code that work on windows, linux, mac, and random unix, so it is a tradeoff many accept. If this really bothers you, get a native java compiler and then you'll have smaller footprints but no portability.

I use several java apps on my P2 300, so I think you are exagerating. Odds are that you don't have much memory and that is what is slowing you down.

Java can only be considered a failure
Really? Java was invented a few years ago. There are now more jobs programming java than any other language. I really don't see how that is a failure.

Java blows

[jmd!]

Of course this is the price for writing code that work on windows, linux, mac, and random unix, so it is a tradeoff many accept.

I don't think it is. Perl, Python, and TCL all run under UNIX and Windows. Hell, they're even compiled at runtime. And somehow they still use much less CPU and memory.

I use several java apps on my P2 300, so I think you are exagerating.

I have 128M of memory. If that's not enough, then that's ridiculous. XNap, a Java napster client, takes ~20 seconds to start up. Java applets in Netscape take 15-30 seconds to start. Oh, and Sun's java plugin likes to crash Mozilla constantly, so I don't even bother enabling it in the first place.

There are now more jobs programming java than any other language.

And they're all boring enterprise level applications. While you may consider that a success, Java didn't change anything. Had it never been invented, though would have been written just the same, in C++.

Most of those apps are likely written so poorly they only run on Windows anyway. I've heard Java's cross platformness is mostly a myth.

Java has done nothing to make consumer apps cross platform.

Java was invented a few years ago

It was invented before Flash. It has Netscape's backing. And it still has less market penetration.

Re:Java blows

[BadBrainDay]

Most of those apps are likely written so poorly they only run on Windows anyway. I've heard Java's cross platformness is mostly a myth.

There's nothing like using the words "I've heard" in an argument to expose yourself as ignorant.

So you're saying most enterprise Java apps only work on Windows? Are you on crack?

Re:Java blows

[stefanlasiewski]

Of course this is the price for writing code that work on windows, linux, mac, and random unix, so it is a tradeoff many accept.

I don't think it is. Perl, Python, and TCL all run under UNIX and Windows.

Yes, but all fo the cross-platform Perl, Python or TCL projects are very small. While these languages run on multiple platforms, they are still harder to port the Java. As a result, most cross-platform Perl, Python or TCL projects are much simpler then many of the Cross platform Java applications.

It was invented before Flash. It has Netscape's backing. And it still has less market penetration.

Er... apples and oranges. Flash is for fancy windows that run in your web browser, and it has Microsofts backing. Not much more to Flash.

Java is a whole universe of applications. You can have a flash-like applet, but that is only a very, very small part of the Java world; and you're right, most java applets suck (In large part because all versions Internet Explorer until 5.5 only supported Java 1.1, which was released five years ago). But nobody is defending Java applets.

The big part of Java is in the server market, where Java app servers like Weblogic, Websphere, Oracle 11i, Tomcat, or Dynamo have become the defacto standard in enterprise-level applications.

Re:Java blows

[bwt]

I don't think it is. Perl, Python, and TCL all run under UNIX and Windows. Hell, they're even compiled at runtime. And somehow they still use much less CPU and memory.

All of the languages you just named are slower than Java. This is common knowledge, but if you need proof, go to Bagley's language shootout. I think you should check your facts instead of making them up.

Don't get me wrong, I like Perl and Python and have used each of them for various tasks. Python's java implementation Jython is quite a nice way to fully mix java and python. I also like Ruby which you didn't mention.

I have 128M of memory. If that's not enough, then that's ridiculous. XNap, a Java napster client, takes ~20 seconds to start up. Java applets in Netscape take 15-30 seconds to start. Oh, and Sun's java plugin likes to crash Mozilla constantly, so I don't even bother enabling it in the first place.

I just downloaded XNap to have a look. I got the splash screen in 6 seconds on my P2 300 with 384 MB. I've never had mozilla 1.1 crash on me, and I often play a java/jython net game called wyvern that is a graphical 2D mud with real time combat.

I think you would do well to get more memory. No amound of memeory is "enough" -- memory always makes things go faster by avoiding swapping, especially if you like to have a lot of apps open at once.

And they're all boring enterprise level applications. While you may consider that a success, Java didn't change anything. Had it never been invented, though would have been written just the same, in C++.


Enterprise applications are boring, huh. I think that says a lot about the your perspective.

Most of those apps are likely written so poorly they only run on Windows anyway. I've heard Java's cross platformness is mostly a myth.

I think it is becoming clear that you are making assertions based on hearsay. My experience is exactly the opposite. In fact, it sounds more like you are describing VB than Java. Java's strongest point is that it really does steer you towards good programming practices. That was the biggest selling point for enterprise development, and the main reason C++ was mostly abandoned for enterprise apps.

Most of the hard parts of enterprise apps in java are written by specialists and offered to the world to reuse. Take a look at the Apache Jakarta project. The open source tools there are the driving force behind most of the enterprise apps out there.

It was invented before Flash. It has Netscape's backing. And it still has less market penetration.

Huh? I'll wait for the citation on that amazing claim. But in the meantime, go and do a job posting count at monster.com by keyword. I did and the results were as follows:
flash 652
java 3518
Frankly, flash is about to find itself completely outdated when SVG takes over.

Re:Java blows

[Suidae]

No amound of memeory is "enough"

Not if you're trying to run java apps.

Re:Java?

[Daleks]

It's big and slow. Very big. Very slow. Java apps/applets aren't usable on my P2 266

Java is good at some things, worse at others. Look at the following for instance:

[MyMachine:~] mylogin% uname -a
Darwin Roadrunner.local. 6.2 Darwin Kernel Version 6.2: Tue Nov 5 22:00:03 PST 2002; root:xnu/xnu-344.12.2.obj~1/RELEASE_PPC Power Macintosh powerpc
[MyMachine:~] mylogin% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1161, based on gcc version 3.1 20020420 (prerelease)
[MyMachine:~] mylogin% cat fib.c
#include <stdio.h>

int fib(int n)
{
if (n < 2) return 1;
else return fib(n-1)+fib(n-2);
}

int main(int argc, char *argv[])
{
printf("%d\n", fib(atoi(argv[1])));

return 0;
}
[MyMachine:~] mylogin% gcc fib.c -O3 -o fib
[MyMachine:~] mylogin% time ./fib 40
165580141

real 0m9.828s
user 0m9.660s
sys 0m0.020s

And now for Java:

[MyMachine:~] mylogin% java -version
java version "1.4.1-alpha"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-alpha-root_22_nov_2002_19_03)
Java HotSpot(TM) Client VM (build 1.4.1_alpha-7-release, mixed mode)*
[MyMachine:~] mylogin% cat fib.java

public class fib
{
public static int fib(int n)
{
if (n < 2) return 1;
else return fib(n-1)+fib(n-2);
}

public static void main(String[] args)
{
System.out.println(fib(Integer.parseInt(args[0]))) ;
}
}
[MyMachine:~] mylogin% javac fib.java
[MyMachine:~] mylogin% time java -server fib 40
165580141

real 0m7.867s
user 0m7.640s
sys 0m0.150s

The results get even more interesting as you compute higher and higher numbers of the Fibonacci sequence. When computing the 43rd Fibonacci number the java bytecode beats the statically compiled C machinecode by a full 10 seconds. For the 44th number it beats it be 19 seconds.

Does this mean that java bytecode is faster than machinecode in all cases? No. Does the fact that a few java applets on your P2 run poorly mean java itself is slow? No. It is true that Java has poor performance in the GUI realm, but it is great for backend server applications. So making the blanket statement that java is slow or fast in general based on a single or handful of benchmarks is just plain wrong.

* I'm not running some special optimized pre-release version of Apple's JVM. It's the pre-release 1.4.1 implementation. Nothing that isn't available on Windows, Linux, Solaris, etc.

Re:Java?

[Anonymous Coward]

I'm being a bit off-topic here, but I thought it would be interesting to see how your program fared in OCaml. First in C to establish the benchmark:

$ gcc -v
Using builtin specs.
gcc version 2.95.4 20020320 [FreeBSD]
$ time ./fibc 40
165580141

real 0m14.607s
user 0m14.249s
sys 0m0.017s

Now in OCaml:

$ cat fib.ml
let rec fib n =
if n < 2 then 1
else fib (n - 1) + fib (n - 2)
;;

Printf.printf "%d\n" (fib (int_of_string Sys.argv.(1) ) );;

$ ocamlopt -v
The Objective Caml native-code compiler, version 3.06
Standard library directory: /usr/local/lib/ocaml
$ ocamlopt -o fibm fib.ml
$ time ./fibm 40
165580141

real 0m8.115s
user 0m7.909s
sys 0m0.016s

Not bad I think :) It's interesting to run both without parameters:

$ ./fibc
Segmentation fault (core dumped)
$ ./fibm
Fatal error: exception Invalid_argument("out-of-bound array or string access")

High-level, safe, decent efficiency ...

Re:Java?

[jilles]

The benchmark becomes even more interesting once you realize that the java benchmark includes the overhead of starting up java and jit compiling the class file. It still is faster.

Re:Java?

[AT]

Wow, that is quite surprising -- so much so that I tried it myself. I reproduced this test on Linux with similar results.

I've tried to figure it out: first I thought maybe the Java compiler did some heavy optimization, but inspecting the bytecode with javap showed it was a straight forward translation of the source.

My other thought is this particular example plays right into the strength of Java's JIT. Since the same code is run over and over, it can be compiled once at runtime. The code is very short, so the just-in-time compilation doesn't take much time. And it can fully exploit Java's key performance advantage: the ability to incorporate runtime profiling information into the optimization process.

Don't get me wrong, this is extremely impressive. But it *is* a contrived example that shows off Java in its best light.

Re:Java?

[Daleks]

My other thought is this particular example plays right into the strength of Java's JIT. Since the same code is run over and over, it can be compiled once at runtime. The code is very short, so the just-in-time compilation doesn't take much time. And it can fully exploit Java's key performance advantage: the ability to incorporate runtime profiling information into the optimization process.

Static compilers make "eduated" guesses as how to best optimize code. When it comes to a fork in the road it, since they don't have actual run-time information, they have to do the best they can and move on. Java can leverage run-time information against the statically compiled bytecode and utilize dynamic optimization. Granted completely linear code will always run better when statically compiled to machine code, but if at any point in the compilation process the compiler has to make an "educated" guess, a better decision can be made at run-time through dynamic optimization. General information on dynamic optimization can be found here [indiana.edu].

Re:Java?

[silvaran]

Oh yeah? Well beat this!

# cat fib.sh
fib() {
n=$1
if [ "$n" -lt "2" ]; then
echo -n "1"
else
first=$(fib $((n-1)))
second=$(fib $((n-2)))
echo -n $((first+second))
fi
}

fib $1

# time ./fib.sh 40
(it's been 10 minutes and I'm still waiting...)

Re:Java?

[smithmc]

Jeez, what kind of machine was this? Using MSVC6, no custom optimizations, on an Athlon 2000+, the C version runs in 1.906 seconds, for the 40th number. The 44th number takes 13.093 seconds. I'll have to get a JDK implementation set up so I can test the Java equivalent...

Re:Java?

[AJWM]

On a P3-550 (dual CPU, but that has no effect here) I get 10.82 sec for the C version (GCC 2.95) and 9.74 for the Java version (JDK 1.3).

Re:Java?

[AJWM]

Which shows how lousy C is at recursive functions. (And how bad recursive calls can be in general).

Rewriting fib(int n) along the lines of

int fastfib(int n)
{
int i;
int f = 0;
int fm1 = 1;
int fm2 = 1;

if (n < 2) return 1;
for (i = 2; i <= n; i++) {
f = fm1 + fm2;
fm2 = fm1;
fm1 = f;
}
return f;
}

(and similar in Java), I get times of 0.004 seconds for C and 0.567 seconds for Java -- most of which is the time to load the JVM (ie the difference between 'time java fastfib 40' and 'time java fastfib 0' is lost in the noise).

Proving that choice of algorithm can make far more difference than choice of programming language.

Inlining

[r6144]

I bet the JVM does far more inlining than GCC.

Re:Java?

[Trane Francks]

Java apps/applets aren't usable on my P2 266

You're kidding, right? I recall running ICQ Java Preview 0.981a very happily on a 486 with 32 megs of RAM. Sure, that system may not have been the quickest, but ICQ Java was no less useable than, say, Emacs.

Re:Java?

[AJWM]

It's big and slow.

In some cases, it's faster than C++.

Don't believe me? Download the Markov examples [bell-labs.com] from Kernighan & Pike's "The Practise of Programming" and time the C++ and Java examples. On a P3-550 I get 3.63 seconds for the C++ and 2.90 seconds for the Java version.

I don't really care...

[ActiveSX]

...unless this will help me stay up longer so I can finish this paper that was due yesterday.

Re:I don't really care...

[gedanken]

Not posting to /. will probably help you get that paper done faster.

More viruses

[delfstrom]

Great, so now virus-writers will be able to create cross-platform office viruses.

Re:More viruses

[cant_get_a_good_nick]

this is different from MS Office how? I had the Concept virus on Word 6, when I ran it on Solaris (under WABI). They also hit Mac Word 6.

In the blurb, they mentioned the Java security model, which if it works for Applets (and it more or less does, after the first buggy implementations) it should be OK for the "fewer things can attack us" macro stuff.

Java scripting language?

[jsse]

Sun's StarOffice division intends to make Java a scripting language for StarOffice,...

A word processor running scripting language? Doesn't that sound so familiar to everyone?

which will help customers take advantage of Java's security features. Java's security model works by limiting the areas of the computer the code can manipulate.

Fortunately, smart people can learn from mistakes of the other and built it with security in mind from the ground up.

but it doesn't stop the creative minds of programmers.....

Re:Java scripting language?

[Anonymous Coward]

Open/Star Office to my mind already has a "Java flavor". You can write add-on components and macros in Java, as well as embedding running applets in your documents.

OpenOffice actually includes a specification for extensibility in arbitrary scripting languages (provides someone bothers to write the support). Currently, C,C++, Python, Java and are supported to some degree. No real reason for Perl, Python, Ruby, Common Lisp not to be, if anyone can be bothered.

See UNO UDK [openoffice.org]on the OpenOffice Site.

Re:Java scripting language?

[Waffle Iron]

That's neat, but they need to standardize on one or two languages (fully supported out of the box in the standard distribution) if they want interoperability between documents on random users' machines.

Also, I fail to see what use a strongly typed and/or compiled language has as a "scripting" extension for an application. Take Java for instance, where you have to create a class and a "main" method just to print "Hello World". This is overkill for calculating the value of a spreadsheet cell, not to mention the dearth of compact string handling functionality (formatting, regex, etc.). I'd stick with Python or Ruby for this job.

Scripting language for StarOffice!

[jsse]

Sun's StarOffice division intends to make Java a scripting language for StarOffice

Great, let's call it Javascript.

Re:Scripting language for StarOffice!

[Anonymous Coward]

Great, let's call it Javascript.

JavaScript was horribly named by inept marketers at Netscape back in 1995. Its real name was "LiveScript" but they changed it at the last minute so they could coast on Java hype. It has nothing to do with Java and the name has been confusing people ever since. And "JavaScript" was a good name, too. It would be nice if BeanShell, for example, could be called "JavaScript" because that's actually what BeanShell is.

It's like the .NET debacle at Microsoft. Every single marketing manager decided that his own projects needed to be part of the .NET initiative. They all hopped on it and diluted its meaning. For all practical purposes ".NET" is basically the name that Microsoft is now associating with every latest version of most of its products, so it means nothing. (Yes, there is a very nice JVM ripoff in there somewhere, if you can find it without getting lost in the slick glossy .NET bullshit.)

IMHO if it's obvious that a programming language has been named by a marketer, that's a red flag. Java and C# were named by marketers. But at least nobody will confuse Java with coffee; that would be silly. But "C#" is as bad a name as "JavaScript". It's going to cause confusion with C and C++ (which are already confused for one another, and with Objective C, especially when HR managers scan people's resumes looking for keywords). And C# is nothing like C, or C++, or Objective C. I have to admit "C++" was a clever way to name a programming language that aspires to be (almost) a superset of C. But in that case the new name was a legal expression in the old one, it was a short, extremely descriptive name, and it made sense. C# fails on all three counts. They should have just named it "Me Too C".

.NET *Framework* is the JVM knockoff

[yerricde]

For all practical purposes ".NET" is basically the name that Microsoft is now associating with every latest version of most of its products, so it means nothing. (Yes, there is a very nice JVM ripoff in there somewhere...)

This JVM-inspired environment is called .NET Framework. Look for the word "Framework" in Microsoft .NET product literature [microsoft.net] to find references to what most Slashdot users seem to associate with ".NET".

C# fails

Some critics have described the Java language as "C++ done right". The C# language is Microsoft's re-hash of the Java language. Now if you stick two ++'s on top of each other, you get something that looks like a hash sign; thus, (C++)++ is C#.

Javascript's Connection to Java

[stu42j]

JavaScript was horribly named by inept marketers at Netscape back in 1995. Its real name was "LiveScript" but they changed it at the last minute so they could coast on Java hype. It has nothing to do with Java

Actually, one of the main reasons for creating JavaScript was to provide a connection between a webpage and a Java applet. From the Core JavaScript Guide: "Through JavaScript's LiveConnect functionality, you can let Java and JavaScript code communicate with each other. From JavaScript, you can instantiate Java objects and access their public methods and fields. From Java, you can access JavaScript objects, properties, and methods."

That's the technical reason for the name. Not to say that marketing had nothing to do with it but there is more to it than that.

See also: Press Release: NETSCAPE & SUN ANNOUNCE JAVASCRIPT(TM) [sun.com]

Reference: Core JavaScript Guide 1.5: What is Javascript [netscape.com]

Flavored staroffice?

[phorm]

Sun To Give StarOffice Java Flavor

Hmmm, I was wondering what the "flavor" of the current staroffice CD was, so I licked a few. Blah, they don't taste very good. I guess a java-flavor would be an improvement, even though I'm not a huge coffee fan anyways.

After reading the title, I just had to post this regardless of any possible karma-burning involved...