Slashdot Mirror

MOD PARENT UP! This is right on the money

Perhaps someone needs to point Mr. Winske at Peter Korn's blog entry covering the subject of accessibility in OpenOffice.org. It covers the strong and weak points on both the Windows and Unix platforms.

Offtopic rant time.

Another Slashdotter here said it right: with Swing most of your time is spent fighting with components to get the user interface to look and feel right.

The fact that a bug like this is still in Java after 5 years gives me an uneasy sinking feeling in my stomach because I wanted to use Java for a project.

Take this one: to get behaviour that 99.9% of the world's developers want, you have to table.putClientProperty("terminateEditOnFocusLost" , Boolean.TRUE); which acts weird with the other workarounds on the first bug page.

Why not make these components non-shitty by default? Do Java devs LIKE writing workarounds all the fucking time? Jesus. 5 years. I think Sun hates Java as much as I am starting to.

Offtopic rant time.

Another Slashdotter here said it right: with Swing most of your time is spent fighting with components to get the user interface to look and feel right.

The fact that a bug like this is still in Java after 5 years gives me an uneasy sinking feeling in my stomach because I wanted to use Java for a project.

Take this one: to get behaviour that 99.9% of the world's developers want, you have to table.putClientProperty("terminateEditOnFocusLost" , Boolean.TRUE); which acts weird with the other workarounds on the first bug page.

Why not make these components non-shitty by default? Do Java devs LIKE writing workarounds all the fucking time? Jesus. 5 years. I think Sun hates Java as much as I am starting to.

When you say you were talking about "the quote" I can only assume you mean the one in the original Slashdot post. It's pretty clear that that's all you read before you posted, which just wastes everybody's time. It's easy to see (from your sig as well as your posts here) that DRM is a Big Deal to you. Fine, but it was not the subject of TFA, and it's not something that Radia Perlman spends a lot of time on (here is a (short) list of her recently-published work at Sun). In the interview, she basically calls DRM a waste of time. For what it's worth, I agree with that. But, you can't expect everyone to climb on a soapbox every time the subject is mentioned in passing.

In a way Linux as a whole (the kernel) is now suffering from the same problems as Debian stable once was, at least from my perspective. Do you guys remember the previous Debian stable? It remained stable for such a long time that eventually you simply needed websites like Backports to be able and run some current software since everything included with Debian was way ancient. Naturally you could run Unstable but it wasn't exactly the best approach for servers. I eventually ended up running Testing and keeping a close eye open for bug reports, exploits, etc. while not updating the box every time something new came out.

And that is what I see happening here as well. The last really stable kernel is IMO 2.4.32. There are no new features being added, only bugs being fixed. Which is IMO exactly what is needed for serious usage since every beginner programmer knows that when you add new features to your software you will also increase the risk of more bugs popping up. These could be bugs resulting in the addition of new code and the way it cooperates with the existing code, or simply bugs which only manifistate themselves in the new routines. Unfortunatly the kernel developers don't see this or they don't care resulting in a rather stable kernel 2.4.32 which unfortunatly lacks some hardware support and certain features when compared with the rather unstable 2.6.x kernel branch.

Personally I'm worried about the future. When looking at the 2.6.x kernel I don't like what I see. When looking at the current Debian Sid and the rather rough way they implemented the new X environment I also can't help wonder if there aren't more bugs than "usual" popping up. /usr/X11R6, so why couldn't they add /usr/X11R7 ?

Anyway, this is all moot now since I have lost fait in Linux all together when it comes to server usage for quite some time. I think that Linux is suffering from its own success and it may well proof fatal in the end, although I really hope it doesn't. I still enjoy running Linux on my workstation and I'm not planning to stop. But when it comes to serious work, like my server, my trust is now put into Sun Solaris 10. While Solaris is also moving into the Open Source environment Sun still uses their common sense and as such split their software into 3 parts: Open Source, Unstable and Stable.

