Slashdot Mirror

Then standardize on a cross-platform API (Java is a possible candidate), and then when you click a link to a remote application (from your browser/finder/explorer thing), that app is quickly downloaded and cached on your end and run like any other local program, with the exception of different privileges and such. These programs might just call back to their home server for their data, in the case of something like a simple game, or they could allow you to read and write data from your local disks. The advantage of using a remote app in the latter case would of course be not having to worry about upgrading or anything - the only version that's available to use is the latest version.

• Portability: Java Web Start is available on Windows, Solaris, and Linux, and is expected to be ported to other platforms.
• Caching: Applications launched with Java Web Start are cached locally. Thus, an already-downloaded application is launched on par with a traditionally installed application.
• Maintainability: If the remote application is updated, Java Web Start updates the locally cached version at the application's next invocation.
• Easy launching: Java Web Start allows applications to be launched independently of a Web browser. The application can also be launched through desktop shortcuts, making launching the Web-deployed application similar to launching a native application.
• Ability to work offline: An application can be used in situations where launching through the browser is inconvenient or impossible.

|Oh, really?

Both Eclipse and Derby are the result of previous shopping sprees by IBM.

Eclipse was developed by the IBM Ottawa Software Lab. This lab started life as OTI, a company which developed Smalltalk technology, that IBM bought in 1996.

Derby is the open-source version of the Cloudscape DB. Cloudscape was a Java DB company which was acquired by Informix in 1999, which was in turn acquired by IBM in 2005.

- I like the idea of using JavaServer Faces and renderkits, so you can easily migrate to different presentation technologies. Did you write directly to Lazlo's API or use a renderkit-type method? IBM has a Lazlo-JSF renderkit and that seems like the best way to go in that world.

Laszlo's code is not tied completely to an actual final renderpath... ie. while currently your only option is flash, as can be seen on their homepage, they have a working DHTML output that works as well... and the idea is that the code you write is independant of what output it finally has.

We code in Laszlo's mixture of XML and Javascript, and it compiles that to Flash for rendering. The final output may be in a browser, may be on a phone, or whatever.

- If you're writing to the API, how tied to it are you? With a rederkit, you can quickly make changes from a web-browser to a PDA, with the components taking care of the display issues. Is display migration an issue?
OK, so we're writing our own 'renderkit' if you will... we're using a modification of the Visual Proxy methodology and as such our final display objects can be changed and modified based on what it's rendering to. But we do use a number of the inbuilt Laszlo visual components (windows, buttons, sliders and the like)... but as they render in flash, anything you can run flash on, they'll run on.

- How is performance? I've always found the examples on OpenLazlo to be slow, limitted, and not seem to be very useful in the real world.
Performance is always something that we battle with, but we're trying to manipulate hundreds of linked visual objects onscreen at one time, with many calculations running in the background. You have to be tricky here and there, but you can do some amazing things. Basically, the limitations are not really a result of Laszlo as such, but the fact that you're running an app within a web browser, and you always have to be conscious of that. The more you use it though, the more you learn the tricks to get a great user experience... I would hate to be trying to do this in DHTML.

- How much time have you spend on the UI versus other techniques (e.g. DHTML/AJAX)? If longer with Lazlo, do your customers see your UI as value-added? Does it reduce your time from working on the core business-logic?

