Morfik Defends IP Rights Against Google

ReadWriteWeb writes "Today Morfik came out fighting in defense of its product JST (Javascript Synthesis Technology). Morfik has implied that Google infringed its IP by releasing Google Web Toolkit (GWT) a couple of weeks ago. The reason? GWT bore more than a casual resemblance to Morfik's JST, which allows developers to use a high-level language of choice and have it compiled to JavaScript. GWT is similar, being a Java-to-Javascript translator. These Javascript compiler products are increasingly necessary for companies like Google, with the high use of Ajax on today's Web and the associated complexity of programming in Javascript."

Comments

Sure..

[suv4x4]

These Javascript compiler products are increasingly necessary for companies like Google, with the high use of Ajax on today's Web and the associated complexity of programming in Javascript.

There's no associated complexity with programming in JavaScript. There's lack of progress in the language (still no native support of ECMA4 in browser, shame that *Flash* comes with ECMA4 implementation in just two months, before browsers do).

JS synthesis is a hack anyway. I've seen the code produced by such technologies, and it's crap. You trust your application's well being to the compiler authors with the hope they update it when it breaks in the latest and greatest browser out there.

The correct way to me is upgrading the JavaScript language itself, and until then, using native JS libraries that can be readily reviewed and edited.

JS as a language isn't so primitive as to require a Java or C++ compiler to write good and clean code for it.

Re:Sure..

[suv4x4]

Google are always on the lookout for sources of meta information about sites they search. Is it possible that the toolkit snaffles information from the compilation environment and builds it into the generated code?

Where's your tinfoil hat :)

If this was the case we'd know about it: the "compiled" code it pretty easy to open and read (even if it's still a JS spaghetti mess of a code). No info can be hidden inside.

They do it for two reasons:

1. PR: after few screw ups, like the google's China service, google's "omg ms doesn't put us default in ie7" rants and so on, they needed a bit of a good image in the community to restore they non-evil status

2. they get thousands of free betatesters world-wide to help them point out flaws in their code, which then they'll use in THEIR OWN applications.

Re:Sure..

[MoonBuggy]

As the other two posters have said, it would be difficult for them to add anything dubious to human-readable code without them being noticed. What I do think, though, is that if Google releases the compiler it puts them in a much better position for reading information from the compiled code; they know (roughly) how the compiler is going to output most common operations and where within those the important information that the code is presenting to the user will lie. From this they can train googlebot to read GWT generated JS pages better than any other bots can read them, putting Google at a competetive advantage when it comes to searching AJAX pages.

Ownership?

[paulthomas]

They "own" the innovation? Some people have a really distorted view of the intent and philosophy of so-called Intellectual Property. As Thomas Jefferson so nicely put it: "He who receives an idea from me, receives instruction himself without lessening mine; as he who lites his taper at mine, receives light without darkening me."

If they think that Google could have actually copied their idea in such a short time, then they are admitting that they had no competitive advantage outside the recourse of litigation. More likely, they developed it concurrently. Google has been making fat web pages as they call them for some time now and I imagine that GWT started as a tool for inhouse projects.

Re:Ownership?

[suv4x4]

They "own" the innovation? Some people have a really distorted view of the intent and philosophy of so-called Intellectual Property.

You can imagine how it went: google released the kit, Morfik read up on it, and realizsed he's screwed, so he went "legal" on the matter.

Risk is part of the business. It sure took a lot of time to develop his JS synthesis compilers, and it's terribly frustrating to see a competitor release a free alternative.

But here's the thing: if the most valuable thing in your product is an "idea" (the idea of roughly translating languages in JS spaghetti code) instead of the product itself, you'll be screwed sooner or later anyways.

Synthesis is a bridge for C++/Java/C# developers to get coding without learning the technology around "AJAX". It has no value to someone experienced in AJAX.