In a way Linux as a whole (the kernel) is now suffering from the same problems as Debian stable once was, at least from my perspective. Do you guys remember the previous Debian stable? It remained stable for such a long time that eventually you simply needed websites like Backports to be able and run some current software since everything included with Debian was way ancient. Naturally you could run Unstable but it wasn't exactly the best approach for servers. I eventually ended up running Testing and keeping a close eye open for bug reports, exploits, etc. while not updating the box every time something new came out.

And that is what I see happening here as well. The last really stable kernel is IMO 2.4.32. There are no new features being added, only bugs being fixed. Which is IMO exactly what is needed for serious usage since every beginner programmer knows that when you add new features to your software you will also increase the risk of more bugs popping up. These could be bugs resulting in the addition of new code and the way it cooperates with the existing code, or simply bugs which only manifistate themselves in the new routines. Unfortunatly the kernel developers don't see this or they don't care resulting in a rather stable kernel 2.4.32 which unfortunatly lacks some hardware support and certain features when compared with the rather unstable 2.6.x kernel branch.

Personally I'm worried about the future. When looking at the 2.6.x kernel I don't like what I see. When looking at the current Debian Sid and the rather rough way they implemented the new X environment I also can't help wonder if there aren't more bugs than "usual" popping up. /usr/X11R6, so why couldn't they add /usr/X11R7 ?

Anyway, this is all moot now since I have lost fait in Linux all together when it comes to server usage for quite some time. I think that Linux is suffering from its own success and it may well proof fatal in the end, although I really hope it doesn't. I still enjoy running Linux on my workstation and I'm not planning to stop. But when it comes to serious work, like my server, my trust is now put into Sun Solaris 10. While Solaris is also moving into the Open Source environment Sun still uses their common sense and as such split their software into 3 parts: Open Source, Unstable and Stable.

Thanks. Hmmm, I followed a link and found http://java.sun.com/j2se/1.4.2/docs/guide/extensio ns/extensions.html which told me something I needed to know: they're now "optional packages" rather than "Standard Extensions". I didn't think that e.g. the PostgreSQL driver sounded like a Standard Extension. Sun has found a really obscure way of saying "add system libraries here".

I'm still a little uneasy about the security implications of dropping something into jre/lib/ext but I'll study it some more.

"For example, there is an implementation of Hotspot for J2ME/CLDC that runs in 1MB."

Bullshit.

No, it is a fact:
http://java.sun.com/products/cldc/faqs.html

"13.What is the CLDC HotSpot Implementation?

The CLDC HotSpot[tm] Implementation is a high performance, battery-preserving virtual machine that is compliant with the CLDC specification. It not only offers significantly improved performance over the KVM, but it also offers greater portability and faster time to market. The CLDC HotSpot Implementation is suitable for devices based on ARM microprocessors/controllers, and with 512KB to 1MB of total memory available for the Java technology stack. The latest release of the CLDC HotSpot Implementation is version 1.0.1."

I wish Java did have more prorpietary hooks for [COM and the like].

It is possible to wrap a JavaBeans component in an ActiveX control, and Jcom goes the other way.

http://java.sun.com/j2se/1.4.2/docs/tooldocs/findi ngclasses.html

This must be your lucky day. Sun has an RPM package for download; the self-installer generates the .rpm file.

    Three new methods have been added to java.io.File class:

          getFreeSpace()
          getUsableSpace()
          getTotalSpace()
[...]

  Changing File Attributes:

  In Mustang the java.io.File API provides access to the file attributes for changing its readability, ability to write and ability to make it executable. Check out the following methods for playing around with file attributes:

  Changing readability: owner-only, owner or everybody
  Making it writable or read-only: owner-only, owner or everybody
  Making it executable or not executable: owner-only, owner or everybody

Umm, about your comment: The link goes to a blog entry of yours about the inefficiency of using StringBuffer.append(String) to append a single-character string instead of just using StringBuffer.append(char). Sure, it's a good idea, but there's another kinda-orthogonal piece of advice that will likely improve runtime performance a good bit more:

The vast majority of the code that uses StringBuffer could save a bunch of time by using the new-ish(JDK 1.5) StringBuilder class, which has the same API but is not internally synchronized. This translates to a runtime savings of approximately a KAJILLION percent by avoiding the horrendous synchronization overhead hit when the StringB*ef in question is only being used by one thread. It's very similar to using an old-skool Vector when an ArrayList will do just as well and not slow down your code.

Like I say every thime this kind of thing comes up, Java isn't slow (any more), but we're certainly not helping matters with this kind of sloppy coding.

Also, back on topic, try writing financial software some time. It's like a different world. Everything is unit tested, and the unit tests don't so much check for bugs as prove that your code works. That way, when a million-dollar bank wire doesn't go through, you can prove that it's not your head that should be on the chopping block. It's actually kind of refreshing knowing that any code you touch is pre-vetted so you don't have to worry about trusting it enough to build on it.

Yeah, because Java doesn't have function pointers.

Granted, using Method for anything but reflection is pretty bad programming practice. But if you absolutely must have function pointers, they're there.

Take a look at java.util.concurrent (as another response has suggested). Specifically, look at:

"Concurrent Programming with J2SE 5.0"
http://java.sun.com/developer/technicalArticles/J2 SE/concurrency/index.html

and

"Concurrency Utilities Overview"
http://java.sun.com/j2se/1.5.0/docs/guide/concurre ncy/overview.html

There's much more to concurrency in Java (especially Java 5) than simple target-object synchronization. (For example, you can set up queues to pass safely from one thread to another.)

You might also want to look at some other frameworks that have been created in Java, such as CSP, covered in a series of DeveloperWorks articles beginning with:

"CSP for Java programmers, Part 1"
http://www-128.ibm.com/developerworks/java/library /j-csp1.html

There's a lot out there to let you think in much higher-level concepts than simple locks (although you can do that to, for the learning exercise ;-).

Take a look at java.util.concurrent (as another response has suggested). Specifically, look at:

"Concurrent Programming with J2SE 5.0"
http://java.sun.com/developer/technicalArticles/J2 SE/concurrency/index.html

and

"Concurrency Utilities Overview"
http://java.sun.com/j2se/1.5.0/docs/guide/concurre ncy/overview.html

There's much more to concurrency in Java (especially Java 5) than simple target-object synchronization. (For example, you can set up queues to pass safely from one thread to another.)

You might also want to look at some other frameworks that have been created in Java, such as CSP, covered in a series of DeveloperWorks articles beginning with:

"CSP for Java programmers, Part 1"
http://www-128.ibm.com/developerworks/java/library /j-csp1.html

There's a lot out there to let you think in much higher-level concepts than simple locks (although you can do that to, for the learning exercise ;-).

Not even that, actually.

In C, it tells the compiler that the read or write to memory can't be reordered. If you do a read, it has to get it from memory right then, rather than reusing one from before that it might have stuck in a register. It doesn't tell the CPU anything about synchronizing its cache or executing the instruction in order, however. You've gotta have both.

In Java, it actually depends on the version of the language. third edition (Java 1.5, I believe). second edition (the first is the same; so Java 1.1-1.4). It appears to say what you said, but I don't buy it. Look at this article by a bunch of Java synchronization experts on double-checked locking. In particular, this sentence:

The consensus proposal extends the semantics for volatile so that the system will not allow a write of a volatile to be reordered with respect to any previous read or write, and a read of a volatile cannot be reordered with respect to any following read or write.

This change might have made it into the third edition. The second and first read like it provides this guarantee, but if these guys say not, then I'm not going to be depending on that without reading all of the chapter on thread interactions (not just the one section on volatile), reading everything they say, and doing some experiments. If that means my software runs 0.5% slower because I have more synchronization overhead than I need, then so be it.

Not even that, actually.

In C, it tells the compiler that the read or write to memory can't be reordered. If you do a read, it has to get it from memory right then, rather than reusing one from before that it might have stuck in a register. It doesn't tell the CPU anything about synchronizing its cache or executing the instruction in order, however. You've gotta have both.

