Submitted On 03-JUL-2001
mort
Are you crazy? It is *intentional* that it throws
exceptions?
If a webpage is loaded with a large paragraph, it is
*acceptable* that the page should fail to load and throw an
exception?
Submitted On 21-JAN-2002
holbrng
I am trying to use a TextPane to view log files, and get
the same problem.. The file has about 260000 characters in
it, and I don't believe it has any lines in it anywhere
32767 characters. All lines have \n linefeeds, and I blow
up every time I load. This NEEDS to be resolved.
Submitted On 19-JUN-2002
volkenborn
Well, thank you, pals!
This Error (note that it's not just an exception but an
error) almost terminated a project we are trying to sell!
Try displaying a 60K sized, concatenated BASE64-encoded
String with JEditorPane, and try to figure out why the
application goes haywire!
If you would at least catch this error internally and throw
a reasonable exception, I could see your point, but the way
you approach this bug right now is plain ridiculous!
Even Lotus Notes didn't expect this behaviour and won't let
you access mails with paragraphs this long... I too suggest
you ought to rethink this issue.
Submitted On 30-SEP-2003
eliasen
I have filed another bug with Sun, including outlining the
workaround described here that requires no more memory.
Hopefully they won't close it and ignore customer input when
a win/win solution obviously exists.
Submitted On 30-SEP-2003
eliasen
Your customers don't feel that this is a reasonable
restriction, much less a reasonable implementation. The cast
to short blindly and silently loses data. Code like this
should never be allowed in what is supposedly a
production-quality system.
This entire problem could be very easily resolved by simply
performing an architectural tweak:
1. Make GlyphView an abstract class.
2. Make two (or more) subclasses of GlyphView; one that
stores offset and length as short (if memory savings are
that important) and one that stores them as int (so you can
actually do what your public interface indicates you can do,
and not lose data.) Call them, say, GlyphViewShort and
GlyphViewInt.
3. Make createFragment(int p0, int p1) in GlyphView a
factory method that constructs the appropriate-sized
GlyphViewShort or GlyphViewInt depending on the size of p0
and p1.
4. Instead of explicitly calling the GlyphView constructor,
create and call a factory method that constructs the
appropriately-sized GlyphView.
5. Instead of accessing length and offset directly, access
them with a method int getLength() and int getOffset().
Thats it. It's that easy. It should take no more than 5
minutes to make all of your customers happy.
That's a lot better than telling your customers that their
code is unreasonable (even when you don't know what they
need to do,) and fail silently, or bomb out horribly if the
sign bits are wrong when you cast to short.
Submitted On 30-SEP-2003
eliasen
If you *really* want to save space for short paragraphs, you
can make a derived class GlyphViewByte that stores offset,
length, and that poorly-named variable "x" into bytes if
they're all small enough to fit.
I also noted in the other bug report that exceptions/errors
aren't thrown reliably--this can simply cause silent failure
too.
Submitted On 02-DEC-2003
eliasen
After I filed the bug on this, along with a solution on how
to fix it for real, Sun never responded. Good job, guys.
If anyone at Sun can justify how a blind, narrowing cast to
short is a good idea in production code, please let us know.
Again, I'll be happy to give you a much better solution
(that not only works in all cases, but saves *more* memory
than your bad bugfix here) as I outlined in the bug report I
filed.
Submitted On 08-MAY-2004
eliasen
To be fair, Sun did respond--almost seven months after I
filed the bug report. They indicate that this bug was fixed
in JDK 1.5.0 beta, and it seems to be. I'm doing Sun's job
for them and indicating that here, as they haven't.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