All of it: classes, typing, interfaces: it's all fake, and impossible to enforce in the runtime, since the runtime doesn't support it (save me the crap about Turing complete since I'm talking practical speed of execution here). So if the compiler doesn't catch it, you're basically screwed.

Re:Ownership?

[paulthomas]

I had a similar experience not too long ago when I realized that a web app I had spent nearly a year working on (when I should have been releasing early and often) was over taken by what is now a very prominent service.

In my case though, after reading through my business plan a few times in denial, I came to the realization that I had accomplished a lot and learned a lot but that was all. There's always next time or the time after that.

If I would have wasted any more energy on it I would be in a much worse situation today.

Language translators?

[Vo0k]

The idea of language translators is as old as mountains. Translating from Fortran to Pascal, from C to Assembly, from C++ or Perl to C, from Csh to Bash, from Awk to Perl. What's so new about Java to Javascript translator? The fact that the guys wrote another "to javascript" translator?

Re:Language translators?

[Anonymous Coward]

Actually, didn't Rhino, the Java classes for the Javascript library in Mozilla come with a JavaScript-to-Java compiler?

Ah-ha! Bingo..
http://www.mozilla.org/rhino/jsc.html

wait for the real story...

[pedantic bore]

There's nothing substantive in TFA. There's nothing to do but speculate at this point.

I doubt that any company would go to court to defend a claim that they own programming language-to-language translation. If they are, then they'll lose or have the case tossed out.

More likely is that someone at Morfik looked at the output from the google toolkit and noticed that it was suspiciously similar to the output from their own ("we never got the parens to line up properly for a nested if and google's compiler messes up in exactly the same way... hmmm" -- or something like that).

Of course, this is just speculation. Still waiting for something resembling facts...

Prior art if there ever was

[SomPost]

I know of several Highlevel-to-Lowlevel language translators (e.g. Java-toC, Oberon-to-C, you name it) that have been around for decades. Surely, you cannot get a patent for doing the same thing with a different language, can you. Can you?!?

Compiling something to JavaScript in the browser environment is about as obvious as compiling to C on Unix. Case in point, here are a few other X-to-JavaScript compilers pulled off the top of my head: Python, Prolog, Oberon, etc. Seems pretty obvious to me. Not that that has ever prevented the US Patent Office from granting a patent, of course.

Well done.

[gowen]

Morfik's founders identified JavaScript as the limiting factor in the development of complex interactive Web-based software applications and decided to develop some proof-of-concept prototypes for the translation of a high-level language to JavaScript.

Congratulations, you've invented a programming language translator. I mean re-invented, obviously.

Can I suggest you invent a C-code to machine-code translator next (you could call it a "compiler"). It's the obvious next step in this genius innovation.

Struts did it first

[Aceticon]

The Struts framework (Struts, not Structs) used in the Java/J2EE world already does some JavaScript generation for client-side validation of form input for a couple of years now.

The truth is, the solution that Morfik came up with is actually one of the two most obvious (to any software designer level IT professional that has done any significat amount of web-interface software design and programming) solutions for the "JavaScript libraries are not 100% standard and the language (the official name is ECMAScript) is bug-prone" problem. The solutions being:

1. Code generation (either based in another language - best candidate being Java - or in configuration files)
2. Good JavaScript libraries and frameworks, possibly including some level of type checking of parameters

Given the state of the USPTO i wouldn't be surprised in somebody already patented both "inovations"...

Re:Who cares if it's bogus?

[suv4x4]

These guys may be gambling on being able to drag this case out to SCO's epic proportions

How easily we trust the news today.

What if I tell you that there's no "case", Morfik doesn't threaten Google with case, Morfik didn't even mention to have claims against Google's kit, and it's all a speculation created by an overly eager reporter who tried to read between the lines in one of Morfik's press releases?

Ok, is this IP infringement?

[Anonymous Coward]

Ok, is this IP infringement? Nobody knows!

Did Google had a close look at Morfik's technology? Yes!

Does GWT looks a lot like what Morfik has done? Having used Morfik WebOS ApsBuilder for a couple of months, and given the GWT demos and description: definitely YES!

And please keep in mind Morfik's tool has A LOT more nice things! It is like Visual Studio and like Borland Delphi but for the Web, i.e. true RAD development invironment! And yes, it supports not just Java, but c#, Pascal and VB. It can target both Linux and Windows WebServers. Go see yoursef!

Sto

Do Some Research

[MikeyTheK]

Well, it's good that many of you are so predictable. You have once again commented on something that you haven't even done the most basic research on in order to get a post listed sooner and mod-troll. So here goes: 1) Morfik is an IDE/RAD tool with a built-in PDF report writer, built-in web server (Apache) and built-in database (Firebird). The other tools to this point don't have any of these features. 2) Morfik allows you to write the code of your application using Java, C#, BASIC, or Object Pascal (client side or server side). You can also mix and match syntaxes to achieve whatever your goal is. It supports state-control, including the forward, back, and reload buttons, bookmarking, etc. so it doesn't break the functionality of your browser. GWT has Java support, and I believe supports state control, but I don't believe does it natively with a database, but I've only been playing with GWT since the public release, so I'm not 100% on this. 3) When Morfik was first featured on Slashdot a mere six months ago, it was met with skepticism and rancor. Now that Google has released GWT the /. tide has turned - apparently now that someone else has released a tool with a subset of the same features, it's obvious and uninteresting. Which is it? What a difference six months makes. 4) The issue isn't the release date of GWT vs. when they got a gander at Morfik. The issue is the start date of work on GWT, or Atlas, or whatever tool you're worried about vs. the date of the Patent application that everyone is complaining about, and the dates of the relevant documents that are cited in the application. Has anybody bothered to look either one up yet? Let's hypothetically say that the patent application was dated in March 2004. Now what? What about how all of this relates to Microsoft's progress on Atlas, or any of the other tools that are suddenly in development to build AJAX apps? 5) I don't see any of you asking what the relevant portions of the patent application are compared to the relevant features of GWT. Aren't these last two questions the ones that are really going to matter?

Re:How well does this cross-compilation work?

[arevos]

Actually, the grandparent poster has a point. Javascript is a dynamically typed language that makes liberal use of high level functions in more complex scripts. Due to Javascript's fluid nature, it would be difficult for a largely static language like Java to match it exactly. For instance, a class in Javascript is merely a function that dynamically constructs an object. One could roughly map a Java class to a Javascript function, but it would be difficult to the inverse. Java's rigid structure would be disadvantageous in this case.

Of course, one could just map the Javascript directly to a class file, and I believe Rhino does just that. However, that's not quite what the gransparent said, and even Rhino doesn't allow a flawless mapping from a Javascript class to a Java one (at least to the best of my knowledge). Classes in Java are just too static to entirely accomodate the more fluid Javascript object builder functions.