In Java, it actually depends on the version of the language. third edition (Java 1.5, I believe). second edition (the first is the same; so Java 1.1-1.4). It appears to say what you said, but I don't buy it. Look at this article by a bunch of Java synchronization experts on double-checked locking. In particular, this sentence:

The consensus proposal extends the semantics for volatile so that the system will not allow a write of a volatile to be reordered with respect to any previous read or write, and a read of a volatile cannot be reordered with respect to any following read or write.

This change might have made it into the third edition. The second and first read like it provides this guarantee, but if these guys say not, then I'm not going to be depending on that without reading all of the chapter on thread interactions (not just the one section on volatile), reading everything they say, and doing some experiments. If that means my software runs 0.5% slower because I have more synchronization overhead than I need, then so be it.

Read this book: Concurrent Programming in Java: Design Principles and Patterns by Doug Lea. It's a bit dry, but well worth the read. Even if you're not programming in Java, the concepts, problems, and solutions are similar. Java just offers some abstraction.

Understand the primitives, wait(), notify(), synchronized. Then learn Java 1.5's java.util.concurrent package, so you won't have to use wait/notify yourself in most cases.

Most programmers don't understand the issues that come up with concurrent programming, and if you can learn them, it's yet another way to set yourself apart. They used to teach this in operating systems class, but these days, who knows.

I'm wondering what all those java applications are doing in Debian!

I'm not getting what you are trying to say, if anyone could make their own implementation of the Java language with their own changes it wouldn't be Java anymore simply because is has been changed from the specs. The specifications of the language can be found at http://java.sun.com/docs/books/jls/

You want to call your implementation Java, you'll need to get the certification from the JCP.

Are you saying the C# standards lacks such requirements?

• Concurrent Programming in Java: Design Principles and Pattern (2nd Edition), by Doug Lea.
• Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea.
• Effective Java Programming Language Guide, by Joshua Bloch. Though this is a general programming guide, its chapter on Threads contains essential "best practices" for concurrent programming.
• Concurrency: State Models & Java Programs (2nd Edition), by Jeff Magee & Jeff Kramer.

You should also note that your complaints about the limitations of Java concurrency are addressed in JSR 166, which has been part of the Java platform since 5.0. This defines a new package with many nifty features. There's excellent coverage in this JavaOne talk.

• Concurrent Programming in Java: Design Principles and Pattern (2nd Edition), by Doug Lea.
• Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea.
• Effective Java Programming Language Guide, by Joshua Bloch. Though this is a general programming guide, its chapter on Threads contains essential "best practices" for concurrent programming.
• Concurrency: State Models & Java Programs (2nd Edition), by Jeff Magee & Jeff Kramer.

You should also note that your complaints about the limitations of Java concurrency are addressed in JSR 166, which has been part of the Java platform since 5.0. This defines a new package with many nifty features. There's excellent coverage in this JavaOne talk.

Seriously, the better documented an open-source piece is, the more open it is, commensurately.

E.g. See:

• http://del.icio.us/eric_boutilier/docssuncom
• http://del.icio.us/eric_boutilier/bigadmin

http://java.sun.com/j2se/1.5.0/docs/api/java/util/ concurrent/package-summary.html

Even better, use Doug Lea's excellent concurrency package, which has been integrated into Java 1.5 but can also be used with older Java versions.

Yes, eBay's entire site: http://www.sun.com/service/about/success/ebay5.htm l. It is fairly easy to map .dll to a servlet in your web container's configuration.

The fact that Y! has to use C++ slows them down significantly. Developer productivity in Java is orders of magnitude better than in C++ because of niceties like refactoring, instant compilation, working "intellisense," simpler syntax, automatic managabilty through JMX, automatic security through JAAS, automatic transaction-handling through EJB, automatic horizontal scalabilty through JMS, and fewer programming errors to avoid. (Compare Effective Java to the three equivalent books for C++.) Moreover, as soon as you start to program in C++ correctly (by using auto-management of resources via auto-pointers and containers and using idioms like PIMPL), you've slowed yourself down to Java speed (or slower) in execution.

