You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by ml...@apache.org on 2006/04/20 14:46:47 UTC
svn commit: r395576 -
/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
Author: mloenko
Date: Thu Apr 20 05:46:47 2006
New Revision: 395576
URL: http://svn.apache.org/viewcvs?rev=395576&view=rev
Log:
fixes for HARMONY-374
java.io.RandomAccessFile.seek(int pos) does not throw IOException if pos < 0
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java?rev=395576&r1=395575&r2=395576&view=diff
==============================================================================
--- incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java (original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java Thu Apr 20 05:46:47 2006
@@ -614,6 +614,9 @@
* occurs.
*/
public void seek(long pos) throws IOException {
+ if (pos < 0) {
+ throw new IOException("seek position is negative");
+ }
openCheck();
synchronized (repositionLock) {
fileSystem.seek(fd.descriptor, pos, IFileSystem.SEEK_SET);
Re: Internationalized messages
Posted by Stepan Mishura <st...@gmail.com>.
On 4/21/06, Anton Avtamonov wrote:
>
> On 4/21/06, Stepan Mishura wrote:
> <SNIP>
> > > > Creating and maintaining these (accessor/strings) is trivial in the
> > > > Eclipse string externalization tool.
> > >
> > > Right.
> >
> >
> > And what about developers that don't use Eclipse?
>
> They can create an accessor manually. Eclipse just helps to generate
> it, no more.
> Do you mean "how too keep them in the same format"?
If it is used just to generate then don't see any problem here.
Thanks,
Stepan.
--
> Anton Avtamonov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/21/06, Stepan Mishura <st...@gmail.com> wrote:
<SNIP>
> > > Creating and maintaining these (accessor/strings) is trivial in the
> > > Eclipse string externalization tool.
> >
> > Right.
>
>
> And what about developers that don't use Eclipse?
They can create an accessor manually. Eclipse just helps to generate
it, no more.
Do you mean "how too keep them in the same format"?
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
<snip>
> And what about developers that don't use Eclipse?
The code that Eclipse produces is pretty much what you would do by hand
anyway IMHO. In any case, we can create the accessors in Eclipse and
commit them for everyone to use, then the other folk just have to worry
about the message catalogs (just follow the convention).
There is nothing Eclipse-specific in these files. The only Eclipse-isms
appear in the source code, where the tool will add a $NON-NLS-1$ token
in a comment to tell the tool that the string on that line is not to be
externalized.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Stepan Mishura <st...@gmail.com>.
On 4/21/06, Anton Avtamonov wrote:
>
> On 4/21/06, Tim Ellison <t....@gmail.com> wrote:
> >
> > Mikhail Loenko wrote:
> > > 2006/4/21, Tim Ellison <t....@gmail.com>:
> > >> Mikhail Loenko wrote:
> > >>> Well, the reason is we did not discuss the topic here
> > >> Sure. What would you like to discuss?
> > >
> > > 1. Do we put all the messages into one file or per-module?
> >
> > I'd prefer one catalog per module now that we have the code split up.
> > The risk is that there will be large duplication of common messages, but
> > let's see, they should stand alone.
>
> Definitely. I think that keeping them serarately increases modularization.
>
> > If we do split them up then I guess it makes sense to put the accessor
> > class and properties files into org.apache.harmony.<component>.internal?
>
> +1
>
> > Creating and maintaining these (accessor/strings) is trivial in the
> > Eclipse string externalization tool.
>
> Right.
And what about developers that don't use Eclipse?
Thanks,
Stepan.
>
> > > 2. When I tried to internationalize it with Eclipse it suggested me
> > > keys looking
> > > different way (something like "RandomAccessFile.1"). So what are the
> keys that
> > > are liked by most of the people?
> >
> > I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
>
> I'm not sure. Module name IMHO doesn't make too much sense since it is
> already 'coded' into accessor location and class location. I would
> prefer <class_name>.<message intention> like
> RandomAccessFile.file_is_closed
> or something similar which keeps the idea of what the message is about.
>
> That requires a bit more efforts but makes the code understandable.
>
>
> Wishes,
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/21/06, Tim Ellison <t....@gmail.com> wrote:
> Anton Avtamonov wrote:
> > On 4/21/06, Tim Ellison <t....@gmail.com> wrote:
> <snip>
> >> I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
> >
> > I'm not sure. Module name IMHO doesn't make too much sense since it is
> > already 'coded' into accessor location and class location. I would
> > prefer <class_name>.<message intention> like
> > RandomAccessFile.file_is_closed
> > or something similar which keeps the idea of what the message is about.
> >
> > That requires a bit more efforts but makes the code understandable.
>
> I'd be inclined to agree, but using long key String turned out to be one
> of the top Eclipse performance bloopers [1] so we actually need to keep
> them short.
Ok, I cautch it. But I didn't propose long keys, just
intention-revealing. They should be definitely no longer then usual
fields/methods names.
Besides, I suppose classlib is ususally quite silent :-). The majority
of messages we need are exceptions, right? I remember our
investigation - exception itself (trace calculation) takes too much;
String impact will be eliminated :-)
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Tim Ellison <t....@gmail.com>.
Anton Avtamonov wrote:
> On 4/21/06, Tim Ellison <t....@gmail.com> wrote:
<snip>
>> I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
>
> I'm not sure. Module name IMHO doesn't make too much sense since it is
> already 'coded' into accessor location and class location. I would
> prefer <class_name>.<message intention> like
> RandomAccessFile.file_is_closed
> or something similar which keeps the idea of what the message is about.
>
> That requires a bit more efforts but makes the code understandable.
I'd be inclined to agree, but using long key String turned out to be one
of the top Eclipse performance bloopers [1] so we actually need to keep
them short.
[1] http://www.eclipse.org/eclipse/development/performance/bloopers.html
(page down to "Message catalog keys")
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/21/06, Mikhail Loenko <ml...@gmail.com> wrote:
<SNIP>
> > I'm not sure. Module name IMHO doesn't make too much sense since it is
> > already 'coded' into accessor location and class location. I would
> > prefer <class_name>.<message intention> like
> > RandomAccessFile.file_is_closed
> > or something similar which keeps the idea of what the message is about.
>
> That would create more duplication like
>
> File.file_is_closed
> RandomAccessFile.file_is_closed
Agree. That's why I said 'something similar' :-)
For this particular case I would keep just
File.file_is_closed
and used it everywhere.
Prefix, IMHO is required just to split functional areas within a
module. It can be class name, but can also be some generalized
'functionality' name like Dialogs.ok_button
The main idea I'm trying to express is that:
- when looking into properties file it should be clear how (where)
each key is used just from its name
- when looking into the code should be clear the idea of the message
behind the key.
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/4/21, Anton Avtamonov <an...@gmail.com>:
> On 4/21/06, Tim Ellison <t....@gmail.com> wrote:
> >
> > Mikhail Loenko wrote:
> > > 2006/4/21, Tim Ellison <t....@gmail.com>:
> > >> Mikhail Loenko wrote:
> > >>> Well, the reason is we did not discuss the topic here
> > >> Sure. What would you like to discuss?
> > >
> > > 1. Do we put all the messages into one file or per-module?
> >
> > I'd prefer one catalog per module now that we have the code split up.
> > The risk is that there will be large duplication of common messages, but
> > let's see, they should stand alone.
>
> Definitely. I think that keeping them serarately increases modularization.
>
> > If we do split them up then I guess it makes sense to put the accessor
> > class and properties files into org.apache.harmony.<component>.internal?
>
> +1
>
> > Creating and maintaining these (accessor/strings) is trivial in the
> > Eclipse string externalization tool.
>
> Right.
>
> >
> > > 2. When I tried to internationalize it with Eclipse it suggested me
> > > keys looking
> > > different way (something like "RandomAccessFile.1"). So what are the keys that
> > > are liked by most of the people?
> >
> > I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
>
> I'm not sure. Module name IMHO doesn't make too much sense since it is
> already 'coded' into accessor location and class location. I would
> prefer <class_name>.<message intention> like
> RandomAccessFile.file_is_closed
> or something similar which keeps the idea of what the message is about.
That would create more duplication like
File.file_is_closed
RandomAccessFile.file_is_closed
...
Thanks,
Mikhail
>
> That requires a bit more efforts but makes the code understandable.
>
>
> Wishes,
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/21/06, Tim Ellison <t....@gmail.com> wrote:
>
> Mikhail Loenko wrote:
> > 2006/4/21, Tim Ellison <t....@gmail.com>:
> >> Mikhail Loenko wrote:
> >>> Well, the reason is we did not discuss the topic here
> >> Sure. What would you like to discuss?
> >
> > 1. Do we put all the messages into one file or per-module?
>
> I'd prefer one catalog per module now that we have the code split up.
> The risk is that there will be large duplication of common messages, but
> let's see, they should stand alone.
Definitely. I think that keeping them serarately increases modularization.
> If we do split them up then I guess it makes sense to put the accessor
> class and properties files into org.apache.harmony.<component>.internal?
+1
> Creating and maintaining these (accessor/strings) is trivial in the
> Eclipse string externalization tool.
Right.
>
> > 2. When I tried to internationalize it with Eclipse it suggested me
> > keys looking
> > different way (something like "RandomAccessFile.1"). So what are the keys that
> > are liked by most of the people?
>
> I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
I'm not sure. Module name IMHO doesn't make too much sense since it is
already 'coded' into accessor location and class location. I would
prefer <class_name>.<message intention> like
RandomAccessFile.file_is_closed
or something similar which keeps the idea of what the message is about.
That requires a bit more efforts but makes the code understandable.
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Mikhail Loenko wrote:
>> 2006/4/21, Tim Ellison <t....@gmail.com>:
>>> Mikhail Loenko wrote:
>>>> Well, the reason is we did not discuss the topic here
>>> Sure. What would you like to discuss?
>> 1. Do we put all the messages into one file or per-module?
>
> I'd prefer one catalog per module now that we have the code split up.
> The risk is that there will be large duplication of common messages, but
> let's see, they should stand alone.
For now, couldn't we go this route, and at some point as things
stabilize, if duplication gets to be a real problem, extract all that is
common and share?
>
> If we do split them up then I guess it makes sense to put the accessor
> class and properties files into org.apache.harmony.<component>.internal?
>
> Creating and maintaining these (accessor/strings) is trivial in the
> Eclipse string externalization tool.
>
>> 2. When I tried to internationalize it with Eclipse it suggested me
>> keys looking
>> different way (something like "RandomAccessFile.1"). So what are the keys that
>> are liked by most of the people?
>
> I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
+1
(and I'll grumble about the o.a.h.<c>.internal later)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> 2006/4/21, Tim Ellison <t....@gmail.com>:
>> Mikhail Loenko wrote:
>>> Well, the reason is we did not discuss the topic here
>> Sure. What would you like to discuss?
>
> 1. Do we put all the messages into one file or per-module?
I'd prefer one catalog per module now that we have the code split up.
The risk is that there will be large duplication of common messages, but
let's see, they should stand alone.
If we do split them up then I guess it makes sense to put the accessor
class and properties files into org.apache.harmony.<component>.internal?
Creating and maintaining these (accessor/strings) is trivial in the
Eclipse string externalization tool.
> 2. When I tried to internationalize it with Eclipse it suggested me
> keys looking
> different way (something like "RandomAccessFile.1"). So what are the keys that
> are liked by most of the people?
I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/4/21, Tim Ellison <t....@gmail.com>:
> Mikhail Loenko wrote:
> > Well, the reason is we did not discuss the topic here
>
> Sure. What would you like to discuss?
1. Do we put all the messages into one file or per-module?
2. When I tried to internationalize it with Eclipse it suggested me
keys looking
different way (something like "RandomAccessFile.1"). So what are the keys that
are liked by most of the people?
>
> > 2006/4/20, Tim Ellison <t....@gmail.com>:
> >> Is there some reason why you are not using the message catalog for these
> >> exception messages like we do for others? These are intended to be read
> >> by users so we want them to the NLS-enabled.
> >>
> >> Take a look at Msg.java and ExternalMessages.properties in
> >> org.apache.harmony.luni.util.
> >
> > Sure I will. Do they work right now? I've saw test failures with
> > messages like "K000"
>
> They should be working -- if not please fix it (or raise an issue as a
Ok, if I see that odd message again, I'll fix it.
Thanks,
Mikhail
> reminder that it should be fixed).
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> Well, the reason is we did not discuss the topic here
Sure. What would you like to discuss?
> 2006/4/20, Tim Ellison <t....@gmail.com>:
>> Is there some reason why you are not using the message catalog for these
>> exception messages like we do for others? These are intended to be read
>> by users so we want them to the NLS-enabled.
>>
>> Take a look at Msg.java and ExternalMessages.properties in
>> org.apache.harmony.luni.util.
>
> Sure I will. Do they work right now? I've saw test failures with
> messages like "K000"
They should be working -- if not please fix it (or raise an issue as a
reminder that it should be fixed).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Internationalized messages (was: Re: svn commit: r395576 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java)
Posted by Mikhail Loenko <ml...@gmail.com>.
Well, the reason is we did not discuss the topic here
2006/4/20, Tim Ellison <t....@gmail.com>:
> Is there some reason why you are not using the message catalog for these
> exception messages like we do for others? These are intended to be read
> by users so we want them to the NLS-enabled.
>
> Take a look at Msg.java and ExternalMessages.properties in
> org.apache.harmony.luni.util.
Sure I will. Do they work right now? I've saw test failures with
messages like "K000"
Thanks,
Mikhail
>
> There are examples of their usage in the source file you modified.
>
> Regards,
> Tim
>
> mloenko@apache.org wrote:
> > Author: mloenko
> > Date: Thu Apr 20 05:46:47 2006
> > New Revision: 395576
> >
> > URL: http://svn.apache.org/viewcvs?rev=395576&view=rev
> > Log:
> > fixes for HARMONY-374
> > java.io.RandomAccessFile.seek(int pos) does not throw IOException if pos < 0
> >
> > Modified:
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> >
> > Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> > URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java?rev=395576&r1=395575&r2=395576&view=diff
> > ==============================================================================
> > --- incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java (original)
> > +++ incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java Thu Apr 20 05:46:47 2006
> > @@ -614,6 +614,9 @@
> > * occurs.
> > */
> > public void seek(long pos) throws IOException {
> > + if (pos < 0) {
> > + throw new IOException("seek position is negative");
> > + }
> > openCheck();
> > synchronized (repositionLock) {
> > fileSystem.seek(fd.descriptor, pos, IFileSystem.SEEK_SET);
> >
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Internationalized messages (was: Re: svn commit: r395576 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java)
Posted by Tim Ellison <t....@gmail.com>.
Is there some reason why you are not using the message catalog for these
exception messages like we do for others? These are intended to be read
by users so we want them to the NLS-enabled.
Take a look at Msg.java and ExternalMessages.properties in
org.apache.harmony.luni.util.
There are examples of their usage in the source file you modified.
Regards,
Tim
mloenko@apache.org wrote:
> Author: mloenko
> Date: Thu Apr 20 05:46:47 2006
> New Revision: 395576
>
> URL: http://svn.apache.org/viewcvs?rev=395576&view=rev
> Log:
> fixes for HARMONY-374
> java.io.RandomAccessFile.seek(int pos) does not throw IOException if pos < 0
>
> Modified:
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
>
> Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java?rev=395576&r1=395575&r2=395576&view=diff
> ==============================================================================
> --- incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java (original)
> +++ incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java Thu Apr 20 05:46:47 2006
> @@ -614,6 +614,9 @@
> * occurs.
> */
> public void seek(long pos) throws IOException {
> + if (pos < 0) {
> + throw new IOException("seek position is negative");
> + }
> openCheck();
> synchronized (repositionLock) {
> fileSystem.seek(fd.descriptor, pos, IFileSystem.SEEK_SET);
>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org