Slashdot Mirror

The network is the computer. Java Ubiquitous computing. Smart toasters.

https://www.javaworld.com/arti...

Dallas Semiconductor tried.

https://www.javaworld.com/arti...

20 years ago.

I still have an ibutton on my keychain, but it never got used that much that I would hope.

We've rediscovered java rings I see...
https://www.javaworld.com/arti...

I've been a programmer in everything from 6502 assembly language to Java with struts and Ajax. I spent 3 years cleaning almost non-functional programming delivered by young, ignorant IBM college grads into something elegant before I became a project manager and then team lead over 15 developers. And I saved my ass off the entire time. Because I knew my time would come.

And it did- in a company that had never had layoffs before after it tried (against a lot of senior programmers advice) to convert to all six SAP packages at the same time and failed catastrophically (because a lot of young people said it could be done if we just ran at it fast enough and "believed!" it would work. I know so many people who had nice houses, kids in college, and good skill sets who never got programmer jobs again.

I'd seen it before after Y2K as well. Mass layoffs. 40 and under got jobs easily- 55 and over left the field. Even tho they had more knowledge than us younger folks.

Age discrimination among programmers is rife and regularly reported in the industry. It's rife in other fields too. But IT is the worst. 80% of people leave the field by age 40. It is not really a career you can count on.

Anyway...Good luck. I'll leave you these to digest.

Time for bed, I'm retired and I'm helping a young whippersnapper programmer friend of a friend who hasn't got a clue how to remove wet sheetrock and insulation from his flooded house. (It's dead simple- you can find it easily without even requiring google fu- he's just young and lacks confidence and much worse physical condition than I am- but I ski 3-4 weeks a year and exercise regularly). After that, I'll be helping a couple other folks with their flooded houses. Then maybe I'll do something longer term thru a formal group like RC (I don't trust their legal document tho) or Barkley (a united way group with a much friendlier legal document.

http://www.businessinsider.com...

He told us, "Sooner or later, your corporation will get rid of you, not because youâ(TM)re old, but because they are concerned what kind of face they put in front of their clients," he said.

"They want to be thought of as youthful, to look progressive, and they won't put a guy out there who is 60 years old. I know it's stupid, but you would be surprised how many people think like that."

"Whatâ(TM)s happening in the tech sector is a general trend toward youth," Dermody tells us.

Facebook, LinkedIn and Salesforce have young work forces. Google's median age based on data from 2014 is the ripe old age of 30. (See chart on median employee age from salary analyst PayScale, below).

"At some Silicon Valley companies, the top executives are explicit in their preference for workers under 35," she says.

https://www.javaworld.com/arti...
A late-1990s study by the National Science Foundation and Census Bureau found that only 19 percent of computer science graduates are still working in programming once they're in their early 40s. This suggests serious attrition among what should be the dominant labor pool in IT.

http://www.scpr.org/programs/a...
But in tech, people tell a different story. Programmers in their 40s leave their graduation years off resumes so as not to tip the employer off to their age. Engineers with 15 years of experience canâ(TM)t get a response from potential employers. Hiring managers at companies in Silicon Valley have spoken openly about preferring younger candidates because they will work longer hours for less money and usually don't have certain family or home obligations that older employees with families might have.

Part of the problem could be that the indus

Sigh. Make me work for a living.

It's always best to do one's own research, as it helps to avoid being fed cherry-picked reality. But, if you insist, here's some stuff I cherry-picked from Google.

The first one is very interesting because it dates all the way back to 1998, when JIT Java was fairly new, but the relative timings are quite comparable, given similar constraints:

http://www.javaworld.com/artic...

Much more recently:

https://benchmarksgame.alioth....

Your Mileage can Definitely Vary, however. I found benchmarks indicating that the "Java" (Don't call it Java or Oracle's lawyers will swarm you - it's Dalvik) on Android is significantly slower.

Some of my own impressions of relative performance are dated, I think. The Gnu compilers have added some very aggressive optimizations in recent years.

The Debian benchmark seems to indicate that raw C (gcc) is on average about twice as fast as either Java or C++. My suspicion is that a lot of modern C++ coding is not only using virtual methods, but taking advantage of string and dynamic memory managers that were not part of the original C++. There is a cost for using pre-packaged solutions, but in an era where machine time is cheap but programmers still cost $10K a year even in India, shops generally favor "Git 'R Dun" over hyper-optimal performance.

I've always been partial to the definition (I think by Alan Kay) that Java is "C++ without the mace and knives". I find Java to be less stressful because I don't obsess about what raw machine code will be produced, and the rigorous compile-time checking means that I can devote more time to worrying about the high-level design. However, a JVM is a greedy thing, so there are still times when I prefer C or C++. Then again, there are times when I prefer Python, Perl, or PHP.

In the end, it's less about language and more about intelligent design. I once encounted a perfectly horrible C++ program that used a very sparse array with a widely-distributed working set. Virtually every computation triggered a page fault; I've seen cases where "efficient" sorts and searches were totally unsuitable because the data was in worst-case form. For performance, the choice of language is less important than how it's used. And above all, measure instead of simply "knowing".

The reason why I take such umbrage against the "common knowledge" that Java is slow is because that knowledge is largely based on old-time interpreter implementations, where on average, an interpreted instruction would take about 10 times longer than its native-code equivalent because a lot of the code being executed wasn't the app, it was the interpreter. JIT-compiled code has no interpreter overhead, so it's primarily limited by the optimization capabilities of the JIT compiler and the tuning settings (small code, slow code vs. fat code, fast code, for example). For lightweight apps, the overhead of launching a JVM, to say nothing of the overhead of doing the JIT compiling is obviously not worth it. For something that launches, runs 24x7 and doesn't restart for weeks at a time, those considerations are fairly trivial - assuming there's enough RAM. If you have dynamic load-balanced re-compiling, then the overall performance is likely to be better than for a static-compiled app.

But juggling instructions tends to only give you about an extra 10% boost, and on the whole, I prefer enough headroom for that not to matter. What makes or breaks most systems is the app itself. I knew of one where a single switch setting could single-handedly bring an IBM mainframe to its knees if set improperly. No compiler in the world could have helped that.

Interfaces are a good thing.

Multiple inheritance is a kludge that leads to dangerous complexification. Composition is a much neater and more maintainable approach.

Microsoft got sued on the trademark. They called their VM Java, and they were actually pretty crappy at it.

http://www.javaworld.com/artic...

They had a point, people were hating Java at that time because Microsoft was saying they had a proper implementation and it was buggy crap, making people think that Java was buggy crap. That's a pretty solid lawsuit. They are using our trademark and making us look bad.

And indeed because Java demands ever more resources just to let you do what you want to do.

Im still not sure if this continual FUD is spread by old people who haven't been able to keep up with the times or by newbies desperate to blame anybody but themselves for their poor code. We already know that by and large your assertion is not true, plenty of resources already disprove it.

Actually in that lawsuit, Sun brought up the emails uncovered in the DoJ investigation where a Microsoft exec (can't recall the name) specifically called out Java as a threat to Windows (the same email mentioned Netscape Navigator as a threat to Windows, and for the same reason.) This is why they won the lawsuit.

Sun did indeed try for copyright infringement, but that portion of the lawsuit was shot down, and the only one that stood was the violation of anti-compete laws.

Sun has argued in court that Microsoft viewed Java's "Write Once, Run Anywhere" capability as a threat to Windows, because Java reduced the incentive for software developers to write programs for the Microsoft operating system.

According to Sun, the version of Java distributed by Microsoft worked better with its Windows software. Such a move threatened Java's ability to provide a cross-platform development environment, Sun's lawyers said.

Microsoft has vehemently denied any wrongdoing and has maintained that it stuck to the letter of its licensing agreement with Sun. Any changes Microsoft made to Java merely allowed developers to take advantage of features specific to Windows, the company has argued.

The case has been watched closely, and Microsoft's dealings with Java were cited by U.S. District Court Judge Thomas Penfield Jackson in the U.S. government's antitrust case against Microsoft as evidence of the software giant's anticompetitive behavior.

Tom Burt, Microsoft's deputy general counsel for litigation, portrayed Tuesday's settlement as a positive outcome for Microsoft.

"Microsoft is very pleased with the successful conclusion of this litigation," Burt said in a statement. The agreement confirms Microsoft's ability to independently develop technology to compete with Sun's products, the company said.

Sun scored a victory in the case in November 1998, when Judge Ronald Whyte of the U.S. District Court in San Jose, California, ruled that Sun was likely to win its case based on the merits and issued a preliminary injunction in Sun's favor. The injunction forced Microsoft to modify the Java technology it had distributed in its operating system, Web browser, and development tools so that it passed Sun's tests.

A U.S. Appeals Court overturned the injunction the following year, questioning the grounds on which Whyte had based his decision. Whyte reinstated the injunction, but based his order on California's unfair competition statutes rather than on copyright law, as Sun had requested. The ruling was seen as a partial victory for Sun.

http://www.javaworld.com/artic...

And the difference between this and the MS Java case is...what exactly? Because the only difference I can see is Google pulled a name out of their ass, which means all MSFT had to do was call it "MS Coffee" and it would have all been golden.

The difference is trademarks. Microsoft called their unauthorized implementation Java(tm). You don't get to do that without passing Sun's certification process. MS never implemented the entire Java specification. They modified some parts and left others out (embrace and extend). So someone who wrote a Java program against the Sun JDK and brought it to the MS platform would potentially see it fail out of the box. Due to these issues Sun used it's trademark to sue for relief from having its brand damaged.

This is different from unauthorized implementations that did not claim to be official Java products. Indeed, prior to Sun open sourcing the HotSpot JVM, there were quite a few open source unofficial implementations: e.g. GNU Kaffe, Apache Harmony, GCJ, etc. Claiming ownership over interfaces/API is a new and treacherous behavior that came along with Oracle.

And what if somebody was to do this to Linux? After all they have access to the code, should be easy enough to just rip it off and take it proprietary by following the Google model, what would the difference be? None at all.

None. Linus owns the Linux trademark in many countries. Assuming someone didn't copy the source code and just re-implemented the APIs, it would be totally kosher as long as you didn't call it "Linux". How do you think Linux was allowed to exist in the first place? It's just an unauthorized implementation of a bunch of POSIX APIs, but because Linus didn't call his kernel a UNIX(tm) system or claim POSIX(tm) compliance, he didn't run afoul of trademark law.

April 2013: "Sonatype's annual survey of 3,500 software developers and shows struggle in setting corporate policy on open source and enforcing it" ref

April 2013: "Control and security of corporate open source projects proves difficult | New Sonatype survey finds 80 percent of most Java applications comes from open source" ref

Nov 2014: "Software developers use a large number of open-source components, often oblivious to the security risks they introduce or the vulnerabilities that are later discovered in them." ref

April 2015: "open-source also represents a vast, unpatched quagmire of cyber-risk that’s putting public safety at grave risk. That’s the assessment of Joshua Corman, CTO at Sonatype" ref

Also RoboVM if you'd like to leverage your Java skills. Allowing you to target Android and IOS.

http://www.javaworld.com/article/2836880/java-ios-developer/robovm-beckons-java-8-programmers-to-ios.html

This is an article from 1998. Scott McNealy liked to show off his Java ring at that time and talk about how it would be used to allow someone to walk into a hotel room and have sensors detect the person and their wishes such as music and mood lighting and it would also store your crypto keys on it. It will be interesting to see if people are read to wear tech as new devices enter the market.

http://www.javaworld.com/artic...

picture
http://upload.wikimedia.org/wi...

For portability, it remains the king.

As long as you don't want to run on iPhone or WindowsPhone, or any number of other CPUs. As long as you stick to Windows/Mac/Linux, Java is good for portability.

You mean as long as you stick to Windows, Mac, Linux, Solaris, z/OS, IBM i (formerly known as OS/400), OpenVMS, ...

Oh, and Java apps can be made to run on iPhones and Windows Phone. It's just not trivially easy.

http://www.javaworld.com/artic...

I really wish someone would bring this up with more serious force behind it. Sun released Java SE under GPLv2.

Also, going out on a limb, I'd guess that the "37 APIs" aren't part of something outside the core stuff - I'm guessing Sun left out J2EE when open sourcing since I see no note about it.

I think you need to keep up... PHP is quite fast nowadays due to Facebook's efforts.
http://www.javaworld.com/javaworld/jw-07-2013/130726-facebook-invents-php-virtual-machine.html
https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/

Wrong exemple, Facebook has since replaced their C/C++ compiler (HipHop) with the use of a virtual machine and they have gained in performance in the process. http://www.javaworld.com/javaworld/jw-07-2013/130726-facebook-invents-php-virtual-machine.html

You are right. They settled the 1997 lawsuit in 2001 and as part of that agreed not to distribution Java anymore. It wasn't a court order, but it was a legally binding agreement of some sort.

http://www.javaworld.com/javaworld/jw-01-2001/jw-0124-iw-mssuncourt.html

When I worked at Microsoft there was talk about how they were legally prevented from shipping anything "Java". I'm actually surprised they are shipping BluRay in the XBox One since the BlueRay spec has Java in it.

It is supposed to be a systems language like C, but better.

IMHO, if it isn't standardized, opened up and backed up by an international standard then it will never be better than C. For all problems that may or may not affect C and for all problems involved in the development and update of a standard for each version of the C programming language, these multiple versions of the C programming language are effectively set in stone. This means that the language is future-proof, as multiple implementations may be developed and, by targetting the standard, they can interoperate without any major consequence.

If Go isn't standardized and if Google intends to control the language then it would be a terrible decision to adopt Go instead of a time-tested, well established tool which is future-proof and resistent to bit-rot. We all have Oracle and Java as a good warning.

It is open sourced. Standardization will come I am sure.

It is supposed to be a systems language like C, but better.

IMHO, if it isn't standardized, opened up and backed up by an international standard then it will never be better than C. For all problems that may or may not affect C and for all problems involved in the development and update of a standard for each version of the C programming language, these multiple versions of the C programming language are effectively set in stone. This means that the language is future-proof, as multiple implementations may be developed and, by targetting the standard, they can interoperate without any major consequence.

If Go isn't standardized and if Google intends to control the language then it would be a terrible decision to adopt Go instead of a time-tested, well established tool which is future-proof and resistent to bit-rot. We all have Oracle and Java as a good warning.

COBOL is probably still the largest installed codebase and remains the behind the scenes 'what makes business go' Mock if you want but can you say any of the modern darling languages will have major league applications still running 30 or 40 years from now? People also mock Fortran, yet it still rocks and has been updated to include many 'modern' features and were it not for crowd bias would be a great choice for many applications.
Ref: here

The Sun vs MS Java fight was a cluster of patents on both sides. Thus why a judge ruled that whilst Microsoft had violated it's license to java, it could develop a similar system,

That fight was not over patents at all, it was over licensing and trademarks. Sun owned the term "Java", and to use it to describe your implementation ("we support Java") you had to sign a license agreement with them, which, among other things, stipulated certification for conformance to standards, and lack of third-party extensions. Microsoft JVM violated that license agreement, and hence damages were sought. Here is the original story back from the day; quote:

"According to Sun's press release, "the complaint charges Microsoft with trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract." Specifically, Microsoft made the choice last week to ship products it claims are fully Java 1.1 compliant, but which failed to pass the Java 1.1 compatibility tests the company received from Sun in February."

Note no mention of patents here.

The judge didn't rule that "Microsoft could develop a similar system", because that would be outside the scope of the lawsuit, which was solely about Java. And, of course, since .NET was never claimed to be a JVM or to support Java, it couldn't be targeted that way to begin with.

I would imagine RIM licenses Java.

There's no doubt about that, since their implementation is honest-to-God J2ME (with extensions on top), and is labelled as such. They'd have to license it from Sun/Oracle regardless of the patents.

Except apps was used by others long before Apple used it to refer to things running on their iphones/ipadsd/iwhatevers.

Here's "app" used to refer to computer software in 1989: http://books.google.com/books?id=uTAEAAAAMBAJ&pg=PT83#v=onepage&q&f=false

"Java App" (as opposed to an applet) was a common term back when I did java, here's one such usage from 1999: http://www.javaworld.com/javaworld/javaqa/1999-07/01-qa-applet.html

And "Apple Store" is fine for Apple to trademark. But it applies to a technology store and not to a fruit store.

Remember that famous Alan Holub piece from 2003? Why extends is evil
Improve your code by replacing concrete base classes with interfaces
By Allen Holub, JavaWorld.com, 08/01/03

In other words, an SML signature is what OOP calls an interface? (Okay, sure, Java forces all objects to support stringification and comparison for equality, but that's not really a fault in OOP.)

Of course, one has to recognize that extends is evil:

Someone asked [James Gosling]: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

back in the 1990s Sun was pushing the idea of a signet ring that would carry all your data and credentials, powered by a java interface. It finally came to realization in 1998.

http://www.javaworld.com/jw-04-1998/jw-04-ringfever.html

At the time I thought it was a splendid idea. The concept was to have public kiosks that would intermediate between the ring and your mainframe to do what ever you wanted to do. Or the ring could authenticate you to some point of sale, or carry your medical records. etc... Remember this was early 90s.

That was also back when Sun worked with other JVM's, as opposed to suing them out of existence like Oracle is doing.

Huh? The grandparent specifically mentioned that Sun sued Microsoft's Java out of existence!

This and this do a reasonable job of explaining. The key phrases respectively, and they express the same thing, are

Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

and

Tell, Don't Ask

Not true at all. For example, that's exactly what Apache Harmony is: a clean room implementation that meets all the conditions.

Stop lying. Apache Harmony does not meet the conditions.

http://www.javaworld.com/community/node/4439

The goal of the patent grant was clearly to avoid fragmentation.

No, the goal of Sun's patent and licensing shenanigans was to gain control of key APIs in the industry. "Fragmentation" was merely a smokescreen.

There are alternate implementations - you are complaining because they have to pass a test suite? Come on, how else can you be sure the VM works!!

I'm complaining because they have to pass a test suite or else face patent infringement claims from Sun. Furthermore, the test suite itself is only available under restrictive terms. That's not an open platform.

Two licensed (meaning safe from lawsuit) implementations

If they are licensed, they are not independent implementations. Open platforms don't need to be licensed and aren't controlled by any one entity.

Harmony [apache.org] (From Apache)

Are you living under a rock??? Harmony isn't licensed, it hasn't passed the JCK, and you cannot run the JCK on it without violating the JCK license. That charade has been going on for years now.

Goldencode - J2SE for OS/2 [goldencode.com]

Yes, a derivative of Sun's source code.

Actors are a really good framework (with a few different implementations) for easy parallelization. Scala has an implementation of Actors as part of the standard library, so they really are first-class citizens.

And when Gosling was asked what he'd do differently if he had to create Java again, he replied 'leave out classes'. JavaScript with namespaces is a lot closer to his current thinking - not surprising, as Sun recruited most of the Self team to make their Java VM not suck in the mid '90s.

That is an oft-quoted phrase of his, and it is also almost always completely misunderstood. It's not that he wants prototype-based OO a la Self or JS. He was rather referring to various problems that come up with class (i.e. implementation) inheritance as the only language-provided way to reuse code in Java. Instead, he wants to only see interface inheritance, and classes strictly as a mechanism of implementing interface - and mixings/delegation as the mechanism of code reuse. The fact that Java doesn't easily enable that later bit is what he referred to as a mistake.

Here is an article that treats it in more detail, and also gives the complete context for the Gosling reference that you have cited.

I think most hiring managers will read past the first page... assuming that they didn't get 100 resumes in response to a single job ad. But in a lot of companies, HR people exist to eliminate candidates more than they work to find the right ones. So they perform a kind of triage, looking for the reasons to dump your resume immediately (which I wrote about at Javaworld in How to Make HR Dump A Programmer's Resume and they are attracted by some strangely shiny things like keywords What HR Professionals Look For in a Programmer's Resume).

Mostly, the idea is to get past the HR department and get to the hiring manager -- the person to whom you'd report, ideally. But if she has a stack of 100 resumes to fill an open position, you need to capture her attention immediately and shout I have the background you need. That's among the reasons that it's a good idea to include FOSS experience, which is what I wrote in the first part of that blog post.

I think most hiring managers will read past the first page... assuming that they didn't get 100 resumes in response to a single job ad. But in a lot of companies, HR people exist to eliminate candidates more than they work to find the right ones. So they perform a kind of triage, looking for the reasons to dump your resume immediately (which I wrote about at Javaworld in How to Make HR Dump A Programmer's Resume and they are attracted by some strangely shiny things like keywords What HR Professionals Look For in a Programmer's Resume).

Mostly, the idea is to get past the HR department and get to the hiring manager -- the person to whom you'd report, ideally. But if she has a stack of 100 resumes to fill an open position, you need to capture her attention immediately and shout I have the background you need. That's among the reasons that it's a good idea to include FOSS experience, which is what I wrote in the first part of that blog post.

I think the JCP has pretty much destroyed Java.

I think quite differently. The JCP has brought us things like JOGL, JAXP, and many more advancements of the Java technology.

They reneged on those promises because it forced them to open up the language too much

Because Sun saw fit to prevent Microsoft from making a bastard version of Java? Because such a version would have destroyed the entire point of Java, Write once/Run everywhere? Much like their MS LDAP? (I mean Active Directory.)
Moot point now that Microsoft has their own Java, er, Runtime.

they have numerous patents on core Java and the libraries.

Do you care to point them out? And how OpenJDK has worked around those?

why should using Mono bother any open source developer?

Because Microsoft is a big software bully. Really, however, the implementation of Mono works around the tricky parts much like OpenJDK does. I know all too well the pain that Mono devs must face. OpenJDK gets dogged for, "Always being behind the one true JVM," or "Java is a patent trap, GPLv2 wasn't enough, now we're making exceptions?!" In the end, I don't think that I'm your target audience for that question because I think Mono does enough to protect itself.

I don't know about .NET, since I don't use it. I do use Mono...but Java is a good example to contrast with Mono because many people regard it as "open"

Java like .NET is a platform. Sun's Java implementation is to Microsoft's .NET implementation as OpenJDK's Java implementation is to Mono's .NET implementation. I can see that you can tell the difference between MS .NET and Mono .NET, I hope I've cleared up the comparison for JVMs as well.

Google is providing a standardized UI on top of Linux

Then let the better UI win. Will it be one that's Java-only, or one that can be used in its native C++ environment or with Python, Ruby, or even Java?

Symbian is dead.

Even if it were true, and with about half of the smartphones in the world running Symbian I don't think it is, what has that to do with Qt?

there is very little need for a specialized UI toolkit like Qt now that there are both fewer platforms for it to run

Huh? There are more platforms than ever for Qt to run. Do you mean Microsoft isn't delivering operating systems anymore?

Technically, Google's Android is a code derivative of DavlicVM and Apache Harmony. Apache Harmony and DavlicVM can be considered as similar to Java. However, Android is Not a subset of Java.

Some links to articles discussing the topic:
http://www.javaworld.com/community/node/2683

Some information on DavlicVM and Apache Harmony:
http://www.dalvikvm.com/
http://harmony.apache.org/

Each VM/platform has its strengths and purpose. There should be room in the IT industry for Java, Apache Harmony, Google App Engine, .NET, Mono, LLVM, Tamarin, Parrot, and many other VM's with their associated programming languages.
Hope you find this information helpful.

Ooh, repositories... holy war turf!

Before committing to Subversion :) you may want to check out Mercurial (think of it as git-done-properly)

Mercurial does "merge tracking," though its not listed as that, it is just inherently part of the system.
You can use something like the graphlog plugin (hg glog) to see a commit history with graphed merges.

I also like using the GUI log viewer (hg view) to view commits, branches, merges, and the details of each commit
(it runs a program called 'hgk', which is similar to or related to 'gitk')

I've only scratched the surface of what can be done with Mercurial. I'd love to hear from some more advanced users on useful repository management methodology, and useful plugins/extensions for Mercurial.

Mercurial:
http://en.wikipedia.org/wiki/Mercurial_(software)
http://www.selenic.com/mercurial/

Comparison of Subversion, CVS, Bazaar, and Mercurial:
http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html?page=1

Graphlog for Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/GraphlogExtension

PCM2 (aka Neil Mcallister) is right.

Here's an excerpt from one of his articles at Infoworld, entitled "Schwartz doesn't get Linux".

Schwartz really had me going there - right up to his next line. "And frankly," he said, "its principal competitor is none other than Microsoft Windows." Huh?! That's like a company that sells nothing but certified, purebred cocker spaniels claiming that the principal competition for its product is a purebred cat. But then, Sun has never been able to own up to the elephant-size mutt in the room. Say what you want about Microsoft's business practices, but at least give Redmond credit for giving up on pretending Linux doesn't exist. If you look at Sun's public statements about Linux over the past few years, you can sum up its competitive strategy in three easy steps:

      1. Equate all Linux with Red Hat
      2. Trash-talk Red Hat, its pricing, and its business model
      3. Point customers toward Solaris

That may be a clever way to run a sales call, but Schwartz can't honestly believe that's how the thought process works in real life - can he? "We will be one of the consolidators of the open source industry," Schwartz went on to say, "as well as, certainly, in the open source operating system industry." Consolidators? Can he be serious? I know that, what with all the buzz around Oracle recently, buying up small open source companies is in vogue. But at least Larry Ellison is smart enough to recognize that it's hard to buy and sell what you cannot own.

While I read the roughlydrafted article pointing to Oliver Rist as a shill, at least we can be sure Neil does NOT shill. In fact, the whole article was anti-fud. Neil, you're on my friends list now. Keep up the good work.

> "If you could do Java over again, what would you
> change?" "I'd leave out classes," he replied.

"After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible. "

Not the same as saying that he didn't want java to be OO.

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

Gosling never said that. He said that as a joke. See http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?page=16

What he did say is that the use of the 'extension' keyword should be avoided.

Unless the VM directly exposes the application that is running within the VM to an OS call ( fopen() ) then the VM must puts its own wrapper around it, do whatever error checking the VM is going to do, then pass it to the OS, let the OS complete the operation, take the handoff back from the OS, then handoff back to the application that is running within the VM.

Do you any concept at all what a Just In Time Compiler is? The JVM has absolutely no problem linking to an fopen() call because it compiles the code into native instructions. The reason why it's faster is because it can optimize that native code at runtime. i.e. It can take the results of runtime profiling and recompile the source into a different code path. That code path can execute for as long as the JVM detects that it is valid. The moment the JVM detects that it is invalid, it can recompile with a more general code path.

You assume there is something magical about system calls. Why? System calls link against code just fine, and an fopen() will run just as fast in Java as it will in C. (Though there's no performance gain because the OS calls are out of the VM's reach.)

I really doubt if java is going to do this any faster:

Your Hello World example is a straw-man. There is no significant computation going on there, and therefore, nothing that can truly be tested. Try something more realistic like inserting 10,000 items into a hashtable, running an RC4 encryption routine, performing a Fast-Fourier Transformation, or one of the millions of other processes that will have a real-world result that can be measured and compared.

In these areas the JVM can (and does!) shine because of its ability to optimize execution on the fly. An expert coder can use low-level features of C/C++ to cheat the test (as McCombs managed to do here), but usually only at the expense of violating the test purpose of the test. (e.g. McCombs ignored the fact that the hashtable would normally contain a wide variety of object types, and thus in optimizing for small strings, screwed up the purpose of the test. Even worse, his solution was highly wasteful with memory and has a bug that would result in a buffer overflow if a large enough number of iterations was passed in.)

In apples to apples comparison, the JVM almost always wins. And there's no reason why it shouldn't. The JVM JIT compiler can do all the same optimizations that a traditional compiler can do, plus a wide variety of optimizations that never used to be possible. The JVM is at the cutting edge of Computer Science. It has well over a decade of new technologies on the now-aging C/C++ platform. There are hundreds of academic papers on the engine, and dozens of computer scientists who have helped make it as fast as it is today.

But don't take my word for it. Go read up on the Hotspot VM before you decide to call me a liar again. Here, I'll even get you started.

A decade old, but easy to read introduction to the engine: http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html?page=1

A more recent architectural overview on the modern Hotspot compiler:
http://java.sun.com/products/hotspot/whitepaper.html

A variety of papers and presentations on the VM:
http://java.sun.com/javase/technologies/hotspot/publications/

The Hotspot FAQ (answers a lot of questions about why Hotspot sometimes shows up impossibly fast/slow in microbenchmarks):
http://java.sun.com/docs/hotspot/HotSpotFAQ.html

When you're done, think about the number of optimizations the VM is doing in everything from heap management to mallo

Merge tracking is the main feature of 1.5, which, according to this guy, is in beta right now. He does a demo of it too.

...getting interviewed about Groovy here.

There's some other good stuff there too, although the interview with Dr. Stonebreaker about column-oriented storage is kind of light on technical detail.

Hi. Java passes *everything* by value.

Unfortunatelly, you are the one that got it backwards. Problem was NOT that MS added win32 specific things - the same was done by others, for examle Apple and there were no lawsuits. Problem is that MS DID NOT implement RMI and JNI as it is in specification for Java 1.1, and also altered classes in the java.* package. It would be ok, if MS did this in com.ms.* package, but altering core libraries not to match specification is just plain wrong. I tried to find some article about the subject, this may be a good one: http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit.html

Java sandbox, 10 years ago http://www.javaworld.com/javaworld/jw-08-1997/jw-0 8-hood.html

or VM, 35 years ago

I guess at least those patents must have expired by now

I believe the GP was talking about this problem, with reading and writing the Vector at the same time (not writing from two threads). Which is not threadsafe.

I certainly see your point. However, the first time an application is distributed isn't an update. A user just goes to website (most know how to do that!), and clicks a link. From then on you could do updates automatically from the application without ever visiting the site again. You also do not have to code up an installer program unique to every platform.
Check this:
http://www.javaworld.com/javaworld/jw-07-2001/jw-0 706-webstart.html?page=2
-Joe
http://www.lovehorsepower.com/

Ok, so I exadurated a little about the 100% CPU, but the point remains. I suspect you don't really know how java does its garbage collection. Here is a nice starting point http://www.javaworld.com/javaworld/jw-03-2003/jw-0 307-j2segc.html?page=1. When your done please explain to me how that can be faster than a simple stack allocation (usually precomputed by the compiler and done when the initial stack is setup on procedure entry) done in C/C++ or a fast O(1) heap based allocator. After all the BS about garbage collection, there is still a heap sitting under it all, and the same heap algorithms are used in C/C++ as java. In fact you can change the heap allocator in C++ if it doesn't match the performace characteristics of your application.

Now, i've seen dozens of programs written in both C++ and java which are written to prove that java has faster memory allocation because of the garbage collector. In ever single case, the C++ example makes some major mistake which would not be made by an experienced C/C++ programmer. Once that mistake is fixed, the C++ version runs anywhere from as fast to significantly faster than the java version, as measured by total wall time. Usually the C++ mistake is there to give the implicit object reuse the JIT did a big boost. The point here is that while you may be able to make C++ programs slower than java, there is usually some way to tweak the C++ program to reverse the situation.

Oh, and while C++ may not have been designed for 64k machines, I ran C++ compilers in DOS and on the early mac's neither of my target machines had 2M of ram.