Authored by: Anonymous on Thursday, May 24 2012 @ 08:28 AM EDT |
I suspect this may be accurate due to the J2SE applications having a main
function while android does not.
Libraries on the other hand will quite happily run on both platforms as long as
they only use the common apis.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 08:53 AM EDT |
Ju-u-u-u-dge A-a-a-alsup!!!!
bkd[ Reply to This | Parent | # ]
|
|
Authored by: Henning Makholm on Thursday, May 24 2012 @ 09:14 AM EDT |
It worries me that the judge's questions to the parties seem to focus so much on
portability of entire programs.
In my view it is much more
important the parts of programs can be reused without extensive
rewriting. For an application provider, it is one thing to need to write a new
UI frontend of your app for each platform you support -- but it is an entirely
different level of a maintenance nightmare if even the functional core of what
the application actually does cannot share code between the different
platforms you support -- say, if String.substring() had to have a different name
on each platform for copyright reasons.
Unsurprisingly Oracle has tried to
steer their case away from this fact, but I wonder why Google hasn't made a
better effort to keep this very important kind of portability in the foreground. [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 09:38 AM EDT |
Yes, "So what?".
Challenge answered, clearly.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 09:42 AM EDT |
Why does it matter? Android isn't Java no matter how many times Oracle says it
is. Google doesn't call it Java and it never was submitted to the
compatability test. I don't understand the purpose of the question.[ Reply to This | Parent | # ]
|
|
Authored by: DannyB on Thursday, May 24 2012 @ 11:55 AM EDT |
There are many large libraries for J2SE that are used on Android as is.
If you consider a library a "program", then yes, significant, large,
non-trivial software packages written for J2SE run as is on Java.
I think that was Google's intent. Otherwise it would not have implemented the
necessary underlying API's.
---
The price of freedom is eternal litigation.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 01:29 PM EDT |
A library for building the same source for Android or desktop java:
libGDX
Libgdx
is an open-source effort, started by Mario Zechner (aka badlogic) in late
2009/early 2010. In it's original form it was an attempt at a rapid prototyping
library which avoids the painfully slow development cycle usually encountered
when creating pure Android applications. The goal was to be able to work mostly
on the desktop, and only deploy to the emulator/a device when absolutely
necessary. That turned out to work pretty well it seems.
Libgdx now is a
multi-backend, cross-platform game development library which is not only
targeting Android but can also be considered a viable framework for desktop
applications (stand-alone, applets, Webstart). It's also become a team effort
and would not be were it is without the great people that have joined the
project over the last year.
[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 02:48 PM EDT |
What is the difference between "application" and "program"?
Anyway, the statement of Oracle is deeply dishonest. Why? Because no one in
his/her right mind would ever want to run the complete J2SE application on
smartphone as it is.
Let's see what kind of J2SE apps do we have:
1. J2SE Command line apps. Anyone keen for a smartphone with a DOS window? I
already envision how people throw away their iphones...
Actually it would be fairly easy to provide, you just need a virtual terminal
(several already exist) and launcher. And of course a bytecode translator,
because google was not allowed to use sun JVM.
2. J2SE AWT and Applets. As we clearly see in our everyday life java applets and
AWT based apps are extremely popular all around the internet and PC's. What a
sucessful technology it is. And sinister google just frangmented it out. Think
about it...
3. J2SE SWING. Not resting on AWT laurels Sun developed another fine piece of
GUI toolkit. Extremely rich, quick, slick, easy to use and incredibly popular.
As it and the apps written using Swing were developed for desktop size displays
(like 14" and way up) with mouse and keyboard, it is perfectly suited for a
tiny touchscreens found on most of the smartphones (ca. 4").
Microsoft already viability of such approach with their WindowsMobile which even
crushed mighty iphone.
4. J2ME - it is not a J2SE and won't run J2SE apps. And vice versa, J2SE is
unable to run apps written for J2ME. So Android does not fragment platform any
more or less than Sun themselves.
That's about it. Anyone keen to have any of this running on their smartphones?
Now to the really important things: the existing frameworks and libraries
written in Java.
As a developer which actually uses Java and Android I would claim, that: the
Android would "run" most of the libraries smartphone developers
actually care about. Thanks to those 37 APIs. This was the whole point of using
this programming language. And they mostly succeeded.
Of course, you would have trouble to run something requiring RMI or CORBA or
something like this, but it would be a perfect excuse to check sanity of someone
who would want to use this on the smartphone.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 02:49 PM EDT |
// the code below is written in invisible characters to protect it from
unscrupulous exploitation as a test program to evaluate the speed of any virtual
machine that it is capable of executing on. Your MIPS May Vary. (;[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, May 24 2012 @ 03:08 PM EDT |
The point of having the 37 APIs is that you can take a large
portion of your existing code and wrap an Android interface
around it. Nobody is taking pre-existing Java programs and
putting them unmodified on Android, and its preposterous to
suggest they are. What they are doing is rewriting 5% or 10%
of their Java programs, which everyone likes more than
rewriting 100%.[ Reply to This | Parent | # ]
|
|
Authored by: symbolset on Friday, May 25 2012 @ 12:46 AM EDT |
This seems to be difficult to understand. Java is many things and Android is
none of them.
"Java" is a trademark jealously protected by first Sun and now
Oracle, and while using the Java mark was an option considered by Google early
on, that consideration had nothing to do with Android - but with basing phones
on the entire Java platform including the mark as in "super-feature phones".
The purpose of protecting this mark is to insure the productivity of people who
learn Java. Microsoft ran afoul of this by labeling their "Java" with the Java
mark and then failing to comply with the compatibility requirements. Android
doesn't have Java compatibility requirements because Android is not
Java.
Java is a virtual machine - actually several virtual machines, that
interpret bytecode and have earned the "Java" mark through validation with the
proprietary test suite. Android uses the Dalvik virtual machine which is not
compatible with this, was never intended to be, and never will be. Dalvik is
not a JVM (Java Virtual Machine) though it shares many similar properties with
them, it lacks the required compatibility conformance tested against the
mandatory proprietary test suite (which comes with its own obligations) because
it is intentionally different (nonstandard and noncompliant) and so could not
ever earn the "Java" mark. Dalvik is sometime referred to in metaphor as a JVM
because it's a difficult linguistic construction to say "A virtual machine that
interprets Java byte code like a JVM that isn't a JVM." Dalvik never was
intended to execute Java byte codes. Dalvik executes Dalvik byte codes which
are similar but not the same.
Java is also a programming language.
Android applications can be written in the Java programming language, of
many different possible programming platforms. Some parts of the Android
platform are written in the Java Programming language. The Java programming
language, like human languages, doesn't have any requirements for conformance
other than that people who speak one dialect of it most easily learn least
deviant dialects of it - and all forms of it evolve over time based on use.
That's what the word "language" means - it's an evolving framework for
connecting symbols with referents. A language is, if I may say so, a
symbolset and the importance of this is how I chose my nym. It's
easier for a Texan to speak with a Bostonian than to learn the verb forms of
Urdu. Languages don't have any IP protection, unless they involve patented
methods designed in, which would be a certain course to designing a failed
language - who wants to learn a language that requires someone's permission to
speak it?
Regardless, if the platform were required to be named after the
programming it were written in then Windows would be called "ASM/C/C++/C#" and
Unix would be called "ASM/C" and nobody knows what we'd call Ubuntu. The
programming language does not make the platform.
Android is not "Java" the
trademark and was never claimed to be. Android is not "Java" the virtual
machine and was never claimed to be. Android is not Java the programming
language any more than your car is unleaded gasoline. Android is not
Java. [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Friday, May 25 2012 @ 02:56 AM EDT |
Must be some really important legal argument turns on this because people keep
hammering away on this point when most of us can't see what the big deal is. If
you want your app to run on a smartphone you are going to want to tweak it
anyway. Different interface for a start. [ Reply to This | Parent | # ]
|
|