Slashdot Mirror

Perhaps I'm biased (I used to work at Thinking Machines) but pany more problems are parallel than you'd think at first, if you have a sufficiently fine-grained parallelism.

"even a compiler can benefit from multiple threads, though current compilers don't do it"

Actually, Parallel Make (i.e. gmake -j, http://developers.sun.com/solaris/articles/paralle l_make.html, or pmake, http://www.llnl.gov/icc/lc/DEG/pmake/pmake.html) can make project builds significantly faster.

Beyond that, any time that you're rendering graphics, or sorting data, or in fact using any large volume of data, or doing more than one thing at a time, multiple processors could help. This is why most graphics cards are highly parallel, and why all high-end databases run well on many processors. Heck, even booting a computer benefits from parallel execution. Of course, it may be hard work expressing the dependencies between processes properly (e.g. parallel makes can break makefiles that have implicit dependencies in instruction order that work serially, but which break when parallelized), but if the problem is worth thinking harder about, it can probably be parallelized.

does anyone actually make a "server" that doesn't have SMP?

Yes

Good to see amd following Sun's lead

http://blogs.sun.com/roller/page/jonathan/20040910

x86 Unix systems have largely been also-rans...

Linux is a also-ran? What about Solaris on x86?

• Java 1.5 API
• Dive into Python
• MSDN

I guess the answer is "it depends". ;-)

If I'm doing anything half-ways complex in web-to-db, yes I do want OO. I'll choose OO DB access in the form of Hibernate, JDBC, JBoss and EJBs and XDoclet. And I'll build my UI with an MVC-based JSP/Servlet framework, usually home-grown, but maybe using JavaServer Faces or Struts.

In my opinion, this kind of OO sophistication makes building even half-ways complex projects better.

Sam

Perhaps one should keep in mind that Linux bigots are as entrenched with the OS of their choice as are Apple's OSX zealots. Ne'er shall the twain meet, it was once said, and I think that this will be another case of more of the same.

One should read Dvorak through the years, and I mean back to the 1980's when he was a columnist for Macworld and other magazines. He can be a blind squirrel that stumbles upon a nut, and he can be as infuriating as any writer who's ever analyzed computing. In other words, when his moth opens and shuts, gospel verses are not written.

First of all, one has to wonder if Apple is going to sell it's computers at the same commodity prices that Dell, HP and Lenovo/IBM do, or are they going to command a higher price than similarly powered Wintel or Linux machines.

The history of Apple suggests that they will try to leverage higher margins from their hardware than their competition, which was fine as long as they had a performance advantage over the rest of the pack. Now that they will be operating on the same CPU hardware, it is difficult to see them having a huge leg up. So where is the compelling reason to switch away from Linux to the BSD kernel and Apple?

That said, Apple is only doing what Sun did with the Opteron-based machines (Sun: Extreme Performance) with an eye more towards the workstation market. Anyway, if Sun's example serves as a guide, it hardly killed Linux.

It seems to have become fashionable to predict the death of Linux. Perhaps it will go by the wayside, but that won't be anytime soon. If anything, Apple itself should provide a writer lik eDvorak with that insight. Perhaps John is trying to join the Dynamic Duo that are Laura Didio and Rob Enderle?

Dunno... why not ask these guys?

There's already a chip which can directly execute java, if that's what you mean, check out the picojava chip.

An exit strategy like IBM in the 90's? Companies go through good times and bad times and Sun will turn themselves around just as IBM did.

For those too young to remember the 90's, it was a time when IBM was getting beat up by RISC UNIX boxes from HP and Sun and mainframes were on the way out.

If Sun wanted to get out of the server market then how do you explain spending $500 million on Solaris 10? Why invest in an all new line using it's own developed Sun hardware based on AMD Opteron chips? Or the new SPARC Throughput Computing chips (http://www.sun.com/processors/throughput/)?

Why invest in an all new line using it's own developed Sun hardware based on AMD Opteron chips? Or the new SPARC Throughput Computing chips (http://www.sun.com/processors/throughput/)?

Why scrap years of development work on the UltraSparc V and Gemeni chips?

The whole "throughput computing chip" is just Sun going along with industry trends. Multi-core chips were in the works at Sun, Intel, IBM, and AMD long before Sun started pushing "throughput computing".