(First up... this is AJAX, very much so it's Asynchronous Javascript and XML)
We spend a fair amount of time on the UI, but only because the main thrust of our app is presenting a whole lot of data in a visual way that the users can interact with in different ways to any other applications in this space... so it's a large portion of the appeal of this app. That it's targetted at the Marketing teams of companies means that it should be easy to use and appealing to work with, hence the flash interface.

We have coded other PHP/Javascript/DB applications for clients (we have one being finished up at present), and while they're nice to work with etc. And do take less time to initially code they have a number of drawbacks:
* Maintenance is harder as writing directly for HTML output means trying to be cross-browser friendly, which results in solutions for each of the major browsers. Flash means it just works the same, full stop.
* It looks the same. While you can do some pretty great things with DHTML etc. It's all still pretty web browser looking, you're tied to that due to limitations of what you can do, and performance issues if you stray too far from the simple. Flash allows you to have nice transitions, animation of key things, fluid interface interactions etc. Plus it's can be very different visually if you so wish.
* As for the time we can spend on Business Logic vs Interface. As in this space we are coding in an OO language, and can create nice class seperation and encapsulation, we can completely split off our business logic from our presentation code. This makes ongoing maintenance of either side of that equation

If they were to GPL it, they would STILL hold the exclusive license. GPLing it doesn't give away the ownership, and it doesn't prevent the owner from also licensing it under other terms.

Quoth the GPL v2:

"2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)"

This is what we call forking, and yes, it is allowed under the GPL v2. Sun won't license it under the GPL for that very reason. See Sun vs. Microsoft, which resulted in .NET.

"I've tried sticking to MVC in a desktop application I'm working on, and I've found it quite hard to integrate the three layers."

Allen Holub agrees with you. So do others TOP may be an alternative (Tablizer is a /. poster).

Well, it's been available since 1999. Seeing as it has taken slashdot—oh about—7 years to figure it out, you can understand why I'm a little peeved over the number of responders who've claimed that the source isn't available.

If you have a problem with the SCSL license, fine. If you have a problem with the JRL license, fine. But to claim that Sun hasn't released the source code? That's just frustrating.

JVM gets bloaty once you start adding all the GUI stuff, though J2ME (used in a lot of phones etc) is a lot smaller.

Word Perfect For Java.

Also, from a development perspective, this is exactly the Model View Controller framework that so many people really like to enforce in their development practices. ... And you can't accidentally put view functionality into the model, the XML communications library you set up shouldn't be processing raw HTML (since passing raw HTML is an abuse of ajax, you should be xmlifying your data, and sending it *as* data).

Also, from a development perspective, this is exactly the Model View Controller framework that so many people really like to enforce in their development practices. ... And you can't accidentally put view functionality into the model, the XML communications library you set up shouldn't be processing raw HTML (since passing raw HTML is an abuse of ajax, you should be xmlifying your data, and sending it *as* data).

And you weren't using the concurrent tenured GC algorithm. Here's a decent article covering JDK v1.4's garbage collection algorithms.

Your apparent description of the problem (heavy swapping, a GC that runs at low priority) is simply wrong. The problem you were seeing is that there was no available space in the "new" heap space for new objects, so objects were immediately promoted to tenured space. Once the tenured space gets to a certain point (I think the default is 75% full), the tenured GC runs and stops the JVM cold in its tracks (if a naive GC algorithm is used). If there is no space to be reclaimed during a tenured GC, it can take a really long time to run. If your heap is large (>512MB, in my experience), this can take >10 seconds.

Use the "concurrent" GC algorithm, and these "stop the world" delays are reduced to less than 0.2 seconds, in my experience.

To use the concurrent GC algorithm, start the JVM with this command-line option: "-XX:+UseConMarkSweepGC". Also, you probably want to do some analysis of the JVM churn of memory. There is a good chance your application may require more "new" space, or different ratios between new & old spaces, and for the survivor space.

If you are having problems with swapping, buy more memory. I don't think porting the code to C++ will help.

A better solution to your problem is to quit doing XSL transforms, XPath, or DOM processing of XML documents in a server-side application. The app where you saw these delays did heavy XML processing, right? Yeah, I thought so. Try using a SAX parser, and re-implement your transforms to work on small blocks rather than entire documents. The problem is you are creating too many new objects (something that XML processing does a lot of) without freeing them, causing your "young" space to get filled up before the "young" GC can run. This causes the tenured space to get cluttered with "new" objects, resulting in fragmentation and increased frequency of tenured GCs. That, in turn, causes a "stop the world" response that compounds the problem, since the JVM is spending >30% of its time attempting tenured GCs when there is nothing it can garbage collect (since it is filled with "new" references).

In a word, server-side XML processing is "Bad".

All the current suggestions from other posters I would agree with, Dr. Dobbs, ACM, IEEE, CUJ. But probably, like regular media, the smaller players are picking up the slack, even if they are web only. ServerSide, JavaLobby, IBM Systems Journal, Software Development, Artima Developer, JavaWorld, and DeveloperWorks are a few of the excellent ones I regularly read.

http://www.javaworld.com/javaworld/jw-12-1997/jw-1 2-volanomark-p2.html

It IS zero install. A jar can be, and in this situation is, an executable file. When you run the jar you run the program.

You can learn about it here: http://www.javaworld.com/javaworld/javatips/jw-jav atip127.html

You wash your hands because you have no arguments left.

"Words Should Be Short and Sweet...For You May Have to Eat Them Tomorrow" - Unknown

Cheers,
Adolfo

Speaking of flyweight objects, you may find this article interesting: http://www.javaworld.com/javaworld/jw-09-1996/jw-0 9-indepth.html

Please, please. How many times does this have to be rehashed here on Slashdot and the Internet in general, especially when good, detailed information is so easily accessible? The Java "language" is an open specification. How do you think GCJ and other projects are able to do their work? Sun's JRE source code is quite a different story, for example, but that's not what I was referring to.

This is incorrect, actually. The final "decisions" are made by the applicable Expert Group for the submitted JSR, which is made up of industry "experts" from many different companies, possibly including Sun, but often not. For a nice breakdown of the entire process, please see here:

Hope that helps.

This is obviously not about the PHP Language itself as you are definitely looking at your alternative as better... While I can program java, I can program python, etc etc... I use PHP for the web, and in an enterprise environment as that! You claim PHP is the root of all evil, take a look at an operating system, whose job is it to make sure that any type of security whole is plugged? Yours. Next lets talk about scalability, PHP is highly scalable as long as you understand the structure and logic of the language, which is not like your current language. That is why it bugs you. Currently I have around 30 files that operate 70 websites (and no this is a single set they are not mirrored on all the sites). Pretty much they are mainly objects and a few controllers which the user can override the global scope in site of their local scope for pages. The configuration is easy and sql injections can happen in just about any language. Programming for the web I can pretty much show you vunrible applications everywhere. This is not just a PHP thing. How about the infamous buffer overflows with Java? Had that one happen? This thread is mainly all opinionated with no factoral history. And if you are going to call out something as huge security risks without providing a fact then you are just blowing steam up everyone for no reason. Get a job, learn more about secure computing, and stop trying to advocate other languages as better than this or that when it is simple opinionated with out any benchmarks, security advisories, references. Now heres my turn. Java has security problems because people code them in according to your philosophy, as for the tutorial on writing secure php code... well here is one for java: http://www.javaworld.com/javaworld/jw-12-1998/jw-1 2-securityrules.html Meanwhile here are the latest records for programming languages (latest versions) php: http://secunia.com/product/3919/ asp.net: http://secunia.com/product/2173/ java jdk: http://secunia.com/product/4621/ j2ee: http://secunia.com/product/2644/ python: http://secunia.com/product/4604/ As for scalability : http://www.onjava.com/pub/a/onjava/2003/10/15/php_ scalability.html http://www.oreillynet.com/pub/wlg/5155 there are numerous resources on the net on writing secure code for all programming languages, everything you mentioned in this entire "rant" is worthless and doesn't do anyone any good. Please go crawl back in your hole.

20k lines of code? That is miniscule. I've got a mid-sized enterprise system that's got 20k FILES containing millions of lines of code integrating a dozen desparate systems over a network of 50 or so servers. It handles thousands of concurrent users performing transactions - not just viewing content. That's just a mid-sized system. Some large scale systems use clusters of hundreds of servers. Not to bash what you're doing but I think you could use a little perspective on the size of your application.

I don't care if you've got a freakin army of PHP programmers, you're never going to build a system that can scale like Java.


1) Scripted languages in general: slow performance

