• ClasspathCurrentTopics

This page lists issues that summarize current problems or topics of GNU Classpath developmentresult or otherwise related information. If you add new issues please file them respectively under Programming or Non-Programming.

Index

Non-Programming related

• Update testing results of FreeSwingTestApps

• Release Preparation

  • ClasspathRelease096

  • ClasspathRelease097

  • ClasspathRelease098

Programming related

appletviewer and Applet testing

• Last edit: 2006-05-09 lillian
• Description: The appletviewer has been merged into classpath. There are still many applets that do not work properly.
• References:

  • Feel free to add your favorite applet links to this page.

Cleaning up graphics2D

• Last edit: 2005-06-27 mjw

• Description: See the ClasspathGraphicsImagesText page for how we want to move forward with graphics2D, gtk+/cairo, text and imaging.

Concurrent encoding/decoding frameworks

• Last edit: 2005-04-18 rschuster
• Description:

  • Historically GNU Classpath has a framework for doing byte<->char conversion that is being used for the classes of  java.io . This framework currently supports ASCII, all sorts of ISO-8859-*, as well as the UTF family.

    Unfortunately libgcj has another framework which targets the  java.io  classes. Besides some pure Java converters libgcj's implementation features a binding to  iconv  which is done using CNI.

    Finally the  java.nio.charset  package brings another framework which is for the NIO classes as well as the one in  java.io  (e.g. see 1.4 constructors for  java.io.InputStreamReader ). Due to Sven de Marothy's work the default NIO Charsets have been fixed and all Java IO Charsets have been converted to the NIO framework. Apart from this he has added support for some more obscure charsets and Unicode 4.0 character surrogates.

    The patch which makes java.io.InputStreamReader and java.io.OutputStreamReader completely dependent on the NIO framework was applied. A first batch of problems introduced by this patch were resolved now, but we seek more help in this regard. Please test applications that use the character encoding framework and report problems.

    Currently Sven works on a charset provider that uses iconv. Future work on the charset framework consists of:

    • Integrate the patches into GCJ and Kaffe

    • Implement the Bidi algorithm for java.text.Bidi

    • Add the 1.5-style character surrogate support in java.lang.Character

• References:

  • A mail quoting the plan to move to NIO charsets

  • GCJ's converter framework

  • A consideration of GCJ's converter framework

  • Crucial VM initialization considerations

  • Unicode 4.0.

  • Bidi algorithm

  • A whole Wiki dealing with Bidi

CORBA implementation

