... you might be bitten by this Java bug rendering arcs as straight lines at large zoom levels.

It looks like a classic to me: in order to improve rendering performance, you approximate arcs with straight lines at small resolutions (if it's just 2 pixels big, nobody will be able to tell the difference). Except of course, when you end up doing the same approximation at a large zoom value - of course a 100-pixel circle looks different from a 100-pixel diamond.

Reported in 2005, still not fixed in current Java (we're in 2009 now).

Sun is really slow at fixing Java bugs.

See also a related Apache Batik bug report. Fortunately, this only applies to Java rendered graphics - SVG export, PDF, Postscript are all fine.

Is there any way to provide an alternate CSS stylesheet for GoLive CS2 only, not for regular browsers? Because there are some things in that layout that are too difficult for the GoLive renderer, it doesn't display them right. The pages are still editable (just plain XHTML), it's just not looking right in GoLive (advanced CSS).

The site already has alternate stylesheets for browsers such as the broken Internet Explorers, so if I could convince GoLive to use their stylesheet it might be looking a lot better in the editor, too ...

I am aware that GoLive CS2 has been abandoned in favor of DreamWeaver. Still it's going to be used in a project I help with the web templates.

(Other options would be Kompozer and Amaya, but none of them seem really fit for production use: Amaya was just removed from Debian because it had some security issues and the maintainers had the impression the code was such a mess that there will be much more such issues. And Kompozer seemed to be a mostly dead branch of a Gecko hack (although there has been a new alpha release this year) ... is there some reliable opensource non-source HTML editor that I'm missing?)

P.S. Sorry, no comments in this blog. Use Email: erich AT debian ORG

Arrays and Generics in Java do not mix very well. In order to create an array, you need to know the object class the array is supposed to store.

Arrays in Java are special: they can efficiently store primitive data types. The expected difference in efficiency between byte[] and Byte[] is pretty big (of course some good VM might optimize) for obvious reasons (think of: references, garbage collection, pointer sizes, ...).

This is probably why you need to know the type before creating an array (because an array of primitive types such as byte will be different from one that stores objects of some kind).

In particular, the following Java code

  String[] foo = (String[]) new Object[0];

public static <T> T[] test() {
  T[] te = (T[]) new Object[0];
  System.err.println(te.length);
  return te;
}
String[] foobar = test();

What happens here is that in the test() method, T actually is replaced with "Object" at compile time. Thus the array type works just fine, and so does the call to te.length. Upon returning, it is then cast into a String[] array and fails.

Now here comes a crazy Java hack:

public static <T> T[] test(T... ts) {
  T[] te = (T[]) java.lang.reflect.Array.
      newInstance(ts.getClass().getComponentType(), 0);
  System.err.println(te.length);
  return te;
}
String[] foobar = test();

The exception is gone, foobar is of the proper type now!

A result of discovering this hack are these two methods:

public static <T> T[] newArrayOfNull(int len, T... ts) {
  // Varargs hack!
  return (T[]) java.lang.reflect.Array.
      newInstance(ts.getClass().getComponentType(), len);
}
public static <T> T[] toArray(Collection<T> coll, T... ts) {
  // Varargs hack!
  return coll.toArray(ts);
}

Notice how elegant the last method looks - and it finally allows you to do toArray(collection) instead of collection.toArray(new WhateverClassTheCollectionHas[0]).

Note that this is still a hack, and may or may not work with all Java compilers, JREs and/or Java versions.

Update: Note that this 'hack' is also not transitive. The context calling toArray needs to know the object type at compile time. So it doesn't save you much more than writing "new KnownClass[0]" etc.

Update: So I'm actually not using this - it's just a hack, and often quite hackish. The problem is that when you call e.g. toArray in an Generics context, it will actually create an array of "Object", so it makes much more sense to verbosely specify the class you want to use for the arrays (and get some reliability in use back).

Has anyone experience with Dropbox?

It seems to be an interesting web storage service, with 2 GB of free storage.

However, the Linux client seems to be closed source (which is understandable, it seems to have a lot of neat features) - so I intend to use the web interface only (at least for now).

Update #2: There is a RFP bug for Debian, some Source is on the download site. And while this sort (except the images) is GPL, it's just the nautilus integration part, not the daemon you also need.

Did you try Dropbox? Does it work well? I know some people (especially Windows users) who could benefit a lot from a service like that, so I wonder if I should recommend them Dropbox. Or is there some better alternative (it should allow sharing of files though - synchronization is not as essential, it is a lot about exchanging files too large for usual email in small user groups; still synchronization probably is a comfortable way of transferring the files without having to think about it yourself)?

No comments in this blog - email me via erich AT debian ORG.

P.S. I know there is some referral program to get more storage, feel free to send me your referral link - I'll remove this PS once I've signed up.

P.P.S. There also is Ubuntu one, but as far as I can tell Ubuntu only so far. Looks very similar.

P.P.P.S. So far, I've received a lot of praise for DropBox.

P^4.S. My own referral link, feel free to use this to sign up (+256 MB for you, too!) and "upgrade" my account.