2) Compiled languages in general: Requires rebuild before changes take effect, so testing and retesting is slowed down.

3) Java/.Net/Byte-code languages: Worst of #1 and #2 above.


Don't believe the hype about Java's performance. Today's just-in-time compilers can optimize code as well as hand optimized code and they don't waste resources optimizing paths that don't get executed. There are many benchmarks out there that confirm that Java's performance is comparable to C++ and even better in some areas.

http://www.javaworld.com/javaworld/jw-02-1998/jw-0 2-jperf_p.html
http://www.tommti-systems.de/go.html?http://www.to mmti-systems.de/main-Dateien/reviews/languages/ben chmarks.html
http://java.sys-con.com/read/45250.htm?CFID=29694& CFTOKEN=101A9EF8-9F8D-153A-37A5E0A40D3EE24A

I agree with your point though, there are a huge number of crappy programmers out there. Good programmers write good code in whatever language they are using.

So, what is good code?

IMHO, good code performs well and is easy to understand and use.

The nice thing about AJAX is that it works in all modern browsers. (And it makes for dynamic pages too.) So a framework that requires .NET is a step backwards.

Way to miss the point dude!

Why is a server side implementation written in .NET that produces client side code a step backwards? Next you'll be telling us that DWR is a step backwards 'cos it's implemented in Java.