I won't make any bold predictions about Sun, but it'll be interesting to see where things go over the years. Focus on original Opteron designs and the resurrection of Solaris x86 make for interesting speculation with regard to transitions though.

I don't believe that the patent you're referencing would cause any problems with file format interoperability. What is described in the patent is a method of tagging source code to specify that a certain property of an object should be serialized in a specific way to correspond to a desired XML schema. Microsoft, in their examples, show C# source code in which they use attributes (the term C# uses for metadata) applied to the properties of a given class to specify the name of the XML tags to which the value of the property will be written when an object of that type is serialized.

In a nutshell, Microsoft's method gives an easy way for programmers to declaratively specify how an object should be serialized to/deserialized from an XML document in a given schema. While I do think that the method they're describing would make things a lot easier for the most common usage, I think it's a bit limited, as I don't see any way to specify multiple possible formats to use. I suppose an adapter class could be used to encapsulate a given object and specify how it could be [de]serialized, or the serialized object could be transformed via XSL to the other desired format(s), but at that point, it seems like it would be only marginally easier than doing it by hand, unless they provided an automated manner of generating such code for you.

Yes, it's clever. Would I use it? Absolutely. Do I think it's patent-worthy. No way. The only difference I see between this and other methods of doing similar things is that they are using runtime-accessible metadata to specify mappings, and I can't think of a reason that would make a significant difference. A preprocessor that simply looked at comment tags in the source code for each property and generated a class to serialize the object accordingly would be just as functional, in my admittedly-quick estimation. It might not be quite as nicely integrated, as Microsoft's XmlSerializer class is designed to operate based on the metadata present, but I hardly think that small difference makes this invention worthy of a patent. It may be clever, but I don't consider it non-obvious.

In any event, I suspect that it would not be difficult to find prior art to at least partially deflect the use of this patent. There are plenty of systems that generate output based on special tags in source code. JavaDoc is a notable and widely-used example. Object serialization has been widely used for decades, so that's not new either. Serializing objects to XML isn't new, as Microsoft cites the SOAP protocol in this very patent. In the very narrow case of tagging source code with instructions on how to serialize the object, specifically as XML, and the ability to specify somewhat complex mappings declaratively, this patent might be applicable, but I don't think it would apply in any other case.

Then again, IANAL. IAAP(rogrammer).

An exit strategy like IBM in the 90's? Companies go through good times and bad times and Sun will turn themselves around just as IBM did.

For those too young to remember the 90's, it was a time when IBM was getting beat up by RISC UNIX boxes from HP and Sun and mainframes were on the way out.

If Sun wanted to get out of the server market then how do you explain spending $500 million on Solaris 10? Why invest in an all new line using it's own developed Sun hardware based on AMD Opteron chips? Or the new SPARC Throughput Computing chips (http://www.sun.com/processors/throughput/)?

Here's two examples of prior art.

Here's two examples of prior art.

> Sure, OpenOffice is great, but commercial enterprises will stick with commercial solutions for which there is support.

There is a commercial version of OpenOffice with support. It's called StarOffice.

http://www.sun.com/staroffice/

The one thing that these others have in common, that MS Office lacks, is support for the OpenDocument DTD. OpenOffice.org v2 will use OpenDocument as its main format.

Note that many of the articles linked to by the original post express skepticism about how open MS' XML will actually be. Recall that in the last year, and even in the last weeks, MS has sought patents from the USPTO for XML and XML related functions. And is even now pushing to get legislation in Europe to make those same patents valid in the EU. That smacks more of a PR stunt rather than an actual opening up.

Furthermore, since the articles don't mention the current leaders in productivity tools with XML-based formats (i.e. OpenOffice.org or StarOffice), that looks all the more like warmed over press release being passed of onto the public as news. What's next? A press release about MS suddenly supporting PDF export like in OOo or StarOffice?

"Java specification" was a simple shorthand for the specification of the virtual machine, language and libraries. No doubt the first two are rather adequately implemented by GCJ and other free software Java projects, but the last is a vast sprawling mess so GNU Classpath has not managed to completely implement it yet.

Yes the API is actually specified. Look over here.

But isn't that also just the beauty of it ?

But isn't that also just the beauty of it ?

