Slashdot Mirror

That suggests to me that calling StringBuffer.toString() would allocate a copy of the buffer into the new String. It says nothing about the fact that this new String will silently carry over the internal StringBuffer allocated memory space. But - surprise! - it does.

The problem that is occurring was basically that a StringBuffer was being used to build various strings. Such a StringBuffer is usually treated as - well, as a buffer. So say the first string was 1024 characters long. The string buffer grows to hold it. (Worst case, a 1023 character buffer having a single character appended would cause a 2050 character buffer. Starting from a new StringBuffer() and building the buffer a character at a time would result in a 1150 character buffer.) The call to StringBuffer.toString() would create a new String that maintains this memory.

JDOM would then reset the StringBuffer length to 0, on the theory that the StringBuffer already contains the scratch space to deal with incoming data. This assumption is wrong - the StringBuffer allocates a new character array of the size it originally had. So the new 5 character string will wind up in a String object that maintains 1145 useless additional characters. Remembering that a Java character is two bytes, we can see that this can easily add up fast, especially with the way StringBuffers are expanded.

While assuming that reusing a StringBuffer saves time/memory is an implementation assumption, assuming that the size of StringBuffer and the size of the resulting String should not correlate is not really an implementation assumption - the docs seem to suggest that a brand new String is allocated that contains only the needed characters. (As opposed to a brand new String that contains the entire memory buffer of the StringBuffer.) This is not the case, and instead new String(stringBuffer.toString()) needs to be used to cause the String to only contain the requested characters.

I would clearly lay the blame on Sun for changing the implementation from what their own API docs dictate.

Here are a few examples:

• Opera 6.0
  I can't get my hands on a license without downloading the software :(
• RealPlayer
  The same thing. They obviously don't want us to read it unecessarily :)
• Flash
  You may not alter, merge, modify, adapt or translate the Software, or decompile, reverse engineer, disassemble, or otherwise reduce the Software to a human-perceivable form. That's more clear cut, and straight out said than in most licenses :)
  ...
  You may not modify the Software or create derivative works based upon the Software.
  ...
  You may not export the Software into any country prohibited by the United States Export Administration Act and the regulations thereunder.
  Which I guess means that Cubans, Lybians, Iranians, North Koreans, Syrians and some others can't use the software, but I may well be wrong as for which nationalities this is.
• Java
  Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software.
  ...
  You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI.
  ...
  You acknowledge that the Software may automatically download, install, and execute applets, applications, software extensions, and updated versions of the Software from Sun ("Software Updates")
• NVidia drivers
  ... SOFTWARE designed exclusively for use on the Linux operating system may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files).
  ...
  Customer may not reverse engineer, decompile, or disassemble the SOFTWARE, nor attempt in any other manner to obtain the source code.

As you see, the licenses limit the terms of use , modification and redistribuation of the software in ways which are to me not acceptable.

If you use Generics, your code will only run in 1.5 VMs. This was a marketing decision. Prototype versions of the Java compiler could previously use Generics and produce code for older virtual machines like the 1.1 VM.

Sun made this decision by itself without listening to its users and even censored its discussion. You can read about in the Generics message board:

http://forum.java.sun.com/thread.jsp?forum=316&thr ead=389987&tstart=0&trange=15

http://forum.java.sun.com/thread.jsp?forum=316&thr ead=321534&tstart=30&trange=15

If you use Generics, your code will only run in 1.5 VMs. This was a marketing decision. Prototype versions of the Java compiler could previously use Generics and produce code for older virtual machines like the 1.1 VM.

Sun made this decision by itself without listening to its users and even censored its discussion. You can read about in the Generics message board:

http://forum.java.sun.com/thread.jsp?forum=316&thr ead=389987&tstart=0&trange=15

http://forum.java.sun.com/thread.jsp?forum=316&thr ead=321534&tstart=30&trange=15

I don't use ints for my enumerations anymore after reading Josh Bloch's Effective Java. The type-safe enum pattern he recommends is fantastic.

I second that. For those interested, the pattern is described in chapter 5 of the book, "Replacing C Constructs," which is available as a free sample chapter.

The book is great, I highly recommend that you read it (the whole book, not just the sample chapters).

No bytecode changes are required. There have been "test" implementations out since Java 1.2. You can get the current 1.3 release at
http://developer.java.sun.com/developer/earlyAcc es s/adding_generics/

So, according to this guy, the advantages are: 1. XML property files

Guess the guy doesn't know about java.util.prefs.Preferences.

