Fedora 18 impressions

For a few days already I'm using Fedora 18. I've not upgraded, I went for a fresh install instead, keeping the old /home.

Positive impressions:

• New Anaconda installer. I was a bit confused at first with the manual disk partitioning, but when I figured it out, it's all clear now. Otherwise it's a much simpler installer. It also is fully Lithuanian (those hours I've pent translating it was not a waste)!
• New Gnome message tray is much better, than the older. The only issue with it is applications, that show permanent icon in tray (like Rhythmbox), you have to get used to Super+M hotkey.
• Gnome 3.6 seems to be faster than the older

Negative sides:

• Gnome Shell is quite unstable for now, I had around one crash each day. Looking forward to updates (perhaps even the ones I intalled a couple hours ago)
• Firefox also suffers some stability problems, not sure if it's related to same problems as Gnote Shell. But this gives me a better chance to give Epiphany a go, so far it seems faster than Firefox.
• There's no ffmpeg plugin for GStreamer 1, only for 0.10. So I can't watch some movies using Totem. I've installed VLC as a temporary solution (I don't like it - UI is very uncomfortable).

How I'd fix Java

If I could change anything in Java, here's what I'd do:

1. Introduce string primitive
It would be just as the String class, except it would never be null, it would be empty string instead. How much boiler plate code does the null-checks cause for String. Autoboxing would work too.
As for consistency, other primitimes could also allow called methods of their relevant class alternatives.
2. Make generics array-like
By introducing generics Java creators worked hard to ensure backward compatibility. And, IMHO, failed. Consider:
• Array of Integer objects can be casted to array of Number objects, but not so collections.
• If you insert something illegal to such downcasted array, you get appropriate exception.
That's not the case for collections. The intent was clear:
• Collections were not designed to throw exception due to incompatible type, as they were designed to always hold Object references. Changing that could break existing code.
• Any down/up-casting was not permitted on generic collections for the same reason.
However, I think this wasn't the right thing to do, because:
• If you're not sure, what your legacy code inserts into raw collection, pass in the one, that hold Object and you'll get no issues.
• If the legacy code is supposed to only insert certain type (say String), so pass in appropriate collection. In case the legacy code inserts something else, you get exception at exact place where the bug in legacy code lays, rather than get an ugly ClassCastException miles away in the new code.
Finally, why not combine autobixing with collections, so that primitives could be stored in them? Well, I mean collections still hold references to wrappers, just you get autoboxing when putting/getting and not-null-ness is ensured.
3. Allow public fields by JavaBeans specification
Probably 90% of classes conforming with JavaBeans specification have only trivial setters and getters. I see no real reason, why public fields are not allowed and all this boiler plate code must be written.
4. Enhanced for should be null-safe
Why it's not called for-each, like in other languages?
This type of for statement was introduced for readability, but having to check for null takes away half of that, because you have to wrap it in an if (you can avoid if by writing apropriate condition in traditional for).
IMO this enhanced for should treat null collection as empty.
5. Allow pass-by-reference or multi-value returns
It really is nasty to write a new class just to return several values from method. I'd love to have something like C++ references or Pythons multi-value return for that.
6. Replace java.io entirely
Just admit - java.io is hopelessly overengineered. The most clumsy and least usable I/O system of all languages I've ever used. With this number of classes you'd expect to have stuff for all possible cases, but in reality there never is a class, that does what you need. You have to combine at least two of them in all cases. And if you need to read a simple text file, out of all there trouble all you get is readLine() - parse it yourself. How to fix it? Just make a clone of C++ iostream - with a couple of rough edges removed and couple extra classes (like for pipes and sockets) it would be nearly perfect solution.
7. Package aliases or smallest unique distinction
One thinkg I don't like about Java packages is the all-or-nothing approach with their names. In case you have 2 classes with same name, you have to use both of them with full package qualification. With standard reverse-domain naming scheme this means ugly long names. What I'd like is aliases, similar to C++ namespace aliases, which could look like:
package alias = com.company.product.whatever.pkg;
With this line alias.ClassName is identical to com.company.product.whatever.pkg.ClassName.
Another solution could be to use the unique part of package name: move backwards from class name to any dot until you get uniques name. Perhaps whatever.pkg.ClassName is enough to identify class and you don't need to type the full ugly package name.