Slashdot Mirror

These are completely different issues. The debate with MS Office / OOXML is that companies are taking data which they own (i.e. documents of any kind) and storing them in a format which is owned by Microsoft and subject to change at their whim. Although this format is a 'standard' it would be very difficult indeed for a third party to create an equivalent to manipulate those documents, hence a company's valuable data is effectively outside of their control. There is therefore a big fear within companies about using anything other than Microsoft software in case it doesn't work - which is right, sometimes it doesn't.

With Jars, if a company develops a Java app they will have the source code (which is plain text files) and use Jars as a distribution mechanism. They will always have their source code so they are never left in a lock-in situation. They can use any Java compiler to create executable code and therefore are not locked-in to Sun.

The most important example of this is with publicly-owned information. In the 1980s it was understandable that data be stored in proprietary formats, but 20 years later there are a variety of fully open and well-documented formats that are more than adequate for most data and there is really no excuse to be locked-in. Microsoft has realised this and produced OOXML which pretends to be open but really isn't.

(posting Anon because I've just been trying to remove your Troll moderations because you're clearly not trolling...)

In addition to a JVM, you need compilers. If there's any part of Java that is complex or that there are incomplete specifications for, it may be those huge standard libraries. But doesn't Sun ship the source code to those with every JDK?

We have the technology to automatically locate a camera and track it with a laser.

High power lasers are easy to get.

We have the platform.

Who's going to take the next step and but a device that can autonomously clear all the cameras from a given area? Mount a camera detector/tracker on a autonomous plane, also mount a high powered laser programmed to pulse when locked onto a camera and set it free in the area you want cleared of cameras?

You want to be absolutely sure it is a camera it is locking onto and not someone's eyes (reduce the chances of error by operating at 3am when few people are about) but surely that is solvable?

I recently wrote up what I (believe to) know about the topic and what I'm still missing:

http://schmidt.devlib.org/java/creating-thumbnails -with-java.html

It's a bit long, but I appreciate comments, preferably by mail.

I'd like to know what you had to do to improve quality. Step-wise down-scaling (always to 50%, until thumbnail size is reached), do a blur filter first, anything else?

Hmm...interesting...this article says that there are 64-bit VMs with JIT. And this one talks about "beta versions for Windows 2000 and Linux on the Itanium platform (the virtual machine being a true 64-bit application)." Now it may be that these JITs are just compiling to x86 code, which then runs on an Itanium, so maybe it wouldn't be quite as fast as code that was specifically generated for the Itanium instruction set, but still I would think the performance would be plenty good enough for running applets in a web browser, which is what the OP was talking about. AFAICT, the issue is simply that nobody has put the work into packaging the existing 64-bit VMs as browser plugins.

warm start (after having been run recently) was 5 seconds which is acceptable but not brilliant for a small app.

JEdit is not a small app. I have just opened up Kate (an equivalent programmer's editor for KDE). It took 10 seconds (first time of opening), and then 3 seconds after that - equivalent to JEdit. I am working with a KDE desktop, so Kate should have far less to do that JEdit.

It seems to me that people are having different sets of standards for Java applications. Because it is 'Java' then delays that they would not notice or care about in other applications are simply labelled 'unacceptable'. For example, I have just tried to open a Gnome image viewer on the same PC. It took 4 seconds - longer than JEdit.

As far as I can see, the evidence is clear and available to anyone with a PC who is willing to try it - Java applications don't take longer to start than other apps, but there is some perception that they do. How this perception is overcome, I don't know.

this lack of a standard vector graphics format also means that afaict there is no way to copy/paste vector graphics from the system clipboard without using custom native code.

This is a reasonable comment, but nothing to do with the size or speed of Java programs. If you want to use a standard graphics format, there is nothing to stop you from doing so. There are plenty of postscript handling libraries for Java:

http://schmidt.devlib.org/java/libraries-postscrip t.html

There are even tools for handling Windows metafiles:

http://piet.jonas.com/

If you want to get this from the clipboard:

Toolkit.getDefaultToolkit().getSystemClipboard()

will provide you will access.