Okay, first off I'm not going to get into an argument about the cost of support etc, that has already been covered in an excellent post Maybe management has a point?.
Anyway some of the apps, and probably the ones that your most likely to use, like openssh, are already supported in Solaris 9 (see the Solaris Freeware section on the Sun site. Assuming that you after getting new machines, your probably going with Solaris 9 anyway.
You've mentioned that your management wants 24x7 support which means that they are probably going to be getting at least Gold level support from Sun anyway so these apps are already supported.

.NET is not a specification for a distributed application server, J2EE is. The advantages or disadvantages quoted in the article in regards to .NET exist whether you're building a simple console application, a desktop forms-based client, a simple web app or a massively distributed, multi-tier one.

I don't necessarily agree with the article itself in some points, but I can't see how the comparison is "unfair" because it's not being made to J2EE but the Java 'platform' (Sun's words, not mine) itself. C# vs. Java would be a completely different thing, but that would be based on the features of the language and the runtime library. J2EE is just an extension of that.

Solaris 9 includes Sun's Secure Shell server software which is their version of OpenSSH and uses the same configuration and setup as OpenSSH (with some minor modifications of course).

Never had to call them, but they have one hell of a good support website.

This is the kind of thing the PAM (Pluggable Authentication Modules) is meant to solve. I'm not sure how you would tie it in to your system yet, but some of these Java-centric links might help:

http://java.sun.com/products/jaas/
http://java.sun.com/j2se/1.4.1/docs/guide/security /jgss/tutorials/
http://java.sun.com/j2se/1.4.1/docs/guide/security /jaas/tutorials/
http://www.pramati.com/docstore/1270002/index.htm
http://www.oreillynet.com/pub/d/861

This is the kind of thing the PAM (Pluggable Authentication Modules) is meant to solve. I'm not sure how you would tie it in to your system yet, but some of these Java-centric links might help:

http://java.sun.com/products/jaas/
http://java.sun.com/j2se/1.4.1/docs/guide/security /jgss/tutorials/
http://java.sun.com/j2se/1.4.1/docs/guide/security /jaas/tutorials/
http://www.pramati.com/docstore/1270002/index.htm
http://www.oreillynet.com/pub/d/861

This is the kind of thing the PAM (Pluggable Authentication Modules) is meant to solve. I'm not sure how you would tie it in to your system yet, but some of these Java-centric links might help:

http://java.sun.com/products/jaas/
http://java.sun.com/j2se/1.4.1/docs/guide/security /jgss/tutorials/
http://java.sun.com/j2se/1.4.1/docs/guide/security /jaas/tutorials/
http://www.pramati.com/docstore/1270002/index.htm
http://www.oreillynet.com/pub/d/861

Why not invest in a shiny new 64-bit RISC UNIX workstation like the Sun Blade 2000? Despite the deceptively low clock frequency, the strong floating-point performance, top-quality operating system, huge memory and I/O bandwidth and serious graphics hardware make this a kick-ass machine. You'd also have a lot less porting headaches moving across to another 64-bit UNIX machine than down to a 32-bit one.

I agree, I first used Free software in 1987, at least Emacs, GCC, and a pile of BSD software. GCC was already considered one of the leading compilers out there, and the BSD software considered the way to go when it came to networking computers. It was at Carnegie Mellon, and they were just finishing up phasing out a TOPS network for a predominately BSD-licensed Unix network with a lot of home grown bells and whistles called Andrew.

In 1987, Sun Microsystems, the "young upstart" company of the data center, was shipping all of their Unix servers and workstations with SunOS, their own take on BSD Unix. They were beating established companies by strategic use of heavy cost cuts both in hardware and in software, partially by co-opting large amounts of Free Software code for their commercial ends (mostly BSD software).

By 1995, Fortune 500 companies were already seeing Linux in their companies. 1994 also was the year that the Free/Open/NetBSD codebases were truly freed of all the prior legal complications, increasing the freedom and popularity of those systems.

Free Software was certainly a very real and growing part of the American computer industry in the 80's and 90's, and the author does his readers a disservice by ignoring this.

Open Source? That was a marketing term invented in 1998, not particluarly relevant for a book that stops in 1995.

At any rate, the SPARC has for a long time been the least impressive of the 64-bit architectures.

Sun emphacises instruction bandwidth over multiple threads, rather than single-thread performance. Makes for bad benchmarks, but good overall throughput (same idea as IBM mainframes, which have slow CPUs, but giant I/O bandwidth that dwarfs any bus-based sytem).

The share price is, of course, lower than in the dot-com heyday when everybody's price was upped beyond any rationalism.