http://www.sun.com/software/solaris/index.jsp

Free. Somewhat less costly than Windows 2003. Sun has adopted the RedHat business model with regards to sales of Solaris, which is Unix: You get the operating system for free. You have to buy support if you need it.

Oh, and it runs on consumer hardware, so hardware costs versus Windows 2k3 are a non-issue.

*some* unixes are expensive. Especially if you're looking at a mainframe or multi-user environment (such as multics). For a unix-based web or mailserver, however, you don't need the kind of muscle you see in a mainframe, and you can get away with spending an awful lot less.

No argument that Linux is a whole lot cheaper than either option, and for my own servers I run Linux. That's a price-point thing, however, coupled with a need. I simply don't need a 64-processor Alpha with 512GB of RAM and an 100TB RAID array.... My webserver is doing quite well on an Athlon64 3200+/1GB and I'm nowhere near filling a 120GB hard drive. Yet.

C++ long => 32 Bit
Java long => 64 Bit

So you are comparing Apples with Melons ;)

Using my mighty +1 Karma Bonus Power...

Can somebody please mod the parent up?? The grandparent poster is apparently too clueless to create Java vs. C++ benchmarks.

Java primitives:

http://java.sun.com/docs/books/tutorial/java/nutsa ndbolts/datatypes.html

C primitives:

http://www.phim.unibe.ch/comp_doc/c_manual/C/CONCE PT/data_types.html

Let's see the benchmark with either int vs. long or long vs., er, long long (or __int64 or whatever).

And then, can't we all just get along? /me ducks

Considering that the M$ environment is under constant pressure from various threats I would like to call the selection of that environment risky, and almost stupid. By selecting other environments you would be running the risk of being more dependent on a few persons with that particular competence. On the other hand the number of persons competent enough to cause trouble will also decrease significantly.

If I was involved I would have selected OpenVMS , now owned by HP as operating system for the servers running either MySQL or Oracle as a database and developing the software in Ada or (horrendous thought) Pascal or maybe Java.

---
OpenVMS - The OS with longer uptimes than Microsoft support policies

I work for a consulting company. We go where the money is. Clients want something on Windows, we write for Windows. Clients want something on Linux, we write for Linux. Client want something on Solaris, we write for Solaris. .NET/Mono is kind of nice because it allows anything to run anywhere (at least, in theory. Practice has some holes in it, but it will get better).

Sounds like you haven't heard of this.

Of course, why not? Actually Sun already seem to be working on Swing-Avalon integration for the next Java release: sun's article

Kinda offtopic....
There's a known bug in hotspot's amd64 version that makes eclipse crash. Disabling the jit compiler worked for me, although with a performace hit. I've been waiting for Sun to fix it for a while already, it's pretty frustrating (so please vote for the bug).

I think those were exactly those of Sun... See http://blogs.sun.com/roller/page/jonathan/20050515 .

Not true. Novell eDirectory has been proven to scale to at least 1 billion objects in 2000. Administration involved breaking the users into 4 groups of 250,000 each and replicating them between the servers. With Novell's management tools, this is trival.

Isn't Sun's Directory Server based off this as well? I thought they'd acquired all the old Netscape stuff back in the Netscape/iPlanet days.

Correct link for self:
http://research.sun.com/self/

First, Microsoft have a longer history of developing virtual machines for programming languages (in Visual Basic).

Java owes a lot (beyond even that) to MS Research. Don't judge a company by its Operating Systems division..

Finally, you want to claim Microsoft Research are credit-stealing whores over the Java community? Where do you think the idea of objects supporting multiple interfaces for the purposes of inclusion polymorphism (seperated from the nightmare of multiple inheritance that plagues/criples OO-languages) comes from?

There is no such animal. There is such a thing as object/relational technology. Some common examples of this are hibernate and EJB. These are not alternatives to relational databases. Rather, they serve to persist objects to and from relational databases. They are built on top of relational databases. They do not replace relational databases.

Alternatives to relational databases are LDAP databases such as openLDAP, OLAP databases such as Hyperion, and XML databases like exist. None of these technologies will replace the relational database. It's more about using the right tool for the job. Relational databases work best with operational data. OLAP works best for planning and forecasting. Think of LDAP as a distributed hierarchical database.

