|
Authored by: Anonymous on Monday, May 21 2012 @ 08:04 PM EDT |
He's probably looking to see how much android fragmented java. [ Reply to This | Parent | # ]
|
|
Authored by: hardmath on Monday, May 21 2012 @ 08:08 PM EDT |
It seems evident that Google's duplication of functionality in the 37 accused
packages promotes interoperability. What other conclusion could be offered?
The real issue is with Google's decision _not_ to duplicate the entire set
JavaSE 1.5 Core API packages, or more plausibly the corresponding Apache Harmony
packages.
In any case the choice of the 37 accused packages was made by Oracle to maximize
their chances of winning copyright damages, and are not the appropriate basis to
evaluate the interoperability (or lack thereof) between Java and Android.
---
"Prolog is an efficient programming language because it is a very stupid theorem
prover." -- Richard O'Keefe[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Monday, May 21 2012 @ 09:25 PM EDT |
As someone pointed out, it isn't really the applications &
programs that are important - it is the ability to
continue using 3rd party libraries too - that all depend on
the same core Java APIs.
One example is the JUnit testing library, but there are a
host of other packages.
Applications and programs, on the other hand, are highly
*unlikely* to run without a change - if only for the fact
that the UI package is going to be very different. [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Monday, May 21 2012 @ 10:08 PM EDT |
There are more than 37 packages in common, at least 51, but 37 is all that
Oracle can claim because Sun/Oracle Java contains many packages that are not
owned by Oracle.
In any case it is not necessarily about _program_ portability, it is also about
_programmer_ portability.
Others have made the point that the UI on Android is completely different from
the many and varied Sun/Oracle UIs: Swing, AWT, LWUI etc, there are many user
classes (parts of a program) that rely on the Java API and could run unchanged
on Android even if the UI classes need changing.
Sensible large programs should be built up of many classes some managing the
database, some doing business processes, some doing UI.
[ Reply to This | Parent | # ]
|
|
Authored by: indyandy on Tuesday, May 22 2012 @ 12:12 AM EDT |
Groklaw - A
Sun Position Paper on Software Patents, 2006 ~pj
Sun's
Position:
-
Throughout Sun's history, we have stood for open
systems, open standards and we have been fighting hard for
interoperability in our sector.
-
Sun believes in innovation
and invests billions of Euro each year in software development. We believe in
protecting these investments.
-
However, Sun believes that this
protection should be balanced to allow for the creation of products which can
interoperate with the protected products to safeguard competition in the
sector and to provide greater choice and lowers costs for consumers.
-
Interoperability is of crucial importance to preserve choice for European
consumers between competing offerings, and to preserve the equality of
opportunity that the European IT sector needs to flourish.
-
Regardless of whether CII patents are desirable to foster innovation in Europe,
if such patents could be used to prevent software vendors from developing new
programmes which can communicate with other programmes used by the customers,
users may find themselves locked into buying programmes from only one vendor.
This would result in increased cost and reduced choice for consumers while also
hindering the growth of the overall EU market for computer implemented
inventions.
-
To avoid stifling innovation and reducing users'
freedom of choice, Sun believe that an interoperability exception is needed in
the draft CII Directive.
-
Article 6 proposed by the European Commission,
and incorporated into the Council's Common Position, is needed to stop patents
on software from preventing developers from engaging in the processes of reverse
engineering permitted under the 1991 EC Software Copyright Directive for the
purpose of achieving interoperability. However, although Article 6 allows
for the development of products through reverse engineering, it does not allow
for the manufacture, sale and use of such products without a license from the
right holder. This effectively leaves existing dominant rights holders with a de
facto veto over new and competing products.
-
More generally, even for
products which are not produced through reverse engineering, an Article 6a is
needed because without it software patent holders could invoke their patent
rights to prevent the production and sale of software which will interoperate
with the patented and other software.
-
Sun therefore proposes a new
Article 6a which addresses this problem by providing a narrow exception
permitting the use of patented technology to the extent "indispensable" for the
development and sale of products which interoperate with the products protected
by the patented technology or with other products.
-
Sun believes this is
a limited, well-defined and clear exception to the exclusive rights of patent
owners which strike a proper balance between the legitimate interests of patent
rights owners and third parties, including both third-party software developers
and end-users.
(My emphasis) [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Tuesday, May 22 2012 @ 01:42 AM EDT |
J2SE apps would not run unmodified in J2ME. Does J2ME fragment Java? [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Tuesday, May 22 2012 @ 10:40 AM EDT |
Google has said time and again that they had to implement the 37
packages in order that prior code written to utilize those packages can still do
so.
Although Google has said that many times, the Judge can't
just take their word for it. He's asking for proof. What prior
code used it, with specifics. What subsequent code used it, with
specifics.
This is where the Android community could help out, and come
forward with a number of specific examples that demonstrate
interoperability.
Here are some examples of open source (LGPLv2, BSD,
Apache, et. al.) Android projects that use Java for
interoperability:
- AndEngine
- cocos2d-android
- SDL This is the purest case of a library
written in C, that uses Java bindings for interoperability between the C code
and the Java language.
- rokon
- libgdx This is another pure case of
an Android library using Java for interoperability. The library itself is
Android/Java and allows the developer to do all testing and development purely
in Java, and when complete create an Android or Java final version. It's must
faster than testing on the Android emulator.
There are many, many more
examples out there in both the opensource and commercial
world.
--nyarlathotep [ Reply to This | Parent | # ]
|
|
|
|
|