For one thing, I contract out to Sun, but from a purely technical PoV, the world would be a poorer place without Sun. Replace a 4xSF15k RAC Cluster with 128 Dell boxes running Linux? Please, not when I've got a business to run.

I love Linux, but above all, I love Unix. Sun do Unix very well, but build Unix boxes par excellence.

Your company has nothing going for it. NOTHING.

Nothing but a bunch of sweet military sales and service contracts. At $massive_workplace_machineroom, Suns outnumber Intel machines 2:1. A project recenty added a Sunfire 15000. I wouldn't say that Sun has nothing going for it.

You've got no marketing; In the media, your N-1 gets mentioned once for every 100 times that .NET mentioned.

That's the general media for the general public who play with Intels, not technical journals that are read by professional CTOs who run shops with > 10,000 users. Besides that, if the media mentions that dog poop tastes great 100 times for every time pizza is mentioned, does that make dog poop taste better than pizza?

Oh, by the way, make sure you do that resume in WORD, so that people can actually READ it.
<clue>
Not if you want a job in a Unix Shop.
</clue>
;)

In other news, doughnut mogul Krispy Kreme (NYSE: KKD) has placed a bid to purchase high-end computing giant Sun Microsystems (NASDAQ: SUNW) in order to secure a first-in-line place for the much anticipated ``blade'' form-factor servers with UltraSPARC IV CPUs to control production, shipping, and doughnut-glazing processes. Officials at Sun Microsystems could not be reached for comment, but a guy hauling garbage out of the rear door of building 7 of the San Diego campus was quoted as saying ``I really like them doughnuts. If they buy us, maybe we'll all get doughnuts for free at lunch. That'd rule.''.

Look out Dell and IBM, when you've got a million doughnut and coffee addicts for your clients, switching them to Unix and Java can't be far behind.

Speaking of buyouts and Sun's great technology...anyone remember where Sun's UltraSPARC chip came from in the first place? Sun bought it from Cray!

Sun just recently went a long way towards competitive price/performance with the introduction of Fire v210 and Fire v240 servers. If you configure an x86 server with similar capabilities, you'll find the Sun price to be very good. Hardware RAID and multiple gig-ethernet adapters isn't that common configuration in a sub-$3500 server.

Sun just recently went a long way towards competitive price/performance with the introduction of Fire v210 and Fire v240 servers. If you configure an x86 server with similar capabilities, you'll find the Sun price to be very good. Hardware RAID and multiple gig-ethernet adapters isn't that common configuration in a sub-$3500 server.

Network Computing 03-Q2

link to N1 N1

I am sure Sun is ahead in many technologies. for e.g N1.
However for a company to be successful/sustainable it has to produce/RnD technologies, that can be easily marketed. If a technology has no market, it will not last long.

That would be Infocom Cornerstone. The point was that since Infocom had experience in getting their games to run on many micro platforms, that could leverage that technology into making business products that also ran identically on many platforms. CS was not an internal tool--it was always intended as a product.

Unfortunately, they underestimated the knowledge of *business apps* that would be necessary to make this work, and the extra costs of expanding the company for this development eventually overwhelmed them. Today we know that the technology for a single development platform that is itself retargeted to host systems can be a product in and of itself. That might have been a way for Infocom to have avoided such a deep commitment to the business environment, although even that road has its share of wrecks.

a 64 node cluster of linux boxes at $2500 each is still a savings of $1.74 million over a
36 way Sunfire 15K

The Sun Fire 15K can maintain 43.2 GB/sec bandwidth connecting all the CPUs (see here). In a cluster, a small multiple of 0.128 GB/sec for Gigabit Ethernet is about all you'd get.

Regardless, you missed my point, because I explicitly mentioned Sun's low-end servers (2 CPUs). Even though these do cost more per node than the PCs, the cost difference is not nearly as dramatic as you were trying to make it out to be.

Also, don't forget that storage costs are basically constant between the systems. The only real variable is the cost for each CPU-RAM bundle. Hardly groundshaking.

a 64 node cluster of linux boxes at $2500 each is still a savings of $1.74 million over a
36 way Sunfire 15K.

An urban legend, according to Sun at least.

But embedding all your documentation in your source code is a very bad idea. That's the concept behind JavaDoc, and I have the bruises to show how badly this works in practice. Writers and programmers tripping over each other. Programmers that don't know how to write markup or even prose. Writers that have to branch the source code tree because the main tree is frozen. There's more, but I'm beginning the have post-traumatic flashes!