• Last edit: 2005-11-17 audriusa
• Description:
  • Since February 2005 Audrius Meskauskas is actively working on GNU Classpath's CORBA implementation. We invite any CORBA Experts to join this effort.

  • The CORBA implementation in the Classpath project is now a working prototype. On the 28 of June, 2005, the last class from the 1.3 API (BindingIteratorOperations) has been comitted. Finally, on the 18 of October, 2005, DynamicImplementation became concrete from abstract, finishing the formal implementation pattern for 1.4. Apart the omg.org, we have the gnu.CORBA with classes, implementing the specified CORBA functionality.

    • This prototype is interoperable with Sun's implementation v 1.4, transferring object references, primitive types, narrow and wide strings, arrays, structures and trees between these two platforms.
    • The prototype provides interoperable support for the Abstract interface and Value types. Those appear in 1.3, being a feature of CORBA 2.3.
    • The remote exceptions are also transferred and handled as expected.
    • The support for parsing stringified object references (IORs), both Big and Little Endian encoded, is implemented.
    • The redirection commands works, LOCATION_FORWARD_PERM changing the target address until the application is restarted and LOCATION_FORWARD redirecting for the current session only.
    • Both Little and Big Endian encoded messages are accepted. The encoding of the sent messages is the same as used in the stringified IOR reference of that object or Big Endian, if no such data available.
    • ORB.string_to_object supports ior:, corbaloc: and corbaname:. corbaloc: and corbaname: can be used with iiop: or rir:.

    • You can use both request-oriented (based on org.omg.CORBA.Request) and stream-oriented (based on org.omg.CORBA.portable.ObjectImpl) invocation models. The current release includes the working examples, demonstrating the client-server communication using both methods.

    • These examples also show, how to use the Classpath naming service.
    • The IDL compiler is not yet written (and not even started), but as a side effect of the required compatibility, the implementation seems accepting the output of the Sun's 1.4 idlj.
    • There are also a lot of classes for the later jdk 1.5+ versions. Not everything is comitted yet, because we try to test at least the basic functionality first.
    • We have newly written org.omg classes (based on the OMG .pdf documents). The documentation in many cases is more detailed than in Suns releases where some methods are not documented at all (see org.omg.CORBA_2_3.ORB, for instance).
  • The Portable Object Adapter is already released. The Portable object adapter (POA) provides deep control on CORBA request processing. The code, generated by the recent IDL to java compilers depends on available POA implementation, now generating servants and not CORBA objects as before. Implementing POA means that such code can already be tested for Classpath. Also, there is no longer need to download the obsolete IDL compilers from archive. Our POA supports the following usage scenarios:
    • POA converts servant to the CORBA object.
    • Servant provides to the CORBA object.
    • POA activates new CORBA object with the given Object Id (byte array) that is later assessible for the servant.

    • During the first call, the ServantActivator provides servant for this and all subsequent calls on the current object.

    • During each call, the ServantLocator provides servant for this call only.

    • ServantLocator or ServantActivator forwards call to another server.

    • POA has a single servant, responsible for all objects.
    • POA has a default servant, but some objects are explicitly connected to they specific servant.

  • We provide the implementation of the org.omg.DynamicAny package. ORB returns the working DynAnyFactory that produces working DynAny's as defined in OMG specification.

  • The PortableInterceptor and related functionality in other packages is now implemented:

    • The sever and client interceptors work as required since jdk 1.4.
    • The IOR interceptor works as needed for jdk 1.5.
    • Sun's IOR interceptor implementation benefits from our project by getting the bug report 6314176.
  • Classpath now includes the first working draft to support the RMI over IIOP protocol. The current implementation is capable for remote invocations, transferring data via RMI-IIOP protocol. It can flatten graphs and, at least for the simple cases, is interoperablewith Sun's jdk 1.5.

  • A number of interesting development tasks is still available, from challenging till relatively easy (see the CORBA task category in ClasspathOpenTasks).

  • The FSF has said that we can safely use these PDF files which describe a newer standard for the IDL to Java mapping. Sun used an older version of the standard but it was decided on #classpath that the newer one can be used because they are generally backwards compatible.

  • The Object Management group has officially assigned us 20 bit Vendor Minor Code Id: 0x47430 ("GC"). We must use this Id to mark remote Classpath - specific system exceptions that other applications may receive from our CORBA implementation, while working together. The group also requested from us a web page URL where we should describe that our exception codes mean and, if we want, provide other information, how to interoperate with our ORB. Thomas Zander suggested a good idea to create a small page with the short URL that will link to the Wiki based page CorbaInteroperability.

  • If no other tool cannot provide the IDL generator, we can always produce one ourselves and stuff it in classpath tools.

• CORBA applications frequently use various proprietary properties. We are currently start supporting the conversion of such programs by providing analogical properties in the gnu.CORBA namespace (see ClasspathMigration page for details).

• GNU Classpath versions since 0.20 will have the clear and simple RMI/IIOP system demo in the form of the Swing based multiplayer network game.

• References:

  • The OMG CORBA specifications we currently use

  • CORBA overview

  • Suggested OMG IDL to Java mapping specification to be used for GNU Classpath

  • Brian Sumner proposes to implement org.omg.CORBA

RMI implementation

• Last edit: 2005-03-29 audriusa
• Description: The GNU Classpath RMI currently provides the basic RMI functionality and is interoperable with other RMI implementations.
• The distributed garbage collector correctly talks with Sun's implementation about the object leases.
• Since the release 0.91, the activation system is also partially implemented, and some simple activation examples already runs. The system alrady can:

  • Activate Activatable.

  • Make the UnicastRemoteObject activatable.

  • Create the activatable remote object that does not extend the Activatable.

  • As necessary parts of the RMI activation system, we have implemented the RMI activation daemon (rmid) and the persistent RMI naming service. Client, server, rmid and naming service can all be restarted without loosing the currently exported remote references. These references are later activated on the first call, newly instantiating the server classes.