Various relational database products have proprietary extensions that may confuse you into thinking that they are alternatives to relational databases. For example, there are extensions to SQL Server that make them seem to act more like OLAP or XML databases.

First of all, Java on the client-side tries to solve a completely different set of problems than AJAX does. Java's goal is to provide a platform independent way of running rich applications. It provides its own libraries, UI toolkit(s), client-side business logic, and is self contained inside a virtual machine. AJAX on the other hand is just a cleaver way for browsers to provide asynchronous communication with servers. It provides nothing that JavaScript can't do already, it just spares you from having to submit a form every time you need to push/pull data.

Now, as for providing an easier method of deploying rich applications, take a look at Java Web Start. Applets are frankly awful; they're slow to load, have limited functionality, and sit inside a browser window (which is NOT where a desktop app belongs). Web Start solves this by providing an extremely simple deployment and update model, while maintaining the user experience only a rich app can.

The "zones" mentioned in the article are nothing to do with Linux, and everything to do with Solaris.

-Stephen

Perhaps if Sun could hack Swing's native look and feel capabilities to be a little more pervasive, we would have a better solution.

Your wish is granted:
http://java.sun.com/developer/technicalArticles/J2 SE/Desktop/mustang/index.html

SunFire v20z or v40z Servers.
http://www.sun.com/servers/entry/v20z/index.jsp
http://www.sun.com/servers/entry/v40z/index.jsp
They're the entry-level servers from Sun, so they have great support. They're on the WHQL List, so Windows XP, 2003 Server and the forthcoming 64-bit versions all run fine.
They also run Linux quite well, and as if that wasn't enough, they all scream along with Solaris installed.
The v20z is a 1 or 2 way Opteron box, in a 1RU case. the v40z is a two or for CPU box that is available with single or dual core Opterons.
Plus, they're one of the cheapest, if not the cheapest, Tier 1 Opteron servers on the market.

SunFire v20z or v40z Servers.
http://www.sun.com/servers/entry/v20z/index.jsp
http://www.sun.com/servers/entry/v40z/index.jsp
They're the entry-level servers from Sun, so they have great support. They're on the WHQL List, so Windows XP, 2003 Server and the forthcoming 64-bit versions all run fine.
They also run Linux quite well, and as if that wasn't enough, they all scream along with Solaris installed.
The v20z is a 1 or 2 way Opteron box, in a 1RU case. the v40z is a two or for CPU box that is available with single or dual core Opterons.
Plus, they're one of the cheapest, if not the cheapest, Tier 1 Opteron servers on the market.

While Swing claims to be cross platform, it makes a lot of assumptions that work for Windows and don't work for X11.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6193066

Also, Sun seems to actively work against Linux on the desktop by introducing these kinds of "features" which substantially slow down Swing applications on newer Linux kernels.

For those wanting to experiment with some of the graphics option in 5.0 here is the page.

I think the Java documentation kinda disagrees with you on that matter.

What I'm trying to get at is that even design patterns that are commonly referred to as "J2EE design patterns" work as designs outside of J2EE. Nothing stops me from having Data Access Objects in Objective-C. I have them. When I hear someone say something like "J2EE Design Patterns", I think "oh, goody, you read a book...". Here is a diagram of design patterns from a Sun article. Every single design concept listed could just as easily apply to a language that is not Java. Can you think of a design pattern that can't be generalized to some object-oriented language other than Java? I can't.

I wouldn't fault you for leaving off MDBs. But why do you think of EJBs as nothing more than the javax.ejb API? Those are some of the basic building blocks of J2EE architecture, and I'd want a J2EE architect to at least be able to tell me what an entity bean is good for, a session bean (stateless or stateful). I mean, what is a session bean anyway (from a logical standpoint) and why would I use it? I would be scared of someone who could recite the entire Java API for me, but I do want to hear how I can build something from the building blocks. I feel that's a fair question.

I agree that it's a fair question, but... I do think of EJBs as things that implement the APIs in javax.ejb.*. Why? Because I'm a technical person, and that's the technical definition. I could go a step further and specify subclasses of EnterpriseBean. Your J2EE server and it's EJB containers aren't going to do much 'bean-like' stuff with any class that doesn't implement that, are they?!