Who could forget William Henry Gates III and his little run-in with Harvard to start a little company geekily named Microsoft...Ha! look where it has lead him to now.

He could be so much more! He could be so much like...us!


/sacasam

"What you don't know about testing, would float a battleship."

A hundred times slower than what? Assembly?

This was in 1998

Please update your trolls.

Abstract Windowing Toolkit. Really, is google so hard?

Here's some info.

The license may be opensource, but Sun sure as hell isn't, they sold java to M$ for chump change for fucks sake, that small amount of cash isn't going to make a difference, even to a company falling as fast as Sun, its clearly indicative of a greater plan to retake the Unix world. Sun is very clearly anti-open-source, after all they are Sco's secret licensee.

Yes. There was a pretty famous lawsuit that alleged that Microsoft illegally targeted many key Borland employees including Anders Hejlsberg (The inventor of Delphi, and the creator of C#) and Paul Gross (former Borland Chief Developer; now a MSFT VP).

At least 34 Borland employees were hired by Microsoft over 30 months; and in at least 2 cases, $1million bonuses were offered to close the deals.

Assume they offered all of the Turbo C & Delphi engineers from Borland $1million - for a mere $34 million they would have wiped out their biggest competitor in a many billion dollar industry. Of course such hiring practices are illegal; but Borland and Microsoft eventually settled with a broad IP-sharing partnership and a $25 million investment from Microsoft into Borland.

As far as threading is concerned, one of the few languages I've dealt with that makes mutexes, semaphores, etc. easy to deal with is Java

Furthermore, we need to get rid of lazy programming.

The creators of the Hotspot VM used to claim that their brainchild would someday outperform C++, because of intelligent optimization at runtime. Don't know if that ever happened.

Microsoft's current inability to handle security issues is much more persuasive. Linux advocates should focus on that, instead of beating a dead horse.

You've obviously not familar with ANT. Now the horrendous practice they started is moving into usage with a number of XML based GUI builders.

Thankfully there is a counter movement to replace such poor usage of XML with scripts.
http://today.java.net/pub/a/today/2003/06/10/jytho n.html
http://www.javaworld.com/javaworld/jw-10-2004/jw-1 004-groovy.html

I'd pull some more links for ya, but I've gotta bolt.

Probably just as long as it took for Sun to get their Java chip into every PC.

The problem with it is that because it's functional you often end up restructuring half the program for what would have been a trivial change in an imperative language.

While I don't disagree with this, there are some counter-arguments too:

• If you find yourself doing that, you may have written your original program in an imperative style in the first place. Alan Holub's argument about getter/setter methods applies to declarative programming too. If you wrote in a more language-ideomatic style, you might not be facing a huge restructure at all.
• Much the same problem can happen in imperative languages, only the class of changes which would trigger such a restructure are different. For example, in a non-GC'd language, you may end up restructuring your program if some critical data lifetime changes. Or, instead of restructuring your program, you might prefer to hack it up instead, making it less maintainable. (It might be argued that languages like Haskell, which discourage this kind of hackery, might be a good thing in the hands of a certain kind of programmer.)
• Even if you do have to restructure half the program, tools like Haskell's type system make this a less painful task than it would otherwise be.

Knowing a language also means knowing what kinds of changes are painful and what kinds of changes are not. Knowing this in advance helps you write your programs to be more future-proof.

What was once a nice elegant language is gradually starting to crumble. As always when a new feature is added to a language people will try and find uses for it (rather than only using it if they really really have to) and we will end up with an unholy mess of hard to maintain code.

I understand that is true in many situations. In fact, Holub himself agrees with you.

... I do believe that data flow should be minimized in a system, and that methods generally should not return basic types (with the exception of boolean), but there's certainly nothing at all wrong with a method that returns an object that implements a known public interface. ...

Besides that, he tries to emphasize design process, to invite us to keep in mind OO principles while looking for an ideal design first, and to settle for something less than ideal afterwards, as late as possible. In a nutshell, if getters or setters are to be used, they ought to be included at the end of the design process, only if a better solution isn't found, but not at the beginning (that's what he regards as evil).

