Enumset

[Roedy Green]

I was thinking of writing some JNI to access the Windows file
attributes. On the Java side this would be an EnumSet. On the Windows
side it would be a bitmap. Are there are any fast ways to
interconvert?

 

[Daniel Pitts]

I was thinking of writing some JNI to access the Windows file
attributes. On the Java side this would be an EnumSet. On the Windows
side it would be a bitmap. Are there are any fast ways to
interconvert?

Fast, as in optimal, or Fast as in, takes less than 5 minutes to
create?

I don't know much about JNI, but I think my approach would be have
this method be private, and simply return the bitmap value (in a int
value, or is possible, a BitSet). Then convert it to a BitSet. Have
the enums declared in the order that the BitSet reports the bits, and
use bitSet.nextSet() (I think thats the name) to determine the ordinal
of the enum you want to add to the EnumSet.

So, in other words, the conversion would be done on the Java side, and
you don't need to worry about performance until you find it to be a
bottleneck.

 

[Roedy Green]

So, in other words, the conversion would be done on the Java side, and
you don't need to worry about performance until you find it to be a
bottleneck.

When you write a library routine, you want it fast since others may
use it in many contexts, including examining the attributes of every
file on disk.

It is frustrating knowing that EnumSat has a bitmask inside, which is
just what I want to get or give. I have asked Sun for a getBitMask
method.

To give someone a get/put of Windows file attributes, it will have to
construct the Enumset bit by bit.

 

[Roedy Green]

To give someone a get/put of Windows file attributes, it will have to
construct the Enumset bit by bit.

Perhaps I can cache some of the most common patterns.

 

[Christian]

Perhaps I can cache some of the most common patterns.

Why do you wan't to use EnumSet?
it does not define more methods than the set interface.
So you could just use a normal set. Create it by copy paste the
sourcecode of RegularEnumSet and add a method to directly access the
bitmap. Where is the problem? Forceing it to be of instance EnumSet
seems just to make your work harder without any positive effect.

Christian

 

[Roedy Green]

So you could just use a normal set. Create it by copy paste the
sourcecode of RegularEnumSet and add a method to directly access the
bitmap. Where is the problem? Forceing it to be of instance EnumSet
seems just to make your work harder without any positive effect.

four reasons:

1. your code-cloning approach would work fine for in-house, but would
not be legal for free distribution.

2. I write most of my code with the intent they be teaching examples.
I like to do demonstrate the use of standard classes.

3. People seem to have forgotten the art of boolean logic with
bitmaps. EnumSet encapsulates it at a higher level.

4. With an EnumSet rather than named bit mask constants I have type
safety. I think all I would need is an int bitmap for a roll-your-own
sit of bit map constants. This is an objection to just handing over a
raw int bitmap to represent the attributes.

 

[Zig]

Perhaps I can cache some of the most common patterns.

IIRC, any JNI library may request and use another classes private
variables. So, if you are using EnumSet, it should be safe for your JNI
code to assume that it is using an instance of java.util.RegularEnumSet,
with a jlong named "elements", and twiddle with it all you like.

This does require a few constraints: Your enums must be aligned such that
1 << enum ordinal == Windows bitmask from WinNT.h, so it means you'll
probably have to stuff your Enum with some RESERVED/PLACEHOLDER Enums to
fill in between undeclared gaps, like:

#define FILE_ATTRIBUTE_SYSTEM 0x00000004
#define FILE_ATTRIBUTE_DIRECTORY 0x00000010

Also, assuming your code would allow setting attributes, then it would
need to either enforce the use of EnumSet as a parameter, or if it allows
just Set, it would have to provide an alternate mechanism for setting
attributes if the user is not using an EnumSet (ala
Collections.synchronizedSet, or HashSet). And, as long as you provide an
alternate method, then you can fail gracefully for the oddball cases, like
GNU classpath, which could set up the classes entirely differently.

HTH,

-Zig

 

[Christian]

four reasons:

1. your code-cloning approach would work fine for in-house, but would
not be legal for free distribution.

I don't know the license under with java is .. I just assumed copying
would be legal..

2. I write most of my code with the intent they be teaching examples.
I like to do demonstrate the use of standard classes.

I do just think in this case you are enforceing a standard class because
you want it not because it would be reasonable to use it.

3. People seem to have forgotten the art of boolean logic with
bitmaps. EnumSet encapsulates it at a higher level.

again no hindrance to roll your own enum set..

4. With an EnumSet rather than named bit mask constants I have type
safety. I think all I would need is an int bitmap for a roll-your-own
sit of bit map constants. This is an objection to just handing over a
raw int bitmap to represent the attributes.

with your own self created kind of set you have type safety too
(besides the possibility to
simply add some boolean setters like setArchived(boolean archieved);

I would never never advertise the use of a plain int..
Though I am also assumeing that you are overuseing enums here..
If I wanted to manipulate and read out File attributes.. I would be
happy with just one class that wraps jni. with the possibility to
ask for each attribute with setters and getters.. and if you want to use
Enums then some method like set(FileAttributeEnum e, boolean enabled);
would be most useful to me ...
the retrieval of an EnumSet would be one of the last methods that would
really often be in use.. and there you then have imho 2 possibilitys..
either use the Set interface and implement it like RegularEnumSet
or use reflections to change the bitmap of RegularEnumSet directly.
Though I would rather recommend the first one. Reuse of api classes yes
but not if they don't fit or would foce me to resort to such kind of
reflection work..
and as you have a very special need (high speed by directly manipulating
the bitmap) well EnumSet doesn't fit..


Christian

 

[Roedy Green]

I do just think in this case you are enforceing a standard class because
you want it not because it would be reasonable to use it.

It is certainly preferable from a teaching point of view to show how
to use a standard class than to do something tricky and confusing --
showing them the entire innards of Enumset.

It is also preferable from a maintenance point of view. If Sun
changes the innards of Enumset, the cloned code won't automatically
follow suit.

If I want some speed, I may have no other option, or write a Stripped
down EnumSt what has just an int instead of long[] with some of the
Enumset methods removed, since I am interested in only one particular
EnumSet.

 

[Roedy Green]

If I want some speed, I may have no other option, or write a Stripped
down EnumSt what has just an int instead of long[] with some of the
Enumset methods removed, since I am interested in only one particular
EnumSet.

The other option is to provide a classic bitmap interface, rather than
an EnumSet for my Windows attribute get/setter.

 

[Lasse Reichstein Nielsen]

The other option is to provide a classic bitmap interface, rather than
an EnumSet for my Windows attribute get/setter.

Another option is to encapsulate the data and just provide methods, e.g.,
boolean isArchived()
boolean isReadOnly()
boolean isDirectory()
boolean isHidden()
etc.
The fact that these are in some ways stored in a number is an implementation
detail that need not be exposed.

If you really want an enum representing capabilities, you can make
one that works on these:
enum FileCapability {
CAN_READ {
public boolean isAllowed(RGFile file) {
return file.isAllowed();
}
},
// ...
;
public abstract boolean isAllowed(RGFile file);
}

You can the build an EnumSet only when you need it for something, using
EnumSet<FileCapability> getCapabilties();
You can cache it in a transient field to avoid recreating.

/L