Talk:Java: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (+typo)
 
(14 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== J2ME and JavaME ==
== J2ME and JavaME ==
Now called JavaME... all this work on the language since the GPLing of Java has gotten Sun to realize how bloated their version is.
Now called JavaME...


=== CDC and CLDC ===
=== CDC and CLDC ===
The CDC is ~10M that implements all the key parts of Java. Getting an existing Java package (that might use Swing, for instance, which is not in CDC) to run under it should be much much faster than a port to Python.
The CDC is ~10M that implements all the key parts of Java. Getting an existing Java package (that might use Swing, for instance, which is not in CDC) to run under it should be much much faster than a port to Python. [https://phoneme.dev.java.net/downloads_page.html CDC implementation: '''phoneME'''].
::CLDC does not implement GUI by itself and must be extended to do this. If to go this way maybe Android could be more an option. Choosing unusual approach, however, may limit the number of developers that are ready to contribute for this platform and will not allow to run existing FOSS java software. [[User:AudriusA|AudriusA]] 15:46, 3 November 2009 (UTC)


=== GCJ and Eclipse ===
=== GCJ and Eclipse ===
Line 12: Line 13:




== OSGi ==
== Existing applicationsets ==
Remote fetching of functionality, allowing that to start/stop services and export this. You can manipulate dependencies between them... including calls out to find the start/stop routines. Talking to CDC about how to make lightweight apps and use cases (and libraries?) work together in a 'just in time' environment.
=== Educational packages ===
''see the main page''


See [http://thehereweb.googlepages.com/runningosgionthenokian800 this n800 page] for more on implementing OSGi and CDC at once.
=== Libraries and coding frameworks ===

''just supporting a JVM allows support of all languages currently supported; Scala, Python, JRuby...''

== Graphics acceleration ==
See [http://www.khronos.org/opengles/ OpenGL ES] and what the n800 w/CDC is doing.


== See also ==
* [http://molit.concord.org/database/activities/285.html more concord cons] sims
* communities around education and other activities.
* find mailing list folks: check w/ hinkmod, ad

=== Some cool apps ===
* G Maps mobile (G Earth?? mobile ;-)
* Gmail mobile
* JVM library (Utah State)

== Java IDE for OLPC? ==

Does anyone know here of a Java IDE that would be light for OLPC?

== We need to have priorities to reduce the footprint ==

I would say, if there is no space, lets drop GCJ and that is done. I likely have right to say so after two years of contributing to GNU Classpath when Java was not free. Sun's implementation is now FOSS and we should benefit from it. We must also realize that Java is no longer pushed by Sun as it used to be and if we do not push themselves we will miss the opportunity to have use of one of the most serious contributions ever made to the Free World.

Java is bundled with many tools and some of these seem not required in OLPC. Surely we need runtime environment and for the sake of Free Software we need a compiler. To produce .jar archives for applets, etc we need a zip tool that is likely already included. I suggest to drop all the rest.

About one third of standard Java classes can also be dropped if we do not violate any law by doing this. CORBA is now seldom used even by the most advanced developers, for instance and can be dropped (be this while I wrote it myself for GNU Classpath). Please forget about OSGI, SWT and so on - all this is '''really''' cool stuff but we can fill in all OLPC hard drive just with the stuff like this. I am also not fully convinced with JavaME as this is not the implementation that is mostly used on laptops at the moment and some even good Java developers, even here, do not know what it is and how to use it. Good text editor is needed with Java syntax highlight - likely already included. If there is enough space remaining after that the next candidate could be any Java supporting IDE. [[User:AudriusA|AudriusA]] 08:22, 3 November 2009 (UTC)

Latest revision as of 21:05, 11 November 2009

J2ME and JavaME

Now called JavaME... all this work on the language since the GPLing of Java has gotten Sun to realize how bloated their version is.

CDC and CLDC

The CDC is ~10M that implements all the key parts of Java. Getting an existing Java package (that might use Swing, for instance, which is not in CDC) to run under it should be much much faster than a port to Python. CDC implementation: phoneME.

CLDC does not implement GUI by itself and must be extended to do this. If to go this way maybe Android could be more an option. Choosing unusual approach, however, may limit the number of developers that are ready to contribute for this platform and will not allow to run existing FOSS java software. AudriusA 15:46, 3 November 2009 (UTC)

GCJ and Eclipse

GCJ can compile eclipse. It's an AOT rather than a JIT... it makes hacking less interesting, but a crosscompiling toolchain could be most useful.

SWT

Eclipse is built on this. Many people bring in SWT bindings for their platform (like GTK on Linux).


OSGi

Remote fetching of functionality, allowing that to start/stop services and export this. You can manipulate dependencies between them... including calls out to find the start/stop routines. Talking to CDC about how to make lightweight apps and use cases (and libraries?) work together in a 'just in time' environment.

See this n800 page for more on implementing OSGi and CDC at once.


Graphics acceleration

See OpenGL ES and what the n800 w/CDC is doing.


See also

  • more concord cons sims
  • communities around education and other activities.
  • find mailing list folks: check w/ hinkmod, ad

Some cool apps

  • G Maps mobile (G Earth?? mobile ;-)
  • Gmail mobile
  • JVM library (Utah State)

Java IDE for OLPC?

Does anyone know here of a Java IDE that would be light for OLPC?

We need to have priorities to reduce the footprint

I would say, if there is no space, lets drop GCJ and that is done. I likely have right to say so after two years of contributing to GNU Classpath when Java was not free. Sun's implementation is now FOSS and we should benefit from it. We must also realize that Java is no longer pushed by Sun as it used to be and if we do not push themselves we will miss the opportunity to have use of one of the most serious contributions ever made to the Free World.

Java is bundled with many tools and some of these seem not required in OLPC. Surely we need runtime environment and for the sake of Free Software we need a compiler. To produce .jar archives for applets, etc we need a zip tool that is likely already included. I suggest to drop all the rest.

About one third of standard Java classes can also be dropped if we do not violate any law by doing this. CORBA is now seldom used even by the most advanced developers, for instance and can be dropped (be this while I wrote it myself for GNU Classpath). Please forget about OSGI, SWT and so on - all this is really cool stuff but we can fill in all OLPC hard drive just with the stuff like this. I am also not fully convinced with JavaME as this is not the implementation that is mostly used on laptops at the moment and some even good Java developers, even here, do not know what it is and how to use it. Good text editor is needed with Java syntax highlight - likely already included. If there is enough space remaining after that the next candidate could be any Java supporting IDE. AudriusA 08:22, 3 November 2009 (UTC)