I've tried his approach and the designs are much better than whatever I am able to conceive any other way (I'm not surprised). But it takes more effort and commitment, of course. And it takes longer.

That link again, without the extraneous space: http://www.javaworld.com/javaworld/jw-09-2003/jw-0 905-toolbox.html.

Well, Holub explains this at length in his article. Let me rephrase and summarize what I understand of what he says.

I think his chain of reasoning (and mine :) is somewhat like this (anyone can personally agree or disagree with any of these, of course):

- Software design is a separate activity, different from coding.
- Good software designs must stick to their underlying paradigm (OO in this case) as much as possible, to reap as much of its benefits as possible.
- Encapsulation is a quality that provides most of the benefits of OO.
- Encapsulation is a quality that good OO designs must pursue with a passion, or else they are very bad OO designs, measured in OO benefits reaped.
- Encapsulation means knowing as little as possible about the inner implementation of an object, ideally nothing.
- Knowing nothing about the inner implementation of an object, and still be able to work with it, is almost always possible.
- Getter and setter methods reveal part of the inner implementation of an object, so using them means running away from encapsulation and embracing the opposite.
- Getter and setter methods are very bad for the quality of the design that includes them.

I don't think Holub believes getter and setter are *always* bad. I do think he believes getter and setter methods are overused. I also think he believes the availability of getter and setter methods discourages long and hard thinking about the best possible design in a given circumstance, so he naturally prefers to approach OO design as if getters and setters would not exist.

My personal opinion (and experience) is that he is spectacularly right.

These phrases from his article include the above, in his words:

A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.

One basic principle of OO systems is data abstraction. You should completely hide the way in which an object implements a message handler from the rest of the program. That's one reason why all of your instance variables (a class's nonconstant fields) should be private.

This implementation hiding principle leads to a good acid test of an OO system's quality: Can you make massive changes to a class definition--even throw out the whole thing and replace it with a completely different implementation--without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other OO features.

Since accessors violate the encapsulation principle, you can reasonably argue that a system that heavily or inappropriately uses accessors simply isn't object oriented. If you go through a design process, as opposed to just coding, you'll find hardly any accessors in your program. The process is important.

I mean, yea, "getters/setters are bad", in public APIs. Getters are bad- unless you need to vend an object and can't afford the overhead of creating entirely new instances when you do so. Setters are _definitely_ bad- unless they're private or are data that act as input for your object, which it recieves from controller-layer objects.

Sure, "inheritance is dangerous" as anyone who has ever written an object-oriented program from scratch and had to modify it can tell you. Inheritance is also the key to code reuse, and can be very powerful when done correctly- do you really want to re-write a section of logic that's shared by 5 other objects ?

These things have their place. They're good targets for "is evil"-type articles because they're often used when they should not be. But to call them "evil" and "bad" without proper qualification? It smacks of unprofessional behavior, at best.

I'm a bit puzzled by claims that use of getter/setter methods and, more puzzling, inheritance, are indications that you haven't solved your problem in an object-oriented manner, or that your problem isn't object-oriented... because, well... not all problems are best solved by object-oriented methods, even if you're using an object-oriented language to do so. Sometimes, you need a variable and a loop... what's wrong with that?