The solution I'd love to see is a tool that merges the embeded-comment docs with the full user docs. This would not only eliminate the problems of JavaDoc, it would flag inconstencies that happen when programmers don't keep the writers up to date.

A previous poster mentioned the MUSCLE project. It provides lots of open-source software for talking to smartcards, primarily for cryptographic applications.

MUSCLE works with JavaCards . With these it is relateively easy to write your own applets that run on the card and do whatever you want.

Lots of vendors supply JavaCard-compliant cards. For example, SchlumbergerSema, iButton, and Gemplus.

Even though Java is *supposed* to initialize to null, there is no real guarantee that this will actually happen.

wrong. The JavaTM Virtual Machine Specification - Second Edition says the following :

Every variable in a program must have a value before it is used:

• Each class variable, instance variable, and array component is initialized with a default value when it is created:
• For type byte, the default value is zero, that is, the value of (byte)0.
• For type short, the default value is zero, that is, the value of (short)0.
• For type int, the default value is zero, that is, 0.
• For type long, the default value is zero, that is, 0L.
• For type float, the default value is positive zero, that is, 0.0f.
• For type double, the default value is positive zero, that is, 0.0.
• For type char, the default value is the null character, that is, '\u0000'.
• For type boolean, the default value is false.
• For all reference types (2.4.6), the default value is null (2.3).
• Each method parameter (2.5) is initialized to the corresponding argument value provided by the invoker of the method.
• Each constructor parameter (2.5) is initialized to the corresponding argument value provided by an object creation expression or explicit constructor invocation.
• An exception-handler parameter (2.16.2) is initialized to the thrown object representing the exception (2.16.3).
• A local variable must be explicitly given a value, by either initialization or assignment, before it is used.

Well then.
Here:
http://www.sun.com/processors/

or

http://www-3.ibm.com/chips/products/powerpc/

Ok, and why would Sun or IBM want to produce an interleaving JIT engine? Sun is producing its own new breed of 64 bit super-duper UltraSPARC chips, and IBM has got its own Power and upcoming PowerPC 64 bit chips. Why would they bust themselves supporting a directly competitive chip? Unless Intel gets into the Java business, I don't see what's in it for the folks who make Java.

Also, although MS could have done this for Windows JVM, the courts have effectively put the handbrake on them doing so, due to the earlier ruling about Sun JVM.

This feature has been available for a while now, but using a dedicated link rather than IP. Sun call it Remote Shared Memory and it's mainly used for database clusters.

sun do provide a download manager: called sun download manager... didn't you get the memo? BTW i don't work for sun i work for Microsoft :^)

MSN web search just plain sucks. I was using a windows box the other day, typed "java api" into the msn search bar because it was there. I figured "that one's easy, msn should be able to handle it."

MSN returns University of Bristol ILRT - Redland RDF Application Framework

The correct answer, which is of course Java 2 Platform SE v1.4.1 and is #1 in google's results[1]. It is #8 in MSN. That was the last time I will ever bother with msn search.

Erik

[1] Well, google gives you 1.3.1, which is pretty much the same thing. That is probably google's biggest fault. When new content comes out, google is only as fast to adapt as the rest of the web is when it comes to updating their links.

Sun still makes such a beastie: here. I've used an older model. It looks very similar to running VMware, you see the whole POST and boot screens in a window. Performance was pretty good, the only problem is that the HD is shared, which brought the machine down somewhat.

Anybody like to cite interesting portions of the EULA of those systems?

Well, you can read the Solaris license here.
It reads like a typical commercial EULA and has some parts in common with the Win XP EULA. However, it does appear less scandalous, overall, relative to Win XP's.

For example, Sun's tends to discourage large-scale commercial use of its no-cost offerings by limiting bundled features rather than imposing artificial connection limits. There is also a single-CPU limit to the no-cost version of Solaris 9 (eight CPUs for
Solaris 8). Regardless, any of these limitations in Solaris tend to err on the side of generosity and are adequate for small businesses, and they bundle in their media kits a lot of GNU tools, lots of Sun ONE software, StarOffice, real OpenGL, an MPEG viewer/recorder, and Oracle 9i (!), among other things, with no time-bombs. They also bundle BEA WebLogic and the Sun compiler suite, but those are only 60-day trials.

As far as I can tell, the only thing that smells of Microsoft's automatic updates in Sun's EULA appears to be limited to the Java WebStart installations they offer for some software. Additionally, I didn't see anything related to collecting information, personal or otherwise. Sun typically has good privacy policies regarding customer data.

