Letters to the Editor
JavaWorld.com, 06/27/03
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
Wireless Java
"High-Availability Mobile Applications"
Michael J. Yuan
Why the omission of SQL Server CE?
Michael,
I enjoyed your article, especially the section that focuses on the database choices for a mobile application. I am wondering,
however, why you left out Microsoft's SQL Server CE? I have been using this database for a mobile sales application for many
months now, and it works nicely. I have not tested it using a JDBC (Java Database Connectivity) connection yet, as I am using
.Net C#. I am, however, a Java programmer from way back and am curious as to your input on whether or not SQL Server CE would
be a viable solution for a mobile application that requires a database. Do I see a wrapper in my future?
FR
FR, SQL Server CE does not provide a J2ME (Java 2 Platform, Micro Edition) API. So I did not cover it in my article. However,
if you use the .Net Compact Framework for PDA development, SQL Server CE is an excellent choice: ADO.Net (Active Data Objects)
support and full VS.Net (Visual Studio) integration. Michael Yuan
Wireless Java
"Let the Mobile Games Begin"
Part 1: A comparison of the philosophies, approaches, and features of J2ME and the upcoming .Net Compact Framework
Part 2: J2ME and .Net Compact Framework in action
Michael Juntao Yuan
Why not use MapServer instead of MapPoint?
Michael,
You should take a look at MapServer (http://mapserver.gis.umn.edu/). It works with ESRI (Environmental Systems Research Institute) shapefiles as well as a multitude of other mapping things.
It is open source and has been around for a while. It is also very fast. There is already a Java client for it, which works
as an applet; it is open source as well.
Scott Carr
Scott, Yes, the open source MapServer does look interesting. But for my article, I was not looking for a generic GIS (geographic
information system) server—I was looking for a managed solution preloaded with high-resolution and copyrighted maps so I could
focus on the middle and UI (user interface) layers. That was why I chose a product from the dark side (Microsoft's MapPoint)!
Michael Yuan
"J2ME Devices: Real-World Performance"
Wang Yi, C.J. Reddy, and Gavin Ang
Can you test integer operations in J2ME?
Wang Yi, C.J. Reddy, Gavin Ang
I am a consultant currently exploring the J2ME (Java 2 Platform, Micro Edition) benchmark standards. I used to come across
many clearly specified benchmark standards for JVM. But, as far as KVM is concerned, it is hard to find any such articles.
Thus, it is great to see your article on J2ME performance benchmarks. However, I still need some clarifications:
- You provided some benchmark applications like JKernalMark, which tests some specific categories like string operations (concatenation/substring).
Since there are other classes, like integers, in MIDP (Mobile Information Device Profile) documentation, why did you test
only string operations?
- Should I do the same tests with integer operations?
- Are there any predefined benchmark standards for J2ME?
Anbukannan
Anbukannan, Regarding your first question: string operations could become much more resource-consumed in small devices (like
J2ME handphones) as compared to integer or long operations, especially for those programmers not familiar with Java. Question
2: Yes, you can complete the same tests with integer operations. However, you'd better provide reasons for doing the tests
first. That is, what's the purpose of testing integer operations? If you are building an application using many integer operations,
it would be more reasonable to benchmark those operations. Many benchmarks (for J2SE (Java 2 Platform, Standard Edition)/J2ME)
will test string operations but not integer operations, for the above reason that I mentioned. Question 3: I don't think any
benchmark standards for J2ME exist currently. But as you do some surfing/researching, you might find that most micro benchmarks
have some common test areas and even test procedures. Wang Yi
Java Q&A
"Cracking Java Byte-Code Encryption"
Vladimir Roubtsov
Is native compilation a viable choice for protecting Java code?
Vladimir,
Do you consider static compilation to native code a viable alternative for Java code protection, especially if used with method
name overloading?
Dmitry
Dmitry, I consider native compilation a viable way of doing Java development, period. As a side effect, it also solves the
code protection issue. However, most people concerned with protecting their Java code also happen to use Java for its .class platform independence. Switching to a native compiler means giving up this simplicity and requires maintaining multiple product
builds for several target platforms. This would be unacceptable to many software organizations at the moment. Vladimir
"All That JAAS"
John Musser and Paul Feuer
Help needed with LoginModule
John Musser, Paul Feuer
I have a question regarding writing LoginModule. Is it necessary to pass a CallbackHandler object to the LoginContext constructor for sending the user's username and password to LoginModule for authenticating Web-based apps?
The LoginContext class provides a constructor that takes in a Subject as a parameter. So I can take the username and password from JSP (JavaServer Pages), create a Subject using these values, and pass it to LoginModule through LoginContext. In LoginModule's login() method, I can retrieve the values from Subject and authenticate the user (in whatever way).
This approach will not use CallbackHandler anywhere. Is this still a valid approach? If valid, is it a good approach and should it be followed? If not, what is the
use of the LoginContext constructor with Subject as a parameter?
Chandar
Chandar, While it is certainly possible to pass your authentication data that way, we don't recommend it. In fact, as we were
deciding to choose JAAS (Java Authentication and Authorization Service), we used a similar approach, but, after looking into
the matter very intensely, we found documentation and guidelines that contradict that method. I can't seem to find it now,
but I believe somewhere in the JAAS documentation, there is some discussion of
LoginModule's purpose and its relation to the
Subject. If I recall correctly, the
LoginContext constructor that includes the
Subject argument is meant solely for attempting to update an already authenticated
Subject with new credentials and new principals. In looking again at the documentation, while I couldn't find the explicit reference,
I did see this implication in the API documentation for
LoginContext.getSubject(). The
@return comment there says:
...the authenticated Subject. If authentication fails and a Subject was not provided to this LoginContext's constructor, this method returns null. Otherwise, this method returns the provided Subject.
With the approach you suggest, this method would actually return to you a
Subject that is, in effect, unauthenticated. It is really the
LoginContext's role to manage the creation of a new
Subject and return it if it passes the authentication by the
LoginModules. Looking also at Sun Microsystems'
LoginModule implementations, such as
com.sun.security.auth.module.JndiLoginModule, you can see that the better place for the username and password is in the shared state
Map. After all, the username and password authentication information are not really credentials, that is, badges granted by some
official service. The
JndiLoginModule's source code shows that, if instructed by its options
Map, it will look in the shared state for username and password information under the keys
javax.security.auth.login.name and
javax.security.auth.login.password. The approach we recommended also reflects the use of the
Callback objects as articulated in the API, specifically the
NameCallback and
PasswordCallback. Getting back to the
getSubject() method, if you had instantiated your
Subject and added username and password as credentials, the
Subject returned from
getSubject() would have these credentials with it, even though they may have failed to authenticate the user. Similarly, if you had instantiated
your
Subject and used the username and password to create a
Principal, your
Subject returned from
getSubject() will contain this
Principal, which may not have actually been authenticated. We believe the API reinforces the approach we outlined, and our approach
and the API together help to inform the programmer's understanding of these relationships. It's hard enough keeping track
of the interaction among all these classes, and I think you'll find that if you leave the credentials and principals solely
to the relevant
LoginModules, your approach will be cleaner, more straightforward, and less idiosyncratic. Paul Feuer and John Musser
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone