Re: GNU Classpath Linuxtag meeting minutes
Andy Walter wrote: On Monday 14 July 2003 18:08, Per Bothner wrote: Mark Wielaard wrote: - [NotYetImplementedException] In the gcj list I suggested UnsupportedOperationException, with a refinement: throw new UnsupportedOperationException (REASON); where REASON is a string literal that includes not implemented and all on a single line (to make it easy to grep for). What about subclassing UnsupportedOperationException like this: Thus, we make sure the user always receives a helpful description and it is easy for VM implementations to replace the contact information by whatever else. I prefer grepping for class names to grepping for strings because there are no undetected typos in class names. I agree with Andy, classes are nicer, since the compiler checks that the names are actually correct. But since we also talked about attracting new contributors on our meeting, I'd like to propose a sightly modified message string: static String nyi = This method has not yet been implemented in GNU Classpath.\n\n + The GNU Classpath project would appreciate receiving + an implementation for it.\n + If you intend to contribute, please take a look at + http://www.gnu.org/software/classpath/docs/hacking.html and + get in touch with other developers on [EMAIL PROTECTED]; I hope that we could get more contributors fixing small missing bits that way. I guess people who dearly want to use a missing feature shouldn't be that hard to convince to implement it ;) cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath Linuxtag meeting minutes
On Tuesday 15 July 2003 15:36, Dalibor Topic wrote: - [NotYetImplementedException] static String nyi = This method has not yet been implemented in GNU Classpath.\n\n + The GNU Classpath project would appreciate receiving + an implementation for it.\n + If you intend to contribute, please take a look at + http://www.gnu.org/software/classpath/docs/hacking.html and + get in touch with other developers on [EMAIL PROTECTED]; Thanks, Dalibor. This message string seems more suitable for GNU Classpath than my proposal. Cheers, Andy. -- aicas GmbH /\ ASCII Ribbon Campaign Haid-und-Neu-Straße 18 * 76131 Karlsruhe \ / No HTML or RTF in mail http://www.aicas.com X No MS-Word in mail Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 / \ Respect Open Standards ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath Linuxtag meeting minutes
On Monday 14 July 2003 14:39, Sascha Brawer wrote: Mark Wielaard [EMAIL PROTECTED] wrote on Mon, 14 Jul 2003 00:46:08 +0200: - Aicas is working on some RMI fixups. In the context of RMI, maybe not everyone knows that there also exists a variant which does RMI over IIOP. It uses the CORBA protocol for RMI, but without using CORBA IDL. [...] http://java.sun.com/products/rmi-iiop/ Thanks for the link, Sascha. For the time being, we'd like to get standard RMI running with GNU Classpath. RMI IIOP might be an interesting approach after that. Cheers, Andy. -- aicas GmbH /\ ASCII Ribbon Campaign Haid-und-Neu-Straße 18 * 76131 Karlsruhe \ / No HTML or RTF in mail http://www.aicas.com X No MS-Word in mail Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 / \ Respect Open Standards ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath Linuxtag meeting minutes
Mark Wielaard [EMAIL PROTECTED] wrote on Mon, 14 Jul 2003 00:46:08 +0200: http://www.dandelis.ch/development/fonts/ I've updated the page to reflect the current state. I did not bother updating the code snapshot, since I'd like to clean up things and bring my implementation a bit further. If you want the code right now, please write me. Tim Tyler his public domain, pure java font rendering program was mentioned http://fonteditor.org/ I've written to Tim, and he said he would not mind us using his code. I'll make sure that the legal issues get resolved; Mark receives a copy of everything. - Aicas is working on some RMI fixups. In the context of RMI, maybe not everyone knows that there also exists a variant which does RMI over IIOP. It uses the CORBA protocol for RMI, but without using CORBA IDL. Actually, CORBA had to be extended to cope for this, but it now is part of the standard. Of course, I don't know whether this is relevant for Aicas -- in any case, [1] has more information. But implementing RMI-IIOP seems like a big task, unless parts of some free Java ORB can be used. IMHO, the main advantage is that IIOP is a better protocol, and that it is possible to replace either client or server by something not written in Java. There exist CORBA bindings for relatively exotic languages, including Lisp, Ada, Objective C, or Smalltalk. There also is an LGPLed project for IIOP on .NET [2]. - We should have a standard NotYetImplementedException. Just returning something random (like null) from stubs is really not acceptable. Kaffe for example has one. What about java.lang.UnsupportedOperationException? - We really have a complete framework now to run significatly large applications. Getting semi-free application written in the java language (but which currently uses a proprietary runtime environment) running with a free VM is a great way to test and/or expand our classes and keeps us focused on the needs of free software developers. Georg Greve said at LinuxTag that he would not mind including a text about Classpath in one of the next issues of Brave GNU World. I've heard that [3] was perceived by some people as a statement that Free Software developers should stay away from Java, although the text doesn't say this. IMHO, we'd best send him a draft text for the column -- any volunteers? I think this would be important. [1] http://java.sun.com/products/rmi-iiop/ [2] http://www.gnu.org/brave-gnu-world/issue-49.en.html [3] http://iiop-net.sourceforge.net/ Best, -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath Linuxtag meeting minutes
Mark Wielaard wrote: - We should have a standard NotYetImplementedException. Just returning something random (like null) from stubs is really not acceptable. Kaffe for example has one. In the gcj list I suggested UnsupportedOperationException, with a refinement: throw new UnsupportedOperationException (REASON); where REASON is a string literal that includes not implemented and all on a single line (to make it easy to grep for). See http://gcc.gnu.org/ml/java/2003-03/msg00016.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
GNU Classpath Linuxtag meeting minutes
GNU Classpath meeting minutes
LinuxTag, 12 July 2003, Karlsruhe (Germany)
Present
- Dalibor Topic (Kaffe)
- Sascha Brawer (GNU Classpath)
- Mark Wielaard (GNU Classpath)
- Andy Wolter (Aicas)
- James Hunt (Aicas)
- Ingo Proetel (Aicas)
Sascha was the most organised and said someone should actually make
notes, so here they are. Some of the notes were made in the Biergarten
so take them with a grain of salt... I have surely forgotten something
important. And sometimes I couldn't clearly remember the context of my
notes. My applogies. If you were present and have more details please
follow up with clarifications and additions.
- Sascha has been working on font reading and rendering, see his very
detailed architecture document, which describes all issues involved
http://www.dandelis.ch/development/fonts/.
Tim Tyler his public domain, pure java font rendering program was
mentioned http://fonteditor.org/
Adam Megacz of http://www.xwt.org/ also needs this
http://gcc.gnu.org/ml/java/2003-07/msg00036.html.
- For the above and AWT/Swing in general the issue of
accessing/mapping frame/display buffers came up multiple times. What
interface should be defined for mapping these (java.nio JNI
additions?).
- OpenGL seems to have all the 2D drawing primitives that you ever
want and implementations are widely available.
- Aicas wanted to know who are interested in the Realtime specs being
discussed in the OpenGroup and the jconsortium
http://www.opengroup.org/rtforum/rt_java/
http://www.jconsortium.org/ Thet were also looking for
participants in an open European standards project (which name I
forgot to write down).
- Aicas is working on some RMI fixups. During the discussion it came
up that since object streams use serialization and serialization
uses reflection, this only will work if you get all the details of
reflection right. It was pointed out that reflection has some
underspecified issues/bugs, for example see this note from Kissme
(Class.getModifiers):
// Arrays are always final and never an interface.
// And also abstract (but that is actually a bug
// - see JDC Bug: 4208179)
// It matters for serial version UID calculations :{
There was much complaining about the broken design of the RMI
protocol. It was suggested to look at how RMI can work on IIOP which
is cleaner.
- Sascha suggested to create a list of such issues and publish a list
for GNU Classpath users/VM implementors of
tricky/underspecified/buggy specs.
- Mark wants to extend the VM interface with more VMState package local
final classes like to JRVM people just did for a couple of java.lang
classes to make it easier to use GNU Classpath with non-JNI/Posix
based VMs.
- The plan for character encodings is to move to the java.nio.charset
interface. We already have required encodings for this. But GNU
Classpath and gcj both still also have their old implementations
(which are actually used in most places). gcj also has a libiconv
provider (but not as java.nio.charset provider). A java.nio.charset
libiconv provider would be nice to have for those systems that
have that library.
- Mark and Dalibor wanted to name next month Mauvegustus and clean up
Mauve (it still contains some bogus/broken tests) and import as much
tests from the different projects that have non-standard core
library tests so they can be more easily shared between the
different projects. Ingo dared Mark to create a Mauve plugin for
Eclipse now that we have it running like the standard JUnit
plugin. (The JUnit framework uses lots of reflection which we don't
want to use for Mauve.) Other ideas were to create a standard JNI
testsuite and maybe security issues/holes tests.
- Acias has property files which lists which class/method needs which
other class/method. This is nice when you are use smart or static
linking of classes.
- Kaffe has split up their library in different profiles (core, awt,
xml, sound, rmi, etc) it would be nice if GNU Classpath also
provided this. We could deliver different jar files.
- We need to update/document the state of each package. It is not
really clear how much has been implemented, signature complete
(japitools), tested (has mauve tests), how compliant with which
spec, etc. packages/classes are. Problem is that we don't have
gatekeepers anymore per package (we had this in the past, but
developers on the project changed and the number of supported
packages has actually exploded).
- The above is also important to show what people can do to help the
project. We really need to setup a more visible task list then the
current Savannah one with task people could do for the project which
are annotated with how hard it would be it (simple - follow
existing example, like image provider or new character encoding,
medium - add something to an existing framework, like jar file
verification for ZipFile, hard - add complete new package or