At some point, my model code is going to have to give my view code some objects to display... what, I'm not supposed to use getters there? At some point my view code is going to want to tell my model code about an object the user modified... I'm not supposed to use a setter there? I often think folks who write such blanket statements as "accessors are bad" are just trying to spark some flames.

I mean, yea, "getters/setters are bad", in public APIs. Getters are bad- unless you need to vend an object and can't afford the overhead of creating entirely new instances when you do so. Setters are _definitely_ bad- unless they're private or are data that act as input for your object, which it recieves from controller-layer objects.

Sure, "inheritance is dangerous" as anyone who has ever written an object-oriented program from scratch and had to modify it can tell you. Inheritance is also the key to code reuse, and can be very powerful when done correctly- do you really want to re-write a section of logic that's shared by 5 other objects ?

These things have their place. They're good targets for "is evil"-type articles because they're often used when they should not be. But to call them "evil" and "bad" without proper qualification? It smacks of unprofessional behavior, at best.

I'm a bit puzzled by claims that use of getter/setter methods and, more puzzling, inheritance, are indications that you haven't solved your problem in an object-oriented manner, or that your problem isn't object-oriented... because, well... not all problems are best solved by object-oriented methods, even if you're using an object-oriented language to do so. Sometimes, you need a variable and a loop... what's wrong with that?

At some point, my model code is going to have to give my view code some objects to display... what, I'm not supposed to use getters there? At some point my view code is going to want to tell my model code about an object the user modified... I'm not supposed to use a setter there? I often think folks who write such blanket statements as "accessors are bad" are just trying to spark some flames.

1. A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.

Apparently the argument against getter / setter functions goes..

1. OO systems should not expose implementation
2. Getter and setter functions mostly expose access to implementation details
3. Therefore, OO systems should avoid getter and setter functions

While the logic is sound, I think that item #2 is debatable.. If you design an object and mindlessly add get/set functions for every piece of private data in the object, then you're probably guilty of exposing the implementation. But if you design the object's public interface first, and decide on the private data afterwards, I would guess that you're probably in the clear to have used get/set functions "correctly." IMO it's not the functions themselves that are the problem, but rather the adherence to correct design principles.

This approach to "security" in Java is so trivially easy to circumvent that its worthless.

There are a number of papers and articles detailing why this type of approach to "IP security" is so misguided. One such article is here: http://www.javaworld.com/javaworld/javaqa/2003-05/ 01-qa-0509-jcrypt.html

The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details for doing so are detailed in the article above), at which time someone can just write the unecrypted class file out to disk (or wherever they wish). Voila! All your IP are belong to us.

A new platform is always interesting, but is it really good when compared to other platforms?

Take Java, for example. You can write a Java Web Start application that launches like a locally-installed application. It's got a reasonable set of GUI components. It runs on most of the platforms I care, it has probably got a bigger installation base than Firefox is.

And then there's a difference in productivity. Java is way more productive than Firefox as a platform. Go to a book store, you see a whole bunch of books on Java. There are countless FAQs, articles, mailing list archives, communities, and local user groups that covers every aspect of Java. A whole range of IDEs and debuggers to make you even more productive. Hundreds of commercial/free libraries you can use.

All of these things help you get the job done quickly.

So what does the Firefox platform bring to the table? Why a developer like me should be intereste in it?

"Despite (or because of) being written in the Java programming language, Sphinx-4 performs as well as similar systems written in C"

It's amazing that the myth of Java being slow is so persistant. In fact, for computational tasks, many benchmarks have shown that a modern optimized JVM with JIT compilation is roughly equivalent with most implementations of C++, with some benchmarks being better for Java and some being better for C++.

Java *used* to be slow, in the days before optimized JIT JVMs. IMHO, another reason the myth persists is because Swing *is* slower than most UI toolkits in many cases, and it's easy to associate GUI slowness with overall slowness.

In my own case, for ease of cross-platform operation, I've ported several computationally intensive image processing programs from C to Java and have experienced a speed degradation of perhaps 10-15%. The Swing GUI, of course, feels more than 10-15% slower.

Here I am with some code written in Java, and I want to call it from Tcl. Write a quick C wrapper, link the .o in, and package require... no...? How do I do that, then?
The first google hit - http://www.javaworld.com/javaworld/jw-05-2001/jw-0 511-legacy.html