The Solaris EULA is pretty typical (denouncing liability, etc), but is noticabliy better than the one for Win XP. This probably stems from the fact that Sun is generally more reasonable towards its customers.

Don't forget: IANAL.

I agree with the safer programming languages (such as Java or OCaml). I agree with the better tools. I agree with dynamic checks, stack guards and whatever. Let's add for good measure static analysis.

But why UML? UML is a modeling language. What the above solutions are trying to catch are implementation issues.

If you're trying to catch issues at the design level, you need much more than a modeling language in which to write vague descriptions. You need tools that can show that your implementation corresponds to the design. You need tools that are capable of dealing with issues such as interlocking threads.

Solaris (Original 1970's version)

How can that be when Sun Microsystems was founded in 1982?

So go with Sun or Linux for networking gear. IMNSHO Solaris and IPFilter makes the best firewall anyway. Linux has good support in other areas such as 802.1Q spanning tree bridging and other neat tidbits. If the technology is open there is no where to hide.

Computer Science seems to be the only profession in which we still have access to the people that helped start it. I've always enjoyed that. Take Whitfield Diffie, for example.

right once, run anywhere, what Java tried, and never quite achieved :(

Here's the Sun Java Card site:
http://java.sun.com/products/javacard/
Lots of good info there, toolkit, spec, etc. The Java Card book from Sun Press is also pretty good.

The card runs it's own stripped down Java VM. The API is different, but the code is really interpreted on the card. Sun has a FAQ list.

The new mark of the beast?

Dear reader the GNOME armageddon has started,

First of all I want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it.

Belive me it took me a couple of days writing this text in a foreign language.

Even if you don't care at all for GNOME, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

On the following lines i'm trying to give you a little insight of the GNOME [gnome.org] community. the things that are going on in the back, the information that could be worth talking and thinking about.

Many of us like the GNOME desktop and some of us were following it since the beginning. GNOME is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of *NIX, only to name some of its advantages.

Unfortunately these advantages changed with the recently new released version of GNOME. The core development team somehow got the idea of targeting GNOME to a complete different direction of users, the so called corporate desktop user.

In other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting GNOME on their computers.

Having this new target in mind, the core development team mostly under contract by companies like RedHat, [redhat.com] Ximian [ximian.com] and Sun [sun.com] decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. So far the idea of a clean easy to use desktop is honourable.

Some of the new ideas, features and implementations such as gconf, [gnome.org] an evil Windows Registry-like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that GNOME leads and the attitude of the core development team made a lot of users really unhappy. These are only a couple of examples and the list can easily be expanded but for now this is enough. Now let me try to get deeper into these aspects.

You may imagine that users got really frustrated, [osnews.com] because their beloved GNOME desktop matured into something they didn't want. During the time, the frustration of a not less amount of people increased. more, [gnome.org] more [gnome.org] and more [gnome.org] emails arrived on the GNOME mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

But the core development team of GNOME don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. The reply they give is mostly the same -- users should either go and 'file a bug' at BugZilla [gnome.org] or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback [gnome.org] isn't appreciated.

If you gonna think about this for a minute then things gonna harden tha

Dear reader the GNOME armageddon has started,

First of all I want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it.

Belive me it took me a couple of days writing this text in a foreign language.

Even if you don't care at all for GNOME, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

On the following lines i'm trying to give you a little insight of the GNOME community. the things that are going on in the back, the information that could be worth talking and thinking about.

Many of us like the GNOME desktop and some of us were following it since the beginning. GNOME is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of *NIX, only to name some of its advantages.

Unfortunately these advantages changed with the recently new released version of GNOME. The core development team somehow got the idea of targeting GNOME to a complete different direction of users, the so called corporate desktop user.

In other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting GNOME on their computers.

Having this new target in mind, the core development team mostly under contract by companies like RedHat, Ximian and Sun decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. So far the idea of a clean easy to use desktop is honourable.

Some of the new ideas, features and implementations such as gconf, an evil Windows Registry-like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that GNOME leads and the attitude of the core development team made a lot of users really unhappy. These are only a couple of examples and the list can easily be expanded but for now this is enough. Now let me try to get deeper into these aspects.

You may imagine that users got really frustrated, because their beloved GNOME desktop matured into something they didn't want. During the time, the frustration of a not less amount of people increased. more, more and more emails arrived on the GNOME mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

But the core development team of GNOME don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. The reply they give is mostly the same -- users should either go and 'file a bug' at BugZilla or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback isn't appreciated.

If you gonna think about this for a minute then things gonna harden that they are directing into the commercial area. The core development team actually don't care for the complaining home user -- it's more