• Since 0.90 release GNU Classpath support the 1.5 API feature to replace the missing stubs by dynamically constructed proxy classes. The rmic code generator is only required for research and backward compatibility purposes.
• References:

  • Simple uses of the RMI activation system

  • Sun's RMI specification

Eclipse command line based code formatter

• Last edit: 2005-03-02 rschuster
• Description:
  • On 01.11.05 Ben Konrath announced his work on a command-line version of the Eclipse sourcecode formatter. It is planned to integrate the patch into Eclipse, add a GNU coding style which is available in the distribution and a Debian package for the formatter.

    Thanks to Ben Konrath the Eclipse Formatter for Java (EFJ) is available as of 02.28.05 from here.

• References:

  • Eclipse Bugtracker entry for the formatter

  • Initial announcement of a command-line version of the Eclipse formatter

  • Ben Konrath announcing the first working version of EFJ

Free Swing applications

• Last edit: 2005-10-06 rschuster

• Description: In order to check our Free Swing implementation we need some real world applications to test against. Look at FreeSwingTestApps to find them, add one you know of and describe problems you found.

• References:

  • Stuart requesting pointers to free Swing apps

Get rid of GdkPixbufDecoder

• Last edit: 2005-06-06 Sven_M
• Description: There are two ways of loading images in Java; Either use Toolkit or Component createImage() methods, or use ImageIO (from 1.4+).

  Currently we use the same native code (using the native gdk-pixbuf library), encapsulated in the GdkPixbufDecoder class. This class is a major kludge, and I'd like to see the issue cleaned up as follows:

  • The GtkImage class (which already can load itself from a local file) should have a constructor from a byte array, this should be used by the createImage() methods when Graphics2D is disabled.

  • An ImageIO service provider creating a BufferedImage should be implemented, either on gdk-pixbuf or using some other native library, and be ImageIO should be used by createImage() when Graphics2D is enabled.

  This will make the architecture simpler, since the Java2D parts and AWT-1.1 parts will be more cleanly seperated (GtkImage does all imaging for AWT 1.1, ImageIO takes over image loading for Java2D.) The code for loading images will be simpler and cleaner too, as it won't have to worry about producing different image types, nor will it have to use the ugly ImageProducer/ImageConsumer interface it does now.

  Previously an idea for an ImageMagick-based provider has been proposed as well. Since this library is more competent than gdk-pixbuf, it is an idea worth entertaining.

• Get rid of:

  • gnu.java.awt.peer.gtk.GdkPixbufDecoder

  • gnu.java.awt.image.ImageDecoder

  • gnu.java.awt.image.XBMDecoder
• Expand:

  • gnu.java.awt.peer.gtk.GtkImage

• Add:
  • gnu.javax.imageio.plugins.SOMETHING (?)
• References:

  • the sources

Preliminary implementation of 'javax.swing.text.html.parser' is complete

• Last edit: 2005-05-15 audriusa
• Description:
  • On 01.13.05 Audrius Meskauskas started the implementation of javax.swing.text.html.parser and closely related classes from javax.swing.text.html. The preliminary implementation of this package is now complete and should parse HTML 4.01. Same as in Sun's implementation, the Classpath parser is error tolerant and DTD driven. Chris Burdess provided a possibility to direct the output of this parser directly into the DOM model.
• References:

  • Announcement by Audrius

Online editable GNU Classpath documentation

• Last edit: 2005-04-05 rschuster
• Description:
  • GNU Classpath's documentation strives for being the best available knowledge resource for Java developers. However due to time and interest constraints it is hard for us to keep the documentation complete. Although we agree that the public documentation is an important aspect of our project there is no one dedicated to work on it.

    We had a discussion on IRC where the idea was presented to create an online editable version of our API documentation. Just like a Wiki it should be possible for everyone to add information to it. Furthermore a mechanism should be implemented that generates diffs which we can apply to our sources easily. Work on such a tool was started by an employee of the computer-science department of the FU Berlin and it will be offered as a topic for a diploma thesis. Another idea was to have some sort of expanded documentation that is not part of our Java sources but shows up in the online version. You could regard that as a Wiki that mirrors the structure of the source tree.

• References:

  • Classpath API documentation

Status of GNU Classpath's API documentation