synchronized(objectToModify)
{
    if(objectToModify.getX() == myObj.getX()) objectToModify.setY(myObj.getY());
}

I dont understand what do you mean by "Java" here but they are already providing JDK source: http://wwws.sun.com/software/communitysource/j2se/ java2/download.html

it just requires spending the money to get it certified.

Actually, FreeBSD were given a license at no cost by Sun, and any not-for-profit organisation with a need for access to a Sun-maintained compliance test kit can get it at no charge. So it's really just a matter of having the motivation to ask.

Luckily, you there are workarounds, such as using Eclipse instead of swing and a different language to avoid checked exceptions.

"Open Source" + "Sun Microsystems" almost certainly = "CDDL"

1) Yeah, it's really so hard to download Java, I mean, where do I start? http://www.microsoft.com/java maybe? oh fuck, it worked. http://www.java.com/ maybe? Oh shit, it did. Hey, even http://java.sun.com/ worked, what is this?

2) Says who? It is a virtual machine afterall, and if you run more Java apps all of them won't use as much memory as the first one did. Also memory are cheap and who cares. It's a good and safe language and you probably ends up with less bugs.

It is very reasonable to run Java in Linux. It's harder/more painful/whatever in the BSDs but it works.

Like all silly blanket statements, this one boils down to the type of certification you're talking about. Some are just tests.. Some actually require you to do something.

Certifications will certainly not hurt you. Some may not do you any good, but none of them are harmful.

Like all silly blanket statements, this one boils down to the type of certification you're talking about. Some are just tests.. Some actually require you to do something.

Certifications will certainly not hurt you. Some may not do you any good, but none of them are harmful.