You could take the question to a more abstract level and ask what the point of EJBs are, or even Java Beans more generally, but... that's a rather technically different question. If you are looking for someone to say "Session, Message and Entity", then you are basically looking for someone to list the interfaces in javax.ejb.*, if you realize it or not. Ok, maybe just the interfaces that implement EnterpriseBean, but still... what is a session bean good for and why would you choose stateless vs. stateful, now, that's a more interesting question, and one which is revealing to ask a candidate.

I left out MDBs because I haven't needed to use them much, if at all, which is part of why I'm not terribly comfortable claiming I'm "expert"... this stuff is complex, and plenty of reasonably-sized applications don't benefit immediately from portions of it, which is why you're seeing plenty of JSP folks but few "J2EE experts". Your needs are specialized, and you have to do a lot of searching to get the right candidate as a result.

I want people who can hit the ground running.

Yea, and I want a gig that pays well enough to allow me to break into the SF Bay Area housing market, preferably without having to commute from the north bay to the south bay. Good luck to us both.

There is a somewhat hilarious description of how the Java developers dealt with all this: http://java.sun.com/developer/technicalArticles/In tl/Supplementary/ [sun.com].

Wow, that solution is just screaming efficiency. ;-)

Any bets when we'll meet a bunch of sentients from another galaxy and break past thirty-two bits per code point?

There is a somewhat hilarious description of how the Java developers dealt with all this: http://java.sun.com/developer/technicalArticles/In tl/Supplementary/.

Transhumanism/singularity will probably whittle down the whole thing to the bit of course!

Well, there's always the Sun-Microsoft joint proposal for a meta-protocol that allows the access platform to select between all of these SSO options. Of course, that just means everyone needs to support everything and results in far more complexity than simply agree to use the standards that already solved the problem nicely, but hey, nobody ever accused Sun or Microsoft of doing the reasonable thing.

It looks that what they are trying to patent is a mail address object that calls another server to see if the mail address is known.

So if, for example, you had a mail address object that did a call to your company LDAP server to implement a method isCompanyMailAddress() you might infringe on their patent.

It is a sad thing. Even though there might be no prior art published, this is obvious to a trained software developer. How else would you implement the isCompanyMailAddress() example above?

While the newer collections are not synchronized, you can turn a collection into a synchronized collection easily using java.util.Collections.synchronizedXXX()

OK, so I picked the wrong example. Java's containers mostly aren't threadsafe, but at least they tell you in the docs how it will behave when using multiple threads (which is usually something like "Note that this implementation is not synchronized. If multiple threads access a list concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally."). But the threading support in Java is still very nice, especially with the new java.util.concurrent package in Java 1.5.

While the newer collections are not synchronized, you can turn a collection into a synchronized collection easily using java.util.Collections.synchronizedXXX()

OK, so I picked the wrong example. Java's containers mostly aren't threadsafe, but at least they tell you in the docs how it will behave when using multiple threads (which is usually something like "Note that this implementation is not synchronized. If multiple threads access a list concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally."). But the threading support in Java is still very nice, especially with the new java.util.concurrent package in Java 1.5.

The concern was that OO.o was using proprietary extensions to Java which aren't well documented and are exclusive to Sun.

Ahh, which might those be? I *love* when non-Java developers try to talk OSS and Java.

The sun.* packages. You know, the ones that are intended to be used only internally, and aren't well-documented. You can review Sun's policy towards them at http://java.sun.com/products/jdk/faq/faq-sun-packa ges.html

Ok, please clarify... What does that has to do with what I said? I *can't* use sun's java. Not the virtual machine, not the compiler, and not the classes. The licencing forbids me to. The licencing forbids *you* to send it to me, even bundled with you own application, regardless of where you are. Yes, the licence allows you to bundle java with your own apps, but forbids from distributing it to *me*. From the same document you pointed,

D.
5. Export Control. As further described at
http://www.sun.com/its, you agree to comply with the
U.S. export controls and trade laws of other countries
that apply to Technology and Modifications.

Got it? It is not free.

11. Export Regulations.
All Software, documents, technical data, and any other materials delivered under this Agreement are subject to U.S. export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with these laws and regulations and acknowledge that you have the responsibility to obtain any licenses to export, re-export, or import as may be required after delivery to you.