• Last edit: 2005-01-24 rschuster
• Description:

  • On 01.09.05 Mark Wielaard applied patches to gjdoc which makes the generation of GNU Classpath documentation work again. He generated the HTML which can be viewed here. Any gnu packages have been left at the moment because we have to think long and hard which ones (gnu.regex, gnu.xml, gnu.java.net?) we want to encourage others to use. We will have to make sure we keep those classes and interfaces stable in the future in that case. For now we should tell people they are obviously free to use them however they want, but they can keep the pieces of the broken program if they rely on them. As you can see some documentation is already excellent. While others still need a lot of work. What we are really missing is good overviews to explain people where to start. It would be nice to have a kind of roadmap on the overview page where/how to start using the library to create some real world programs. Suggestions for layout, stylesheets etc. are very welcome. Plans have been uttered to generate the documentation automatically.

• References:

  • GNU Classpath API documentation

  • Mark's site for describing how to use gjdoc for GNU Classpath

  • Mark's mail about fixes for gjdoc to make it work again

Status of VM support for JNI function 'GetDirectBufferAddress'

• Last edit: 2005-04-09 rschuster
• Description:

  • From a user's perspective the ability to use Java NIO direct buffers depends largely on the support of the JNI function GetDirectBufferAddress, as it allows native and Java applications to conveniently access a shared area of memory.

    Apart from its possible internal usage e.g. for accessing memory mapped files, a number of third party libraries like JOGL and sdljava make use of it. The question raised on 01.06.05 wanted to find out the current status of support from the GNU Classpath and VM side of things.

    • JCVM currently lacks support for the function.

    • kissme returns  NULL  and prioritizes stability before adding newer features at the moment.

    These VMs are known to support the function:

    • IKVM

    • JamVM 1.2.4

    • GCJ (CVS and snapshots since February 2005)

    • SableVM 1.1.10

    • Kaffe (CVS head)

    On 2005-01-07 Michael Koch committed a patch from libgcj to GNU Classpath that fixes a problem with accessing the buffer's address if it is a view of a ByteBuffer. This means proper support for  GetDirectBufferAddress  will be possible with GNU Classpath 0.14 .

• References:

  • Initial question regarding the NIO support

  • A patch that fixes the Classpath side of things

Throwpoint audit

• Last edit: 2006-05-18 gbenson
• Description:

  • We need Mauve tests for all the calls to SecurityManager to ensure sure that all required calls are in place and functioning correctly.

• References:

  • Mostly complete list throwpoints

  • Mauve throwpoint tests status page

  • Some information on writing throwpoint tests

Classpath and Sun's GPLed javac

• Last edit: 2006-11-18 gnu_andrew
• Description:

  • Currently, building the GPLed release of Sun's javac requires a 1.5 compiler (ecj) and the generics branch of GNU Classpath from CVS (which includes a regular expression fix). The main problem at present is the need for a set of stubs to support sun.* classes used by javac. These are:

  •  sun.reflect.annotation.AnnotationParser 

  •  sun.reflect.annotation.AnnotationType 

  •  sun.reflect.annotation.EnumConstantNotPresentExceptionProxy

  •  sun.reflect.annotation.ExceptionProxy 

  •  sun.misc.ServiceConfigurationError 

  •  sun.misc.Service 

    The last two (from sun.misc) need to be fixed by Sun using the main Java API (currently in javax.imageio, but expected to be moved in 1.6) instead of internal classes. The others are more problematic, and I don't know of a solution at present. To get the compile to work, a set of stub classes can be used. We have only so far succeeded in running the compiler in order to obtain the help messages and version number. Trying to compile a class itself requires

    a VM that implements the new sun.misc.Unsafe API, as well as providing the regular expression fix mentioned above and using the generics branch. Current experiments so far have resulted in:

  • jamvm -- fails on the unsafe API

  • ikvm -- generics release of 0.30 fails due to missing regex fix, most recent

    • snapshot appears only to use HEAD. Need to try CVS.

  • cacao -- not tried, but the source doesn't show an implementation of Unsafe

  • gcj -- the eclipse branch has an implementation of Unsafe on generics,

    • currently in the progress of creating a build with the regex fix. An

      earlier build failed due to a bug in isEnum().