Here I am with a library written in C, or Fortran, and I want to call it from Java... well, how badly do I want it?
http://java.sun.com/docs/books/tutorial/native1.1/ It is really easy.

In the mid late 90's when everyone was going to use the netscape web browser and Sun's java to run all their applications from applets on thin-client sun terminals. Oh, and all your news would come from "Push" technology like Pointcast.

I've never used Cloudscape, but coming from its Informix roots I trust this - to a certain extent, of course.

Cloudscape has a relatively small market share among SQL databases, but it is popular in certain niches. It came bundled with Sun's reference implementation of J2EE at one time, too; I don't know if that's still the case.

Heres the api for starters.

I've always found that all of this is very well documented. I've never developed an application in anger using it, but have been playing round with the technology as a client for content management on mobile devices e.g. Uploading of photos from camera phones, articles from PDA's etc.
I think you are probably correct about it's usefulness in the future, but dig around a bit further and there is a wealth of information out there.

Oooo oooo, more info...

Dell made an agreement with Sun a while back to ship the Sun Java Runtime Enviroment with their computers, so I'm pretty sure that they'd be free to bundle other items such as Firefox if they wanted to.

<Sarcasm TYPE="DRIPPING">

Oh yes, those academic bufoons! They don't know anything next to us in the trenches. They sit in their ivory tower and play with slow languages and espouse worthless advice. Why, they wouldn't know the first thing next to a self taught coder! Save your breath you academic morons, memory deallocation and GOTOs are there for a reason, and I'm going to use them!

</Sarcasm>

LISP has failed to take the world by storm, decade after decade, for sound reasons...

Agreed. "Sound reasons" being LISP is not applicable to a lot of common problems that computer programmers need to solve. We need to create GUIs and code that is organized in easily understood objects, not run set based logic to solve complex artificial intellegence conundrums. If we needed to do mostly the latter, LISP would be everywhere. LISP has its niche. It is very good at what it does, which is compute set based problems. It is not good at what it doesn't. The same is true of C++.

GC doesn't just automate memory management; dependence on it automatically confines the language to niche uses.

The LACK of garbage collection is something that most programs will not require. I would

...There are compilers which can do optimizations on profiling data from the actual running program. Beat that java....

I don't want to be partisan here, but that's exactly what Sun's Hotspot JVM does (note: article from 1998 -- first hit on Google hotspot optimizations).

The Sun JVM analyzes run-time profiling data in real time as the code executes and optimizes the "hot spots". In practice, you can even see it -- if you run a loop many times, the first few times after the JVM starts it will usually run slowly, and then it will speed up as the hot spot compiling kicks in.

Here's a tip.

Write a paper for a trade or online magazine. It doesn't have to be a doctoral thesis. Just a simple "Hello World" article will suffice. Be sure it's a topic that hasn't been beaten to death and be sure it's a topic you know cold. "How to" articles are always in demand at places like IBM's DeveloperWorks or JavaWorld.

You will be surprised how impressive even the simplest article will make your resume look. Being an author makes you an expert in the eyes of your typical HR resume reader, especially when compared to your typical "C/C++/Java/Perl/VB/PHP/......" resume.

Good luck!

JoAnn

The Microsoft JVM was fully compatible with Sun's JDK 1.1.

Sun merely disliked the MS implementation of java because it included extensions: Mainly the ability to deal with COM objects easily and the availability of an MS specific GUI api called AFC while Sun was developing JFC/Swing.

• It had no implementation of JNI.
  
• It had no implementation of RMI. (Instead they had the libraries for COM objects, as you mention; if they had those libraries in addition to RMI, it wouldn't have been a violation.)
  
• About 50 fields and 50 methods in the packages java.awt, java.io and java.lang were altered.
  

Sun claimed such features could harm the portability of java. But extending a programming language is not a crime.

For instance OSX include a Java binding to its Coca GUI api and GCJ can be used to compile java to native code. Sun could also decide that theses extensions are harming Java and sue Apple or GNU.

Developers are not dump [sic]. They can still use the core language/api if they wish to. But such extensions are often useful.