Re: [cp-patches] KerberosPrincipal - Try number two
Jeff == Jeff Bailey [EMAIL PROTECTED] writes: Jeff I've attached my most recent version of KerberosPrincipal. I have Jeff addressed most of the comments by Casey and Mark as well as comments Jeff from others online. Jeff String a = gnu.classpath.SystemProperties.getProperty(java.security.krb5.realm); It is more usual in Classpath not to use a fully qualified name, but instead to add an import. Jeff return new ; This isn't valid java. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-testresults] FAIL: regressions for libgcj on Wed Dec 28 10:53:59 UTC 2005
Baseline from: Wed Dec 28 03:22:15 UTC 2005 Regressions: FAIL: Thread_Sleep -O3 output - bytecode-native test FAIL: Thread_Sleep -O3 output - source compiled test FAIL: Thread_Sleep output - source compiled test Totals: PASS: 3375 XPASS: 0 FAIL: 3 XFAIL: 10 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for libgcj on Wed Dec 28 18:31:44 UTC 2005
Baseline from: Wed Dec 28 03:22:15 UTC 2005 Regressions: FAIL: Thread_Sleep -O3 output - bytecode-native test FAIL: Thread_Sleep -O3 output - source compiled test FAIL: Thread_Sleep output - bytecode-native test Totals: PASS: 3375 XPASS: 0 FAIL: 3 XFAIL: 10 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for libgcj on Wed Dec 28 22:17:22 UTC 2005
Baseline from: Wed Dec 28 03:22:15 UTC 2005 Regressions: FAIL: Thread_Sleep -O3 output - bytecode-native test FAIL: Thread_Sleep output - source compiled test Totals: PASS: 3376 XPASS: 0 FAIL: 2 XFAIL: 10 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
RE: proposed plan for moving GNU Crypto to Classpath
Casey Marshall wrote: I'd prefer to keep .in files to a minimum. We could attain the same thing by using reflection for the parts that may or may not be available or are disabled at compile time. I agree. At the moment it is possible to compile Classpath without using any of the build infrastructure, IMO we should aim to keep it that way. Are there any opinions about adding test suites to Classpath? It seems to me like that had been abandoned in favor of an external test suite (Mauve). Mauve is definitely the place for tests. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [GNU Crypto] Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
hello Anthony, On Monday 12 December 2005 20:52, Anthony Green wrote: On Mon, 2005-12-12 at 20:48 +1100, Raif S. Naffah wrote: would adding a second Provider --that supplies the strong stuff; i.e. ciphers, modes, padding, etc..-- living in its own package sub-directory/hierarchy and eventually (when the segmentation of Classpath into multiple jars occur) be packaged in its own jar help solve your problem? Yes, that would be nice. looking at the current Classpath package structure and classes, i see that an implementation of a Cipher using RSA is already included. those are normally part of the javax.crypto strain. do you strip those out when you package your export-controlled applications? cheers; rsn pgpBcUaqmp7QO.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: proposed plan for moving GNU Crypto to Classpath
Casey Marshall wrote: On Dec 27, 2005, at 8:49 AM, Raif S. Naffah wrote: I'd prefer to keep .in files to a minimum. We could attain the same thing by using reflection for the parts that may or may not be available or are disabled at compile time. Yes, please. I'd also like to avoid having more *.java.in files than absolutely necessary. * when classes from GNU Crypto, rely on AWT or Swing, they will be re-written as templates conditioned by existing Classpath configuration option(s). Why is that needed? Aren't AWT and Swing still available, even if no native peers are compiled? Yes, they are still available. The AWTCallbackHandler may not work properly without a peer implementation, but that should be the concern of the person disabling the native peers. For example, the user may want to supply their own peer implementation, instead of GNU classpath's implementations. Are there any opinions about adding test suites to Classpath? It seems to me like that had been abandoned in favor of an external test suite (Mauve). I'd prefer to see all tests go into Mauve. It is much easier to use than runtime/library specific test suites, as anyone who has tried to run kaffe with libgcj's test suite or vice versa can confirm, I guess :) I had put together my own proposed patch set, and sent a message about it from an address that needs approval for classpath-patches (I'm writing this over a slow VNC connection). It's rather simpler than this, and mostly just involves renaming gnu.crypto to gnu.javax.crypto, and org.metastatic.jessie to gnu.javax.net.ssl, and adds a configure switch to disable compiling crypto classes (I'd rather avoid doing a lot to support export control, because AFAIK only one person needs it (sorry, Anthony ;-) and it is more infrastructure to maintain). It may make sense to bifurcate GNU Crypto into weak and strong eventually, however. The patch is at http://metastatic.org/source/gnu-crypto- jessie.patch and a tarball of new files at http://metastatic.org/ source/gnu-crypto-jesise.tar.gz. Thanks, Casey! cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
javax.swing.JComboBox
Hi,
in javax.swing.JComboBox.contentsChanged:
{
// if first and last index of the given ListDataEvent are both -1,
// then it indicates that selected item in the combo box data model
// have changed.
if (event.getIndex0() == -1 event.getIndex1() == -1)
selectedItemChanged();
}
it handles when the indexes are both -1, but it doesn't seem to handle any
other case. Is this indeed the correct behavior? In particular, this seems
to break MetalFileChooserUI, because
DirectoryComboBoxModel.setSelectedItem() always calls fireContentsChanged
as
fireContentsChanged(this, 0, items.size() - 1);
So, basically, when the popup list calls JComboBox.setSelectedIndex(...),
JComboBox never calls selectedItemChanged(), which never lets the listeners
in MetalFileChooserUI know that the selected item has changed.
Does this seem right?
DefaultComboBoxModel.setSelectedItem(...) is:
{
if (selectedItem == null)
{
if (object == null)
return;
}
else
{
if (selectedItem.equals(object))
return;
}
selectedItem = object;
fireContentsChanged(this, -1, -1);
}
which is why anything which uses the default model works.
Incidentally, if you modify contentsChanged to run selectedItemChanged() on
other than -1, -1, you seem to get an infinite loop. I think that this is
fixable, however, if you put checks into MetalFileChooserUI's
DirectoryComboBoxAction.actionPerformed to only change the directory and
rescan if something has actually changed. I haven't verified this yet,
though.
Thanks,
-Chris
--
Let us endeavor so to live that when we come to die even the undertaker
will be sorry. -- Mark Twain, Pudd'nhead Wilson's Calendar
== Evil Overlord Quote of the Day (www.eviloverlord.com) =
217. If I'm wearing the key to the hero's shackles around my neck and his
former girlfriend now volunteers to become my mistress and we are all
alone in my bedchamber on my bed and she offers me a goblet of wine, I
will politely decline the offer.
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