Apart from those pluses mentioned by lokedhs (snapshotting is no trivial feature to have, if you're running databases, for example, or want admin abilities like rollback) - What ZFS offers that no other Linux filesystem offers, let alone HFS+, is end-to-end data integrity and self-healing. That's why I picked Solaris 10 for a high-integrity database app recently. Nobody else could offer the integrity guarantees (apart from some SAN vendors perhaps).

Apart from those pluses mentioned by lokedhs (snapshotting is no trivial feature to have, if you're running databases, for example, or want admin abilities like rollback) - What ZFS offers that no other Linux filesystem offers, let alone HFS+, is end-to-end data integrity and self-healing. That's why I picked Solaris 10 for a high-integrity database app recently. Nobody else could offer the integrity guarantees (apart from some SAN vendors perhaps).

Apart from those pluses mentioned by lokedhs (snapshotting is no trivial feature to have, if you're running databases, for example, or want admin abilities like rollback) - What ZFS offers that no other Linux filesystem offers, let alone HFS+, is end-to-end data integrity and self-healing. That's why I picked Solaris 10 for a high-integrity database app recently. Nobody else could offer the integrity guarantees (apart from some SAN vendors perhaps).

What about Niagara?

Unfortunately, last I heard, Sun was being their usual selves and hiding key architectural details (e.g., chipset stuff) that are holding up the porting effort.

That was about a month or so ago -- hopefully Sun have decided to open up by now ...

In my November 2005 I posted BlogEd, ZFS and OSX, where I described an odd software defect that occured to me on my 17" laptop, and that dissapeared after I reinstalled a new hard drive, after my old one died on me. I am not sure what the defect was due to, but it is clear that with ZFS hard drive corruptions would be detected much earlier. This would be quite a serious advantage.

zraid

http://blogs.sun.com/roller/page/elowe?entry=zfs_s aves_the_day_ta

no more silent data corruption.

very useful for masses of data in large files etc. exactly what professional mac users are wishing for

It seems like giving them away to people would be a far better way of getting rid of old, but still usable, computers

Not necessarily. Often these old machines are highly inefficient in terms of the computing power they provide vs the electricity they consume. Sure, having one of these at home would be cool - in fact I did used to use the next model down as my home server - but these days I just don't want to either pay the power bill or try to justify the waste of resources. Sometimes it really is better just to let this old kit go to silicon heaven.

Actually, I think you hit the nail on the head there with "...but my point is that VS is the standard, and can't be used to learn (at least not easily)". See, I know you're wrong about this, but the important point is that this is your perception. MS, Apple, Sun, Linux (et al), don't have anything set up for the curious person interested in programming to pave the way, or at least shed light on it. Not only is the barrier too high, but you don't know where to start appropriately climbing!

Hmm... I wonder why such a thing doesn't exist? You think it'd be intuitively obvious from a marketing perspective as a means of attracting potential developers. They don't even have to teach you the skills so much as provide you a path in a clear and obvious manner.

A cavaet to that: I just remembered Sun does provide a path: The New to Java Center. Perhaps more vendors do offer this sort of thing but fail to make them obvious.

When it comes to power - I still think they should have bought Transmeta. And Sun knows something the rest of the industry doesn't (yet).

Sun's vision is more relevant today than ever before and is embodied in the product and service breakthroughs it has recently brought to market - from the 'pay-per-view' utility computing Sun Grid and the eco-friendly 32-processor-on-a-chip Coolthreads system, to Sun's innovative software pricing model for the Java Enterprise System and the open sourcing of Java[tm], the Solaris[tm] Operating System and the UltraSPARC T1 chip.

Also, for anyone interested, I recently came across this discussion... while rare, it at least does look like people have raised the question before. This link is to a discussion thread from 2004. Although, they do go in loops about a solution.

http://forum.java.sun.com/thread.jspa?threadID=554 751&messageID=2718194

"The GUI libraries can make use of DirectX and OpenGL."

They can or they do? On Windows Swing has an actual Win32 Window at the bottom and layers other graphic objects on top written in Java. Where does DirectX come into the picture?

Because DirectX can be used within Win32 Windows.

"The threading is superb"

Which threading? The Java threading behavior isn't the same on all platforms and isn't even consistent from one release of Java to the next.

These days Java threading is pretty much the same on all major platforms. It used to be very different (I remember the poor situation with early Linux versions). The threading is not consistent from release to the next because things improve. I would certainly not want the early bugs in threading continued on to later releases. The threading and concurrency facilities in modern Java is very good. Check out http://java.sun.com/j2se/1.5.0/docs/guide/concurre ncy/

When you use threading in Java you have to write your code as if your thread could be preempted at any time but also write it as if your thread will never be preempted.

Explain. Java has clear guidelines about what can be pre-empted and what can't (this is one of the reasons why porting Java onto 16-bit OSes can be hard, as all 32-bit operations are supposed to be atomic).

* One of many examples: I think a lot of people might be interested in SunRay if it wasn't that its use is still painfully tied to Solaris, which nobody wants to use so much as within 50 feet of a desktop machine.

Perhaps you should get your facts straight. The text below is from Sun's Sun Ray software page, with the Linux support in bold. Take a look at the Java Enterprise System's support for various operating systems, I think you'll be surprised.


# Sun Ray Server Software 3.1 is also designed to run on the following operating systems with x64 servers:

          * Solaris 10 3/05 or greater
          * Java Desktop System, Release 2 on x86
        * Red Hat Enterprise Linux Advanced Server 3 on x86 (32-bit)
        * SuSe Linux Enterprise Server 8 Service Pack 3 on x86 (32-bit)


http://www.sun.com/software/sunray/index.xml ..and no, I don't work for Sun. I did post this from a Solaris x64 workstation, which suits me fine.

Personally I quite like the look of the SunRays (especially the newer ones) - but to be fair, for home use it's a bit silly to have a workstation running SunRay server so you can use the SunRay when you could just use the workstation.

It's a business methodology (or philosophy as they call it) used at Sun.

http://www.sun.com/aboutsun/sunsigma/

Check out the FAQ section.